MKBOOTIMG-TOOLS
MY GITHUB SOURCE:
https://github.com/ModdingMyMind/mkbootimg_tools
Original Author: xiaolu (GITHUB SOURCE: https://github.com/xiaolu/mkbootimg_tools)
Heavily Modified By: Modding.MyMind
This project is originally based from xiaolu. To make this compatible for ARM I modified the script, compiled some binaries such as file, bash, grep, gzip, lzma, xz, mkbootimg, etc.
-- This project uses busybox but due to how stripped and limited busybox is it ultimately led to me having to compile a few binaries from source. These binaries must be part of the project in order for the project to be successful. For example, busybox grep will not always give accurate offsets for the android header. One of MANY bugs found with busybox.
This project supports device tree binaries found inside the Boot.img and Recovery.img.
This project supports multiple Ramdisk compressions.
-- This project will check the ramdisk compression and if it determines that the tool does not support that particular compression then it will display a hazard warning letting the user know that the compression is not supported and that the ramdisk currently cannot be decompressed or compressed until support has been officially added.
-- If the compression is supported it will display what type of compression the Ramdisk is and how many blocks it has when unpacked.
This project will determine your kernel size, ramdisk size, and TRUE OFFSETS (not just the standard mkbootimg.c offsets).
-- With respect to the offsets; You will learn that many available tools found available specifically handle images where the ANDROID! header is located at 0x0. Not all images are built like this from stock. This project will find the header, base, kernel offset, ramdisk offset, second offset, and tags offset. It will rebuild the image using DD to insure the android header is located at 0x0. The found offsets inside the image will be cross referenced to see if the OEM of that image built it using the standard mkbootimg.c. If it detects any offsets which are built using NON-standard offsets then it will display a warning as well as show you what the image TRUE offsets actually are. Those same offsets are then applied to properly rebuild your image to insure that it boots like it was intended to do.
-- The warning will let you know that you may modify mkbootimg.c with the NON-standard values if you wish to have a binary specific to your device. The offsets displayed are not the address. Because the offsets are determined and not the address this makes it possible for this project to not have to rebuild mkbootimg.c. When the project is used to rebuild your image using the mkbootimg args such as --ramdisk_offset, --kernel_offsets, etc, etc, this then tells mkbootimg.c to ignore the hardcoded offsets and only use the ones it has been instructed to use. This is even more successful by insuring the BASE is accurate and applying the base as one of the mkbootimg args (--base 0 <-- this is lazy and stupid).
The mkboot script requires two args whether unpacking the image or repacking the image.
-- mkboot boot.img bootfolder (This will unpack the image)
1. mkboot is the script.
2. boot.img is the actual image.
3. bootfolder will be created and become the project folder.
-- mkboot bootfolder newboot.img (This will repack the image)
1. mkboot is the script.
2. bootfolder is the project folder which has the needed files and information to repack.
3. This will be the name of the finished build.
UNPACK STANDARD IMAGE
This image uses standard mkbootimg.c:
[email protected]:/data/local/tmp/mkbootimg_tools-master # ./mkboot boot.img work
Unpack & decompress boot.img to work
kernel : zImage
ramdisk : ramdisk
page size : 2048
kernel size : 2529072
ramdisk size : 230255
base : 0x12200000
kernel offset : 0x00008000
ramdisk offset : 0x01000000
second_offset : 0x00f00000
tags offset : 0x00000100
cmd line : mem=471M console=ttyMSM2,115200n8 androidboot.hardware=thunderc lge.rev=10
Ramdisk is lzma format.
1436 blocks
Unpack completed.
[email protected]:/data/local/tmp/mkbootimg_tools-master #
Click to expand...
Click to collapse
REPACK STANDARD IMAGE
Image repacked with standard mkbootimg.c:
[email protected]:/data/local/tmp/mkbootimg_tools-master # ./mkboot work boot.img
mkbootimg from work/img_info.
kernel : zImage
ramdisk : new_ramdisk.lzma
page size : 2048
kernel size : 2529072
ramdisk size : 230029
base : 0x12200000
kernel offset : 0x00008000
ramdisk offset : 0x01000000
tags offset : 0x00000100
cmd line : mem=471M console=ttyMSM2,115200n8 androidboot.hardware=thunderc lge.rev=10
Kernel size: 2529072, new ramdisk size: 230029, boot.img: 2762752.
boot.img has been created.
[email protected]:/data/local/tmp/mkbootimg_tools-master #
Click to expand...
Click to collapse
UNPACK NON-STANDARD IMAGE
This image uses non-standard mkbootimg.c:
[email protected]:/data/local/tmp/mkbootimg_tools-master # ./mkboot recovery.img work
Unpack & decompress recovery.img to work
****** WARNING ******* WARNING ******* WARNING ******
This image is built using NON-standard mkbootimg!
RAMDISK_OFFSET is 0x01608000
You can modify mkbootimg.c with the above value(s)
****** WARNING ******* WARNING ******* WARNING ******
kernel : zImage
ramdisk : ramdisk
page size : 2048
kernel size : 5834192
ramdisk size : 4351685
base : 0x80600000
kernel offset : 0x00008000
ramdisk offset : 0x01608000
second_offset : 0x00f00000
tags offset : 0x00000100
cmd line : console=ttyHSL0,115200,n8 user_debug=31
Ramdisk is gzip format.
14837 blocks
Unpack completed.
[email protected]:/data/local/tmp/mkbootimg_tools-master #
Click to expand...
Click to collapse
REPACK NON-STANDARD IMAGE
Image repacked with non-standard mkbootimg.c:
[email protected]:/data/local/tmp/mkbootimg_tools-master # ./mkboot work recovery.img
mkbootimg from work/img_info.
kernel : zImage
ramdisk : new_ramdisk.gzip
page size : 2048
kernel size : 5834192
ramdisk size : 4358038
base : 0x80600000
kernel offset : 0x00008000
ramdisk offset : 0x01608000
tags offset : 0x00000100
cmd line : console=ttyHSL0,115200,n8 user_debug=31
Kernel size: 5834192, new ramdisk size: 4358038, recovery.img: 10194944.
recovery.img has been created.
[email protected]:/data/local/tmp/mkbootimg_tools-master #
Click to expand...
Click to collapse
UNPACK IMAGE WITH INCOMPATIBLE RAMDISK
[email protected]:/data/local/tmp/mkbootimg_tools-master # ./mkboot boot-1.img work
Unpack & decompress boot-1.img to work
kernel : zImage
ramdisk : ramdisk
page size : 2048
kernel size : 3580032
ramdisk size : 594701
base : 0x10000000
kernel offset : 0x00008000
ramdisk offset : 0x01000000
second_offset : 0x00f00000
tags offset : 0x00000100
cmd line :
****** HAZARD ******* HAZARD ******* HAZARD ******
Ramdisk is data format. Can't unpack ramdisk.
This tool currently does not support data.
****** HAZARD ******* HAZARD ******* HAZARD ******
[email protected]:/data/local/tmp/mkbootimg_tools-master #
Click to expand...
Click to collapse
REPACK IMAGE WITH INCOMPATIBLE RAMDISK
[email protected]d:/data/local/tmp/mkbootimg_tools-master # ./mkboot work boot-1.img
mkbootimg from work/img_info.
****** HAZARD ******* HAZARD ******* HAZARD ******
Ramdisk is data format. Can't repack ramdisk.
This tool currently does not support data.
****** HAZARD ******* HAZARD ******* HAZARD ******
[email protected]:/data/local/tmp/mkbootimg_tools-master #
Click to expand...
Click to collapse
*Reserved*
If your boot.img and/or recovery.img is found to not be supported using this tool then please send me your boot.img and recovery.img so I may review it and determine if official support can be added. Thanks.
Add support for MediaTek Images:
-- Unpack and repack boot/recovery images.
-- Append proper headers to ramdisk when repacking.
-- Compiled mkimage to assist with the headers.
-- This support currently does not include the logo images at this time.
-- MT6516
-- MT65x3 (MT6513 and MT6573)
-- MT65x5 (MT6515 and MT6575)
-- MT6577
-- MT65x2 (MT6572 and MT6582)
-- MT6589
-- MT83xx (MT8377 and MT8389)
Modding.MyMind said:
If your boot.img and/or recovery.img is found to not be supported using this tool then please send me your boot.img and recovery.img so I may review it and determine if official support can be added. Thanks.
Click to expand...
Click to collapse
getting error
Code:
[email protected]:/ $ su
/mkbootimg_tool/ARM <
/mkboot boot.img h3ll <
<Unpack and repack boot.img tool>
----------------------------------------------------------------------
Not enough parameters or parameter error!
unpack boot.img & decompress ramdisk
mkboot [img] [output dir]
mkboot boot.img boot20130905
^[[?1;2cUse the unpacked directory repack boot.img(img_info)
mkboot [unpacked dir] [newbootfile]
mkboot boot20130905 newboot.img
^[[?1;[email protected]:/data/local/tmp/mkbootimg_tool/A;2c1;2c <
sh: 1: not found
sh: 2c1: not found
sh: 2c: not found
127|[email protected]:/data/local/tmp/mkbootimg_tool/ARM #
H3LL said:
getting error
Code:
[email protected]:/ $ su
/mkbootimg_tool/ARM <
/mkboot boot.img h3ll <
----------------------------------------------------------------------
Not enough parameters or parameter error!
unpack boot.img & decompress ramdisk
mkboot [img] [output dir]
mkboot boot.img boot20130905
^[[?1;2cUse the unpacked directory repack boot.img(img_info)
mkboot [unpacked dir] [newbootfile]
mkboot boot20130905 newboot.img
^[[?1;[email protected]:/data/local/tmp/mkbootimg_tool/A;2c1;2c <
sh: 1: not found
sh: 2c1: not found
sh: 2c: not found
127|[email protected]:/data/local/tmp/mkbootimg_tool/ARM #
Click to expand...
Click to collapse
Check the permissions, check that bash is placed at /system/xbin, and insure the image you are trying to unpack is in the same directory where the mkboot script is located or else, insure you specify the image path properly.
If it still errors out insure your device is ARM and compatible for the project. If yes, then at the top of the script will be; #set -x. Uncomment it and run the script again, then copy and paste it's output here.
Also, send me your image to download and verify on my end. Thanks.
Modding.MyMind said:
Check the permissions, check that bash is placed at /system/xbin, and insure the image you are trying to unpack is in the same directory where the mkboot script is located or else, insure you specify the image path properly.
If it still errors out insure your device is ARM and compatible for the project. If yes, then at the top of the script will be; #set -x. Uncomment it and run the script again, then copy and paste it's output here.
Also, send me your image to download and verify on my end. Thanks.
Click to expand...
Click to collapse
tried same output as above here's boot.IMG
H3LL said:
tried same output as above here's boot.IMG
Click to expand...
Click to collapse
Your image doesn't have an android header. It's elf. This tool currently doesn't support it but now that I have your boot.img I can see about adding support. Can you send me your recovery image as well so I may verify that the process is the same for both when unpacking and repacking. Some images such as MediaTek have different headers for the ramdisk depending on whether it's the boot or recovery and so I would like to confirm the same with yours as well. Thanks.
Edit: Also, this tool won't work on your device unless the binaries are compiled from source for your machine. It's currently for ARM, but your device won't play nice with it.
Modding.MyMind said:
Your image doesn't have an android header. It's elf. This tool currently doesn't support it but now that I have your boot.img I can see about adding support. Can you send me your recovery image as well so I may verify that the process is the same for both when unpacking and repacking. Some images such as MediaTek have different headers for the ramdisk depending on whether it's the boot or recovery and so I would like to confirm the same with yours as well. Thanks.
Edit: Also, this tool won't work on your device unless the binaries are compiled from source for your machine. It's currently for ARM, but your device won't play nice with it.
Click to expand...
Click to collapse
there is no recovery. img for this device (its not mediatek) its in ramdisk of the boot.img....yeah my device is ARM
H3LL said:
there is no recovery. img for this device (its not mediatek) its in ramdisk of the boot.img....yeah my device is ARM
Click to expand...
Click to collapse
Reviewed the binaries and somehow overlooked a few after compiling them. Some aren't even true static when I originally thought I did compile them as such. There are also some which are true static but focus on either hard floats or soft floats. So, I need to go back and recompile the ones which stood out and push them to my repo. This may very well be why it isn't playing fair on your Sony device.
With that said, adding support for your image is gonna be a bit complicated to write out in bash since it is very involved lol. However, I am gonna make an attempt by taking on the challenge and seeing if I can get it done .
The github account doesn't exist anymore and there's no download link?
[null]
how to compile this for windows
I can't use one over the other because I need gamepass cuz Iwant to save money on hardware not buy games on steam but also i need linux because bash is miles better than some IDE which takes up 30 gb at minimum
Hello All,
My Imjtool is now at version 1.6 , supporting MediaTek images, improving QCom FBPK (SD845 and onwards ".img"), DTBO (Device tree blob overlay) slicing, super.img (liblp logical partitions) and block based update images (system.transfer.list and ..new.dat) even when compressed with Brotli (.br) compression.
By now, there's support for quite a few formats, including proprietary QCOM FBPK, Huawei UPDATE.APP, and even UEFI containers:
Code:
/**
*
* Rudimentary Android image and partition unpacking tool
*
* v0.1 - Support unpacking of BootLoader and Boot images, as well as imgdata
* v0.2 - Supports offset= (for HTC and other boot.imgs where ANDROID! is wrapped)
* Supports cmdline= (to override kernel command line)
*
* v0.3 - Integrated mkbootimg functionality, added dt_size and id
*
* v0.4 - cmdline, addrs..
*
* v0.4.1 - Fix for Edvard Holst on Essential PH1 images.. (who uses Essential nowadays, I wonder?)
*
* v0.5 - Update with LZ4 binaries, fix for extract devicetree even if can't uncompress kernel
*
* v0.6 - Samsung images (with DT > 0) - Device Tree now found whereever it may hide
*
* v0.7 - system.transfer.list support
*
* v0.8 - FBPK (SD845 CrossHatch (Pixel 3 XL) bootloader images) AND Huawei Mate
* Also compiles cleanly
*
* v0.85 - system.transfer.list support for v4 (MTK 64 bit)
*
* v1.0 - EFI. Worthy enough a feature that (after three years) I hit version 1 on it, and - JCOLOR
*
* v1.1 - Samsung baseband images ("TOC") - 03/04/2020
*
* v1.2 - DTBO, super.img (03/20/2020) and integrated Brötli
*
* v1.2.1 - Lots of QCOM EFI GUIDs added. Thanks to anonymous contributor!
*
* v1.3 - Can now also pack super.img and boot.img based on existing!
*
* v1.4 - uBoot uimage format
*
* v1.5 - MTK images!
*
* v1.5.1 - Fixes: QCOM FPBK fixed (accidentally removed during refactoring around 1.3.. oops)
* UEFI now unpacks files by UI, if presenr, rather than GUID
*
* 1.6 - Peek into images to detect payload format
*
*
* platform-innovation-framework-for-uefi-complete-specifications-v0.90-v0.97 from Intel
* was invaluable for figuring out EFI
*
*
* This tool is part of the free downloads for the book
* "Android Internals: A Confectioner's Cookbook"
* But (as of v1.0) is also quite useful or MacOS T2 firmwares
*
* Author: Jonathan Levin, http://NewAndroidBook.com
*
* (New edition of Book and the loooong overdue Vol II coming soon! Check /TOC.html on site!)
*
* License: Use freely, BUT give credit where due. This way people learn of the website and books.
*
* If you have suggestions for improvement/new image types/etc - let me know and I'll gladly
* add them in.
**/
Totally free to use, feedback or requests appreciated.
Link: NewAndroidBook.com/tools/imjtool.html
Hello!
I've stumbled into this tool while trying a stupid thing. I've realized that on Xiaomi Mi A3 (laurel_sprout) the android splash images are stored in xbl.elf.
Code:
<!-- This is LUN 1 - Boot LUN A" -->
<physical_partition>
<partition label="xbl_a" size_in_kb="3584" type="DEA0BA2C-CBDD-4805-B4F9-F428251C3E98" bootable="false" readonly="true" filename="xbl.elf"/>
<partition label="xbl_config_a" size_in_kb="128" type="5A325AE4-4276-B66D-0ADD-3494DF27706A" bootable="false" readonly="false" filename="xbl_config.elf"/>
<partition label="last_parti" size_in_kb="0" type="00000000-0000-0000-0000-000000000000" bootable="false" readonly="true" filename="" />
</physical_partition>
<!-- This is LUN 2 - Boot LUN B" -->
<physical_partition>
<partition label="xbl_b" size_in_kb="3584" type="DEA0BA2C-CBDD-4805-B4F9-F428251C3E98" bootable="false" readonly="true" filename="xbl.elf"/>
<partition label="xbl_config_b" size_in_kb="128" type="5A325AE4-4276-B66D-0ADD-3494DF27706A" bootable="false" readonly="false" filename="xbl_config.elf"/>
<partition label="last_parti" size_in_kb="0" type="00000000-0000-0000-0000-000000000000" bootable="false" readonly="true" filename="" />
</physical_partition>
I've used imjtool on Ubuntu 18.04 WSL and was able to extract xbl.elf contents, where, indeed the bmp files are stored (see attachment).
Now my question is, how to "repack" the elf file if I wanted to replace those bmp files for other ones?
Is that possible?
err.. no. But I could probably add that as a feature - I'll admit this is the first time I'm getting this request.
Thing is XBL is signed, and even if you unlock the bootloader, that only takes effect well after XBL loading (in fact, after ABL), so you won't be able to reflash XBL without risk of bricking.
Sure you need this?
Typhus_ said:
Hello!
I've stumbled into this tool while trying a stupid thing. I've realized that on Xiaomi Mi A3 (laurel_sprout) the android splash images ares stored in xbl.elf.
Code:
<!-- This is LUN 1 - Boot LUN A" -->
<physical_partition>
<partition label="xbl_a" size_in_kb="3584" type="DEA0BA2C-CBDD-4805-B4F9-F428251C3E98" bootable="false" readonly="true" filename="xbl.elf"/>
<partition label="xbl_config_a" size_in_kb="128" type="5A325AE4-4276-B66D-0ADD-3494DF27706A" bootable="false" readonly="false" filename="xbl_config.elf"/>
<partition label="last_parti" size_in_kb="0" type="00000000-0000-0000-0000-000000000000" bootable="false" readonly="true" filename="" />
</physical_partition>
<!-- This is LUN 2 - Boot LUN B" -->
<physical_partition>
<partition label="xbl_b" size_in_kb="3584" type="DEA0BA2C-CBDD-4805-B4F9-F428251C3E98" bootable="false" readonly="true" filename="xbl.elf"/>
<partition label="xbl_config_b" size_in_kb="128" type="5A325AE4-4276-B66D-0ADD-3494DF27706A" bootable="false" readonly="false" filename="xbl_config.elf"/>
<partition label="last_parti" size_in_kb="0" type="00000000-0000-0000-0000-000000000000" bootable="false" readonly="true" filename="" />
</physical_partition>
I've used imjtool on Ubuntu 18.04 WSL and was able to extract xbl.elf contents, where, indeed the bmp files are stored (see attachment).
Now my question is, how to "repack" the elf file if I wanted to replace those bmp files for other ones?
Is that possible?
Click to expand...
Click to collapse
morpheus______ said:
err.. no. But I could probably add that as a feature - I'll admit this is the first time I'm getting this request.
Thing is XBL is signed, and even if you unlock the bootloader, that only takes effect well after XBL loading (in fact, after ABL), so you won't be able to reflash XBL without risk of bricking.
Sure you need this?
Click to expand...
Click to collapse
No, of course I don't "need" this. And, yes, my device is fully unlocked (critical partitions included).
Thing is, on Android community it's usual to change the splash screen but, normally, there's a splash.img (or logo.bin, etc) where all image files ares stored. Those files belong to a splash partition, which typically, isn't that "important" so even if we mess up flashing the wrong stuff onto it, a new flash with the proper img (or bin) file would solve the issue.
Now, for what I've understood, what you're saying is that we could face the risk of hard bricking the device if the "repack" would create a corruptible elf file, right?
After extracting the elf file I've noticed a LOT of stuff there, besides the 2 bpm files I wanted to change, and so if this is an unnecessary risk, I'll just forget about it.
Funny thing is, on this device (Xiaomi Mi A3), there's a splash partition and we can "dd" it but it results on a splash.img filled with zeros. I wonder if we could create a splash.img using the bpm files I've found on the xbl.elf file and flash it on the splash partition...just to check if it would overwrite the bpm files present on xbl.elf.
Don't know, guess I'll try it...just have to find a splash image tool compatible with the device resolution.
Either way, thank you for answering me.
Just making sure there - better safe than sorry, as, even with "critical partitions" unlocked, I can't vouch for your boot sequence not rejecting this - whether the ELF is valid or corrupt won't be the main risk - what will be is that the bootROM (or UEFI runtime) might reject this xbl as it won't be validly signed.
Still, it's an interesting challenge. I can get on it. I'll update, and you can always get me over DM.
BTW, I just updated imjtool.tgz (at same URL) with a minor update to accommodate for all QCOM GUIDs I could get my hands on. If you try it again you should be able to see lots more "DXE" files in human readable, rather than GUID notation..
Typhus_ said:
No, of course I don't "need" this. And, yes, my device is fully unlocked (critical partitions included).
Thing is, on Android community it's usual to change the splash screen but, normally, there's a splash.img (or logo.bin, etc) where all image files ares stored. Those files belong to a splash partition, which typically, isn't that "important" so even if we mess up flashing the wrong stuff onto it, a new flash with the proper img (or bin) file would solve the issue.
Now, for what I've understood, what you're saying is that we could face the risk of hard bricking the device if the "repack" would create a corruptible elf file, right?
After extracting the elf file I've noticed a LOT of stuff there, besides the 2 bpm files I wanted to change, and so if this is an unnecessary risk, I'll just forget about it.
Funny thing is, on this device (Xiaomi Mi A3), there's a splash partition and we can "dd" it but it results on a splash.img filled with zeros. I wonder if we could create a splash.img using the bpm files I've found on the xbl.elf file and flash it on the splash partition...just to check if it would overwrite the bpm files present on xbl.elf.
Don't know, guess I'll try it...just have to find a splash image tool compatible with the device resolution.
Either way, thank you for answering me.
Click to expand...
Click to collapse
morpheus______ said:
BTW, I just updated imjtool.tgz (at same URL) with a minor update to accommodate for all QCOM GUIDs I could get my hands on. If you try it again you should be able to see lots more "DXE" files in human readable, rather than GUID notation..
Click to expand...
Click to collapse
Cool, thanks for the update. I'll check it.
Stupid question, isn't the elf file signature one of it's files inside it's content? If it is, and if we preseve it (like don't touch it), after "repacking" wouldn't it still be signed with the same valid signature? Or the process to "repack" will forcibly resign it with a different signature?
The goal was to simply replace one bpm file (the one that states unlocked) since the other one only appears when the bootloader is locked...no point on changing that. All of the rest would remain exactly the same.
Thank you for spending time around this.
There are many ways to sign files. In the case of ELF, it's a separate section which signs all contents of the ELF but itself. The problem is, that it signs *all* contents, so that if you add a section - you've changed the header and you've messed the signature up. Same idea as signing an APK - so that you can't tamper with any of the files in it.
When you "repack" you can't re-generate the signature because it's a hash (which you can recompute easily) signed with the private key of the vendor (which you don't have). The old signature section won't be valid anymore because you will have altered the contents and/or added sections at this point.
J
Typhus_ said:
Cool, thanks for the update. I'll check it.
Stupid question, isn't the elf file signature one of it's files inside it's content? If it is, and if we preseve it (like don't touch it), after "repacking" wouldn't it still be signed with the same valid signature? Or the process to "repack" it will forcibly resign it with a different signature?
The goal was to simply replace one bpm file (the one that states unlocked) since the other one only appears when the bootloader is locked...no point on changing that. All of the rest would remain exactly the same.
Thank you for spending time around this.
Click to expand...
Click to collapse
morpheus______ said:
There are many ways to sign files. In the case of ELF, it's a separate section which signs all contents of the ELF but itself. The problem is, that it signs *all* contents, so that if you add a section - you've changed the header and you've messed the signature up. Same idea as signing an APK - so that you can't tamper with any of the files in it.
When you "repack" you can't re-generate the signature because it's a hash (which you can recompute easily) signed with the private key of the vendor (which you don't have). The old signature section won't be valid anymore because you will have altered the contents and/or added sections at this point.
J
Click to expand...
Click to collapse
Right, I understand.
Anyway, is the tool updated already? I'm just asking since I've tried it right now and it shows the exact same content after extracting xbl.elf again.
yep.
NewAndroidBook.com/tools/imjtool.tgz is direct link.
Patching ELF might take me a while
J
Typhus_ said:
Right, I understand.
Anyway, is the tool updated already? I'm just asking since I've tried it right now and it shows the exact same content after extracting xbl.elf again.
Click to expand...
Click to collapse
How to repack super.img
I^m trying to modify system.img inside super.img.
First step extract super.img file:
Code:
imjtool super.img extract
It creates a file image.img, inspecting it with imjtool I get:
Code:
$ imjtool image.img
liblp dynamic partition (super.img) - Blocksize 0x1000, 2 slots
LP MD Header @0x3000, version 10.0, with 4 logical partitions on block device at partition super, first sector: 0x800
Partitions @0x3080 in 2 groups:
Group 0: default
Group 1: group_basic
Name: system (read-only, spanning 1 extents and 4613 MB)
Name: vendor (read-only, spanning 1 extents and 574 MB)
Name: product (read-only, spanning 1 extents and 665 MB)
Name: odm (read-only, spanning 1 extents and 4 MB)
I proceed with extracting the content of image.img
Code:
imjtool image.img extract
It extracts 4 files:
system.img
vendor.img
product.img
odm.img
After mouting system.img and make my change, how can I repack the 4 files and recreate super.img?
I've tried with
Code:
imjtool make super.img system.img vendor.img product.img odm.img
but the result is something different...
bagbyte said:
I^m trying to modify system.img inside super.img.
First step extract super.img file:
Code:
imjtool super.img extract
It creates a file image.img, inspecting it with imjtool I get:
Code:
$ imjtool image.img
liblp dynamic partition (super.img) - Blocksize 0x1000, 2 slots
LP MD Header @0x3000, version 10.0, with 4 logical partitions on block device at partition super, first sector: 0x800
Partitions @0x3080 in 2 groups:
Group 0: default
Group 1: group_basic
Name: system (read-only, spanning 1 extents and 4613 MB)
Name: vendor (read-only, spanning 1 extents and 574 MB)
Name: product (read-only, spanning 1 extents and 665 MB)
Name: odm (read-only, spanning 1 extents and 4 MB)
I proceed with extracting the content of image.img
Code:
imjtool image.img extract
It extracts 4 files:
system.img
vendor.img
product.img
odm.img
After mouting system.img and make my change, how can I repack the 4 files and recreate super.img?
I've tried with
Code:
imjtool make super.img system.img vendor.img product.img odm.img
but the result is something different...
Click to expand...
Click to collapse
Update: I've found my answer: https://forum.xda-developers.com/showpost.php?p=82241115&postcount=70
That's because 'make' wasn't designed for super.img creation, but for initrd (boot.img).
Now that I know people need this, I'll add that in. Updates to follow.
J
bagbyte said:
I^m trying to modify system.img inside super.img.
First step extract super.img file:
Code:
imjtool super.img extract
It creates a file image.img, inspecting it with imjtool I get:
Code:
$ imjtool image.img
liblp dynamic partition (super.img) - Blocksize 0x1000, 2 slots
LP MD Header @0x3000, version 10.0, with 4 logical partitions on block device at partition super, first sector: 0x800
Partitions @0x3080 in 2 groups:
Group 0: default
Group 1: group_basic
Name: system (read-only, spanning 1 extents and 4613 MB)
Name: vendor (read-only, spanning 1 extents and 574 MB)
Name: product (read-only, spanning 1 extents and 665 MB)
Name: odm (read-only, spanning 1 extents and 4 MB)
I proceed with extracting the content of image.img
Code:
imjtool image.img extract
It extracts 4 files:
system.img
vendor.img
product.img
odm.img
After mouting system.img and make my change, how can I repack the 4 files and recreate super.img?
I've tried with
Code:
imjtool make super.img system.img vendor.img product.img odm.img
but the result is something different...
Click to expand...
Click to collapse
This is very helpful. Many thanks!
Chaser
Yeah great stuff... just used imjtool to extract abl.img and hunt for hidden fastboot commands.
This is an awesome tool!!!
Thanks a lot and best regards,
scholbert
morpheus______ said:
That's because 'make' wasn't designed for super.img creation, but for initrd (boot.img).
Now that I know people need this, I'll add that in. Updates to follow.
J
Click to expand...
Click to collapse
Thank you for this tool!! I could also definitely use the ability to do this ^^^ with imjtool.
Unpacking/Repacking for Samsung S9
Hey, nice work, thank you!
I pulled the working boot.img from a Samsung Galaxy S9. I am just trying to unpack it, repack it and flash it back, and see it working (as a test, if that works I'll move to replace the kernel).
Your tool also extracts the DTB, which is great, abootimg didn't do that. However, when I repack like
Code:
imjtool.x86_64 make boot-repacked.img extracted/kernel extracted/ramdisk extracted/kernelimage extracted/devicetree.dtb
the result is only 38M large, the original is 55M, which seems already fishy. When I flash it anyway (using heimdall if it matters), it results in a bootloop.
So my questions are:
Am I using your tool wrong? Is the Samsung S9 not supported? Or is it a bug?
Another thing that puzzles me:
imjtool unpacks
Code:
devicetree.dtb kernel kernelimage ramdisk
abootimg unpacks
Code:
bootimg.cfg initrd.img zImage
So I know abootimg apparently misses the DTB (and "kernelimage" which is the .config used when the kernel was built) - But is your tool missing the info in bootimg.cfg (e.g. kernel command line?)
Thanks for your work/help!
This is what imjtool printed when extracting, in case it matters:
Code:
Boot image detected
Part Size Pages Addr
Kernel: 29126664 14223 0x10008000
Ramdisk: 9880749 4825 0x11000000
Secondary: 0 0 0x10f00000
Tags: 0x10000100
Flash Page Size: 2048 bytes
DT Size: 1787904 bytes
ID: d251a0a387fd671226676852a14905ff726e6c79000
Name: SRPQH16B002KU
CmdLine: androidboot.selinux=permissive androidboot.selinux=permissive
Found GZ Magic at offset 13352456
extracted/kernelimage.gz:
gzip: extracted/kernelimage.gz: decompression OK, trailing garbage ignored
57.7% -- replaced with extracted/kernelimage
Extracting kernel
Extracting ramdisk
Searching for DT at 0x2534800
Found DT Magic @800
Hi Arcepth,
Odd; I have an S9 myself, and re-creating the image worked for me way back when I tried it. Could you do me a favor and send your boot.img? DM is fine.
The kernel command line should be taken from the boot.img, (the .cfg file abootimg generates is artificial). You can specify cmdline= to imjtool and it will embed that cmdline.
Samsung's odd with their device tree. They put it as the secondary, whereas others just fuse it to the kernel.
Any deviation from what Samsung expects will boot loop. I know this the very hard way
Anyway, DM me.
Using imjtool on S20 boot.img
I am having the same issue with Galaxy S20's "boot.img".
The original is ~60MB but after repack is ~38MB
-----------------------------Log---------------------------
root:/home/tools/imjtool# ./imjtool.x86_64 boot.img extract
Boot image detected
Part Size Pages Addr
Kernel: 37801996 18459 0x10008000
Ramdisk: 889691 435 0x11000000
Secondary: 0 0 0x10f00000
Tags: 0x10000100
Flash Page Size: 2048 bytes
DT Size: 2 bytes
ID: ##################################
Name: S##########
CmdLine: androidboot.hardware=exynos990 androidboot.selinux=permissive androidboot.selinux=permissive
Found GZ Magic at offset 16951272
extracted/kernelimage.gz:
gzip: extracted/kernelimage.gz: decompression OK, trailing garbage ignored
62.7% -- replaced with extracted/kernelimage
Extracting kernel
Extracting ramdisk
Searching for DT at 0x24e7800
Unable to locate device tree
-----------------------------------End Log---------------------------------
My command for repack:
roothome:/home/tools/imjtool# ./imjtool.x86_64 make boot2.img extracted/kernel extracted/ramdisk extracted/kernelimage [cmdline='androidboot.hardware=exynos990 androidboot.selinux=permissive androidboot.selinux=permissive'] [addr=0x10008000]
I didn't try to flash this though.
Thank you for the feedback! The tool is built around my use cases, but I don't get to experience all the crazy variants in image formats out there..
Anyway - I got this one: It took a bit to figure out but Samsung shoves a LOT of stuff after the DT which isn't part of the boot.img specification, as well as stuff which now is (AVB0) but I wasn't aware of when I started imjtool. So - I'm updating imjtool to handle this. I can already reliably detect and extract all their extras:
Code:
[email protected]öst (~/Documents/Android/src/Imjtool) %./imjtool ~/Downloads/boot.original.img
Boot image detected
Part Size Pages Addr
Kernel: 29126664 14223 0x10008000
Ramdisk: 9880749 4825 0x11000000
Secondary: 0 0 0x10f00000
Tags: 0x10000100
Flash Page Size: 2048 bytes
DT Size: 1787904 bytes
Found Samsung DTBH @0x2534800 with 6 trees
[email protected] (0x49000 bytes): Chip:0x2652 Platform:0x50a6 subtype:0x217584da hw_rev:0x10-0x10
[email protected] (0x49000 bytes): Chip:0x2652 Platform:0x50a6 subtype:0x217584da hw_rev:0x11-0x11
[email protected] (0x48800 bytes): Chip:0x2652 Platform:0x50a6 subtype:0x217584da hw_rev:0x12-0x13
[email protected] (0x48800 bytes): Chip:0x2652 Platform:0x50a6 subtype:0x217584da hw_rev:0x14-0x16
[email protected] (0x48800 bytes): Chip:0x2652 Platform:0x50a6 subtype:0x217584da hw_rev:0x17-0x19
[email protected] (0x48800 bytes): Chip:0x2652 Platform:0x50a6 subtype:0x217584da hw_rev:0x1a-0xff
DTBH block ends @0x26e9000
Warning: DT ends 0x26e9000, but filesize is 0x3700000 - looking further
Found [email protected]
ID: d251a0a387fd671226676852a14905ff726e6c79000
Name: SRPQH16B002KU
CmdLine: androidboot.selinux=permissive androidboot.selinux=permissive
And I'm working on finalizing a "repack" command which will use the base boot.img you provide and just enable the select overriding of portions or values.
Please try this build: http:// NewAndroidBook.com /tools /imjtoolbeta.tgz
You can use repack (base.img) and then change a variety of parameters. New image will be repacked.img in same dir.
Repacked size looks better now
Tried the beta and it looks much better! The "repacked.img" is much closer to the original size (I tried with a kernel built from official source code).
Only issue left is that ODIN fails to flash my created "boot.img.tar" file to the S20.
Just see a generic "RQT_CLOSE" message on ODIN.
Any clue what I'm missing? (already LZ4 compressed, tarballed with various methods, even disabled AVB)