Die Konsequenz war eine Eigenentwicklung – Stand 2025 zwar aufwendig, mittlerweile gibt es für einzelne dieser Lücken durchaus erste Tools. Aus der Entwicklung entstand aber mehr als eine einmalige Lösung für ein Projekt: die Grundidee eines flexiblen Fuzzing-Frameworks, das sich auf mehrere Protokolle erweitern lässt, statt für jede neue Schnittstelle wieder bei null anzufangen. So entstand RagnarTooth.

Was ist eigentlich Fuzzing?

Fuzzing ist im Kern automatisiertes Testen von Code oder Software durch gezielte Variation von Eingaben und Protokollabläufen. Das können ungültige Werte, Grenzwerte oder unstrukturierte Daten sein – oder auch das bewusste Durcheinanderbringen von Abläufen, etwa das Senden von Daten out-of-order oder die Verschlüsselung eines Kanals, bevor der eigentliche Schlüsselaustausch stattgefunden hat. Ziel ist es, Systeme zum Absturz zu bringen, in Deadlocks zu treiben, Non-Compliance mit der jeweiligen Spezifikation aufzudecken oder Speicherfehler zu provozieren.

Drei Dimensionen sind dabei besonders entscheidend: Die Angriffsfläche – das kann eine einzelne Funktion, ein Dateiformat, eine API oder Kernel-Schnittstelle sein, aber auch eine komplette Kommunikationsschnittstelle wie BLE. Die Parameterwahl, also wie neue Testfälle erzeugt werden – von einfacher Mutation über zufällige Generierung, Coverage-gesteuerte Verfahren und symbolische Ansätze bis hin zu LLM- oder Agenten-basierten Methoden. Und die Sichtbarkeit auf das Zielsystem: White-Box mit vollem Quellcode-Zugriff, Grey-Box mit partieller Einsicht, oder Black-Box, bei der das System ausschließlich von außen beobachtet wird – der Regelfall bei den meisten Security Assessments externer Produkte.

SweynTooth als Vorbild – und seine Grenzen

Für BLE-spezifisches Fuzzing gibt es einen wissenschaftlich fundierten Referenzansatz: SweynTooth, vorgestellt 2020 auf der USENIX Annual Technical Conference. Der Ansatz ist speziell auf BLE zugeschnitten und zielt auf Implementierungsfehler in BLE-Stacks ab. Bei seiner Veröffentlichung deckte SweynTooth 18 Schwachstellen in neun verschiedenen SoC-BLE-Stacks und -SDKs auf – hauptsächlich Deadlocks, Abstürze oder das Umgehen von Sicherheitsmaßnahmen.

Methodisch behandelt SweynTooth Fuzzing als mathematisches Optimierungsproblem: Ein Suchraum aus Mutationswahrscheinlichkeiten wird über eine Zielfunktion – das BLE-Protokollmodell – auf einen Lösungsraum abgebildet, konkret die Anzahl der erzeugten Anomalien. Als Optimierungsverfahren kommt Particle Swarm Optimization (PSO) zum Einsatz, ein metaheuristischer Algorithmus, der in einer Vielzahl von Fachbereichen erfolgreich Anwendung findet. Optimiert werden hierbei Mutationswahrscheinlichkeiten für übermittelte Eingaben, welche über hunderte Iterationen hinweg angepasst werden. Die Antworten der Zielgeräte werden daraufhin mit den Erwartungen abgeglichen, um Anomalien zu messen. Diese werden kumulativ über alle Iterationen gezählt, sodass Partikel, die wiederholt Auffälligkeiten erzeugen, im Optimierungsprozess bevorzugt werden.

So überzeugend das Konzept ist – für die praktische Nutzung hatte SweynTooth einen entscheidenden Nachteil: Der Code selbst wurde nie veröffentlicht, verfügbar sind nur das Whitepaper und einzelne Proof-of-Concept-Skripte. Für ein eigenes Assessment bedeutete das: Prinzip verstehen, aber selbst nachbauen – und dabei gleich so gestalten, dass sich der Ansatz nicht nur auf BLE beschränkt.

RagnarTooth: die eigene Architektur

RagnarTooth trennt bewusst zwischen protokollunabhängigen Kernfunktionen und protokollspezifischen Bausteinen. Zu den Kernfunktionen gehören der Controller, ein Konfigurationssystem, Logging und Reporting. Diese Bausteine bleiben über alle unterstützten Protokolle hinweg gleich.

Protokollabhängig sind dagegen vier Komponenten: das Protokoll selbst, das zugrundeliegende Modell (vergleichbar mit dem Protokollmodell aus dem SweynTooth-Prinzip), der Test-Adapter, der die eigentliche Kommunikation mit dem Zielsystem übernimmt, sowie das Frame-Format der jeweiligen Schnittstelle. Für ein neues Protokoll müssen im Wesentlichen nur diese vier Bausteine neu implementiert werden – die Kernlogik rund um Steuerung, Konfiguration und Reporting bleibt unverändert wiederverwendbar.

Auch die Optimierungsstrategie selbst ist austauschbar konzipiert – aktuell ist mit Particle Swarm Optimization allerdings erst ein Verfahren tatsächlich implementiert.

Wo RagnarTooth heute steht – und wohin die Reise geht

Wie jedes Framework in aktiver Weiterentwicklung hat auch RagnarTooth noch nicht jede Ausbaustufe erreicht – und genau diese Transparenz gehört für uns zu einem seriösen Security-Ansatz dazu. Aktuell exportiert RagnarTooth Ergebnisse als strukturierte Log-Dateien zur Auswertung; automatisierte Proof-of-Concept-Generierung und quantifizierbare Coverage-Metriken befinden sich in der Entwicklung. Die bestehenden Protokoll-Modelle sind bewusst auf konkrete Projektanforderungen zugeschnitten, statt als vollständige, universelle Referenzmodelle jedes unterstützten Protokolls angelegt zu sein – ein pragmatischer Ansatz, der sich in der Praxis bewährt hat.

Zwei Ausbaustufen treiben wir aktuell konkret voran: Coverage-Metriken, die künftig eine belastbare, quantifizierbare Sichtbarkeit in den Testfortschritt liefern, und die Erweiterung um Unterstützung für das CAN-Protokoll – ein naheliegender Schritt angesichts der Verbreitung von CAN in automotive-nahen und industriellen eingebetteten Systemen.

KI in der Fuzzing-Entwicklung

Bei der Entwicklung von RagnarTooth kamen KI-gestützte Entwicklungstools durchgängig als Hilfsmittel zum Einsatz, unter anderem für Debugging und die eigentliche Implementierung. Ein hilfreicher Ansatz dabei: eigene Skills mit klaren Spezifikationen anzulegen, die als Grundlage für KI-gestützte Code-Generierung dienen.

Grundsätzlich lässt sich KI-Unterstützung in praktisch allen Phasen von Fuzzing sinnvoll einsetzen – von der Entwicklung des Test-Harness über das Input-Mapping bis zur State- und Grammatik-Analyse von Protokollen, der Analyse gefundener Ergebnisse sowie der Entwicklung von Proof-of-Concept-Skripten und Patches. Erste Experimente mit vollständig agentenbasierten Fuzzing-Pipelines auf Basis klassischer Fuzzing-Engines – wie sie etwa im Rahmen der AIxCC 2025 gezeigt wurden – deuten in eine interessante Richtung.

Eine Einschränkung bleibt dabei wichtig: KI allein als Fuzzer einzusetzen, ist ineffektiv. Die eigentliche Stärke liegt nicht darin, klassische Fuzzing-Engines zu ersetzen, sondern darin, die Entwicklung, Analyse und Auswertung rund um den eigentlichen Fuzzing-Prozess spürbar zu beschleunigen.

Fazit

RagnarTooth zeigt exemplarisch, wie aus einer konkreten Tool-Lücke in einem Security Assessment ein wiederverwendbares, erweiterbares Framework werden kann. Der Ansatz orientiert sich am wissenschaftlich fundierten Prinzip von SweynTooth, geht mit der sauberen Trennung von Kernfunktionen und protokollspezifischen Bausteinen aber bewusst über eine reine BLE-Lösung hinaus. Die nächsten Schritte – Coverage-Metriken und CAN-Unterstützung – zeigen, dass Sicherheitsassessments für vernetzte, eingebettete Systeme ein Feld bleiben, in dem sich Tooling kontinuierlich weiterentwickeln muss, um mit neuen Protokollen und Schnittstellen Schritt zu halten.

Genau hier setzt unsere Arbeit als NewTec an: Wenn Standard-Tools an ihre Grenzen stoßen – sei es bei BLE, CAN oder proprietären Protokollen wie im IrDA-Beispiel – entwickeln wir maßgeschneiderte Security-Testing-Lösungen für eingebettete Systeme. Das reicht von individuellen Fuzzing-Strategien über klassisches Penetration Testing bis zur Anbindung an einen strukturierten PSIRT-Prozess, der gefundene Schwachstellen kontrolliert in den Entwicklungsprozess zurückspielt. RagnarTooth ist dabei kein internes Experiment geblieben, sondern fester Bestandteil unserer Security-Assessments für Kundenprojekte.

Quellen:

· M. E. Garbelini, C. Wang, S. Chattopadhyay, S. Sumei, E. Kurniawan: "SweynTooth: Unleashing mayhem over Bluetooth Low Energy", 2020 USENIX Annual Technical Conference (USENIX ATC 20), USENIX Association, Juli 2020, S. 911–925.

· https://asset-group.github.io/disclosures/sweyntooth/