AutoPatch beta (~ for 3.12.0)

[frostschutz]

Well, based on this 3.12 patch discussion, here's a prototype for the Kobo patching itself using patch files you copy to the reader.

This is an early beta, there may be bugs, it may brick your reader...

Currently it only runs at startup (1-2 minutes after the device finished booting into nickel), sees if there's anything to patch, in which case it does that and reboots. While you'll notice the reboot, there is no visual feedback of any kind.

The patches are stored in a hidden dir .autopatch; you can use one big file or split them up into multiple patch files. You can disable individual patches either by editing them to `no` or moving them to a subdir like disabled/. Patches that fail to apply will be moved to failed/ subdir and the output of the patch32lsb program added so you have a clue as to what may have gone wrong.

https://github.com/frostschutz/Kobo

AutoPatch - beta 1
------------------

This mod allows the Kobo to patch itself, using patch files stored
in a hidden .autopatch directory. The patches will be applied when
the device boots.

Currently, it patches only three files:

libadobe.so, libnickel.so.1.0.0, librmsdk.so.1.0.0

For each file you may use multiple patch files (patch32lsb format):

libadobe.so*.patch, libnickel.so.1.0.0*.patch, librmsdk.so.1.0.0*.patch

If a patch fails to apply, it will be moved to the failed/ subdir along
with a logfile that shows the output of the patch32lsb program.

If you want to disable a patch, you can either edit it and set it to `no`,
or you can move the patch file itself to the disabled/ subdir.

In order to uninstall this mod, create an empty file 'uninstall'
(no extension) in the hidden .autopatch directory and reboot.

Actually, this isn't quite what I had in mind In the future it could be improved to allow patching any file, and patches independent of firmware versions (in case it's a string replacement, and the string is unique).

Edit: beta3 released

Edit: Project discontinued. To uninstall, create a .autopatch/uninstall file

[frostschutz]

Not much feedback so far... any thoughts? Any point developing this any further?

[Ripplinger]

Actually, I'm not sure exactly what this does or how it makes GeoffR's patch any easier. What can it automate when you need to manually select yes/no for each patch, and even change numbers to your liking in some of the patches? I guess I'm not seeing how any of that can be automated.

[GeoffR]

Sorry I haven't go to testing this yet. I don't have any experience with cross-compiling to run on Kobo devices, do you have a patch32lsb executable available? Edit: I was looking at the github ink and missed the attachment.

What happens when the firmware is updated, does the autopatcher need to be re-installed?

Does it handle the situation where a firmware update only changes some files and not others? For example the librmsdk.so.1.0.0 is sometimes identical from one firmware version to the next.

From what I understand the device needs to reboot twice after changing a patch to install the new patch?

There are some definate advantages to doing it this way: you don't need to run the patching program (kpg.exe or patch32lsb) on an external computer, and the files to be patched are taken directly from the device instead of extracted from a downloaded firmware archive.

For those already used to patching from an external computer there probably isn't any incentive to switch to this method, but perhaps those who haven't patched before will find this method easier.

[frostschutz]

Originally Posted by Ripplinger

I guess I'm not seeing how any of that can be automated.

Maybe the name is poorly chosen; it's not supposed to automate the editing of patches at all, that part will always have to be done manually I guess. It just performs the patching itself, given the patchfiles. So it only replaces the step that's currently done on the computer (downloading firmware, executing some script, putting the resulting KoboRoot.tgz on the reader).

Originally Posted by GeoffR

What happens when the firmware is updated, does the autopatcher need to be re-installed?

No; it currently only adds files to the firmware, without modifying any existing ones, so nothing is overwritten by an update. Until you do a factory reset...

Originally Posted by GeoffR

Does it handle the situation where a firmware update only changes some files and not others?

It uses checksums to keep track of things. It will try to (re)apply patches whenever the checksum (of either files or patches) changes. If someone uses KoboRoot.tgz to replace only one file, then it would be patched again.

Originally Posted by GeoffR

From what I understand the device needs to reboot twice after changing a patch to install the new patch?

Yes, but only because it's not hooked into USB yet. The final version should react to changed patchfiles the same way it does to putting KoboRoot.tgz on it and patch/reboot the device only once.

Originally Posted by GeoffR

For those already used to patching from an external computer there probably isn't any incentive to switch to this method, but perhaps those who haven't patched before will find this method easier.

It also opens up to new possibilities, like a patch [Yes/No] selection screen on the device itself. (Although that's beyond my ability at this point)

It already supports several patch files, so if you were to split the one big file into individual ones, you'd no longer have to edit just for [Yes/No], you could just move the ones you don't want into the disabled dir.

I still want to add support for patches that work for any firmware version as long as its unique signature can be found; so while a string may be at a different address in each firmware version, as long as it's the same string and unique the patch should still work.

[GeoffR]

Originally Posted by frostschutz

It uses checksums to keep track of things. It will try to (re)apply patches whenever the checksum (of either files or patches) changes. If someone uses KoboRoot.tgz to replace only one file, then it would be patched again.

So if the firmware updated automatically but librmsdk.so.1.0.0 didn't change, then the device would reboot again after the new firmware installed just to patch librmsdk.so.1.0.0? (the other patches would fail). Maybe an all-or-nothing option would be useful, so no patched files are installed unless all the patches succeed.

I still want to add support for patches that work for any firmware version as long as its unique signature can be found; so while a string may be at a different address in each firmware version, as long as it's the same string and unique the patch should still work.

I've added this sort of capability in patch32lsb v0.9, a version for testing posted here. (One of the fuctions needs to be made more efficient, but it should still produce correct results.) The idea should be workable for some patches that only modify data, but not for many of the ones that modify code, as often the code changes depending on its position relative to other code or data.

[frostschutz]

Originally Posted by GeoffR

Maybe an all-or-nothing option would be useful

It already treats each individual patch file as all-or-nothing; so if one patch depends on another patch, they should be in the same file; whereas independent patches can be split into separate files.

Originally Posted by GeoffR

The idea should be workable for some patches that only modify data, but not for many of the ones that modify code, as often the code changes depending on its position relative to other code or data.

Of course, in an all-or-nothing mode, the idea of making at least some of the patches version-independent, is kind of useless. A single address patch (or single change to a patched string) would then block all others.

I'll put your updated patch32lsb in the next beta, I'll also try to get the USB hook in place for that one.

[frostschutz]

AutoPatch beta3 uses the v0.10 patch32lsb and patch files (from here), and the same USB hook and nickel freeze I'm using in AutoShelf. It no longer reboots automatically, you'll have to do that at your convenience.

It doesn't seem to work well, though. patch32lsb says 'cannot parse line' for find_base_address. For that reason I won't attach it here, but you can get it from the GitHub releases page.

Edit: BAH. My mistake, I had another copy of old patch32lsb in the wrong path. So stupid

[boriar]

Is AutoPatch beta2 public?

[frostschutz]

beta2 was a mistake, so it's beta3... it's attached to the first post

[boriar]

I have some doubts:
If i want to patch the files where i put *.patch files?
If i put *.patch in disable/ the program disable the patch independent of the yes/no switch?
When the patch is applied the files remain in the same directory or it is move to avoid be repatched the next time?
I want to be all clarified before install it because at the moment i have the file patch with GeoffR's program but i want to be able to activate/deactivate within nickel.

Edit: Is there some date to the next beta?

[frostschutz]

where i put *.patch files?

The patch files go into the .autopatch folder. You can have several of them, as described in the first post. E.g. libnickel.so.1.0.0-something.patch and libnickel.so.1.0.0-other.patch. In theory you could give each independent patch its own file and just move the ones you don't want to disabled/.

If i put *.patch in disable/ the program disable the patch independent of the yes/no switch?

Yes, it will act as if the patch wasn't even there. You could just as well delete a patch file you don't want - but moving it instead gives you the ability to move it back at a later time.

When the patch is applied the files remain in the same directory or it is move to avoid be repatched the next time?

Repatching is avoided by remembering the input and result of the last patch run. If you modify any of the patch files, they will be reapplied.

Edit: Is there some date to the next beta?

Right now I have a slight motivation problem with this mod; 1) there seems to be little interest/feedback, i.e. people seem to be happy patching externally as it were; 2) while I did a lot of patching on my last reader, I find I need considerably less patching than expected on the Kobo after all.

So right now I'm not sure if / when I'll find the time / motivation to make a new beta.

[pipcat]

I want to test AutoPatch with KHD downloads, but I don't know so much about linux internals and I have some questions...

- You included patch32lsb.c but not the executable. We need to compile it for kobo devices with specific parameters or we can use a binary from Metazoa pack?

- Can you explain autopatch.rules ?
KERNEL=="fsl-usb2-udc" (autopatch and autoshelf)
ACTION=="remove" (autopatch)
SUBSYSTEM=="drivers" (autoshelf)

- suspend_nickel() and resume_nickel(). How did you find that ? ;-)

- To process KHD downloads, in autopatch.sh, before cd "$AUTOPATCH" line, maybe this will be enough:

# If there are downloaded patches from KHD extract them
DOWNLOADED_ZIP="download.php"
if [ -f /mnt/onboard/"$DOWNLOADED_ZIP" ]
then
	unzip -o /mnt/onboard/"$DOWNLOADED_ZIP" *.patch -d /mnt/onboard/.autopatch
	rm /mnt/onboard/"$DOWNLOADED_ZIP"
fi

[pipcat]

Still not tested, but I've prepared an AutoPatch Mod to be used with KHD.
I didn't find patch32lsb binary for arm in mobileread. Can somebody post it ?

Files: https://github.com/pipcat/kobo/tree/.../autopatch-khd
Readme:

Spoiler:

AutoPatchKHD
============

Mod of AutoPatch to be used with KHD website.

INSTALL:
--------
Create a KoboRoot.tgz with:
- /etc/udev/rules.d/autopatch-khd.rules
- /usr/local/AutopatchKHD/ patch32lsb, autopatch-khd.sh

If your device does not have the original binaries because you already patched them, include:
- /usr/local/Kobo/ libnickel.so.1.0.0-original libadobe.so-original librmsdk.so.1.0.0-original

USAGE:
------
AutoPatchKHD script is launched when device restarts.
If there is a download.php(.zip) in root folder it will be processed and deleted.

- With internet acces in Kobo device:
	- Open Kobo browser and go to http://pip.cat/khd/kobo 
	- Select a profile for your firmware and download.
	- You can create your own profiles registering at http://pip.cat/khd (not from Kobo device)

- Without internet, connecting with usb cable:
	- Create a .zip file with your .patch files or download it from KHD.
	- Copy to root of device with name download.php(.zip)
	
- After a download.php(.zip) is created, restart Kobo device to apply changes. Info will be at:
	- .autopatch-khd/logs : Log files with patching process messages.
	- .autopatch-khd/last : Last .patch files used to patch binaries.
	- .autopatch-khd/todo : Temporary folder, should be empty after process.

- To restore all original files:
	- Create an empty download.php(.zip) and restart device.

- To uninstall:
	- Create an empty file uninstall in .autopatch-khd folder and restart device.

INFO:
-----
- When AutoPatchKHD processes a zip file containing patches, all binaries (libnickel, libadobe and librmsdk) will be patched or restored.
- So zip file must always contains all patches to do. It's not intented to patch one by one.

- Example, with a zip containing only libnickel.so.1.0.0.patch
	- libnickel will be patched from original, and libadobe and librmsdk will be restored to original if they were modified.

ABOUT:
------
- AutoPatch is a tool created by frostschutz
https://github.com/frostschutz/Kobo

- patch32lsb is an open source program created by GeoffR, used by AutoPatch and Metazoa.

- Metazoa firmware patches are packs of hacks maintained by GeoffR
https://www.mobileread.com/forums/showthread.php?t=260100

- KHD (Kobo Hacks Database) is a website created and maintained by pipcat
http://pip.cat/khd

Other info:
-----------
- Writing udev rules: http://www.reactivated.net/writing_udev_rules.html

[frostschutz]

Originally Posted by pipcat

- You included patch32lsb.c but not the executable.

My arm-gcc is currently broken so I can't build a new one either at the moment