How to capture traces on victim devices?

Hello,
I see that in all the LAB examples, the API trigger_high() and trigger_low() is already part of the firmware of the victim. How to do the same (capture trace) on targets where we cannot write this in the firmware? In other words, we have physical access to the victim device, but cannot modify code in victim device.

Regards,
Sharath

Hi Sharath,

You’ll need to find something else you can use for a trigger. Typically the operation you’re interested in is triggered by some outside signal (a reset signal, serial communication, etc). These make a good candidate for a trigger signal.

Note that the trigger here doesn’t have to be just a simple rising/falling edge. You could, for example, use something like a PhyWhisperer (PhyWhisperer-USB - NewAE Hardware Product Documentation) to trigger on a particular USB packet.

Alex

Thanks for the super fast response.
Is there an example showing external triggers?
E.g. Jupyter notebook or other code snippets to trigger externally?

We do have chipwhisperer-jupyter/Lab 6_4 - Jittery Triggering on UART.ipynb at master · newaetech/chipwhisperer-jupyter · GitHub for triggering on UART, but triggering varies too much to do a general notebook on it.

I’m trying to attack tiny AES using CPA, do you have a specific example for this ( external triggers)?
I am using CW Nano. I see that the above trigger example does not work on CW Nano.

Sorry, the Nano cannot execute the above lab, as it only accepts TIO4 as an input. You could try connecting a wire between TX and TIO4, but you’ll need to make sure to set TIO4 as high-z in the target firmware.

Alex

I’m looking for how to start trigger and capture traces using Jupyter commands (instead of trigger_high() in victim firmware). Could you please tell what command can be used to do the same? CW Nano is my HW. I am also using the onboard STM device as the victim. My intention is to have a set of Jupyter command equivalent of trigger_high, so that I can start capturing the trace from the attacker, without victim’s help (currently the examples work with victim’s help as trigger_high() is called from victim and trigger_low() is also called from victim to stop capturing).
To summarize:

  1. Jupyter command to trigger_high() without victim’s help
  2. Jupyter command to trigger_low() without victim’s help
  3. HW is CW Nano, victim is onboard STM device.

There’s no command to do what you’re asking. You’ll need to follow what I said in my previous post to trigger on UART.

Thanks, got it. Can I use your example on UART and replicate it in Nano (with some minimal changes)?

Could you please elaborate the above suggestion? I don’t understand the rationale behind it.

The Nano doesn’t have the ability to change which pin it triggers off of, so you need to manually make the connection. You set the target trigger pin to high-z to prevent it from driving the new trigger pin.

I have an issue in driving the LEDs on the STM target of CW Nano.
I added the following code in
trigger_high()
{
/* Glow the red LED to let the external world know that AES encryption has started*/
HAL_GPIO_WritePin(GPIOA, GPIO_PIN_4, SET);
}

The red LED just does not glow at all. What am I doing wrong?
The same issue exists with green LED on PIN_2 also, it never glows, why?

Are you setting the pin low again when the AES operation is finished? If so, the pin is going to toggle way too fast for you to see.

No, I just set it and never reset it.

Have you set the pin up properly (i.e. done the same setup for the pin as in trigger_setup())?

The platform init does it from your code example already.
void platform_init(void)

{

/* LEDs */

GPIO_InitTypeDef GpioInit;

GpioInit.Pin       = GPIO_PIN_2;

GpioInit.Mode      = GPIO_MODE_OUTPUT_PP;

GpioInit.Pull      = GPIO_NOPULL;

GpioInit.Speed     = GPIO_SPEED_FREQ_HIGH;

HAL_GPIO_Init(GPIOA, &GpioInit);

// HAL_GPIO_WritePin(GPIOA, GPIO_PIN_2, SET);



GpioInit.Pin       = GPIO_PIN_4;

GpioInit.Mode      = GPIO_MODE_OUTPUT_PP;

GpioInit.Pull      = GPIO_NOPULL;

GpioInit.Speed     = GPIO_SPEED_FREQ_HIGH;

HAL_GPIO_Init(GPIOA, &GpioInit);

Sorry, I’m not able to help then. The code you posted turns the LEDs on for me.

Oh okay, i will check on another device, maybe there’s HW issue.

Tried on another CW Nano HW, it does not work. I wonder what is wrong? LEDs work fine when I use a wire and power it, just does not work from code.

I found the issue. In your example code of aes for CW Nano, the platform init() initialises the led drives, but it is done before clock init for port A, which is done in trigger_init().

Calling the led drives after the above clock init, it works.