kobopatch request thread

[rtiangha]

Originally Posted by geek1011

Yes, these ones are probably possible, as they have a bx pc before them and are compiled for tail-calling. I just need to check that they don't use r0, and figure out where I'll get the string from.

For a link to settings, try replacing the first replace value with F7 F6 19 B5. For the browser, try 1B F7 51 B1. For beta features, try 06 F7 CB B4. This is untested (I'm doing this from my phone) and doesn't include the string, but it should launch properly when you press it. The worst that will happen if this is wrong is that nickel will crash and reboot, and you'll need to disable the patch (or try a different replacement).

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?

[Marco77]

Originally Posted by ps67

Is it possible a patch to have indentation levels in index? I know that Kobo index is flatten by design and I don't know if that behavior can be changed with a patch, but if:

1) it is not too difficult (like hours of work);
2) it is funny for You to do the patch;
3) You have time to do it;

I would like to see how could appear a patched index.

Originally Posted by geek1011

Probably not at the moment, unless I end up writing a tool for injecting significant amounts of additional assembly (it would involve finding enough contiguous free space and possibly messing with the ELF table).

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.

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?

[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.

[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.

[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?

Here's the first replacement for beta features (4.19.14123): 05 F7 F5 B6.

And, see here: https://temp.s3.geek1011.net/kp-2019-12-24_19.04.23.mp4.

[BetaMaster]

Originally Posted by geek1011

Try this in libnickel for 4.19.14123:

Change Google search language:
  - Enabled: no
  - Description: Changes the language used for Google in the reader selection menu.
  # In WebSearchMixinBase::doGoogleSearch:
  # don't let the firmware override the hl parameter (NOP QUrlQuery::addQueryItem)
  - ReplaceBytesNOP: {Offset: 0x86EBAE, FindBLX: 0x4CE0B0}
  # hl = interface language
  # gl = primary search result country
  # See https://developers.google.com/custom-search/docs/xml_results_appendices#interfaceLanguages
  - FindReplaceString: {Find: "https://www.google.com/search?safe=active", Replace: "https://google.com/search?hl=en&gl=en"}

I won't be including this in the patch zip, though, unless there is more demand for it.

Many thanks for this patch!!! It helps me to find more specific results based on my country. I hope Kobo will implement real Google translate in the future.

[Dirk-71]

Wish: Bring back "advanced font control" for all fonts. In older versions of the firmware I could use this for ALL fonts. Now it appears only for some font-families and that's a pity. It was one of the settings that is unique for Kobo.

[JSWolf]

Originally Posted by Dirk-71

Wish: Bring back "advanced font control" for all fonts. In older versions of the firmware I could use this for ALL fonts. Now it appears only for some font-families and that's a pity. It was one of the settings that is unique for Kobo.

The patches for Advanced Font Control was for side loaded fonts was always for TTF and not OTF. So if any of your fonts are OTF, you'll have to convert them to TTF.

[Dirk-71]

Originally Posted by JSWolf

The patches for Advanced Font Control was for side loaded fonts was always for TTF and not OTF. So if any of your fonts are OTF, you'll have to convert them to TTF.

Ok, thank you for your help! I'll check that!

[skldmf]

Who wants me to do a overdrive enablement patch?

[jackie_w]

Originally Posted by skldmf

Who wants me to do a overdrive enablement patch?

No-one with any long-term common sense wants you to do that. It would royally p*ss-off Kobo because you'd be depriving them of potential sales of high-end devices. It's a short step from there to them deciding to devote their efforts to locking down the firmware. Everybody would lose.

If you have these technical skills why don't you do something more productive with them than you've managed in the last couple of days? Perhaps geek1011 has some backburner projects he could send your way.

[JSWolf]

Originally Posted by jackie_w

No-one with any long-term common sense wants you to do that. It would royally p*ss-off Kobo because you'd be depriving them of potential sales of high-end devices. It's a short step from there to them deciding to devote their efforts to locking down the firmware. Everybody would lose.

If you have these technical skills why don't you do something more productive with them than you've managed in the last couple of days? Perhaps geek1011 has some backburner projects he could send your way.

I'm not planning on buying a new Kobo any time soon. So if I didn't already have a good system in place for Overdrive, I might have said yes to the patch.

[geek1011]

Originally Posted by jackie_w

No-one with any long-term common sense wants you to do that. It would royally p*ss-off Kobo because you'd be depriving them of potential sales of high-end devices. It's a short step from there to them deciding to devote their efforts to locking down the firmware. Everybody would lose.

Yes, there's a reason why I haven't ever touched Dropbox or OverDrive in the patches, and don't even mention or respond to most requests.

If you have these technical skills why don't you do something more productive with them than you've managed in the last couple of days? Perhaps geek1011 has some backburner projects he could send your way.

I don't really have much right now except the overly complex/time-consuming ones in red in the first post (screenshots setting entry, inverted rotated options in menu, etc).

Although, if skldmf/anyone else knows how to write Go, kobopatch.patchlib does need quite a bit of refactoring, especially the zlib css minification and the unit tests (they're a gigantic mess because they were written as I was learning how the whole patching process works and as I was still working on the design of kobopatch). It's not currently a priority for me, as it works well enough as it is, it won't need much future updates (there's only so many different ways you can modify a binary), and it has enough test coverage.

[jackie_w]

Originally Posted by JSWolf

I'm not planning on buying a new Kobo any time soon. So if I didn't already have a good system in place for Overdrive, I might have said yes to the patch.

I'm sure many others would, too, but it's short-term thinking.

Isn't the main reason we like Kobos that they're so open, can be easily customised and made to work well with things like calibre? Why punish Kobo for allowing us to do this?

[NiLuJe]

FWIW, this is why mentions of tethering or Special Offers removal are a hard "no" rule in the Kindle Dev forum (and offenses are dealt with swiftly & harshly).

So, yeah, nope, not happening ;p.

(And, on a technical level, this is why, on the K4, where I haven't found a way to detect if the device is SO, KOReader will *NOT* override the system's screensaver. On newer devices, it will on non-SO devices, but will let the Kindle deal with it on its own (i.e., show SO screensavers) on SO devices).

TL;DR: Don't Be A Dick (TM), or everybody loses.