Questions regarding measure port and glitch success, backdating firmware

[blip]

So I was having a rough time getting the CWPro to VCC glitch on fault101’s fault 2_1. I tried scanning though widths until I found one that began to reliably reset the target (I’m using the CW308 with the STM32F3 target), and then backed off a notch and began to scan over offset, repeat, and ext_offset. I tried for weeks, off and on, to no avail.

Ultimately, I began to suspect the hardware, and wanted to see if the repeats, specifically, were having any effect (they didn’t seem to have any effect on the number of resets I was seeing when attempting to find a glitch). Since I don’t have a scope, I wanted to use the CW capture functionality. I hooked up the measure port to an SMA tee, got a few captures, and verified that the repeats were indeed doing something.

On a lark, I actually did another scan over variables, with the repeats around 10, and I got glitches! Lot’s of 'em. Thinking that I had just not had the glitch cable tightened enough, I removed the measure cable, and re-ran the scan. No glitches.

Still wondering why it would only work with both cables hooked up to an SMA tee, I dug out an old CWLite I had gotten from BlackHat a few years back, and tried with that. As it turns out, the CWLite will only glitch with the measure cable unhooked.

So, here are my questions:

1. Do I have a dud CWPro? The only time I see mention in the docs / forums about using an SMA tee is for capturing a trace, not for making the vcc glitch work in the first place. (I’m not the most dilligent in document or forum combing, and could have easily missed where this is mentioned?)

2. Is this difference in behavior between CWLite and CWPro just a difference in the hardware? Is there some attribute of the CWPro that requires the measure port to be connected before a vcc glitch will succeed? I was under the impression that the hardware was “mostly the same” between the two.

3. Could this be a firmware thing? My CWLite is running on “0.52” firmware (as gleaned from the scope.fw_version_str member), whereas my CWPro is running “1.61.0”

4. Related to 3, is there any way to backdate firmware? All I see instructions for is updating it…

Any help or answers would be greatly appreciated!

[Alex_Dewar]

@blip

Do I have a dud CWPro? The only time I see mention in the docs / forums about using an SMA tee is for capturing a trace, not for making the vcc glitch work in the first place. (I’m not the most dilligent in document or forum combing, and could have easily missed where this is mentioned?)

Nope, your CWPro is fine. VCC glitching is pretty sensitive to resistance, inductance, capacitance, etc. of the overall circuit, stuff like this happens from time to time.

@blip

Is this difference in behavior between CWLite and CWPro just a difference in the hardware? Is there some attribute of the CWPro that requires the measure port to be connected before a vcc glitch will succeed? I was under the impression that the hardware was “mostly the same” between the two.

Yeah, the glitch hardware is exactly the same. The only potential difference you might run into is that the LP glitch MOSFET was changed a few years ago due to part availability. This wouldn’t be a Lite vs Pro thing though, it’s just about when the ChipWhisperers were made. That being said, properties of all the devices in the glitch path (MOSFET, target, etc) have some amount of variance, which could explain the differences between your Lite and Pro.

@blip

Could this be a firmware thing? My CWLite is running on “0.52” firmware (as gleaned from the scope.fw_version_str member), whereas my CWPro is running “1.61.0”

The glitching is all handled through the FPGA bitstream, which is reprogrammed after every power cycle. There has been some changes with the glitch logic over the years, and there’s always some internal differences between bitstream builds, so this could be another reason for the glitch differences. If you want to try out different bitstreams, you can replace cw1200.py and cwlite.py with older versions, power cycle your device, and restart your notebook.

Alex