Clock glitching with CW1200 and CW308


#1

I am currently going through tutorial F1 (intro to clock glitching) with the CW1200 and CW308 (Target is the STM32F3). The python code does not output any error, but I am not getting a single successful glitch.

I do see the variations on the CLKIN signal, so it does seem like everything should be working fine.

Any fine-tuning that I might have missed?


#2

I mean other than expanding the offset range (which I increased to [-49,49] without success.


#3

Also wondering if the “Glitch” led (CLK Status) on the CW1200 should be blinking while glitching. Because right now, it’s green and stable as a rock (?).


#4

Hi Whilibarj,

To clarify, I am using the CW308 but my attack board is a CW1173 (LITE) and I’m unable to replicate your issue, it works for me as is.

When I do the first attack I do get the red LED3 blinking rapidly. Can you verify all of your connections? (Ribbon/Glitch -> VOUT lines)?

You can try varying the width, walking through -49 to 49 should yield some results. The “max” minimum step size is (1/512)*100 (~.2) so you could try that.

On the CW308 are all of the MH6 switches set to EXT-DC? Is EXT-DC SWITCH set to ON?

Is this the first tutorial you’ve run or have others worked for you as well?

In the Jupyter tutorial, can you try using Kernel -> Restart & Run All. Does the assertion test at the end fail?

If you are running this with an oscilloscope I would recommend trying it unattached as well. It does have an electrical effect on the system that might be messing things up.

Just the fact that LED3 is not blinking for you makes me think it’s something to do with your hardware. Try the steps I outlined above and report the results.

Hope this helps!
Alex


#5

The LED3 does blink (on the target) The one that does not and that I am wondering about is the “Glitch” one on the CW1200 (under CLK Status). I just don’t know if this one should be blinking or not.

I have tried different ranges for width and output. I indeed noticed that the step size could not go lower than 0.2. One thing that I do not understand is that even though the step is set to, say 1, the increment is not actually one. You can see this on the tutorial page. (https://chipwhisperer.readthedocs.io/en/latest/tutorials/fault_1-openadc-cwlitearm.html#tutorial-fault-1-openadc-cwlitearm). Looking at Out[10], even if the step is supposed to be set at 1, the increments are more like 1.171875. Not a problem I guess, but something I do not understand yet.

Another thing I have noticed with different ranges: the progress bars seem to “crash” at 51% when I set wide ranges, so it seems like it is skipping some values (52% to 100%). Maybe my problem is there?

EXT-DC is set to on indeed. I have reset the Kernel and ran everything again from scratch multiple times. Oscilloscope was connected only to check if the clock signal had variations.

All other tutorials have worked fine, but they were power analysis tutorials. Funny thing is that the second fault injection tutorial is not working as well (see my other post at VCC Glitching with CW1200 on STM32F3 (CW308))

Of course the assertion tests fail as I have no successful glitches.


#6

So… No idea? :frowning:


#7

Hey sorry for the delay, I just got the same hardware setup as you and I can confirm a few things.

The CLK Status LED you’re wondering about is NOT supposed to be blinking so that’s fine.

The issue might actually be the Python script itself. Try indenting this line once:

 attack1_data.append([scope.glitch.width, scope.glitch.offset, successes/sample_size, repr(response)]) 

At the top of the while loop comment out the line that resets successes to 0.

Then in the next Python cell, add the bottom line:

print (successes)

There’s a possibility that you are getting glitches and the Python code didn’t make it obvious.

I can confirm it is working with defaults on my board setup. Could you tell me what hardware revision you’re using? (Backside label, mine is 1.1)


#8

Hardware version here is 1.2

I’ve made the suggested modifications (removed the line resetting successes to 0, and indenting up the attack1_data line) and ran with the following parameters:

offset_range = Range(-49, -30, 0.2)
scope.glitch.ext_offset = 37
scope.glitch.repeat = 10
width_range = Range(-10, 10, 1)

And I indeed got a good bunch of successes, at many different offset/width values actually. Not sure I fully understand the turnaround on this one, but it does finally work. Thanks!

I am still very confused by the increments being different than 0.2 and 1 respectively (?). 1 seems mapped to 6/512 while 0.2 seems mapped to 2/512… Some kind of rounding up to the next step value?

Now trying to figure out the issue with the VCC Glitch tutorial.

By the way, using the same ranges/steps for offset/width in the Attack 2 of the Clk Glitch tutorial, I am getting a ton of “WARNING:root:Timeout in OpenADC capture(), trigger FORCED”, and a few “Timeout happened during acquisition”. Not sure why. But I did get successes as well.