SOLN_Fault 1_2 not working about chipwhisperer-jupyter HOT 4 CLOSED

Hi Max,

Yup, that does make sense. Good catch! You might be able to skip over or corrupt the sram write at 0x340, so if you haven't tried that, give it a shot.

Alex

from chipwhisperer-jupyter.

Hi Alex,

thanks for the hint!

In fact, using more glitch repetitions (=5) does the trick.
Is it correct to assume that the store operation simply is more 'stable' and thus needs a heavier glitch to fault?

Besides, what did go wrong in the first place?
Did my compiler produce a different loop from what has been used for testing?
Or did I simply miss the hidden objective here of not just taking the pre-configured parameters for granted? :P

As my title suggests, the problem expands to the solution as well - at least for me.

from chipwhisperer-jupyter.

I think this is a combination of a few things:

1. We mostly concentrate on the STM32F3 now instead of the Xmega so it didn't come up in our regular usage
2. We haven't had our automated testing for main platforms (CWLITEARM, CWLITEXMEGA, and CWNano) so it didn't automatically get caught. This should get fixed at some point.

As for why you need a repeat of 5, you might be glitching both the ldi r25, 0x00 and the loop comparison.

Anyway, thanks for the report. I'll add a note to the lab that says you might need to increase the repeat and explains why.

Alex

from chipwhisperer-jupyter.

No worries, thanks for the great tutorial and explanations!

Maybe one final question: Presumably did not glitch over the SRAM write, yet.
Could you point me any direction how to accomplish that (lets say with repetition=1 and tuning some other parameters), just for completeness sake?
Me poking around with glitch offset and width did not yield any results so far and from what i learned here, this might be an important capability for further application :)

I'll leave this open for you to close it at your discretion.

from chipwhisperer-jupyter.