this is a general question regarding VGA (not for the ChipWhisperer in particular).
When trying a glitching attack I often see that people are using two nested loops. One outer loop iterates over a range of delays, the inner loop iterates over the various (glitch) width values.
Now my question is: What are strategies to come up with the initial set of parameters ranges?
The “delay” parameters seems to be more easy. I would chose a range that covers the area where I expect the security check I’d like to bypass to happen. But still, I do not now how fine granular this value should be? At which steps should I increase the delay for example?
For the “width” parameter this seems to be even more difficult. Should this be based on the clock frequency of the target controller? Should I increase the width until the device shows misbehaviour?
I would be grateful if you could share some strategies!
Yeah that makes sense. It’s hard to say how small your steps need to be - some devices seem to be easier to glitch than others. From my experience, something like the Lite or the Husky seems to be in a pretty good spot to glitch most things, but you might be able to get away with something less precise.
Yeah, generally I see glitches in a narrow width band between having no effect and causing resets 100% of the time.
Selecting the initial set of parameters for an error attack can be complex and depends on many factors, such as the specific architecture of the target device, the type and characteristics of the errors you are trying to reproduce, and other factors. For delay parameters, you can start with a small range and gradually increase it until you see the effect. This can help you narrow down your search and reduce the number of parameter combinations you need to check. You can also try to determine at what stages of internal device operation the security checks occur, and adjust the delays based on this information. For the width parameters, you can use the device’s clock frequency information to select the range of values that might cause an error. You can also try iteratively increasing the width value, starting with a small value until you see the effect. In general, selecting an initial set of parameters is a trial and error process, and you may need many iterations to find the optimal parameters for your particular attack.
Thanks for your replies!
What confuses me is, that often people seem to be successful with glitches which are quite long compared to the clock period.
This is one example: Glitching the Olimex LPC-P1343
The LPC1343 is running at up to 72 MHz according to the datasheet. This gives a clock period of 13,8ns. Now his glitcher is running at 12MHz, therefore you have a clock period of 83,3ns. He successfully glitched the target with a width of 15 which is equivalent to (15*83,3ns) 1,25µs.
This seems like a very long time!
Have you ever destroyed a device from choosing the width too long?
Typically, devices like this will boot using an internal oscillator. The user is then responsible for switching over to a faster clock/PLL in their code. In any case, the ratio between the target clock and the size of the theoretical glitch tends to matter less with voltage glitching, at least partially because the actual glitch you get looks nothing like an X second wide square glitch. From the looks of things, that example you listed measures the glitch at the glitch transistor, which will look very different from the actual glitch.
You’re fighting a lot of things when you glitch (board/trace inductance and capacitance, resistance/inductance in the cable between the glitch transistor/target VCC, the voltage regulator trying to keep the voltage stable, etc), so it tends to be better in practice to just increase the width until you start seeing some effect, then focus on that area.
I’ve never seen this happen. I think theoretically you might be able to damage a target chip via a large inductive spike after releasing the glitch, but I’ve never run into that issue, and it won’t be so much related to the glitch width past a certain threshold as other factors. A very large width shouldn’t cause any harm to a target. You’re more likely to overheat the glitch transistor than damage the target chip.
@Alex_Dewar do you typicially add countermeasures against ringing?
While playing with voltage glitches I had the issue of very large spike when trying to glitch VCC (capacitors removed) because of the voltage regulator trying to fight against the glitch, as you say. I tried to add some diodes in parallel to mitigate that (had nearly 13V peak for a 5V powered microcontroller) in addition I added a small series resistor (round 10 ohms) to limit the current from the regulator. Since my glitches did not show any success, I later investigated a bit more and realized that it is possible to glitch the internal core voltage which is what I am trying now, though I havent removed the diodes and the series resistor after that. But no luck so far. While searching through the internet I had the impression, that most people do not add additional protection measures against ringing. I actually wonder if the ringing itself helps for glitches and the additional measures against ringing possibly makes it harder to glitch. Could that be?
Edit: I removed the diodes and the 10 ohms resistor in the meantime. The glitch doesn’t really look different. It is actually quite clean. I don’t think this will have a big impact. I think I then just need to be more patient…
Generally the shunt resistor takes out a good bit of the ringing on our target boards. I wouldn’t be surprised if some ringing was good for glitching as, but we haven’t done much testing on that.
Alex, thanks for your help so far!
I now know that the bootloader is running @16 MHz (Renesas V850 architecture).
Still, I have no luck with glitching. Currently I use a similar setup like that one, though the protocol is different for me:
Also his bootloader seems to run at 16 MHz from reading his python code. At roughly 70ns glitch width I see errors. He seems to glitch for around 200ns but due to the ringing it could also be 400ns in total. Unfortunately it is very difficult to find an upper bound. Since there are no signs of a reboot if you glitch too long. You either get a “denied”, “success” reply or nothing (never saw “success” so far). As soon as I reach the 70ns, I get nothing. Observing the glitch under 70ns the glitch is not low enough to trigger an error condition.
Even glitching up to 600ns width, I was not successful.
I’m also using the IRF7807z MOSFET for driving the glitches, those are used on ChipWhisperer devices too. He uses a different MOSFET. Does that make much difference in your experience?
And do you have any experience with longer glitch widths of multiple microseconds? I wonder if I should go up a bit more. Just dont want to destroy the MOSFET.
Another idea would be to cut off VCC completly and instead power the core directly from outside. I could then use something like a MAX4619 to test different “low” voltages. But I guess this will propably not work if the internal voltage regulator also powers other areas which then might not be powered any longer.
Yeah, that makes a huge difference. We’ve had to make some substitutions as parts go in and out of stock/get discontinued and you end up needing entirely different settings afterwards.
I wouldn’t worry too much, you’re really unlikely to cause any damage to the MOSFET in microseconds. That IRF7807z, for example, is rated for current pulses of 88A, which you’re not going to get anywhere close to.