Warning / Sanity Check for glitch settings

Embedded Security Glitching
1

Hi,

In certain cases, some glitch width/offset settings lead to a “double pulse”.
This happens when either:

  • Offset + Width > 50
  • (Width < 0) && (0 < Offset < abs(Width))

Since I’m using the Glitch Signal (HS2, “glitch only”) to trigger external equipment, I have to take care to avoid these special cases. (In fact, it took me quite a while to figure out what’s wrong when I saw the double pulses.)
So it would be nice to have some extra checks that throw a warning if the user is running in such problems.

Did anyone else run into this?
What method do you recommend for triggering external equipment with the CW-Lite?
Since I want to use the ext_offset and repeat settings, I guess I can’t use the actual trigger output, right?

By the way, I’ve noticed that whenever I change the glitch width/offset settings, I happen to see a long train of glitch pulses on HS2. Is there a way to prevent this?

Cheers,
Jones

2

Hi Jones,

This is a known issue that popped up when we fixed another bug related to glitch generation: https://github.com/newaetech/chipwhisperer/issues/261. It’s possible that the train of glitches is also related to this update. Thanks for the suggesting regarding the warning, I’ll talk to Colin about implementing it

You should be able to trigger external equipment using the glitch port on the ChipWhisperer if you want to keep HS2 open, which will also allow you to use the ext_offset and repeat settings. Keep in mind that the glitch port is open drain.

Alex

3

EDIT: Alright, I think I’ve tracked down what’s happening. I believe this is a bug with the glitch module that was recently fixed. There’s a separate issue with large negative offsets (reported as <-45, was <-49 on my CWLite) that was introduced in the new glitch module. Updating to the newest release should solve your issue

Alex

4

Hi Alex,

thanks for the quick response.
I’ve pulled the latest development branch now and even performed a FW upgrade of the ATSAM3U.
This is my config, signal is taken from HS2:

scope.default_setup()
scope.adc.basic_mode = "high"
scope.clock.adc_src = "clkgen_x1"
scope.clock.freq_ctr_src = "clkgen" 
scope.clock.clkgen_freq = 10e6
scope.clock.clkgen_src = "system"
while not scope.clock.clkgen_locked:
    time.sleep(0.5)
while not scope.clock.adc_locked:
    time.sleep(0.5)
scope.io.hs2 = "glitch"
scope.io.glitch_hp = True
scope.glitch.clk_src = "clkgen"
scope.glitch.output = "glitch_only"
scope.glitch.trigger_src = "manual"

scope.glitch.repeat = 1
scope.glitch.ext_offset = 0
scope.glitch.offset_fine = 0 
scope.glitch.width_fine = 0 

scope.glitch.width = -20
scope.glitch.offset = 5
scope.glitch.manual_trigger()

image
image926×907 15.3 KB 

scope.glitch.width = -20
scope.glitch.offset = 15

image
image823×916 15.1 KB 

scope.glitch.width = 30
scope.glitch.offset = 30

image
image813×917 14.9 KB

It basically boils down to the two constraints I noted above. In all other cases it works just fine.
Maybe you can enlighten me a bit on this issue :wink:

Thanks a lot,
Jones

5

Hi Jones,

This is definitely super similar to the original bug: https://github.com/newaetech/chipwhisperer/issues/261. I’d guess that either the bug can still crop up in some situations, or the old bitstream is still being loaded into the FPGA.

I’m going to get some code to you than calculate a hash of the bitstream being loaded so we can know for sure if the correct bitstream is being loaded. In the meantime can you try performing a glitch at an offset of -49. IIRC width can be positive or negative here, but probably best to try both).

Also, I don’t think it affected anything here, but you have the HP voltage glitch on as well (scope.io.glitch_hp = True)

Alex

6

Hi Jones,

Can you try running the following code:

from chipwhisperer.hardware.firmware.cwlite import getsome
data = getsome("cwlite_firmware.zip", filelike=False)
import hashlib
m = hashlib.sha256()
m.update(data)
print(m.hexdigest())

The hash should be: e68f04d4490912311f6a108dbe5cc4a8ee273878a184b3d5b4835926306d1a0b.

Alex

7

Hi Alex,

the hash matches…
Anything else I can try?

Thanks,
Jones

8

Hi Jones,

If you try running the glitch at -49, do you see the glitch? Also, try setting scope.glitch.repeat=1000 and reading it back. Does the value get set properly?

Alex

9

Hi Alex,

Ah, I overlooked that on your last message.
I just tried it - and it works. Also, I can’t even reproduce the issue now.

I’m not sure what happened.
I did update the FW before the weekend, but I did reboot the PC during the weekend.
My best guess is that some old code wasn’t updated directly after the git pull and required a reboot.

I’ll keep on experimenting, but I’m pretty sure it’s fixed now.

Thanks a lot for your quick support!!

Jones

1 Like