Chipwhisperer Pro Target carrier PCB Schematic

I have a chipwhisperer pro kit and I am trying to understand how to voltage glitch my STM32F targe board. Using the chipwhisperer lite I can find a matching schematic and understand what the headers are, how to apply code, etc., but I do not find a schematic for the chipwhisperer pro or target carrier board.

Is there a schematic for the Chipshisperer pro target carrier board? Where can I find this?

Do I need to use the “Crowbar glitch” out put on the pro to do this or can it be done thorugh the J1 signal connections?

There seem to be some dead links around but I have figured out that target carrier board is called the “CW308 UFO target board” and here are details: https://rtfm.newae.com/Targets/CW308%20UFO.html

We don’t have an actual schematic out for the Pro, but most of the stuff that applies to the Lite applies to the Pro (20-pin, glitch/measure ports, etc). The main upgrades on the Pro are a better FPGA enabling more features (SAD trigger, UART/SPI trigger, stream mode, etc), extra triggers, and the LCD screen.

As you’ve found, https://rtfm.newae.com has the hardware documentation. In particular, the starter kit section lists all the stuff in each of the kits: https://rtfm.newae.com/Starter%20Kits/index.html, so that will probably help you find documentation for the parts you have.

Alex

Thank you for the details Alex!

Our current problem is that anytime we connect the ‘Crowbar Glitch’ to the CW308 the Chipwhisperer Pro (CW1200) the Chipwhisperer Pro resets (screen goes dark momentarily) if/when it attempts to glitch. When I remove the ‘Crowbar Glitch’ signal from the CW308 and connect it to a power supply it works fine (repeatedly shorts out the power supply limited to 500 mA for each trigger event). But when connecting it to the CW308 it resets the Chipshisperer Pro (CW1200) when it tries to glitch. I have tried to configure the CW308 to use external power and to use the on-board LDO for 3.3V power to the target but no matter what I see the CW1200 resets when it goes to glitch if it is connected to the CW308.

  1. What is the correct location to connect the ‘Crowbar Glitch’ output to the CW308? Is this intended to connect to the SH- SMA connector (J17) for doing glitch experiments?

  2. Is the ‘Crowbar Glitch’ output of the CW1200 always requried for glitch experiments (can the CW1200 send glitches down the 3.3V line that is seen on pin 18 of J1 connector on the CW308)?

  3. Do you know what I might check in the code or look for on the board config/switches to help resolve this issue?

Are you powering the ChipWhisperer Pro with the provided 5V power supply? The Pro is pretty close to
the USB current limit, so it might be fine for the most part with just the USB power, but run into issues during power intensive stuff.

Alex

Yes, we are powering with 5V supply, and removed the USB cable to test that its working.

All seems to work correctly when glitch signal is disconnected (after programming cycle the ARM target sends trigger pulse on TIO3, CW1200 sees our programmed trigger on TIO3 and sends out a glitch matching the glitch parameters on the “Crowbar Glitch” net). This crowbar glitch works to short out our benchtop power supply set to 3.3V 500mA, no problems.

But then when connecting the “Crowbar Glitch” signal to J17 (VOUT) of the CW308 the ARM target stops sending the trigger and the CW1200 resets on the USB bus when we call scope.arm(). Still working on it, will update if we figure out something. Let us know if you have any ideas (and thank you!!).

What version of ChipWhisperer and what CWPro firmware version are you on (scope.fw_version)? It’s possible this is some firmware bug that we haven’t seen before. Also, can you print your scope settings (print(scope)), just to make sure everything’s okay there?

Also, to answer your earlier questions:

What is the correct location to connect the ‘Crowbar Glitch’ output to the CW308? Is this intended to connect to the SH- SMA connector (J17) for doing glitch experiments?

Yup, that’s correct

Is the ‘Crowbar Glitch’ output of the CW1200 always requried for glitch experiments (can the CW1200 send glitches down the 3.3V line that is seen on pin 18 of J1 connector on the CW308)?

The crowbar glitch connector is always required for voltage glitching. Trying to glitch the 3.3V line itself would be much more likely to cause issues anyway.

Do you know what I might check in the code or look for on the board config/switches to help resolve this issue?

If you have an oscilloscope handy, you could try monitoring some voltages on the board (SHUNTL, SHUNTH, the 5V/3.3V pins coming from the ChipWhisperer).

Alex

Figured out the reset on the USB bus (screen goes dark) when we create a new Chipwhisperer object (scope = cw.scope). In our code this happens when we have to reprogram the target after there have been a few attempts at resetting the target without recovering the trigger. This was probably happening with the CW-Lite as well but we didn’t notice b/c of no screen.

We also had to move our code to reset the target until after we set up the parameters of our new scope object.

So it was not losing power on the CW1200 when glitching, our code was failing to reset the target and then re-enumerating on USB bus before it programmed the target each time.

So now we have a running (CW1200/Pro) setup to compare to our (CW-Lite) setup.

We observe that the ARM target used with the CW308 seems to be more sensitive (i.e. becomes corrupted and does not respond to a reset event and must be reprogrammed to resume) than the ARM target on the CW-Lite. The case is the same when enabling the external 3.3V LDO regulator on the CW308.

Good to hear you got that solved. Regarding the different glitch effects, is your CW-Lite setup using the built in target? If so, the glitch itself likely looks pretty different due to physical differences such as resistance/capacitance/inductance between the crowbar MOSFET and the power pin, which may be causing the different effects you’re seeing.

Alex

Yep our CW-Lite is using the built-in (small & compact with limited parasitic effects) target.

It is interesting to consider how much the design/layout can affect the attempt/success rate of the experiment.

Yeah, we’ve seen very different results even just switching to a longer/shorter SMA cable. This paper, for example, uses an arbitrary waveform generator to precisely control what the glitch looks like and found that different glitch waveforms work better for different vulnerabilities: https://tches.iacr.org/index.php/TCHES/article/view/7390/6562

Alex

1 Like