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..
Just 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.
Darwin users: remember to xattr -d com.apple.quarantine /path/to/imjtool to get past annoying GateKeeper
Why 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...
Lastly - If you're downloading a rooting tool - and you want to avoid getting malware. I just downloaded An NVIDIA Shield root image, for example - which is really nothing more than a bootimg. So it was trivial to run this tool to extract it - specifically, get to the ramdisk, then cpio -ivd and make sure I can have a peek at it before installing.
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?
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:
Version 0.2 Changes
Supports offset= (for HTC and other boot.imgs where ANDROID! is wrapped)
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.
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:
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.