For over a decade, reverse engineers, hardware security auditors, and IoT penetration testers have faced an exhausting bottleneck: extracting and analyzing embedded firmware safely. Legacy utilities like Binwalk—while revolutionary in their time—have devolved into brittle webs of external dependencies, Python wrappers, unmaintained decompression utilities, and severe command-injection risks. In a groundbreaking release presented by IoT security researcher Matt Brown, two modern C++20 companion tools, Moria and Mithril, redefine how embedded software is mapped, extracted, and audited without root privileges or external dependencies.
The Firmware Extraction Bottleneck: Why Legacy Tooling Fails
Modern connected devices—from smart cameras and industrial PLCs to automotive gateways and home automation hubs—run deeply stripped operating systems. When an auditor captures a flash dump via SPI flash desoldering, UART bootloader interruptions, or manufacturer update interception, the resulting binary is typically a multi-layered composite blob. It often bundles bootloader offsets, device trees, compressed kernels, and nested read-only filesystems.
Traditionally, extracting these filesystems required invoking binwalk -e. However, Binwalk does not perform filesystem extraction natively. Instead, it delegates unpacking to external host system binaries:
sasquatchorunsquashfsfor SquashFS partitions.jeffersonfor JFFS2 volumes.ubireaderfor UBI and UBIFS images.- Custom host utilities for cramfs, romfs, and Android sparse archives.
Because legacy extraction tools rely on shell-outs and unhardened C/Python parsers, malicious or weaponized firmware images can exploit directory traversal flaws (such as symlinks pointing outside the extraction root) or command injection vulnerabilities. Past CVEs demonstrated that running automated scanners against untrusted firmware images on CI/CD runners could grant remote attackers arbitrary code execution on the host machine.
Furthermore, legacy workflows frequently required sudo or root permissions to mount loopback filesystem drivers or reconstruct device nodes in /dev. In modern containerized CI/CD environments and automated LLM-driven security pipelines, granting root execution to untrusted third-party binaries is a non-starter.
Moria: In-Process, Deterministic Firmware Unpacking
Developed by security researcher Matt Brown (founder of Brown Fine Security), Moria is an identification and extraction engine written in clean C++20. Unlike shell-based wrappers, Moria parses headers, computes checksums, and unpacks filesystems entirely in-process, without spawning external system binaries and without requiring sudo.
Core Capabilities of Moria
- Broad Native Filesystem Support: Directly extracts SquashFS (supporting gzip, xz, lz4, and zstd compression), ext2/3/4, F2FS, FAT12/16/32, exFAT, NTFS, HFS+/HFSX, XFS, btrfs, JFFS2, UBI/UBIFS, romfs, YAFFS2, cramfs, and EROFS.
- Recursive Unpacking by Default: Automatically handles nested multi-stage containers. If an image contains an outer UBI volume holding a gzip-compressed SquashFS layer, Moria unpacks each layer down to the raw root filesystem.
- Hostile Input Hardening: Every binary read is strictly bounds-checked. File writes enforce sandboxed path traversal prevention using POSIX
openatwithO_NOFOLLOWflags, guaranteeing that malicious symbolic links cannot overwrite host operating system files. Decompression streams enforce strict ratio limits to neutralize decompression bombs. - Deterministic Structural Identification: Eliminates random tie-breaking. Every identified partition reports an exact byte offset, partition type, and confidence score.
- Machine-Readable JSON Output: When passed the
-jflag, Moria emits structured JSON telemetry, allowing scripts, security orchestrators, and AI agents to programmatically parse extracted structures.
| Feature Dimension | Legacy Toolchain (Binwalk / Scripts) | Moria (C++20 Engine) |
|---|---|---|
| Execution Architecture | Spawns external host processes (unsquashfs, 7z, cpio) | 100% In-process C++20 extraction |
| Privilege Requirements | Often requires sudo for loopback mounts/nodes |
Unprivileged user (Zero root required) |
| Path Traversal Protection | Vulnerable to malicious symlink escapes (CVE history) | Strict openat + O_NOFOLLOW sandboxing |
| Decompression Safety | Unbounded; vulnerable to zip/archive bombs | Bounded decompression ratio & byte caps |
| Output Serialization | Ad-hoc terminal text scraping | Native deterministic JSON (-j) |
Mithril: Semantic Static Scanner for Embedded Security
While Moria maps and unpacks the physical bytes of an image, Mithril operates on the extracted files and directory structures. Pointed at any single binary or unpacked rootfs directory, Mithril conducts static audits across four security vectors:
1. Deterministic Secret & Key Verification
Rather than relying on noisy regex pattern matching that floods security reports with thousands of false positives, Mithril implements an offline verification ladder:
- Pattern Recognition: Matches known structural entropy and format archetypes.
- Syntactic Parsing: Fully parses the cryptographic structure (e.g. validating ASN.1 headers in PEM certificates, private RSA/EC keys, or JWT token signatures).
- Algorithmic Validation: Recomputes check-digits and token checksums (such as GitHub personal access tokens, AWS credential formats, and crypt password hashes).
This ladder ensures that reported secrets are verified and structurally valid before notifying security teams.
2. Firmware-Aware SBOM Recovery
Standard Software Bill of Materials (SBOM) scanners inspect package management databases like dpkg, rpm, or Alpine's apk. Embedded IoT firmware almost never retains these databases to save storage space.
Mithril bypasses this limitation by interrogating ELF headers, compiled version banners, versioned shared library exports (such as libc.so.0, uClibc, and musl), and Linux kernel strings. It identifies embedded packages like BusyBox, OpenSSL, Dropbear SSH, and dnsmasq even in completely stripped images, exporting standardized CycloneDX and SPDX manifests.
3. End-to-End CVE Attribution & Kernel Checklists
Once components and kernel versions are identified, Mithril queries local vulnerability mirrors (OSV and NVD/CPE datasets) without making any network calls at scan time. It correlates detected versions against a version- and Kconfig-gated kernel CVE checklist, annotating results with CISA KEV (Known Exploited Vulnerabilities) and EPSS (Exploit Prediction Scoring System) data to highlight actively weaponized vulnerabilities.
4. Open-Source License Governance
For connected hardware manufacturers, shipping proprietary products containing uncredited GPLv2 or AGPL-licensed code represents serious legal and supply-chain liability. Mithril automatically extracts embedded licenses across binary images, providing legal clarity prior to commercial distribution.
Hands-On Workflow: From Flash Binary to Threat Intelligence
Combining Moria and Mithril creates an end-to-end audit pipeline that takes an unknown flash dump and produces actionable threat intelligence in seconds:
# Step 1: Identify and unpack firmware into isolated directory
moria -e target_device_firmware.bin -C ./firmware_rootfs
# Step 2: Audit extracted filesystem for secrets, SBOM, and CVEs
mithril -j ./firmware_rootfs > security_audit.json
# Step 3: Inspect high-priority findings via command-line filters
jq '.vulnerabilities[] | select(.cisa_kev == true)' security_audit.json
A critical design advantage of Mithril is zero network egress during scans. Sensitive proprietary firmware images, pre-release consumer electronics, and classified defense hardware can be analyzed entirely within air-gapped security enclaves without telemetry leakage.
Defensive Engineering: Hardening IoT Devices Against Reverse Engineering
The availability of deterministic in-process extraction tools highlights the urgency for device manufacturers to strengthen hardware and software security postures:
- Cryptographic Secure Boot: Implement hardware-enforced root-of-trust (such as ARM TrustZone, secure boot ROMs, or dedicated HSMs) to verify signed bootloaders and kernels before execution, preventing tampered firmware from booting.
- Flash Encryption at Rest: Use hardware-accelerated AES flash encryption (available on ESP32, i.MX, and STM32 microcontrollers) so that desoldered flash chips yield only ciphertext.
- Debug Interface Deprovisioning: Permanently blow eFuses or physically isolate JTAG, SWD, and UART pads on production circuit boards to block physical bus tapping.
- Credential Hygiene: Eliminate hardcoded private keys, default root passwords, and staging certificates from production root filesystems. Use unique per-device certificates provisioned during factory test flows.