Berkner Tech

Fuzzing Embedded Network Protocols With boofuzz

Fuzzing an embedded network protocol with boofuzz, from modeling the format to triaging a crash

Most embedded crashes come from input the developer never imagined: a length field that lies, a string with no terminator, a message out of order. Fuzzing automates finding them. With boofuzz you describe the protocol, and it generates the malformed traffic that breaks the parser. Here is how to fuzz an embedded device.

Why Fuzz an Embedded Target

Embedded parsers are written in C, run with no memory protection, and rarely see hostile input during development. That combination is exactly where fuzzing pays off: it explores the malformed inputs that code review and normal testing skip, and on embedded a parser crash is often a memory-corruption bug in disguise.

Step 1: Model the Protocol

Describe the message format once, marking which fields should be mutated:

Anatomy of a boofuzz fuzzable field showing the field type, baseline value, and fuzzable flag
from boofuzz import *
s_initialize('login')
s_string('USER', fuzzable=True)
s_delim(' ')
s_string('admin')
s_static('\r\n')

Step 2: Run It and Watch for Crashes

Point a session at the target, connect the request, and let it run while monitoring the device:

session = Session(target=Target(connection=TCPSocketConnection('192.168.1.50', 23)))
session.connect(s_get('login'))
session.fuzz()
Example output
[2026-06-01 12:03:11] Test Case: 1453
[2026-06-01 12:03:11]   sending 4096-byte USER field
[2026-06-01 12:03:12] FAIL: target did not respond after test case 1453
[2026-06-01 12:03:12] Suspected crash; saving reproduction case

Test case 1453 sent an oversized field and the device stopped responding. That reproduction case is now a concrete bug to root-cause, and on an MCU it is very likely a memory-safety issue.

Three Things Fuzzing Finds

What a fuzzing run typically surfaces:

Three things fuzzing finds in embedded protocols: parser crashes, memory bugs, and state confusion

Fuzzing Well

Model the protocol accurately so mutations reach deep code paths, monitor the target so you actually catch the crash and can reproduce it, and fuzz the parsers that face the network first. Building fuzzing into development catches these bugs before they ship, when they are cheap to fix.

Where This Fits

Protocol fuzzing of a device’s network-facing parsers is a standard part of a penetration test. That testing is the kind of work we do at Berkner Tech.


References and Further Reading