[geek1011]

Originally Posted by rtiangha

Would it be possible to get the updated value to change the Browse Kobo link on the home screen to access Beta Features instead for 4.19? And is it easy to find? If so, how? I feel silly for asking something so simple and I'm willing to do it myself but I don't know how; is there a tutorial or tool kit that makes things easier, or do I need a hex editor and what do I look for?

Yes. I'll do it within the next few days.

Originally Posted by Marco77

Hi @geek1011
Is the LD_PRELOAD trick the way you found to achieve that? It has the additional advantage you don't even have to write everything in assembly but also plain C.
OTOH, user code is only executed while hooking existing symbols, but there should be a workaround for that.

The assembly injection I was describing wasn't referring to that; it was referring to modifying the elf section headers and symbol tables. The LD_PRELOAD hack I made for the dotfiles thingy isn't the same as this (although LD_PRELOAD could be used to override certain libnickel functions).

This isn't what you're asking, but since we're discussing this, I'll also mention the other two things I'm considering. First, I'm considering expanding the assembler built in to kobopatch to more than BLX instructions (currently, I'm not working on this as it isn't worth the time for the current patches). Second, I'm looking (whenever I have the time/interest) into live patching libnickel using strace pokes. I'm also looking into live patching nickel CSS using a LD_PRELOAD hack on the qUncompress function (I'd check the address passed and patch it if necessary) or by directly modifying the GUI (I'd rather not do it this way, though).

My other question, since we're in developer's corner, what is the usual workflow when you create a new/custom patch? It has the risk of loop-crashing the nickel process, am I correct? Are there provisions to put back the device in workable state in such occurrences?

Can you for instance:

1. Enable remote access to the device (telnet/SSH, USBnet maybe) so that it automatically runs at device startup
2. tweak the libpath of whatever controls the .so load order, using a KoboRoot.tgz to a path controlled by the telnet/ssh user (supposedly, not root)
3. drop the modified .so's in that path
4. In case of emergency, delete the overriding .so either by SSHing into the device, or prying the device open, mount its microsd in a PC and remove the file from partition 3
   If things go awry, reflashing (what) via recovery? put vanilla update zip in .kobo? In worst case, reimage the microSD using a backup?

Usually, I have a pretty good idea of the risks involved with different types of patches. It really isn't anywhere near as scary as people make it if you are familiar with it. For most quick patches, I usually get it on the first or second try and just end up using the normal patching process on my Mini. Usually, the only safety I need is provided by enabling a lock screen and my USB storage without PIN patch. Note that nearly all patches can be reverted as long as you can do a full manual reset. For ones touching the home screen or anything in the boot process, I generally do a memory patch with GDB first, then if it continues to run, I actually apply the patch and test. For others, it really depends on the situation and my priorities regarding time, if I have data on the Kobo I want to keep, what the patch affects, and so on.

Originally Posted by NiLuJe

Once you have shell access (whatever method you're using, f.g., SSH (preferably over USBNet) or serial), you can also simply kill nickel, patch it manually, start it manually, and watch it harmlessly crash and burn since you're already in a shell.

Yes. Although, I've had quite a bit of trouble getting the environment set up right ... nickel is quite finicky to launch. You can also patch the memory directly using GCC.