[Magisk] badabing2003:
Hi,

I think I might have hit a Magisk Manager bug, I'd like to check here first before reporting it as a bug in case anyone has seen this or thinks it's not a bug.

This is how it all started.

Two days ago, I patched boot.img of Pixel 6 September release.

Let's call the source boot.

boot_175dd086.img
MD5: 175dd0866bbe9907e2c994660cfb04ba
SHA1: 7f04123661284ff8d554f01060b00eb6f188a07b

I used Magisk Canary 25203 (38ab6858)

I used PixelFlasher which used

/data/adb/magisk/boot_patch.sh to patch it.

I got a patched file (second row, item #2 dated Sep 06)

MD5: 8db3c1e6a94a49e8e2c12c07c3dc6fe4

SHA1: 3888c78b768403cf1fae46f55b1e2d235348e62f

For reference.

The second column in the image is the source boot's first 8 characters of the MD5 Hash

The first column in the image is the patched boot's first 8 characters of the MD5 Hash

Obviously the first row which is not patched has both values being the same.

So far so good, I have been doing this for a long time now.

Today I used Magisk Manager UI to select boot_175dd086.img and get a patched file.

I expected the hash to be 8db3c1e6a94a49e8e2c12c07c3dc6fe4 similar to the one I got two days ago, after all nothing has changed about the source boot, nor the Magisk version.

The newly generated patch (line 3 above marked as item #1 in the image)

MD5: 49812686f9c69443ac6919472936ac51

SHA1: e5c78036b804fb1397d95cc1b105ac7c949837a4

I compared the two generated patches.

They are binary identical with the exception of this segment.

That segment is SHA1.

Obviously this is being inserted by Magisk, and it looks like it is supposed to be SHA1 of the source boot.img judging from one of the values, 7f04123661284ff8d554f01060b00eb6f188a07b

But why is the other 9c43d3fa9822dfd1f2eb7cc2768bbfa3c6c0bddf, and where is it coming from? And considering that everything else is binary identical, it can't be a different source boot.img can it?

Digging deeper, I noticed that I had two files on the phone in /storage/emulated/0/Download

1- boot_ccce82c5.img,
MD5: ccce82c5cb937aa4881cb410e50826b4
SHA1: 9c43d3fa9822dfd1f2eb7cc2768bbfa3c6c0bddf
2- boot_175dd086.img
MD5: 175dd0866bbe9907e2c994660cfb04ba
SHA1: 7f04123661284ff8d554f01060b00eb6f188a07b

In Magisk Manager, I select to patch, and then select boot_175dd086.img and it ends up patching boot_175dd086.img (I think) but inserting sha1 of boot_ccce82c5.img

The two source boot.img files are truly different

It would be impossible to get binary identical patched files (minus the sha1 part)

What is going on?

How is this possible.

Is it possible that the part that is supposed to get the sha1 is picking up the wrong file, but the patcher is picking up the correct file?

At this point I'm not even certain if it used boot_ccce82c5.img or boot_175dd086.img to generate the patch, how can I be certain? by inspecting the output?

I'm assuming that this is exactly why the sha1 is inserted to indicate the source used.

If the proper source is being used, but the wrong sha1 is being inserted, I suppose it is a bug, which defeats the point of inserting the sha1, however probably also harmless.

Is it possible that the sha1 process is looking for first match of boot*.img and picking the wrong file?

I really can't see what else could be the cause other than some values being cached between runs even if Magisk Manager is stopped.

This the output of using boot_patch.sh

- Unpacking boot image
Parsing boot image: [/sdcard/Download/boot_175dd086.img]
HEADER_VER [4]
KERNEL_SZ [24999644]
RAMDISK_SZ [0]
PAGESIZE [4096]
CMDLINE []
KERNEL_FMT [lz4_legacy]
VBMETA
- Checking ramdisk status
Loading cpio: [ramdisk.cpio]
- Magisk patched boot image detected
Loading cpio: [ramdisk.cpio]
Remove [.backup]
Remove [.backup/.magisk]
Remove [init]
Remove [overlay.d]
Remove [overlay.d/sbin]
Remove [overlay.d/sbin/magisk32.xz]
Remove [overlay.d/sbin/magisk64.xz]
Remove [.backup/.rmlist]
Dump cpio: [ramdisk.cpio]
- Patching ramdisk
Loading cpio: [ramdisk.cpio]
Add entry [init] (0750)
Create directory [overlay.d] (0750)
Create directory [overlay.d/sbin] (0750)
Add entry [overlay.d/sbin/magisk32.xz] (0644)
Add entry [overlay.d/sbin/magisk64.xz] (0644)
Patch with flag KEEPVERITY=[true] KEEPFORCEENCRYPT=[true]
Loading cpio: [ramdisk.cpio.orig]
Record new entry: [init] -> [.backup/.rmlist]
Record new entry: [overlay.d] -> [.backup/.rmlist]
Record new entry: [overlay.d/sbin] -> [.backup/.rmlist]
Record new entry: [overlay.d/sbin/magisk32.xz] -> [.backup/.rmlist]
Record new entry: [overlay.d/sbin/magisk64.xz] -> [.backup/.rmlist]
Create directory [.backup] (0000)
Add entry [.backup/.magisk] (0000)
Dump cpio: [ramdisk.cpio]
- Repacking boot image
Parsing boot image: [/sdcard/Download/boot_175dd086.img]
HEADER_VER [4]
KERNEL_SZ [24999644]
RAMDISK_SZ [0]
PAGESIZE [4096]
CMDLINE []
KERNEL_FMT [lz4_legacy]
VBMETA
Repack to boot image: [new-boot.img]
HEADER_VER [4]
KERNEL_SZ [24999644]
RAMDISK_SZ [491587]
PAGESIZE [4096]
CMDLINE []

Yet the generated patch file has the wrong sha1 md5

Looking for magisk_patched.img in /storage/emulated/0/Download ...
Found /storage/emulated/0/Download/magisk_patched.img
Pulling /storage/emulated/0/Download/magisk_patched.img from the phone ...
md5 of magisk_patched.img: 49812686f9c69443ac6919472936ac51

I even pulled back the boot_175dd086.img and computed the md5 and sha1 just in case there was an issue with the transfer.

They match the original boot_175dd086.img

Sorry for the long winded post, I don't like leaving out details that could be relevant.