Skip to content

Mocking Embedded Systems
With Fuzz Data

In this recorded live coding session, Daniel Teuchert, will demonstrate an automated mocking approach, that will instantly improve your code coverage and protects your embedded software against unexpected edge cases.

What Is the Best Way to Simulate Hardware Dependencies?

To test an embedded application with dynamic inputs, you would usually have to compile and run it first. But with embedded software, you often have the problem that the code only runs on certain hardware or that the application requires input from external sources. For this reason, embedded developers use mocking to simulate these hardware-dependent functions. In this recorded live coding session, Daniel Teuchert demonstrates how to mock embedded systems with fuzz data. With this approach, you can use the advanced mutation strategies of feedback-based fuzzing to simulate the behavior of external sources under realistic conditions and cover unexpected and unlikely edge cases.

In this preview, Daniel explains why embedded systems with dependencies are so difficult to secure.

Fuzzing Embedded Applications With Dependencies Is a Challenge

Embedded applications with dependencies are complex and therefore difficult and costly to test. In some cases cross-compiling is not possible. This creates many a challenge because:

Challenge 1: Public API documentation is available Yet developers must write many tests for the programs, which is incredibly time consuming.

Challenge 2: The exchange between hardware-dependent interface and hardware must be secured. It is absolutely important to ensure the functioning of the software and hardware and to avoid downtimes. Especially during security tests, the application must be prevented from crashing. Therefore, they must cover all possible states and behaviors. In all cases, but especially in unusual ones, the system should ideally display an error message that makes it possible to trace the error back.

Problem Solver

With random, unexpected, or invalid test inputs, you can overcome most of these challenges. Hardware dependencies require fuzz testing and mocking with fuzz data. You can ensure the stability of your software by applying fuzz tests and you can protect yourself against harmful edge cases and unexpected behaviors. This allows you to find vulnerabilities much earlier in the development process and save precious time.

Fuzz Testing With API Documentation

For example, to automatically generate test harnesses, you need some form of documentation that defines the public APIs. Often, there is already some form of API documentation. The information is stored in a simple CSV or Excel spreadsheet in many cases. This documentation can be used to automatically generate advanced fuzz tests without further customization.

In the automatically generated fuzz test, the fuzzer randomly selects functions from your public API and calls them in a random order with random parameters. Based on the feedback about the code, the fuzzer can modify the functions and the parameters to provide high code coverage. This enables you to generate test cases that you might not have thought of and identify flaws early in the process.

Mocking With Fuzz Data

Normally, you must first compile and run the application to test it with dynamic input. However, often embedded software has the problem that the code only runs on certain hardware or that the application needs input from external sources. For this reason, mocking these dependencies is required for any kind of security testing.

There are several ways to simulate your dependencies. On the one hand, you could use traditional mocking methods, but this way your fuzzing runs will most likely not achieve high code coverage, since not all possible constraints are considered.

On the other hand, you can use your fuzzing engine to generate return values dynamically for your mocking. This way, you can use the magic of feedback-based fuzzing to simulate the behavior of external sources under realistic conditions. Unexpected and unlikely edge cases can thus no longer steal your time or cause frustration. Combining different DAST, IAST and fuzzing approaches is the best safeguard in the end.

Don't Waste Time and Start Now

Implementing fuzz testing allows you to find vulnerabilities and bugs at an earlier stage in your development process. You know that the earlier you find a bug in an embedded application, the easier it is to fix it. So do yourself a favor and fix the bugs before they show up in production or before attackers exploit them.

Get the Full Recording