The consequence was an in-house development – a considerable effort as of 2025, although initial tools have since emerged for some of these gaps. But the work produced more than a one-off solution for a single project: the basic idea of a flexible fuzzing framework that can be extended to multiple protocols, rather than starting from scratch for every new interface. That is how RagnarTooth came about.

What is fuzzing, exactly?

At its core, fuzzing is the automated testing of code or software through the targeted variation of inputs and protocol sequences. These can be invalid values, boundary values or unstructured data – or the deliberate disruption of sequences, such as sending data out of order or encrypting a channel before the actual key exchange has taken place. The aim is to crash systems, drive them into deadlocks, uncover non-compliance with the relevant specification or provoke memory errors.

Three dimensions are particularly decisive here. First, the attack surface: this can be a single function, a file format, an API or a kernel interface, but also a complete communication interface such as BLE. Second, the choice of parameters, i.e. how new test cases are generated – from simple mutation and random generation through coverage-guided and symbolic techniques to LLM- or agent-based methods. And third, visibility into the target system: white-box with full access to the source code, grey-box with partial insight, or black-box, where the system is observed exclusively from the outside – the norm for most security assessments of third-party products.

SweynTooth as a model – and its limitations

For BLE-specific fuzzing, there is a scientifically grounded reference approach: SweynTooth, presented in 2020 at the USENIX Annual Technical Conference. The approach is tailored specifically to BLE and targets implementation flaws in BLE stacks. On its publication, SweynTooth uncovered 18 vulnerabilities in nine different SoC BLE stacks and SDKs – mainly deadlocks, crashes or the bypassing of security measures.

Methodologically, SweynTooth treats fuzzing as a mathematical optimisation problem: a search space of mutation probabilities is mapped via an objective function – the BLE protocol model – onto a solution space, specifically the number of anomalies generated. The optimisation method used is Particle Swarm Optimisation (PSO), a metaheuristic algorithm that has been applied successfully across a wide range of disciplines. What is optimised are the mutation probabilities for transmitted inputs, which are adjusted over hundreds of iterations. The responses of the target devices are then compared against expectations in order to measure anomalies. These are counted cumulatively across all iterations, so that particles which repeatedly produce irregularities are favoured in the optimisation process.

Compelling as the concept is, SweynTooth had one decisive drawback for practical use: the code itself was never published. Only the white paper and individual proof-of-concept scripts are available. For our own assessment, this meant understanding the principle but rebuilding it ourselves – and designing it from the outset so that the approach would not be limited to BLE.

RagnarTooth: our own architecture

RagnarTooth deliberately separates protocol-independent core functions from protocol-specific building blocks. The core functions include the controller, a configuration system, logging and reporting. These building blocks remain the same across all supported protocols.

Four components, by contrast, are protocol-dependent: the protocol itself, the underlying model (comparable to the protocol model in the SweynTooth principle), the test adapter, which handles the actual communication with the target system, and the frame format of the respective interface. For a new protocol, essentially only these four building blocks need to be re-implemented – the core logic for control, configuration and reporting remains fully reusable.

The optimisation strategy itself is also designed to be interchangeable, although Particle Swarm Optimisation is currently the only method actually implemented.

Where RagnarTooth stands today – and where it is heading

Like any framework under active development, RagnarTooth has not yet reached every stage of its roadmap – and for us, this kind of transparency is part of a credible approach to security. RagnarTooth currently exports results as structured log files for analysis; automated proof-of-concept generation and quantifiable coverage metrics are in development. The existing protocol models are deliberately tailored to specific project requirements rather than designed as complete, universal reference models of every supported protocol – a pragmatic approach that has proven itself in practice.

We are currently pursuing two concrete next steps: coverage metrics that will provide reliable, quantifiable visibility into testing progress, and support for the CAN protocol – a logical step given how widespread CAN is in automotive-related and industrial embedded systems.

AI in fuzzing development

AI-assisted development tools were used throughout the development of RagnarTooth, including for debugging and the actual implementation. One helpful approach was to create custom skills with clear specifications to serve as the basis for AI-assisted code generation.

In principle, AI support can be used meaningfully in virtually every phase of fuzzing – from developing the test harness and input mapping to state and grammar analysis of protocols, analysing findings, and developing proof-of-concept scripts and patches. Initial experiments with fully agent-based fuzzing pipelines built on classic fuzzing engines – such as those demonstrated at AIxCC 2025 – point in an interesting direction.

One important caveat remains: using AI on its own as a fuzzer is ineffective. Its real strength lies not in replacing classic fuzzing engines, but in significantly accelerating the development, analysis and evaluation work surrounding the actual fuzzing process.

Conclusion

RagnarTooth is a prime example of how a specific tooling gap in a security assessment can become a reusable, extensible framework. The approach is based on the scientifically grounded SweynTooth principle, but its clean separation of core functions and protocol-specific building blocks deliberately takes it beyond a pure BLE solution. The next steps – coverage metrics and CAN support – show that security assessments for networked embedded systems remain a field in which tooling must evolve continuously to keep pace with new protocols and interfaces.

This is exactly where our work at NewTec comes in. When standard tools reach their limits – whether with BLE, CAN or proprietary protocols, as in the IrDA example – we develop tailored security testing solutions for embedded systems. These range from individual fuzzing strategies and classic penetration testing to integration with a structured PSIRT process that feeds identified vulnerabilities back into development in a controlled manner. RagnarTooth has not remained an internal experiment; it is an integral part of our security assessments for customer projects.

Sources:


· 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, July 2020, pp. 911–925.
· https://asset-group.github.io/disclosures/sweyntooth/