Add more file formats for Container Browser to unpack/decompress

[UvuvDev]

What is the feature you'd like to have?
One of the most tedious things to do is extract the runtimes out of firmware. If it is not a simple binwalk -E ./firmware.bin, and instead is multiple layers of compression and filesystems, it is really annoying to have to deal with it. Example: the Google Pixel 11 Pro modem.img has 11 layers of transforms/extractions. I would like to either add a plugin to do the extraction, or expand on the container browser system to support this.

Architecture is kind of the issue here: how do we support 50+ formats without creating an insane amount of technical debt? Of course dependencies are a good option until licensing gets involved. Things like ZIP, TAR, should be easy enough, but proprietary Android filesystems? And how aggressive should we be with recursive extraction/decompression? How do we handle false positives?

I am currently working on a plugin to do this but I'm not sure the costs vs benefits of using a plugin vs integration into core, besides licensing. I am basically just adding platforms and support until something breaks / gives, and if it doesn't then I'll put it out and we could integrate it as a core plugin.

[zznop]

How is what you're describing not handled by Container Transforms: https://binary.ninja/2026/03/31/container-transforms.html

We support over 10 container formats natively, and you can write container transform plugins to extend it. It also does recursive extraction.

Also, we have an official plugin that uses the unblob API on the backend here: https://github.com/Vector35/blob_extractor

[UvuvDev]

The container view at the moment I would say is best suited for things like malware triage: Base64 decoding, ZIP extraction, TAR extraction, these are all very useful but for OTA firmware updates it isn't enough. It will usually get one layer deep and then hit a wall, and it is the easiest layer to handle. I'll rename the issue to extending container formats then: I did not realize Container Transforms were recursive, so it is definitely better to just extend that. In terms of plugins vs native support I am not sure which is better for this so I will ask around to see what the cost-benefit is, besides the obvious.

#8301

Brian linked me this issue that is open, which I think is necessary to add if we want to deal with full filesystems.

[zznop]

Yeah, #8301 is necessary to represent the directory structure of firmware extractions in projects. But, you could totally add more container transforms to extract about any image. The problem is every vendor has a different format for distributing firmware updates (containing many different nested formats). We've added support for some of the common ones:

>>> list(Transform)
[<transform: Deflate>, <transform: Gzip>, <transform: Zlib>, <transform: Bzip2>, <transform: LZMA>, <transform: LZMA2>, <transform: LZ4Block>, <transform: LZ4Frame>, <transform: Zstd>, <transform: LZF>, <transform: XZ>, <transform: Zip>, <transform: CaRT>, <transform: Tar>, <transform: AR>, <transform: CPIO>, <transform: DMG>, <transform: UImage>, <transform: FIT>, <transform: TRX>
...

But there are thousands of container formats out there.

[UvuvDev]

Yeah we can hopefully get the most common ones, prioritizing the ones that send unencrypted firmware OTA (ex. Google) since their formats are immediately usable instead of requiring a rooted phone or device to be an oracle. There's more than Google but they are the ones I can think of off the top of my head who do plain-text for most things.

Brian says that a plugin would be best here because of licensing issues with proprietary formats, which is fair. I will look into it further, as the plugin I have right now is independent of the container browser but can probably be ported easily.