search

newaetech / chipwhisperer-jupyter

Interactive ChipWhisperer tutorials using Jupyter notebooks.
220 stars 70 forks source link

SOLN_Fault 1_2 not working #25

Closed maxbeckmann closed 2 years ago

maxbeckmann commented 3 years ago

Hey,

while working through your (great!) glitching courses I might have encountered a bug in the 1_2 password bypass example, leading to the bypass not working as intended.

As a result from a lot of head-scratching and trial and error I came to notice, that the bypass fails for every wrong password not starting with the correct letter 't'. This especially expands to the all-zero password used in the solution. When using an otherwise incorrect password starting with 't' however, the bypass works like a charm.

Given my understanding is correct, the clock glitch should allow us to skip one single instruction. Looking at the disassembly I assume to see a reason for the described outcome: image

When the first letter is 't', r25 is not set to zero at 0x00000338 and the glitch might eventually skip the backward jump at 0x0000033e. If the initial character takes any other value however, we might glitch over the r25 = 0 assignment, but then are still left in the loop where simply the next check will leave us failing. Glitching over 0x0000033e instead, the assignment is executed as it should and we are again lost. Accordingly, the attack can not work as long as the assembly looks as it does and we merely may skip one instruction.

Does this make any sense to you?

Kind regards, Max

alex-dewar commented 3 years ago

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

maxbeckmann commented 3 years ago

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.

alex-dewar commented 3 years ago

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

maxbeckmann commented 3 years ago

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.