As a general concept, fault injection is a technique that studies how a system reacts to unusual or unexpected external forces. The idea is that, if you can trigger a glitch at the precise moment, you might be able to use that to your advantage in disabling security features or otherwise gaining further access to the device in question. In the hardware world, this could be achieved by fiddling with the power going into the device, or subjecting it to extreme temperatures.
We’ve covered voltage glitching attacks on these pages in the past, but most of the tools used are fairly expensive if you’re not doing this kind of thing professionally. Luckily for us, [Aditya Patil] has developed a fault injection tool that can run on a standard ESP8266 development board. Obviously it’s not as capable as a bespoke device costing hundreds of dollars, but if you just want to experiment with the concept, it’s a fantastic way to wrap your head around it all.
Now to be clear, the ESP8266 alone isn’t able to generate the sort of high-voltage spikes that are often used to glitch out a chip. The idea with this project is that the ESP would serve as the programmable timer used to trigger a high voltage generator or other nefarious piece of kit. That said, if you’ve got something low power enough that could get confused by rapidly having ~3 V applied to its power rails, in theory you could use the dev board without any additional hardware — though we’d strongly recommend at least throwing a MOSFET between the ESP and whatever you’re harassing.
With the firmware flashed to the ESP8266, plugging the board into your computer will provide you with a serial interface through which the software can be configured and attacks can be launched. While this interactive menu system is nice, and reminds us a bit of the Bus Pirate, [Aditya] also provides an example Python script that will let you fire commands at the system far faster than you could type them out.
If you’re looking for more capability, something like the PicoGlitcher would probably be the next step up, but if you want to really dive into the deep-end, the ChipWhisperer line of devices from [Colin O’Flynn] are really where it’s at. Check out the fascinating talk he gave about voltage glitching during the 2021 Remoticon if you’d like to learn more about the technique.
I applaud [Aditya Patil] for creating his own fault injection circuit. This isn’t easy, and I’d be interested in what was managed to be glitched with this setup.
The Github page explanation of the device is quite far from how FI is performed in a real world environment. Similarly, the implementation is capable of performing pulses in the order of several micro seconds by leveraging digitalWrite and delayMicroseconds. This is several orders of magnitude slower than what is usually required. For inspiration, please see the PicoEMP implementation by nilswiersma. It uses RP2040 PIO to generate pulses with a resolution of 8 ns (1/125 MHz).
Looking at the code, i can confidently say this project has never been used for actual fault injection.
Have you actually tried it? Because if not then you have no right to criticise others.
I’m not criticizing him, i know nothing about him. Why would i criticize a literal stranger? I wish them nothing but the best with no strings attached.
I’m criticizing (attacking, vilifying, obliterating, whatever you prefer) their work. It’s not very good quality. I can only assume they’re still in the process of modifying/improving it.
Introducing glitches is not easy. Using software timers, software PWM and including no hardware description doesn’t help. Seriously, tell me if this code is for an EMF based glitch device or some kind of power rail glitch injection?
This person put their best effort to develop a useful device for reverse engineering and ethical hacking of locked-down hardware. You came here and by insulting his work you directly started attacking him for no reason. If you are so clever then why don’t you post your own code so we may look at it and laugh? Not so tough now, are you?
Come on, shinsukke clearly said they’re criticizing the work not the author. On top of that, they provide a list of arguments on what’s missing. This is constructive feedback. Just like the other commenter Jan-Willem said above, this implementation is very limited and leaves a lot to be desired.
The guy behind the project did a good job in documenting it though and now, getting the feedback, he’ll have a nice opportunity to improve it a lot.