I recently let the magic smoke from my personal ChipWhisperer and was in dire need of a fault injection hardware to do some experiments. Like any other hacker, instead of ordering and waiting I decided to make one myself using some of the other hardware I already have. Since hardware obviously needs software to run the fault injecting setup, why not use ChatGPT to help me make one quickly and analyze how it works rather than writing all the code myself ?
Before we head to the main topic, let’s have some basic introduction on fault injection.
Hardware fault injection is a technique used to deliberately induce faults or errors into hardware components, such as microprocessors, memory chips, or communication interfaces. This results in bypassing critical security implementations such as code read protection, debug protection, password authentication or corrupting cryptographic operations (DFA) to gain control over a system.
Hardware fault injection tools work by injecting targeted errors – aka faults – into the hardware at specific points in time or under specific conditions. The tool can inject different types of faults, such as single-bit errors, stuck-at faults, or transient faults, and can control the timing and duration of the faults.
One common hardware fault injection technique is called “clock glitching”, which involves manipulating the clock signals of a processor or other hardware component to introduce timing errors. Another technique is “voltage glitching”, which involves briefly reducing the voltage supplied to a component to induce errors.
The hardware module typically includes circuitry that can generate the required faults, such as digital glitches or voltage perturbations, and can monitor the system’s response to the injected faults. The software running on the host computer provides a user interface to configure the fault injection parameters, such as the type and duration of the fault, and to control the timing of the fault injection.
The tool may also include mechanisms to automate the fault injection process, such as scripting or scheduling tools that allow users to create and run automated fault injection test cases.
During the fault injection process, the tool injects the targeted faults into the hardware system while monitoring its behavior and recording any errors or anomalies that occur. The results of the fault injection test can then be analyzed to identify potential weaknesses or vulnerabilities in the system and to evaluate the resistance to faults in the system.
Here is an example of a vanilla target application that increments the value of “cnt” using two nested loops. The loops execute when a serial message is received, and GPIO 2 goes HIGH at the beginning of the loop and LOW once it’s done. This gives us a window of opportunity to inject a fault.
Think of this tool as Ash controlling Pikachu – once the fault is injected, the loop can be disrupted in various ways, such as skipping or corrupting instructions, breaking out of the loop, or jumping to a different code location. This results in the “cnt” value being altered from its original value. Identifying the type of fault is known as fault modelling.
If you want to learn more about fault injection and do some serious stuff, you check on Colin’s amazing work and check out this book on Hardware Hacking
The objective of this project was to create a simple and easy-to-use fault injection tool using the Teensy 4.0 microcontroller and the Arduino platform with the help of AI assistance. The side-quest is also to make the project as cross-compatible as possible with other Arduino supported board which means we avoid playing with Teensy hardware specific implementation.
We can visit https://chat.openai.com to inquire about building a fault injection tool and explore the AI’s response.
I was surprised to learn that it might be considered illegal. Let’s provide more specific details to the AI and see what it suggests.
I am familiar with this code, but I won’t run it because the jitter in the loop digitalRead() is too high. Instead, we can explore using hardware interrupts, which are superior to pooling loops.
The interrupt implementation was successful in setting the “triggered” flag as intended, but it does not solve the main issue as the flag is still being checked within the loop as before. To address this, let’s further investigate and make some modifications.
This is a promising development. While the use of micros and time for creating delay is a good idea, it’s important to ensure that the main logic is not happening within the loop() function. At this point, human intervention is necessary to collaborate with the AI and achieve optimal results. Let’s continue to seek further improvements.
This implementation is preferable, and although it uses digitalWrite(), Teensy also provides digitalFastWrite() which is significantly faster, as well as delayNanoseconds(). This delayNanoseconds function also works with other generic arduino but it’s pulse width depends on the speed of the MCU. So benchmark your minimum pulse width and pulse delay from interrupt. Let’s instruct the AI to utilize these functions.