As of August 2020 the site you are on (wiki.newae.com) is deprecated, and content is now at rtfm.newae.com. |
Difference between revisions of "CW1200 ChipWhisperer-Pro"
(→Streaming Mode) |
(→Streaming Mode) |
||
Line 53: | Line 53: | ||
While streaming, the ChipWhisperer hardware sends ADC data back to the capture software while recording more samples (instead of waiting until the end of the capture). During this process, the ADC samples are sent back to the computer in packets of approximately 3000 samples at a time. As a block diagram, this looks like: | While streaming, the ChipWhisperer hardware sends ADC data back to the capture software while recording more samples (instead of waiting until the end of the capture). During this process, the ADC samples are sent back to the computer in packets of approximately 3000 samples at a time. As a block diagram, this looks like: | ||
− | + | [[File:Cwpro-stream.PNG|800px]] | |
The main danger in streaming mode is that the FPGA's sample buffer can overflow if the PC doesn't request these packets quickly enough. In practice, the maximum transfer rate is around 10 Msamples/s, so the maximum ADC frequency is approximately 10 MHz in streaming mode. Trying to stream above this rate will usually cause data to be lost: the FPGA overwrites samples after the buffer is full, so it's impossible to recover these samples after overrunning the buffer. | The main danger in streaming mode is that the FPGA's sample buffer can overflow if the PC doesn't request these packets quickly enough. In practice, the maximum transfer rate is around 10 Msamples/s, so the maximum ADC frequency is approximately 10 MHz in streaming mode. Trying to stream above this rate will usually cause data to be lost: the FPGA overwrites samples after the buffer is full, so it's impossible to recover these samples after overrunning the buffer. |
Revision as of 10:57, 15 March 2017
The CW1200 (ChipWhisperer Pro) is an upgraded version of the ChipWhisperer Lite capture hardware. The Pro includes an FPGA with much more space than the Lite, allowing many new features to be added, including a larger sample buffer, streaming-mode captures, additional trigger methods, and a touchscreen interface. These features make it a high-end device suitable for laboratory use.
Check out a sneak peek of the CW-Pro.
(TODO: picture of CW-Pro)
Contents
Power Supply
The ChipWhisperer Pro can only be powered through its 5 V jack. It cannot be powered through the USB port - internally, there are no connections to the USB port's 5 V rail. This limitation is primarily due to the high current draw of the Pro: while powering the touchscreen running and an external target, it would be easy to exceed the USB current limit, causing all sorts of issues.
To make this setup more flexible, the Pro ships with two power sources:
- A 5 V, 2.1 A power supply. This supply is suitable for a permanent bench setup.
- A USB-to-barrel jack cable. This solution is more portable: if you're travelling with a laptop, you can use a second USB port for power. A USB charger will also work here.
If you're using the USB power cable, it is recommended to use a separate power supply to power any external target boards.
Basic Usage
The basic features on the Pro are exactly the same as the ChipWhisperer Lite. This means that any scripts and tutorials made for the Lite will work on the Pro, too: the connectors and pinouts are exactly the same.
AVR Programmer
This section was recently updated for ChipWhisperer 5. The old version can be found here: https://wiki.newae.com/V4:CW1173_ChipWhisperer-Lite/AVR_Programmer.
The CW1173 and CW1200 have built-in support for programming either Atmel AVR or Atmel XMEGA device. This is designed to allow you to program our target boards (including the built-in XMEGA target).
Note this programmer is fairly simple, and does not provide all the features of a stand-alone programmer.
The AVR device programmer requires four connections to the target: RESET, MOSI, MISO, SCK. See #20-Pin_Connector for details of AVR programming pin connections.
Accessing the Programmer
First, setup the ChipWhisperer as usual:
import chipwhisperer as cw
scope = cw.scope()
target = cw.target(scope)
Next, the AVR programmer can be accessed through the cw.programmers.AVRProgrammer object:
prog = cw.programmers.AVRProgrammer
Programming the Flash
Note to use the AVR programmer you may require a valid clock source for the AVR. It is suggested to use the default ChipWhisperer setup, which will generate a 7.37MHz clock:
scope.default_setup()
Note that NewAE's Notduino targets have the transmit and receive pins swapped compared to the usual targets. If you're using one of these targets, swap them using the API:
scope.io.tio1 = "serial_tx"
scope.io.tio2 = "serial_rx"
Next, try programming the device by calling cw.program_target()
:
cw.program_target(scope, prog, "<path to hex file")
The default SPI data rate for the programmer is too fast for devices which are running slower than 2 MHz. If programming a device with a clock source slower than 2 MHz, you will need to enable the "Slow Clock Mode". In "Slow Clock Mode" the entire SAM3U and FPGA clock is changed from 96 MHz to 12 MHz. Note the default fuse bytes for a virgin ATMega328P result in a 1 MHz clock, so you will need to use "slow clock mode" to program the correct fuse bytes, after which point you will not need to use "slow clock mode".
To enable slow clock mode, call program_target
with an additional slow_clock = True
parameter:
cw.program_target(scope, prog, "<path to hex file", slow_clock=True)
noteThe 'slow clock mode' is used to provide a slower SPI clock than would otherwise be possible. When switching into 'slow clock mode' it will cause all DCM blocks in the FPGA to become unlocked. You will need to reset the DCM blocks, or simply call
default_setup()
again (this will reset the serial pins, so you'll have to swap them again if you're using a Notduino target).
Programming the Fuses
By default the AVR programmer allows you to modify the LOW fuse byte only, as this byte controls the clock source selection. To change the value of the fuse byte, you'll need to manually setup the programmer:
avr_programmer = prog(slow_clock=False) #call with slow_clock = True to enable the slow clock
avr_programmer.scope = scope
avr_programmer.open()
avr_programmer.find()
Once that's accomplished, the readFuse() and writeFuse() methods can be used to read and write the fuse bits, respectively:
fuse_vals = avr_programmer.readFuse(<value>)
avr_programmer.writeFuse(<value>, <lfuse>)
with <value> corresponding to one of the following: "low", "high", or "extended".
See an Online Fuse Calculator to better understand what the values mean.
tip
- If programming a virgin ATMega328P device, the default low-fuse value of
62
results in the internal 8 MHz oscillator being divided down to 1 MHz. Any external clock is ignored.The low fuse byte must be changed to
D0
to use the external clock provided by the ChipWhisperer toolchain.
Troubleshooting
If you run into issues when programming the AVR, try the following troubleshooting methods:
- Ensure the ChipWhisperer is outputting a clock if the target requires one.
- Ensure you have the serial pins the right way around
- Ensure the fuse bits are set correctly.
This section was recently updated for ChipWhisperer 5. The old version can be found here: https://wiki.newae.com/V4:CW1173_ChipWhisperer-Lite/AVR_Programmer.
The CW1173 and CW1200 have built-in support for programming either Atmel AVR or Atmel XMEGA device. This is designed to allow you to program our target boards (including the built-in XMEGA target).
Note this programmer is fairly simple, and does not provide all the features of a stand-alone programmer.
The AVR device programmer requires four connections to the target: RESET, MOSI, MISO, SCK. See #20-Pin_Connector for details of AVR programming pin connections.
Accessing the Programmer
First, setup the ChipWhisperer as usual:
import chipwhisperer as cw
scope = cw.scope()
target = cw.target(scope)
Next, the AVR programmer can be accessed through the cw.programmers.AVRProgrammer object:
prog = cw.programmers.AVRProgrammer
Programming the Flash
Note to use the AVR programmer you may require a valid clock source for the AVR. It is suggested to use the default ChipWhisperer setup, which will generate a 7.37MHz clock:
scope.default_setup()
Note that NewAE's Notduino targets have the transmit and receive pins swapped compared to the usual targets. If you're using one of these targets, swap them using the API:
scope.io.tio1 = "serial_tx"
scope.io.tio2 = "serial_rx"
Next, try programming the device by calling cw.program_target()
:
cw.program_target(scope, prog, "<path to hex file")
The default SPI data rate for the programmer is too fast for devices which are running slower than 2 MHz. If programming a device with a clock source slower than 2 MHz, you will need to enable the "Slow Clock Mode". In "Slow Clock Mode" the entire SAM3U and FPGA clock is changed from 96 MHz to 12 MHz. Note the default fuse bytes for a virgin ATMega328P result in a 1 MHz clock, so you will need to use "slow clock mode" to program the correct fuse bytes, after which point you will not need to use "slow clock mode".
To enable slow clock mode, call program_target
with an additional slow_clock = True
parameter:
cw.program_target(scope, prog, "<path to hex file", slow_clock=True)
noteThe 'slow clock mode' is used to provide a slower SPI clock than would otherwise be possible. When switching into 'slow clock mode' it will cause all DCM blocks in the FPGA to become unlocked. You will need to reset the DCM blocks, or simply call
default_setup()
again (this will reset the serial pins, so you'll have to swap them again if you're using a Notduino target).
Programming the Fuses
By default the AVR programmer allows you to modify the LOW fuse byte only, as this byte controls the clock source selection. To change the value of the fuse byte, you'll need to manually setup the programmer:
avr_programmer = prog(slow_clock=False) #call with slow_clock = True to enable the slow clock
avr_programmer.scope = scope
avr_programmer.open()
avr_programmer.find()
Once that's accomplished, the readFuse() and writeFuse() methods can be used to read and write the fuse bits, respectively:
fuse_vals = avr_programmer.readFuse(<value>)
avr_programmer.writeFuse(<value>, <lfuse>)
with <value> corresponding to one of the following: "low", "high", or "extended".
See an Online Fuse Calculator to better understand what the values mean.
tip
- If programming a virgin ATMega328P device, the default low-fuse value of
62
results in the internal 8 MHz oscillator being divided down to 1 MHz. Any external clock is ignored.The low fuse byte must be changed to
D0
to use the external clock provided by the ChipWhisperer toolchain.
Troubleshooting
If you run into issues when programming the AVR, try the following troubleshooting methods:
- Ensure the ChipWhisperer is outputting a clock if the target requires one.
- Ensure you have the serial pins the right way around
- Ensure the fuse bits are set correctly.
XMEGA Programmer
This section has been recently updated for ChipWhisperer 5. The previous version can be found here: https://wiki.newae.com/V4:CW1173_ChipWhisperer-Lite/XMEGA_Programmer
The XMEGA device programmer requires only two connections to the target: clock (PDIC) and data (PDID). The PDIC line is usually shared with the RESET pin, and the PDID pin is a specific pin on the XMEGA device. See #20-Pin_Connector for details of XMEGA programming pin connections. Once you have the scope setup, the programmer can be accessed through cw.programmers.XMEGAProgrammer
:
prog = cw.programmers.XMEGAProgrammer
cw.program_target(scope, prog, "<path to fw hex file>")
This section has been recently updated for ChipWhisperer 5. The previous version can be found here: https://wiki.newae.com/V4:CW1173_ChipWhisperer-Lite/XMEGA_Programmer
The XMEGA device programmer requires only two connections to the target: clock (PDIC) and data (PDID). The PDIC line is usually shared with the RESET pin, and the PDID pin is a specific pin on the XMEGA device. See #20-Pin_Connector for details of XMEGA programming pin connections. Once you have the scope setup, the programmer can be accessed through cw.programmers.XMEGAProgrammer
:
prog = cw.programmers.XMEGAProgrammer
cw.program_target(scope, prog, "<path to fw hex file>")
Using Glitch Port
This section has been recently updated for ChipWhisperer 5. The previous version can be found here: https://wiki.newae.com/V4:CW1173_ChipWhisperer-Lite/XMEGA_Programmer
The "GLITCH" port is used for voltage glitching. It's connected to two MOSFET elements, as the following figure shows:
The CW1173 glitch output can be commanded to turn on either of those MOSFETs via scope.io.glitch_hp
and scope.io.glitch_lp
fields:
scope.io.glitch_hp = True #enable high power glitch
scope.io.glitch_hp = False #disable high power glitch
scope.io.glitch_lp = True #enable low power glitch
scope.io.glitch_lp = False #disable low power glitch
Be careful using this feature, as you don't want to short the MOSFETs for too long. It's also possible to damage the ChipWhisperer-Lite by burning these MOSFETs up if used incorrectly. See tutorial Fault_2 (https://chipwhisperer.readthedocs.io/en/latest/tutorials/fault_2-openadc-cwlitearm.html#tutorial-fault-2-openadc-cwlitearm) for more information.
This section has been recently updated for ChipWhisperer 5. The previous version can be found here: https://wiki.newae.com/V4:CW1173_ChipWhisperer-Lite/XMEGA_Programmer
The "GLITCH" port is used for voltage glitching. It's connected to two MOSFET elements, as the following figure shows:
The CW1173 glitch output can be commanded to turn on either of those MOSFETs via scope.io.glitch_hp
and scope.io.glitch_lp
fields:
scope.io.glitch_hp = True #enable high power glitch
scope.io.glitch_hp = False #disable high power glitch
scope.io.glitch_lp = True #enable low power glitch
scope.io.glitch_lp = False #disable low power glitch
Be careful using this feature, as you don't want to short the MOSFETs for too long. It's also possible to damage the ChipWhisperer-Lite by burning these MOSFETs up if used incorrectly. See tutorial Fault_2 (https://chipwhisperer.readthedocs.io/en/latest/tutorials/fault_2-openadc-cwlitearm.html#tutorial-fault-2-openadc-cwlitearm) for more information.
Using Measure Port
The "MEASURE" port is the input to the low-noise amplifier and ADC.
== Using Measure Port == The "MEASURE" port is the input to the low-noise amplifier and ADC.
20-Pin Connector
The pinout is as follows:
Number | Name | Dir | Description |
---|---|---|---|
1 | +VUSB (5V) | O | Not Connected on ChipWhisperer-Lite. |
2 | GND | O | System GND. |
3 | +3.3V | O | +3.3V to Target Device, can be turned off, 200mA available. |
4 | FPGA-HS1 | I/O | High Speed Input (normally clock in). |
5 | PROG-RESET | I/O | Target RESET Pin (AVR Programmer). |
6 | FPGA-HS2 | I/O | High Speed Output (normally clock or glitch out). |
7 | PROG-MISO | I/O | SPI input: MISO (for SPI + AVR Programmer). |
8 | VTarget | I | Drive this pin with desired I/O voltage in range 1.5V-5V. |
9 | PROG-MOSI | I/O | SPI output: MOSI (for SPI + AVR Programmer). |
10 | FPGA-TARG1 | I/O | TargetIO Pin 1 - Usually UART TX or RX. |
11 | PROG-SCK | I/O | SPI output: SCK (for SPI + AVR Programmer). |
12 | FPGA-TARG2 | I/O | TargetIO Pin 2 - Usually UART RX or TX. |
13 | PROG-PDIC | I/O | PDI Programming Clock (XMEGA Programmer), or CS pin (SPI). |
14 | FPGA-TARG3 | I/O | TargetIO Pin 3 - Usually bidirectional IO for smartcard. |
15 | PROG-PDID | I/O | PDI Programming Data (XMEGA Programmer). |
16 | FPGA-TARG4 | I/O | TargetIO Pin 4 - Usually trigger input. |
17 | GND | O | |
18 | +3.3V | O | |
19 | GND | O | |
20 | +VUSB (5V) | O | Not Connected on ChipWhisperer-Lite. |
== 20-Pin Connector == The pinout is as follows:
Number | Name | Dir | Description |
---|---|---|---|
1 | +VUSB (5V) | O | Not Connected on ChipWhisperer-Lite. |
2 | GND | O | System GND. |
3 | +3.3V | O | +3.3V to Target Device, can be turned off, 200mA available. |
4 | FPGA-HS1 | I/O | High Speed Input (normally clock in). |
5 | PROG-RESET | I/O | Target RESET Pin (AVR Programmer). |
6 | FPGA-HS2 | I/O | High Speed Output (normally clock or glitch out). |
7 | PROG-MISO | I/O | SPI input: MISO (for SPI + AVR Programmer). |
8 | VTarget | I | Drive this pin with desired I/O voltage in range 1.5V-5V. |
9 | PROG-MOSI | I/O | SPI output: MOSI (for SPI + AVR Programmer). |
10 | FPGA-TARG1 | I/O | TargetIO Pin 1 - Usually UART TX or RX. |
11 | PROG-SCK | I/O | SPI output: SCK (for SPI + AVR Programmer). |
12 | FPGA-TARG2 | I/O | TargetIO Pin 2 - Usually UART RX or TX. |
13 | PROG-PDIC | I/O | PDI Programming Clock (XMEGA Programmer), or CS pin (SPI). |
14 | FPGA-TARG3 | I/O | TargetIO Pin 3 - Usually bidirectional IO for smartcard. |
15 | PROG-PDID | I/O | PDI Programming Data (XMEGA Programmer). |
16 | FPGA-TARG4 | I/O | TargetIO Pin 4 - Usually trigger input. |
17 | GND | O | |
18 | +3.3V | O | |
19 | GND | O | |
20 | +VUSB (5V) | O | Not Connected on ChipWhisperer-Lite. |
Upgrading SAM3U Firmware
This section has been recently updated for ChipWhisperer 5. The previous version can be found here: https://wiki.newae.com/V4:CW1173_ChipWhisperer-Lite/Upgrading_SAM3U_Firmware
When talking about the ChipWhisperer's firmware, there is really two parts to this:
- The FPGA Bitstream file.
- The SAM3U USB interface chip firmware.
The FPGA bitstream alone is what is normally configured by the ChipWhisperer-Capture software. This bitstream is always the most up-to-date, since it's automatically reloaded by the computer every time you power cycle the ChipWhisperer-Capture. The SAM3U firmware however is not automatically updated, but it tends to change less frequently.
Checking Firmware Version
The firmware version is printed at start-up. You will see a line that looks like this indicating the version of the SAM3U Firmware:
Found CW-Lite, Serial Number = 442031204630xxxxxxxxxxx SAM3U Firmware version = 0.11 b0 Programmed FPGA
If your firmware version is outdated, a warning will be printed. You can also see the firmware version in the Config CW Firmware dialog:
Note the main version is 0.11 in this example. The "b0" indicates a "build" number. Typically this will be "build 0", but special versions will use a different build number to indicate a variant of a regular version.
Upgrading Firmware
See https://chipwhisperer.readthedocs.io/en/latest/api.html#firmware-update for instructions on how to update the SAM3U firmware.
Linux usbserial module Workaround
There is an issue in some versions of Linux, where the SAM3U is not assigned a serial port when it enters bootloader mode. Here are some steps to resolve this issue (Note. this is not a permanent fix, you must go through these steps each time you put your ChipWhisperer into bootloader mode.). These steps assume you've already put ChipWhisperer into bootloader mode.
- Unplug your ChipWhisperer (Leave unplugged until instructed otherwise)
- Reboot your computer
- Once logged in again, open a terminal session
- Run this command:
sudo modprobe usbserial vendor=0x3eb product=0x6124
- Plug your ChipWhisperer back in
- Check that a serial port is now open using:
ls -l /dev/ttyUSB*
You should now be able to program the bootloader from ChipWhisperer Capture through the port you created
Manual Update
If the above instructions fail, there is no big problem. The SAM3U chip contains a hardware-resident bootloader. You may need to follow instructions on the Manual SAM3U Firmware Update page (including using BOSSA) if you are unable to use the automatic system that is part of ChipWhisperer-Capture.
This section has been recently updated for ChipWhisperer 5. The previous version can be found here: https://wiki.newae.com/V4:CW1173_ChipWhisperer-Lite/Upgrading_SAM3U_Firmware
When talking about the ChipWhisperer's firmware, there is really two parts to this:
- The FPGA Bitstream file.
- The SAM3U USB interface chip firmware.
The FPGA bitstream alone is what is normally configured by the ChipWhisperer-Capture software. This bitstream is always the most up-to-date, since it's automatically reloaded by the computer every time you power cycle the ChipWhisperer-Capture. The SAM3U firmware however is not automatically updated, but it tends to change less frequently.
Checking Firmware Version
The firmware version is printed at start-up. You will see a line that looks like this indicating the version of the SAM3U Firmware:
Found CW-Lite, Serial Number = 442031204630xxxxxxxxxxx SAM3U Firmware version = 0.11 b0 Programmed FPGA
If your firmware version is outdated, a warning will be printed. You can also see the firmware version in the Config CW Firmware dialog:
Note the main version is 0.11 in this example. The "b0" indicates a "build" number. Typically this will be "build 0", but special versions will use a different build number to indicate a variant of a regular version.
Upgrading Firmware
See https://chipwhisperer.readthedocs.io/en/latest/api.html#firmware-update for instructions on how to update the SAM3U firmware.
Linux usbserial module Workaround
There is an issue in some versions of Linux, where the SAM3U is not assigned a serial port when it enters bootloader mode. Here are some steps to resolve this issue (Note. this is not a permanent fix, you must go through these steps each time you put your ChipWhisperer into bootloader mode.). These steps assume you've already put ChipWhisperer into bootloader mode.
- Unplug your ChipWhisperer (Leave unplugged until instructed otherwise)
- Reboot your computer
- Once logged in again, open a terminal session
- Run this command:
sudo modprobe usbserial vendor=0x3eb product=0x6124
- Plug your ChipWhisperer back in
- Check that a serial port is now open using:
ls -l /dev/ttyUSB*
You should now be able to program the bootloader from ChipWhisperer Capture through the port you created
Manual Update
If the above instructions fail, there is no big problem. The SAM3U chip contains a hardware-resident bootloader. You may need to follow instructions on the Manual SAM3U Firmware Update page (including using BOSSA) if you are unable to use the automatic system that is part of ChipWhisperer-Capture.
Advanced Features
Streaming Mode
The ChipWhisperer Pro has a streaming mode that allows extremely long captures as long as relatively low sampling rates are used. For example, this plot shows an exerpt from two traces with nearly 1 million samples:
TODO: add streaming example
This capture mode is useful for many types of attacks, including:
- Full captures of slow software AES libraries
- Power analysis on ECC
- Context switches on embedded operating systems
While streaming, the ChipWhisperer hardware sends ADC data back to the capture software while recording more samples (instead of waiting until the end of the capture). During this process, the ADC samples are sent back to the computer in packets of approximately 3000 samples at a time. As a block diagram, this looks like:
The main danger in streaming mode is that the FPGA's sample buffer can overflow if the PC doesn't request these packets quickly enough. In practice, the maximum transfer rate is around 10 Msamples/s, so the maximum ADC frequency is approximately 10 MHz in streaming mode. Trying to stream above this rate will usually cause data to be lost: the FPGA overwrites samples after the buffer is full, so it's impossible to recover these samples after overrunning the buffer.
On the software end, there are two things to watch for:
- Long captures from streaming mode (millions of points) may take several seconds to record. When working with these long captures, make sure the software's timeouts are long enough.
- Extremely long captures take a lot of memory. 64-bit Python is recommended if you plan on capturing many traces with millions of samples - you can hit the memory limit on 32-bit Python pretty quickly.
SAD Trigger
UART/SPI Trigger
SMA I/O
Touchscreen
- Pictures of screens - Descriptions of displays