Auto Reset Timeout/Delay

Embedded Security ChipWhisperer Software
1

Hi All.

I’m using the V4 to perform some clock glitching on an external target, i.e. non-tutorial targets, using the approach discussed here with the CW1200.

I have a couple of questions:

  1. In the script aux_reset_cw1173.py, # Delay between arming and resetting, in ms, is delay_ms = 1500. Suppose my CW1200 resets after arming, how does this delay_ms affect the glitching process?

  2. What causes the CW1200 to reset the target? Upon completion of the glitch? Or is this configure by some timeout or delay?

  3. Will there by a problem if the reset point and trigger point are 5 ms apart?

  4. I also encountered the following intermittent warnings:
    WARNING:Trigger not found in ADC data. No data reported!
    WARNING:Captured trace in “ChipWhisperer/OpenADC - Channel 1” has len=0
    WARNING:Trace too short (length=0) This MAY SUGGEST DATA CORRUPTION
    WARNING:Padding with 5000 zero points

  5. Please correct me if I’m wrong. I understand the CW1200 glitch process as follows:
    a. Starts with the arming of CW1200, then wait delay_ms. (If I shortened this to say 100ms, will there be a problem?)
    b. Resets target, then wait for external trigger (Does the CW1200 wait infinitely or is there like a timeout defined?)
    c. Execute glitch parameters, then reset (Does the CW1200 reset the target immediately after the glitch or it waits for some defined delay?)

  6. Is clock glitching even possible on a target that has an external crystal oscillator with internal PLL? E.g. STM32 system clock running at 120MHz derived using PLL from external crystal 8MHz.

Thanks in advance =)

Regards,
Melvin.

2

In the script aux_reset_cw1173.py, # Delay between arming and resetting, in ms, is delay_ms = 1500. Suppose my CW1200 resets after arming, how does this delay_ms affect the glitching process?

If you used resetThenDelay, the delay happens after. If you used delayThenReset, it happens before. The reset itself is independent of the glitch, it only needs to occur if your target needs to be reset before attempting a glitch.

What causes the CW1200 to reset the target? Upon completion of the glitch? Or is this configure by some timeout or delay?

The CW1200 resets the target after the event the reset is registered to occurs. I want to say that "before_trace", for example, is right after you hit the capture button (or the multiple capture button), before the scope is armed, but it’s been a while since I’ve done anything with the aux modules.

Will there by a problem if the reset point and trigger point are 5 ms apart?

There shouldn’t be. Just make sure the scope is armed before trigger occurs.

I also encountered the following intermittent warnings:
WARNING:Trigger not found in ADC data. No data reported!
WARNING:Captured trace in “ChipWhisperer/OpenADC - Channel 1” has len=0
WARNING:Trace too short (length=0) This MAY SUGGEST DATA CORRUPTION
WARNING:Padding with 5000 zero points

IIRC, that’s something that pops up for large offsets. I remember fixing something similar in CW5, but I’m not sure if it’s the exact same issue. In any case, it shouldn’t be a problem here since you’re presumably only doing glitching.

Please correct me if I’m wrong. I understand the CW1200 glitch process as follows:
a. Starts with the arming of CW1200, then wait delay_ms. (If I shortened this to say 100ms, will there be a problem?)
b. Resets target, then wait for external trigger (Does the CW1200 wait infinitely or is there like a timeout defined?)
c. Execute glitch parameters, then reset (Does the CW1200 reset the target immediately after the glitch or it waits for some defined delay?)

This will depend on what you registered the delay to and which reset type you used. I don’t recall if there’s a timeout on the glitch trigger, so I’ll have to get back to you there. Everything in the glitch module happens starting with the trigger occurring, as can be seen here: Deprecated API — ChipWhisperer 5.7.0 documentation

Is clock glitching even possible on a target that has an external crystal oscillator with internal PLL? E.g. STM32 system clock running at 120MHz derived using PLL from external crystal 8MHz.

Nope, you need to have an actual clock input that the target is running off of. I haven’t really done much regarding PLLs, but considering that, in my experience, a small flash delay in the STM chips is enough to defeat clock glitching, I’d guess the glitch wouldn’t make it through here as well.

3

Hi Alex,

Thanks for the reply. Just want to make sure I understand them correctly.

Say I used delayThenReset, delay_ms = 150ms, and I have a glitch trigger that occurs just before the if-else statement that I want to glitch. Will the glitch take place regardless the value of delay_ms?

Suppose I used the multiple capture button, what causes the next capture to take place?

How do I ensure this?

What if I desolder the target’s crystal and supply 8MHz using the CW1200? Or the PLL itself will destroy the clock glitches that pass through it? What do you mean by small flash delay in the STM chips is enough to defeat clock glitching?

Thanks again =)

Regards,
Melvin.

4

Say I used delayThenReset, delay_ms = 150ms, and I have a glitch trigger that occurs just before the if-else statement that I want to glitch. Will the glitch take place regardless the value of delay_ms?

In that case, the glitch will happen regardless of the value of delay_ms, except in the case where it causes the scope to not be armed before the glitch occurs (i.e. if you do a large resetThenDelay before arming the scope). This is something where using a Python script with the API is a lot easier to follow, since things aren’t based on events, but instead things being called explicitly. For example, the following example, pulled from Fault_1, is explicit in what is happening:

scope.arm() #glitch module is readied. If the trigger is set after this point, the glitch will occur
reset_target(scope) # target is reset, which will eventually trigger the glitch
ret = scope.capture() #wait for the CW to trigger or time out
 if ret:
   print('Timeout happened during acquisition')

response = target.read(timeout = 10) #read response from target
# target response handling...

Suppose I used the multiple capture button, what causes the next capture to take place?

When you hit the button, a callback is triggered, which optionally calls some aux module stuff before doing the capture, likely in a loop. IIRC there’s a CaptureM in one of the files (cwcore.py/cwapi.py or something, I think, it’s since been removed from the codebase, so it’s a little hard for me to check)

There shouldn’t be. Just make sure the scope is armed before trigger occurs.
How do I ensure this?

This is a bit harder with aux modules, since I don’t believe there’s documentation about when they’re actually called, but basically you need to make sure whatever causes the trigger to happen (i.e. reset, serial communication, etc) doesn’t happen before the arming takes place.

What if I desolder the target’s crystal and supply 8MHz using the CW1200? Or the PLL itself will destroy the clock glitches that pass through it? What do you mean by small flash delay in the STM chips is enough to defeat clock glitching?

There’s a modifiable flash access delay on the STM chips that needs to be used at higher clock speeds. Having this on prevented clock glitching from working. Also the clock glitching for the FPGA tutorial does bypass the PLL (https://wiki.newae.com/Tutorial_CW305-3_Clock_Glitching), so again I would say that clock glitching would not make it through the PLL.

Alex