Mikrocontroller-basierte Geräte in Verbindung mit ihrer dedizierten Software werden als eingebettete Systeme oder Embedded Systems bezeichnet, welche typischerweise für eine spezifische Anwendung entwickelt werden. Ein wesentliches Merkmal eingebetteter Systeme ist ihre als Firmware bezeichnete Software, welche eng mit der verbauten Hardware, einschließlich der angeschlossenen Peripheriegeräte, gekoppelt ist. Ein weiteres wesentliches Merkmal ist die Vielfalt dieser Systeme, die aus den eingesetzten Betriebssystemen, CPU-Architekturen, Kommunikationsmechanismen und Peripheriegeräten resultiert. Diese zwei Hauptmerkmale machen das Fuzz Testing von Firmware zu einer Herausforderung, für die bis jetzt keine allgemeingültige Lösung existiert.

Das Zusammenspiel von Hardware und Firmware während der Ausführung muss beim Fuzzing beachtet werden. Zudem ist die Maximierung der Ausführungsgeschwindigkeit, sowie die Messung der erreichten Codeabdeckung elementar für den effektiven Einsatz des Testverfahrens. Basierend auf diesen Rahmenbedingungen werden in vorhandenen Ansätzen Kompromisse zwischen der Genauigkeit von Tests, dem dafür entstehenden Aufwand und  der Performanz des Fuzzing-Prozesses eingegangen.

Beim Fuzzing definiert ein Testgerüst ein spezielles Stück Code, welches die Interaktion mit der zu testenden  Software ermöglicht und eine kontrollierte Umgebung für den Fuzzing-Prozess bereitstellt. Testgerüste übermitteln Eingaben an die zu testende Software und stellen sicher, dass diese während eines Tests immer aus einem definierten Zustand gestartet wird. Testgerüste für das Fuzzing von Firmware basieren auf der Abstraktion und Emulation der Hardware oder dem Einsatz von Hardware-in-the-loop-Verfahren.

Sollen Firmwareteile getestet werden, die keine Abhängigkeit zu spezieller Hardware aufweisen oder liegt der Fokus des Tests auf der Funktionalität von bestimmten Firmwareteilen, anstatt auf ihrer Interaktion mit der Hardware, wird ein architekturunabhängiges Testgerüst erstellt. Dazu wird entweder hardwareunabhängiger Code verwendet oder auf Funktionen zum Abstrahieren der Hardware zurückgegriffen. Sollen Teile der Firmware, welche auf spezielle Hardwarekomponenten, wie Peripheriegeräte, angewiesen sind, ohne Hardwarebezug getestet werden, so werden die Interaktionen mit diesen Komponenten abstrahiert. Der Vorteil dieser Methode ist die Architekturunabhängigkeit und eine hohe Ausführungsgeschwindigkeit, die Abstraktion der Hardware kann allerdings zu einem hohen initialen Aufwand führen.

Alternativ können Emulatoren verwendet werden, um Abhängigkeiten der Firmware zur Hardware abzubilden. Emulatoren ermöglichen es, Betriebssysteme und Programme, die für eine bestimmte Prozessorarchitektur kompiliert wurden, mit einer anderen Prozessorarchitektur auszuführen. Dabei werden die Instruktionen der Zielarchitektur durch Instruktionen der Hostarchitektur ersetzt. So kann beispielsweise eine Firmware, die für die ARM-Architektur gebaut wurde, ebenso auf Systemen mit einer x86-Architektur ausgeführt werden. Für die Emulation der Zielhardware oder einzelner Hardwarekomponenten existieren zahlreiche frei verfügbare Werkzeuge, wie etwa QEMU.

Beim Emulator-basierten Fuzzing wird durch die Simulation der Zielarchitektur das Verhalten der Firmware realitätsgetreuer abgebildet, als dies bei Testgerüsten mit Hardwareabstraktionen der Fall ist, wodurch Interaktionen mit der Hardware getestet werden können. Außerdem entbindet das Testen mit einem Emulator von der Notwendigkeit, eine dedizierte Zielhardware zu verwenden und ermöglicht die Nutzung der Ressourcen des Host-PCs, was zu einer erhöhten Effizienz von Tests führt. Für die Emulation wird eine Emulator-spezifische Modellierung der Hardware benötigt, welche auf Grund der Vielfalt eingebetteter Systeme oft nicht vordefiniert ist und manuell erstellt werden muss. Abstraktionen und Ungenauigkeiten dieser Modellierung, genauso wie Fehler in der Emulation können das Ergebnis des Fuzz Testings von hardwarenaher Software negativ beeinflussen.

Die realitätsgetreuste Methode für das Fuzzing von Firmware stellt die Ausführung des Testgerüstes direkt auf der Zielhardware dar. Das als Hardware-in-the-Loop (HIL) bezeichnete Verfahren ermöglicht das Testen von hardwarenaher Software wie Treibern, ist bezüglich der Ausführungsgeschwindigkeit und des Sammelns von Laufzeitinformationen allerdings durch die verwendete Zielhardware beschränkt. Um die Effizienz zu erhöhen, wird die Zielhardware lediglich zum Ausführen des Testgerüstes verwendet. Die Analyse der Laufzeitinformationen und die Generierung neuer Eingaben findet auf dem Host-PC statt, welcher mit der Zielhardware über Debug-Schnittstellen wie JTAG oder SWD kommuniziert und den Ablauf des Tests steuert.