Latest Developments in Unblob: New Formats, Smarter Extraction, and a More Hardened Release Pipeline

It has been a while since our last unblob update, so this is a good time to look at what changed since release 25.11.25, which was published on November 25, 2025.

The short version is: unblob learned a lot of new tricks over the last few months. We expanded format support in several interesting directions, improved extraction workflows for real-
world use, fixed a few annoying edge cases, and kept tightening the project around testing, packaging, and supply-chain security.

Let’s dive into the biggest changes.

Unblob & Friends

First and foremost, we wanted to express our gratitude to people spreading the unblob's gospel. Specifically, we wanted to thank:

• all the contributors that reported issues, opened pull requests or simply discussed all things unblob
• Trail of Bits for mentioning unblob when walking the reader through their DistrictCon's Junkyard competition winning entry
• 0x0j for mentioning unblob at the end of their SPI flash dumping tutorial

Again, if you used unblob in your work, hobby, or in workshops tell us at research@onekey.com ! Even if you used it during that one pentest we want to know :)

More formats from the firmware wilderness

One of the most visible areas of progress is format coverage. Since v25.11.25, the number of documented handlers and variants in unblob grew from 71 to 83.

What's great about those handlers is they're mostly coming from external contributions.

On the archive side, unblob now supports MSI files, which makes it easier to inspect Windows installer payloads without leaving the usual workflow. MSI support is currently partial rather
than full semantic MSI extraction, but it is already useful for carving and exploring installer contents.

We also added several D-Link-related formats: Alpha encimg firmware images in two variants, DEAFBEAD archives, and FPKG archives. This makes unblob much more useful when dealing with older or vendor-customized D-Link images.

QNAP networking firmware support also landed. This is separate from the existing NAS-oriented work and specifically targets networking device images encrypted with the PC1 cipher. In practice, this means unblob can now handle another class of vendor-specific encrypted firmware that previously required custom tooling.

On the compression side, unblob gained support for QNX deflate and for UCL compression. These two changes complement each other nicely, because QNX deflate can use either LZO or UCL internally. The result is better handling of QNX-related samples without having to bolt on format-specific one-offs everywhere. We were already supporting UCL compression through our private QNX filesystem handlers, so we've technically open-sourced the UCL decompressor.

We also added support for Xamarin compressed assemblies, which is helpful when dealing with mobile or embedded .NET ecosystems where assemblies are stored in compressed form instead of as plain DLLs.

On the filesystem side, unblob now recognizes UFS1 and UFS2. Extraction is still limited there, so this is currently more about identification and carving than full filesystem unpacking,
but we're working on extraction. There are some open-source extractors for UFS but their version support is split and all of have limitations like the inability to create empty files. We know Sleuthkit has partial support for it, but we've decided against having Sleuthkit as a dependency given its size and its own dependencies.

Finally, SquashFS support got broader again. unblob now supports non-standard SquashFS v2 signatures as well as SquashFS v4 Broadcom variants. If you spend enough time with firmware images, you quickly learn that “standard format” often means “standard until a vendor decides otherwise,” so this kind of compatibility work pays off quickly.

Better extraction workflows

Not every improvement is about adding a new handler. Some of the most practical changes are about making unblob easier to use in larger workflows.

One example is the new --delete-extracted-files option. A common pattern in recursive extraction is that one handler produces an intermediate file, which is then immediately consumed by another handler. Keeping every intermediate artifact is useful for debugging, but it is not always what you want in production or large-scale analysis runs.

With the new option, users can remove fully extracted intermediate files automatically. This can be enabled for all handlers or restricted to selected handlers only. That makes it much
easier to keep output trees manageable without giving up recursive extraction.

Another small but important addition is --no-sandbox. unblob’s sandboxing is valuable, but there are times when you want to disable it temporarily, especially during debugging sessions or
when working with breakpoint-based tooling. Having an explicit opt-out makes those workflows less awkward.

We also extended the plugin system so plugins can register custom report types. That may sound like an implementation detail, but it is actually a useful step for teams integrating unblob
into larger analysis platforms. It allows plugins to emit richer structured metadata without forcing everything into the built-in report model.

More robust extraction in the weird cases

A lot of engineering work in unblob goes into edge cases that only become obvious once you run the tool at scale or throw malformed samples at it.

Gzip handling is a good example. unblob now merges concatenated gzip members into one chunk instead of treating them as separate fragmented outputs. This matches how such files are
commonly expected to behave and avoids confusing results for downstream users.

Tar handling also got better. We fixed support around GNU timestamp prefixes and made extraction filtering more explicit. Tar archives are deceptively simple until you hit historical
variants and vendor quirks, so these smaller fixes matter more than they may seem.

The extfs handler received an important hardening fix as well. malformed superblocks could previously trigger excessive memory use, and this is now handled much more safely. This OOM bug was identifed by oss-fuzz, check out https://issues.oss-fuzz.com/issues/471508504 for more details.

Performance and testing

There were also a few focused performance improvements.

Memory-mapped File objects now use MADV_SEQUENTIAL, which gives the kernel a better hint about access patterns during sequential reads. On top of that, File.size() now uses len() instead of going through fstat(), which avoids unnecessary overhead.

These are not flashy changes, but they are exactly the kind of small improvements that help when unblob is processing large samples repeatedly.

TODO: explain proc termination
Testing also improved in a meaningful way. We added end-to-end tests around process termination behavior, covering cases like signals and worker crashes. This is the kind of test coverage that becomes increasingly important as tools move from “works on my machine” utility status into production pipelines and automation environments.

Documentation, packaging, and release hardening

A significant part of the work since 25.11.25 went into project quality and maintainability.

The documentation got a substantial refresh, including an improved README, a new CONTRIBUTING.md, and better development guidance. Handler documentation was also cleaned up, and handlers can now opt out of generated public docs when needed. That helps keep the public format list useful without exposing entries that are not meant to be documented.

On the packaging and CI side, unblob is now tested against Python 3.14 in CI, and wheel-building was improved across platforms. We also added automatic GitHub Release creation on tag
push, which makes releases easier to consume.

Security and supply-chain hardening saw a lot of attention too thanks to gh-guard. GitHub Actions are now pinned to full commit SHAs, workflow permissions were tightened, persist-credentials was disabled on checkout steps, OpenSSF Scorecard was added, OSV alerts were enabled in Renovate, cargo-deny was introduced, and the Rust toolchain is now pinned explicitly.

None of these changes alter how unblob extracts firmware on their own, but together they make the project easier to trust, easier to contribute to, and easier to ship safely.

Unblob & Academic Research

Unblob was actively used by the academic research community in 2025.

In From Constraints to Cracks: Constraint Semantic Inconsistencies as Vulnerability Beacons for Embedded Systems presented at USENIX Security 25 by Zhao, J. et al., the authors explain in "Discussion and Limitation" that:

Binwalk and Unblob are the most widely used tools for firmware unpacking, both relying on underlying libraries to support diverse firmware formats. Compared to Binwalk, Unblob provides more convenient usage and integrates automated analysis for certain encrypted firmware, reducing manual effort. Leveraging Unblob, NÜWA can automatically analyze vulnerabilities such as CVE-2024-27129 and CVE-2024-27130 with minimal human intervention

In Vulnerability Assessment of Low-Cost IoT Devices: Towards a Virtual Hardware Security Training Environment by Alessandro Genova, the author used unblob to extract MTD partitions.

In Target-Centric Firmware Rehosting with Penguin by Fasano, Andrew, et al. the authors explain in "Implementation" that:

Binwalk and unblob are two open-source filesystem extractors that recursively scan binary blobs for filesystems and extract their contents. Binwalk has been widely used in the literature for both static and dynamic analysis of firmware images, but its development stalled since 2021, only later to be rewritten. The rewrite (Binwalk v3), while a positive development, was yet to meet feature parity at the time of writing while many of the previous version’s extractors suffer from known flaws. Recently, unblob was released as an alternative filesystem extractor designed to improve upon the capabilities of Binwalk. In limited testing we found unblob to outperform Binwalk 2.x in terms of both speed and accuracy, often by a wide margin. However, unblob does not support every filesystem format that Binwalk does, and neither tool is designed to preserve filesystem permissions or symlinks.

We hope we've closed the gap since then. Andrew's contributions, be it issues, discussions or pull requests pushed unblob forward and in the right direction. Thanks again :)

Internship Program

We're trying our best to setup some kind of internship program for unblob where CS students can join the unblob maintainer team and either focus on writing handlers or help improve unblob core. Something similar to Google Summer of Code.

In 2023, Antoine joined us and released a steady flow of new handlers (almost one every week over the course of his 14 weeks internship !).

In 2025, Raphael joined us and released a handful of complex handlers including EROFS, UPX, and partclone.

In 2026, Logan already released 3 new format handlers since he joined us 8 weeks ago.

Closing thoughts

Overall, the first few months of 2026 were a strong cycle for unblob.

We expanded support for a number of formats that routinely appear in real firmware analysis, improved extraction ergonomics for recursive workflows, fixed several robustness issues, and
kept investing in the surrounding engineering work that makes an open-source tool sustainable.

A nice side effect of this cycle is that several of these improvements came from community contributions, particularly around new formats. That kind of input continues to be one of the
best ways for unblob to grow in the right direction: toward the weird formats and awkward edge cases that analysts actually encounter.

As always, if you run into a format unblob does not yet support, let us know. Chances are it is weird enough to be interesting.