MobileRead Forums - View Single Post

Renate · 11-17-2022, 08:50 AM

So, acknowledging that updating is a universal problem, let's move on.

Surprisingly, in 1.5 GB of an Onyx update, not every single byte has changed! Big chunks of it stay the same although their relative position within a container has. It's very easy to come up with a mod that references some absolute address. Example: In framework.jar change the data in classes2.dex at offset 0x2eebfc to 0x000e. In the mod for the next update that 0x000e will be the same, but the 0x2eebfc will probably be different.

One way of dealing with this is to manually search for each new update where the place is to be modified.

Another way is to automatically search for the right spot. This is often done for text files where it's easier to identify similar sections in the stock and the patch. In many executable or binary files there are often offsets or references that change radically with slight updates.

With some types of files there are indications where everything goes and you can use these as reference points to the area that you want to modify. Many executable files have symbol tables. If I know where "onyx_hall_probe" is, I know that I want to fix the spot 0xe4 past that. Of course, this presumes that there has not been wholesale changes to the area of interest. This is very often true.

So, we have patching as a two step procedure. 1) Find all the symbols, 2) Verify and modify the places of interest at an offset from a symbol.

Finding symbols is a bit different for a kernel, an ELF file, a Dex file (from a jar or apk) or a generic binary file. There are tools for each of them, respectively: kallsyms.exe, elfview.exe, dexdump.exe, findtext.exe.

I've also been working on a tool called kpatch.exe that tries to streamline the second step of this procedure, the actual verification and patching. Even in a 64 bit world modifications are 8 bit (text sections), 16 bit (smali code and Thumb), 32 bit (ARM and ARM64). Usually there are things you want to check if you have the right spot.

So, in the end you have a script, batch file or a makefile that throws together a bunch of commands that do all the modification that you desire. Admittedly it is a bit messier than one would like, but it gets the job done.

Code:

C:\>make framework
adb pull /system/framework/framework.jar
/system/framework/framework.jar: 1 file pulled, 0 skipped. 81.8 MB/s (27916979 bytes in 0.326s)
unzip framework.jar *.dex
dexdump classes2.dex /cKeyboardEntryMap > c2.sym
kpatch classes2.dex c2.sym poke3.kpc Keypad
Profile #2: Keypad
002eebec generateMap
002eebfc 001b -> 000e
002eebfe 092e -> 0000
002eec00 0001 -> 0000
002eec02 2071 (ok)
Applied 3 patches
zip /r. /n fw.jar classes.dex classes2.dex classes3.dex
zipalign -f 4 fw.jar framework.jar
del c2.sym classes.dex classes2.dex classes3.dex fw.jar

Of course, there are other ways to patch a jar. You can disassemble with apktool, text edit the smali (or use mergesmali.exe), then build it again with apktool. This is a bit more intrusive. Also, currently there are problems with using apktool on Android 10 system core files and it just won't work.

11-17-2022, 08:50 AM	#3
Renate Onyx-maniac Posts: 3,985 Karma: 18026955 Join Date: Feb 2012 Device: Nook NST, Glow2, 3, 4, '21, Kobo Aura2, Poke3, Poke5, Go6	So, acknowledging that updating is a universal problem, let's move on. Surprisingly, in 1.5 GB of an Onyx update, not every single byte has changed! Big chunks of it stay the same although their relative position within a container has. It's very easy to come up with a mod that references some absolute address. Example: In framework.jar change the data in classes2.dex at offset 0x2eebfc to 0x000e. In the mod for the next update that 0x000e will be the same, but the 0x2eebfc will probably be different. One way of dealing with this is to manually search for each new update where the place is to be modified. Another way is to automatically search for the right spot. This is often done for text files where it's easier to identify similar sections in the stock and the patch. In many executable or binary files there are often offsets or references that change radically with slight updates. With some types of files there are indications where everything goes and you can use these as reference points to the area that you want to modify. Many executable files have symbol tables. If I know where "onyx_hall_probe" is, I know that I want to fix the spot 0xe4 past that. Of course, this presumes that there has not been wholesale changes to the area of interest. This is very often true. So, we have patching as a two step procedure. 1) Find all the symbols, 2) Verify and modify the places of interest at an offset from a symbol. Finding symbols is a bit different for a kernel, an ELF file, a Dex file (from a jar or apk) or a generic binary file. There are tools for each of them, respectively: kallsyms.exe, elfview.exe, dexdump.exe, findtext.exe. I've also been working on a tool called kpatch.exe that tries to streamline the second step of this procedure, the actual verification and patching. Even in a 64 bit world modifications are 8 bit (text sections), 16 bit (smali code and Thumb), 32 bit (ARM and ARM64). Usually there are things you want to check if you have the right spot. So, in the end you have a script, batch file or a makefile that throws together a bunch of commands that do all the modification that you desire. Admittedly it is a bit messier than one would like, but it gets the job done. Code: C:\>make framework adb pull /system/framework/framework.jar /system/framework/framework.jar: 1 file pulled, 0 skipped. 81.8 MB/s (27916979 bytes in 0.326s) unzip framework.jar *.dex dexdump classes2.dex /cKeyboardEntryMap > c2.sym kpatch classes2.dex c2.sym poke3.kpc Keypad Profile #2: Keypad 002eebec generateMap 002eebfc 001b -> 000e 002eebfe 092e -> 0000 002eec00 0001 -> 0000 002eec02 2071 (ok) Applied 3 patches zip /r. /n fw.jar classes.dex classes2.dex classes3.dex zipalign -f 4 fw.jar framework.jar del c2.sym classes.dex classes2.dex classes3.dex fw.jar Of course, there are other ways to patch a jar. You can disassemble with apktool, text edit the smali (or use mergesmali.exe), then build it again with apktool. This is a bit more intrusive. Also, currently there are problems with using apktool on Android 10 system core files and it just won't work.