You have no fuzzer here: Fuzzing automotive firmware in exotic environments
Modern vehicles rely on dozens of electronic control units (ECUs) that manage critical vehicle functions. The firmware of an ECU is low-level software that controls the microcontroller within the unit, enabling it to read sensor values and issue commands to actuators. Since ECUs control critical functionalities, ensuring their security is essential for both safety and reliability. While fuzzing has become a standard technique for finding vulnerabilities in desktop and server software, applying it to automotive firmware presents a very different set of challenges.
Compared to classic software, ECU firmware usually works on unique hardware setups, relies on hardware parts, and operates in conditions where code coverage, memory error detection, and instrumentation are hard to implement. Therefore, the majority of today's automotive fuzzing activities still mainly target communication protocols like CAN or UDS while most parts of firmware remain mostly unexplored, i.e., blackbox.
In this study, we present the real-world difficulties of developing a firmware fuzz testing framework for automotive ECUs and how to overcome them. During this research we have designed a fuzz testing framework capable of rehosting firmware and integrated with AFL++. We also present our methodology to reduce the cost of fuzzing by prioritizing regions with the most probability of containing a vulnerability in the firmware. Furthermore, we discuss how we developed our custom memory error detector tool, designed to identify out-of-bounds memory operations in Tricore-based firmware with an AUTOSAR software stack.
The framework successfully identified all vulnerabilities in our manually crafted benchmark. Moreover, we also managed to find numerous memory safety violations in real-world TriCore firmware.
This talk explores the practical obstacles that prevent effective fuzzing of embedded automotive firmware. We'll discuss why proprietary processor architectures, hardware dependencies, memory-mapped peripherals, interrupt handling, and limited tooling make firmware fuzzing fundamentally different from user-space software fuzzing.
To address these challenges, we'll present an architecture-aware workflow based on firmware emulation and targeted fuzzing. Rather than attempting to emulate an entire ECU, we discuss how firmware slicing and function prioritization can significantly improve performance by focusing on code regions that are more likely to contain security-relevant bugs.
As a practical case study, we examine Infineon's TriCore architecture, one of the most widely deployed processor families in automotive ECUs. TriCore demonstrates how architectural design decisions can directly affect both vulnerability discovery and exploitability. For example, its register-based calling convention stores return addresses in dedicated registers instead of on the stack, making traditional stack overflows behave very differently from what most existing fuzzers expect. This seemingly small architectural difference highlights why generic fuzzing approaches often miss important classes of bugs when applied to embedded systems. While this could look like a benefit, from a memory error detection point of view this could be a limitation. Fuzz testing tools are dependent on the state of the program to find out if a test case is making a problem into the program under test or not. For example, in the case of overwriting the return address of a program during fuzz testing, the execution will be terminated and fuzzer will notice that something happened. But when it comes to TriCore, since the return address is not saved on stack, a stack overflow won’t lead to over writing of return address and termination of the program execution and existing fuzzers are not able to detect such cases.
As a result, one of the main challenges that we need to address during this research is to design an approach for detecting memory errors when a vulnerability is touched by the fuzzer.
A popular methodology for detecting those silent memory errors is using memory sanitizers. A famous example is AddressSanitizer, a memory error detection tool capable of detecting vulnerabilities like stack buffer overflow, heap buffer overflow, or use after free. Such capabilities are not included in current emulation engines like Unicorn and we will integrate our memory error detection solution to the AFL++ framework.
In summary we will make the following contributions:
• We will address the lack of tool chain support for TriCore architecture in current fuzz testing frameworks such as AFL++.
• We design a methodology to prioritize and slice parts of the firmware with the highest possibility of being vulnerable to optimize the performance of the fuzz testing.
• We propose a methodology for detecting memory safety violation bugs during fuzz testing.
• We provide our analysis for the detected bugs and how the vulnerability scoring system could be different in TriCore context.
Reza is a security researcher with a focus on the security of cyber-physical systems. He previously worked as a research assistant at the CISPA Helmholtz Center for Information Security and has spent the past several years working as a senior product security engineer in the automotive and industrial automation sectors. His interests include firmware security, fuzzing, reverse engineering, and securing safety-critical embedded systems.