imjtool (formerly known as imgtool)
The imjtool
utility is another one of the tools I'm including in my book, this time to accompany the chapter about the Boot process. I deal a lot with the internal format of images there, and realized I needed a quick extractor. This became more important when I started to deal with the L preview, and Google Glass system images I used for research. Over time, as I've encountered more and more proprietary image formats, I've had to extend the tool to support them all. I've also had to change the name (from imgtool
to imjtool
, as of March 2020) since it turns out the former was taken up by MAME..
By any name, you can get the tool:
-f
and range extraction). June 2024Just unpack the tar. There are macOS (Intel), Linux x86_64 and Android ARM64 images (remember they might need chmod +x to run, and prefix with ./). As usual, you might want to check out the RSS feed, or follow my company's Twitter for more updates.
xattr -d com.apple.quarantine /path/to/imjtool
to get past annoying GateKeeperWhy should I care?
Well, most users wouldn't. But if you need a quick tool to unpack Android images, this is useful. Think of it as the inverse of mkbootimg (from the AOSP), coupled with simg2img (the sparse image extractor). Another bonus feature it provides is unpacking the Linux bzimage kernels.
Also, if you're a Darwin user, there's no good LZ4 or XZ built-in to the system.
And if you're ever encountered a broken ZIP file and unzip wasn't too helpful...
Version 2.0 (6/2024) also allows searching inside an image, and range extraction.
What if it doesn't work on _________ (some image or file)?
LET ME KNOW. There are myriad image formats and corner cases which I don't normally run into, but you likely will. If I know about them (preferably through a download link to the image) I can easily fix it.So how do I use it?
Like So:
To obtain an Android system image, you can either get it from a zip (e.g. Google's update, Amazon's update.bin, etc), or by dd
'ing for a device, then copying it over. Note that some devices (e.g. the HTC One M8) may need a bit of processing, in this case stripping the 256 header HBoot uses:
If you're using the Google images, it's easier:
You can also use it to extract the filesystem image (basically, do what simg2img
does:
Lastly, you can use it for imgdata extraction as well (as the file format there is derived from that of the boot image:
ChangeLog
Version 0.2 Changes
- Supports offset= (for HTC and other boot.imgs where ANDROID! is wrapped)
- Supports cmdline= (to override kernel command line)
Version 0.3-0.4 Changes
- Supports making images (similar functionality to mkbootimg) with the "make" argument
Version 0.5 Changes
- Minor updates to support cases where kernel can't be decompressed (notably, Samsung 6Edge - Thanks, Dan!)
- Update with LZ4 binaries
Version 0.6 Changes
- Samsung images (with DT > 0) - Device Tree now found on next page after ramdisk
Version 0.7 Changes
- Now works on MTK system.new.dat/system.transfer.list files (read more about the format)
Version 0.8 Changes
- Now also unpacks Huawei images!
- .. and Pixel 3 (Qcom Snapdragon 845) images!
Version 0.85 Changes
- Now also unpacks MTK and other system.transfer.list version 4 images
Version 1.0 Changes
- Finally , Version 1.0 :-)
- Built-in GZ/LZMA
- Full support for EFI firmware files, SCAP, MacEFI images, etc - so now you can extract QCOM xbl/abl further!
- ..And Apple's (yep, Apple's) T2 EFI images, Firmware.scap,etc:
I generally recurse when I can detect layering, but - you might need to run this tool more than once since many images have multiple layers of encapsulation:
I don't purport to cover all EFI GUIDs here. Your favorite tool is probably better. I built this for my own use cases (primarily, command line, greppable, scriptable, cross platorm), and I think it's useful enough to provide freely. If your specific image isn't supported, you can always drop me a line. Ranting on twitter denigrating my work and/or me won't help. And btw, you're welcome.
Version 1.2 Changes
- Supports super.img images (liblp logical partitions)
- Supports DTBO
- Supports Samsung TOC
- Supports Brotli compressed (....new.br) block based images. For now, work with me and supply the number of blocks by getting them from the ...transfer.list (second line):
v2.0(β) - ZIP/XZ/LZ4/BZ2 support
Including partial zips! For example:
v2.0 - -f
and range extraction
Three useful features:
-f:
: A simple but useful feature enabling you to search for a string (or non-printable bytes, using '\x' escaping).
extract 0x...-0x....
: Will extract a specified range (which is easier for my workflow than messing with dd bsize=... skip=.... count==..
extract 0x...+0x....
: Will extract a the +..
count of bytes from the specified start.
Shameless plug for the book, and RFC
Android Vol II is out - and now I'm onto III (security) and IV (hardware/advanced topics). In the interim, I encourage you to try out the tool (as well as the even more powerful Dextra, and the simple but useful bindump) and, of course - JTrace. Shoot me an email (to j@) if you've any questions. Or comments. Or in general. All are welcome.
If you want to learn all about Android Internals, please check out the Android Internals & Reverse Engineering Training course my company, Technologeeks, offers. The next training is likely only a few months away!
Version 0.5 Changes
Version 0.6 Changes
Version 0.7 Changes
Version 0.8 Changes
Version 0.85 Changes
Version 1.0 Changes
I generally recurse when I can detect layering, but - you might need to run this tool more than once since many images have multiple layers of encapsulation:
Version 1.2 Changes
- Supports super.img images (liblp logical partitions)
- Supports DTBO
- Supports Samsung TOC
- Supports Brotli compressed (....new.br) block based images. For now, work with me and supply the number of blocks by getting them from the ...transfer.list (second line):
v2.0(β) - ZIP/XZ/LZ4/BZ2 support
Including partial zips! For example:
v2.0 - -f
and range extraction
Three useful features:
-f:
: A simple but useful feature enabling you to search for a string (or non-printable bytes, using '\x' escaping).extract 0x...-0x....
: Will extract a specified range (which is easier for my workflow than messing withdd bsize=... skip=.... count==..
extract 0x...+0x....
: Will extract a the+..
count of bytes from the specified start.
Shameless plug for the book, and RFC
Android Vol II is out - and now I'm onto III (security) and IV (hardware/advanced topics). In the interim, I encourage you to try out the tool (as well as the even more powerful Dextra, and the simple but useful bindump) and, of course - JTrace. Shoot me an email (to j@) if you've any questions. Or comments. Or in general. All are welcome.
If you want to learn all about Android Internals, please check out the Android Internals & Reverse Engineering Training course my company, Technologeeks, offers. The next training is likely only a few months away!