[Magisk] zgfg:
Cuting-off zero byte fillers from the long patched images

Time ago (v20.4 and earlier), Magisk used to cut the zero bytes trailer from the patched images

Since v2042x it changed, now when v21.4 patches e.g. my 128 MB boot.img, the patched img also results with 128 MB, unlike with v20.4 where my patched img was around 20-21 MB.

In fact, all the last 128-21 MB are 107 MB of zero byte fillers (of no real use)

Since I usually store several of the last patched images (you never know when something could go wrong with Canary and I want to be easily able to go back where things worked, or just to test/compare accross the versions),

I don't like to store hundreds of MB of useless empty trailers (although, zipping before storing the patched img files would shrink them)

Below is the method how to detect the end of the real stuff in the patched img, and to cut off the zero byte trailer:

1) Rename your magisk_patched_XXXXX.img to long.img (names do not matter but my commands below use the same/known names instead of the random magisk_patched_XXXXX.img name).

Keep the renamed file in Downloads folder on Internal memory (otherwise commands must be adjusted to your path)

2) Go to Terminal, type in:

su

and grant the root

3) Type/paste the following command to Terminal:

od -c /sdcard/Download/long.img

It will start dumping the binary long.img in octal format, it can take a minute or two

4) When it ends, it will look like on my first screenshot.

Find the line where "T R A I L E R ! ! !" ends and look at the next octal address where zeroes start.

In my case, zeroes start at the address 1227111240.

Recalculate that to decimal: 1227111260 (octal) = 21729968 (decimal).

5) In fact, you can better round off to the 4K byte offset, hence instead of 122711260 use 122720000 (octal) = 21733376 (decimal).

Observe that I rounded to the higher octal address ending with four zeroes.

That's because in both cases the cut-off files will use the same number of 4 KB blocks (and hence will take the same space) on Storage

6) Now, put that decimal number 21733376 (or little smaller 21729968) into the following command and type/paste to Terminal:

dd bs=1 count=21733376 if=/sdcard/Download/long.img of=/sdcard/Download/short.img

7) Look now to the Downloads floder, besides the previous (as you renamed it to) 128 MB long.img, there is now also a shorter 21 MB short.img

8) We will now dump the cut-off short.img to compare.

You can use the same command like in step 2, but by replacing the file name long.img to short.img at the end of that command

To make dumping faster, I will dump just the last lines from just before where "T R A I L E R ! ! !" was starting, hence I will dump from 122711220 (octal) = 21729856 (decimal):

od -j 21729856 -c /sdcard/Download/short.img

Scroll up in Terminal and compare how it looked like when you dumped the original long.img.

Everything is now the same, just that zero bytes end now at 122712000 (octal) = cca 21 MB, not like previously at 1000000000 (octal) = 128 MB

Finally, you can flash from Fastboot this new short.img instead of the original long.img (i.e., instead of the really original random-named magisk_patched_XXXXX.img)

NOTES:

- Do not use my numbers like 21733376, calculate your own numbers as described in steps 4-5

- If aynthing goes wrong, just flash back your original long.img

- Do it carefully but at your own risk!

- The change in v2042x was introduced to fix issues on some devices where the shortened magisk_patched.img did not work.

For those devices patched img must be of the same size as the originial boot/recovery/ramdisk before patching.

Therefore, for those devices the method as above will not work - although their patched img will probably not look like the mine above, i.e., it will probably not have the zero byte fillers at the end, hence there won't be a trailer to cut it off

PS:

Next time, when Magisk update comes, you don't need to repeat the whole tedious process.

Instead of patching the long, original boot.img (and obtaining again patched img with zero byte fillers), just re-patch with new Magisk your short.img from previous Magisk version - resulted new magisk_patched.img will remain short, i.e., without the empty trailer