HouseFuzz: Service-Aware Grey-Box Fuzzing for Linux Firmware

“With the rapid proliferation of IoT devices, Linux-driven firmware is widely deployed in routers, NAS, cameras, and other terminals. However, numerous vulnerabilities present in these network services pose serious security risks. Traditional firmware fuzzing tools have inherent shortcomings in service identification, fuzzing feedback collection, and the generation of semantically valid inputs, leading to limited exploration space and a high rate of missed vulnerabilities. HOUSEFUZZ is a “service-aware” grey-box fuzzing system specifically designed to improve the multi-process service and custom protocol scenarios of Linux-based firmware. ”

• 📄 Paper Title: HouseFuzz: Service-Aware Grey-Box Fuzzing for Vulnerability Detection in Linux-Based Firmware
• 📅 Publication Date: IEEE Symposium on Security and Privacy (SP),2025
• 🏫 Author Affiliation: Fudan University

• ⚙️ Open Source Code： https://github.com/seclab-fudan/HouseFuzz

01

—

Method Introduction

HouseFuzz focuses on the core issue of “why firmware fuzzing has long been ineffective” by introducing service awareness, multi-process coverage collection, and protocol semantic inference, providing a new breakthrough for the stagnated research in firmware fuzzing. Below is a quick overview of the core metadata of the paper:：

1. 🐾 Holistic Service Identification: Traversing system initialization to locate network-facing, daemon, and utility processes, achieving more complete service simulation and recovery of startup commands.
2. 🔀 Multi-Process Fuzzing Framework: Based on multi-process coverage aggregation and multi-process vulnerability determination oracle, compensating for the narrow perspective of single-process fuzzing collection.
3. 🧩 Service-Protocol Guided Fuzzing (TDG): Introducing Token Dependency Graph (TDG) to model the token-level semantic constraints of custom firmware protocols, combining grammar (CFG) and TDG to generate semantically valid mutation test cases.

Figure 1. Example Vulnerability

• Figure 1 shows a buffer overflow vulnerability in Linux firmware, with the triggering process consisting of four steps:

1. Service Initialization: The ncc process automatically runs mini_httpd during system startup and binds a network port to wait for requests (L24-L26).

2. Request Sending: The attacker sends a malicious packet to trigger mini_httpd (L27-L28).

3. Request Processing: The handle_request() of mini_httpd parses the HTTP request, confirming it ends with “.ccp” at L34, and forwards it to ncc via a socket (L35-L36).

4. Vulnerability Triggering: After receiving the IPC request at L3, ncc calls ipc_handler() (L6). After several checks (L8, L13-L17), it executes the vulnerability code at L19, leading to a buffer overflow due to the lack of length validation on the input string when formatting to buf.

Figure 2. Method Framework Diagram

Summary: HOUSEFUZZ Workflow: System initialization traversal → Service identification → Multi-process fuzzing (coverage aggregation + multi-process oracle) → Online/Offline TDG inference → Protocol-aware test case generation.

02

—

Key Mechanisms

To achieve comprehensive awareness of firmware services and high-quality input generation, HOUSEFUZZ breaks down system capabilities into a series of core modules that collaborate. From initialization patching and service identification to multi-process coverage collection and protocol semantic inference, each module is designed around the three main goals of “improving simulation fidelity, expanding exploration space, and generating more effective test cases”.

Module	Implementation Highlights	Main Functions
Initialization (INIT) Simulation and Exception Patching	Based on QEMU tracing system calls/basic blocks, locate interrupt/suspend points and patch them to advance the initialization process	Discover more service processes that start during the initialization phase but are missed by traditional methods.
Network/Daemon Process Identification	Extract network channels and command lines through parameters of system calls like bind/execve, dynamically backtrack IPC keys to determine daemon processes	Recover real startup parameters and determine inter-process dependencies, ensuring simulation fidelity.
Multi-Process Coverage Collection	Assign independent coverage bitmaps for each process, merge bitmaps by ELF executables, and determine cross-process completion timing using TCE (Test Completion Event)	Guide mutations with full service process coverage to avoid missing paths that require inter-process collaboration to trigger.
TDG (Token Dependency Graph) Inference	Combine offline static (CFG/data/control flow analysis) and online string comparison instrumentation (strcmp) to construct three types of tokens (Path/Key/Value) and their dependencies	Generate high-quality test cases that meet semantic constraints, improving hit rates.

03

—

Experimental Results

The paper conducted extensive comparative experiments on real firmware datasets (baseline: GREENHOUSE / EQUAFL / Firm-AFL, etc.), with key conclusions as follows:

• 🔎 Service Discovery: On 60 extractable firmware images, HOUSEFUZZ identified 311 network-facing processes, far exceeding FirmAE’s 128 and GREENHOUSE’s 44, with significantly higher recall (HOUSEFUZZ ≈ 80.4%).
• 📈 Code Coverage: On 41 commonly fuzzable services, HOUSEFUZZ achieved an average edge coverage of 14,767, compared to GREENHOUSE’s 11,072, an improvement of approximately 24.8% (statistical test p < 0.01, effect size Â12 ≥ 0.71).
• 💥 Vulnerability Discovery: On the same 41 services, HOUSEFUZZ located 128 unique vulnerabilities (including 110 0-days), while GREENHOUSE identified 46 (40 0-days) — meaning HOUSEFUZZ discovered approximately 175% more 0-days. Overall, the experiments uncovered hundreds of vulnerabilities and obtained multiple CVE/CNVD.

Tool	#Services (Test Set)	Avg. Edge Coverage	#Unique Vulnerabilities
GREENHOUSE	41	11,072	46
HOUSEFUZZ	41	14,767	128

Summary: Advantages: Full-stack improvements (identification → simulation → multi-process feedback → protocol semantics), showing significant effects on real firmware, having reached numerous 0-days and completed disclosures. Limitations: (1) TCE detection relies on common waiting system calls (like select/poll), requiring engineering extensions to support other models; (2) TDG offline static analysis and online instrumentation have risks of false positives/negatives; (3) Multi-process collection incurs significant time/memory overhead.

📌 Conclusion

HOUSEFUZZ brings the concept of “service awareness” into firmware grey-box fuzzing: by discovering more services through complete initialization traversal, guiding exploration with multi-process coverage, and grasping the semantic constraints of custom protocols with TDG, it achieves significant improvements in code coverage and vulnerability discovery capabilities on real firmware. This design holds strong practical value and engineering reference significance for teams looking to implement automated vulnerability mining in manufacturer firmware or embedded device fields。

📣 Welcome to Discuss

• Do you think engineering teams should prioritize “enhancing simulation fidelity (supporting more syscalls / fewer patches)” or “investing in protocol reverse engineering to improve TDG coverage” in industrial applications?

• In your engineering environment, is a 6–7× runtime overhead acceptable for a more than 2× increase in 0-day discovery rate?

📌 Like + Bookmark + Share, your support is our greatest motivation to continue analyzing high-level software security papers!