boot.img unpacking & repacking - General Questions and Answers

Hi guys,
I'm fiddling with some boot images, trying to extract TWRP from arter97's Razer Phone 2 (Aura) r14 kernel, and use it with a Magisk-patched stock kernel.
I've found several tools to unpack and repack the images, although jcadduono's bootimg seems to be the simplest. When I repack the unpacked Magisk-patched boot.img, the file size is 20M instead of the 64M. The original boot.img is mostly padded with zeros, but with a 56-byte footer starting with AVBf.
When I use avbtool add_hash_footer --partition_name boot --partition_size 67108864 --image new.img, it pads to 64M and adds nearly the same footer. There are 2 0x30's in the original that are changed to 0x20 in the new version. The image boots just fine, though.
However, when I replace the Magisk-patched stock ramdisk with the one from arter97's kernel, rebuild, and resize, the phone boots only into TWRP. I can't boot into system. (It's worth noting that arter97's ramdisk is compressed with lz4 instead of gz, so I had to expand it and re-compress with gz. I'm assuming his kernel adds lz4 support.)
Any ideas what I'm doing wrong?
Thanks,
-edison

Related

[Q] Is it safe to flash this?

Hi there XDA! I have a really big question/problem. I want to theme Clockworkmod Recovery with custom pictures/icons/themes and such. So far I installed Ubuntu VM, decompiled the Recovery Image into Kernel and Ramdisk, replaced the pre-loaded icons with my custom icons to the ramdisk. Finally, I recompiled it into a new recovery image!
However, since this program is designed for device boot images, Im still curious, can this be used for recovery images? I haven't editing anything within the kernel, just opened the ramdisk, replaced the /res/images with my own and did abootimg --create newcwm.img.
EDIT : All I know is that in the boot.cfg the boot parameter size has to be exact fit or hardbrick.
so I have attached the 2 files that shows the recovery image data/config of both of them.
Don't worry its just 2 txt files. Inside the other archive has the flash ready images. BOTH OF THEM. Also includes the already decompiled ramdisk and kernel to take a look at. In addition the bootimg.cfg is also in. It has everything you need to know
So, heres the question. If I decide to flash it to mmcblk0p21 which is the verified recovery partition for the GT-i9505, (Info on the partition informations/mount points below
http://forum.xda-developers.com/showthread.php?t=2342841
Then, hopefuly the flash to the recovery partition shouldn't hardbrick my device. Am I right? Or missing something.
I will attach both my image and the cwm recovery Image I decompiled. Please if you can tell me if theres something that has to be fixed to prevent me getting a $700 paperweight.
Note: The layout might be confusing inside the Archive, just please bear with me and just take your time. I can wait
PRESS ME TO DOWNLOAD

Unpack repack of stock recovery image without modification changes its file size

I have got a properly working stock recovery.img of my Poco X2. Its size on disk is 134mb. But when I unpack and repack it without changing a single thing, repacked image becomes smaller... precisely less than half of original size which is 47mb. Why? I tried carliv image and AIK in windows, mkboot and AIK in ubuntu 20.04. Result was same.
Another issue is that I compiled an ofrp for my device without any error. But the compiled image size is 54 mb. It flashes successfully but doesn't boot (goes to fastboot mode). I had a twrp.img also. It was the same size as of my stock recovery which is 134mb. I just unpacked repacked it like above, its size became smaller to 55mb... then I flashed and it didn't boot to recovery. But the 134mb size twrp.img booted successfully. So what is this problem? How can I keep my recovery image size 134 mb?
@Koken2003
Ask it in AIK thread.
@HemanthJabalpuri
Its not about AIK. Its how can i unpack and repack recovery.img without changing the size. Thanks
Koken2003 said:
@HemanthJabalpuri
Its not about AIK. Its how can i unpack and repack recovery.img without changing the size. Thanks
Click to expand...
Click to collapse
Its not about size that makes it not bootable.
It may strip some bytes of important data(maybe signature) when repacking.
If you ask about this in AIK thread osm0sis(developer of AIK) will observe your recovery.img.
Thanks

Repack AP_---.tar.md5 file with all whatever original signatures

The device is a Sam Gal A11W.
I want to change one text file in the /system partition.
In order to do that, I want to start from the stock firmware I already downloaded, make the change then flash the whole modified firmware.
There are 5 .tar.md5 files (4 if we consider only one of CSC_ and HOME_CSC_) in this firmware, which can be flashed just fine in their original form.
What I want to do is to:
1 - unpack the AP_***.tar file (contains meta-data/fota.zip, boot.img.lz4, carrier.img.lz4, dtbo.img.lz4, metadata.img.lz4, recovery.img.lz4, super.img.lz4, userdata.img.lz4, vbmeta.img.lz4)
2 - unlz4 the super.img.lz4,
3 - unsparse the super.img to super.ext4.img (using simg2img)
4 - lpunpack the super.ext4.img into individual dynamic partitions (there are only 4: odm.img, product.img, system.img, vendor.img - this is NOT an A/B device !!)
5 - modify the text file on system.img
6 - lpmake the super.ext4.img back from odm.img, product.img, system.img, vendor.img
7 - re-sparse the super.ext4.img back into super.img (using img2simg)
8 - lz4 the super.img back into super.img.lz4
9 - Re-TAR the super.img.lz4 file plus all the rest of the original .img.lz4 files back into the AP_***.tar file
10 - Flash the AP_***.tar file to this mother****ing piece of Samsung crap without errors, and that is WITHOUT UNLOCKED BOOTLOADER, because the scumbags eliminated the OEM Unlock option from the Dev Options.
What I already know is:
- How to do the whole process without preserving any signatures.
This is already explained in this thread:
Editing system.img inside super.img and flashing our modifications
I'm trying to modify my system.img (/system/build.prop) to include support for multi users. After struggling a lot, I've succeeded following your guide (that's an awesome work btw) to unpack, mount, modify, umount and repack super.img. Then...
forum.xda-developers.com
but the author assumes the bootloader can be unlocked and therefore doesn't deal with any signatures / security-crypto-baloney checks.
What I (still) need to know is:
1 - How many crypto-security-baloney-whatever-signatures are there on all these files ?
2 - How can I restore them during repackaging so the flashing process does not get screwed up by the locked phone ?
If anyone here knows the answer to these 2 things ... well I guess they must be the Android Godfather Almighty !!
have you figured this out?
FugkGoocle said:
The device is a Sam Gal A11W.
I want to change one text file in the /system partition.
In order to do that, I want to start from the stock firmware I already downloaded, make the change then flash the whole modified firmware.
There are 5 .tar.md5 files (4 if we consider only one of CSC_ and HOME_CSC_) in this firmware, which can be flashed just fine in their original form.
What I want to do is to:
1 - unpack the AP_***.tar file (contains meta-data/fota.zip, boot.img.lz4, carrier.img.lz4, dtbo.img.lz4, metadata.img.lz4, recovery.img.lz4, super.img.lz4, userdata.img.lz4, vbmeta.img.lz4)
2 - unlz4 the super.img.lz4,
3 - unsparse the super.img to super.ext4.img (using simg2img)
4 - lpunpack the super.ext4.img into individual dynamic partitions (there are only 4: odm.img, product.img, system.img, vendor.img - this is NOT an A/B device !!)
5 - modify the text file on system.img
6 - lpmake the super.ext4.img back from odm.img, product.img, system.img, vendor.img
7 - re-sparse the super.ext4.img back into super.img (using img2simg)
8 - lz4 the super.img back into super.img.lz4
9 - Re-TAR the super.img.lz4 file plus all the rest of the original .img.lz4 files back into the AP_***.tar file
10 - Flash the AP_***.tar file to this mother****ing piece of Samsung crap without errors, and that is WITHOUT UNLOCKED BOOTLOADER, because the scumbags eliminated the OEM Unlock option from the Dev Options.
What I already know is:
- How to do the whole process without preserving any signatures.
This is already explained in this thread:
Editing system.img inside super.img and flashing our modifications
I'm trying to modify my system.img (/system/build.prop) to include support for multi users. After struggling a lot, I've succeeded following your guide (that's an awesome work btw) to unpack, mount, modify, umount and repack super.img. Then...
forum.xda-developers.com
but the author assumes the bootloader can be unlocked and therefore doesn't deal with any signatures / security-crypto-baloney checks.
What I (still) need to know is:
1 - How many crypto-security-baloney-whatever-signatures are there on all these files ?
2 - How can I restore them during repackaging so the flashing process does not get screwed up by the locked phone ?
If anyone here knows the answer to these 2 things ... well I guess they must be the Android Godfather Almighty !!
Click to expand...
Click to collapse
Try using modified/patched Odin. As for trying to bypass unlocking the bootloader to flash the modified firmware or trying to "mimic" or "fake" the original signature, that isn't going to work. Samsung's proprietary signature is an enigma that can't be cracked. Though you might be able to match the MD5 by adding a dummy file to the file you are modifying and filing it bit/byte by bit/byte, one step at a time, the goal is to add characters to the file until it is large enough to make your modified file match the original file's MD5. That is if your modified file is smaller than the original file, if your modified file is larger than the original file, you can delete unimportant files from the modified MD5 file until it is smaller than the original MD5 and then create the dummy file filled with dummy characters until it exactly matches the original MD5 bit for bit. Then try flashing your MD5 file once you gets it's MD5 code matching bit for bit. Try the patched version of Odin to flash your modified file. No guarantees that it will work but part of the security checks during flashing checks the MD5 for a match/mismatch.
Rab_DaJew said:
have you figured this out?
Click to expand...
Click to collapse

CrashDump mode after flashing blue_spark kernel r112

Hey folks,
I have rooted (magisk) OnePlus 8 phone with Android 11, w/o TWRP recovery. I'm trying to replace kernel with one of blue_spark, here's what I'm doing
1. Download zip file from https://github.com/engstk/op8/releases/tag/r112
2. Extract and unpack Image.gz
3. Unpack Magisk patched boot.img to /tmp (magiskboot unpack boot.img)
4. Replace kernel with unpacked Image (cp Image /tmp/kernel)
5. Repack boot.img (magiskboot repack boot.img boot-new.img)
6. Boot with boot-new.img (fastboot boot boot-new.img)
And here is when I'm getting into "QUALCOMM CrashDump Mode"
The same result if I build kernel from sources. Repacking boot.img with original kernel works, so problem is unlikely in magiskboot.
I'm trying to figure out the problem, but without kernel logs it's troublesome. Any ideas?
Thanks.
Hm... It looks like, I also have to update DTB. After that device boots successfully. Seems a bit strange to me. What's the difference in supported devices between blu_spark and stock kernel?
Ok, turned out AVB was enabled in the original device tree:
fsmgr_flags = "wait,slotselect,avb";
Switching it off fixes boot process.

Question about boot.img and ramdisk.cpio

Hello,
I'm just getting into Android, and I've been messing around with boot.img with Magisk.
The boot.img that I'm specifically looking at is Pixel 6a.
I used `magiskboot unpack boot.img`, but I only got a kernel file.
Now, I'm wondering where the ramdisk.cpio. From what I read, ramdisk determines what to mount and whatnot.
Even without a ramdisk, I can fastboot flash boot boot.img it to my device and it will still work.
If there is no ramdisk in boot.img, then how does the device know what to mount or what the file hierarchy is when I flash it?
If the stock boot.img doesn't have a ramdisk, does not mean I have to generate my own?
Thanks!
init is on system, no ramdisk required.
https://source.android.com/docs/core/architecture/partitions/system-as-root#sar-partitioning
alecxs said:
init is on system, no ramdisk required.
https://source.android.com/docs/core/architecture/partitions/system-as-root#sar-partitioning
Click to expand...
Click to collapse
does that mean if I do include ramdisk.cpio, it overrides the one on system?
Yes, if you modify the kernel so ramdisk is extracted and processed (that's what Magisk does)
alecxs said:
Yes, if you modify the kernel so ramdisk is extracted and processed (that's what Magisk does)
Click to expand...
Click to collapse
Thank you so much for the link. I read up on it, and as you said, boot.img just carries a kernel file and ramdisk is in system.img.
It looks like you can also unpack, modify, and repack system.img and flash it onto pixel devices, so do you know why Magisk decided to create ramdisk.cpio and repack it into boot.img when it could have modified system.img? Is it because boot.img has a kernel file?
Thanks
Magisk also mods the DTB from "skip_initramfs" to "want_initramfs".
drunk_santa said:
It looks like you can also unpack, modify, and repack system.img and flash it onto pixel devices, so do you know why Magisk decided to create ramdisk.cpio and repack it into boot.img when it could have modified system.img?
Click to expand...
Click to collapse
Because Magisk is systemless-root method
https://topjohnwu.github.io/Magisk/boot.html

Categories

Resources