• Introducing XDA Computing: Discussion zones for Hardware, Software, and more!    Check it out!

[TOOL] imjtool - Unpack and extract a variety of OTA images from various vendors

Search This thread
Mar 24, 2020
43
39
NewAndroidBook.com
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
 
Last edited:

Typhus_

Senior Member
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?
 
Last edited:
Mar 24, 2020
43
39
NewAndroidBook.com
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?



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?
 
  • Like
Reactions: Muhammad.hasnain

Typhus_

Senior Member
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?

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.
 
Mar 24, 2020
43
39
NewAndroidBook.com
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..


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.
 
  • Like
Reactions: Muhammad.hasnain

Typhus_

Senior Member
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..

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.
 
Mar 24, 2020
43
39
NewAndroidBook.com
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

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.
 
  • Like
Reactions: Muhammad.hasnain

Typhus_

Senior Member
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

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.
 

bagbyte

Member
Aug 16, 2009
24
6
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

Member
Aug 16, 2009
24
6
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...


Update: I've found my answer: https://forum.xda-developers.com/showpost.php?p=82241115&postcount=70
 
Mar 24, 2020
43
39
NewAndroidBook.com
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

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...
 
  • Like
Reactions: jherwig

scholbert

Senior Member
Aug 1, 2007
1,347
814
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
 

arcepth

New member
Apr 17, 2020
3
0
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
 
Last edited:
Mar 24, 2020
43
39
NewAndroidBook.com
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.
 

nclman

New member
Jul 2, 2020
3
0
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.
 
Mar 24, 2020
43
39
NewAndroidBook.com
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.
 
Last edited:
  • Like
Reactions: nclman and arcepth

nclman

New member
Jul 2, 2020
3
0
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)
 

Top Liked Posts

  • There are no posts matching your filters.
  • 16
    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
    3
    @morpheus______
    Just found this and using it now. It is very useful and thank you. I am glad to see you are still maintain this.
    Yep. Still maintaining and also up to v1.10, which can do Chrome Auto Update (CrAU) and FBPK/FBPTv2 (used in nexus 6 (oriole/raven) factory images, as well as vendor boot and android boot v4.

    Note I'm working on repack (to allow super.img and vendor boot) so functionality of repack may be broken. This is fixable, and will be stable again by v1.11
    3
    Update to tool:

    - Now supports "payload.bin" (Chrome Auto Updater, CrAu format), and integrates with bz2, xz, gz natively.

    - ..partition...new.dat.br with ...partition...transfer.list (Brotli compression) works well, though you might need to specify the number of blocks manually

    - Also supports android bootimg v3, and vendor_boot images.

    Bug or feature reports welcome.

    Download link: http://NewAndroidBook.com/tools/imjtool.html
    2
    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.
    1
    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?



    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?