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

It has been a while since our last unblob update, and with the release of 26.3.24 this is a good time to look at what changed since our previous 25.11.25 release, 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 Unix FileSystem (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 easier to navigate.

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.

A More robust extraction

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.

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.

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 (millions of syscalls on very large firmware).

Process handling also became more robust. We fixed a failure mode where unblob could keep running even after a MultiPool worker had terminated or crashed, and now the main process detects that condition and exits cleanly instead of continuing in a broken state. That makes signal handling and worker supervision much more predictable in automated runs, and the accompanying tests now cover those termination paths directly.

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

Documentation, packaging, and release hardening

A significant part of the work since v25.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 management easier for us.

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 and early 2026.

In their thesis titled "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 "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 "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 CONTINUES

We've setup an internship program since 2023 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. We're really happy to have him on board !

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.