Methods to identify glitch parameters

Hello,

I have been experimenting with voltage glitching, I have tested on practice targets with a constant loop to glitch out of & on public products with documented fault injection vulnerabilities, which I have been able to successfully glitch. I am now interested in identification of glitch parameters for situations such as debug protection. This can be separated into two main investigations 1.) Glitch width 2.) Glitch delay. The width identification process seems straight forward, write testcode in a loop, continually glitch and adjust width until you see the loop value change. Now where I would like more information is identification of the point where to apply this glitch, take the NRF52 for example, a successful glitch can occur at around 5000 microseconds after triggering at high, with a width of around 10 microseconds. I can test this and successfully glitch. But how is this point identified, I would love a list of methods that are leveraged in identifying glitch points for things such as debug port locking. For example, I watched a talk some time ago (which I now unfortunately am unable to find, if anyone knows what I am referring to, please post link) where the speaker talked about loading the firmware onto the target device then setting a breakpoint in the code where the lock value was copied in memory, on the oscilloscope, this breakpoint caused an obvious flatline indicating where to glitch. Another technique I have seen is glitching from bootup onward in a range and just hoping for success - which seems inefficient. I am looking for more methods to identify these points. Thank you!

Hi,

Personally, I most often just scan the entire range with width/offset values I’ve tested previously. I don’t think we have a list of methods that you can use to narrow down the range, but one thing we’ve done in the past is to set different values in the fuse bytes that control debug access (0xFF vs 0x00, for example). You can then capture power traces and then group them based on the fuse bytes’ value to see when the device is accessing those flash values.

You can see an example of that in chipwhisperer-jupyter/courses/faultapp1/LPC1114_Fuse_Bypass.ipynb at master · newaetech/chipwhisperer-jupyter · GitHub in the DPA on Fuse Bytes section.

Alex