Approved_users, administrator
366
edits
Changes
Created tutorial
This tutorial will build upon information covered in [[Tutorial A3 VCC Glitch Attacks]] and [[Tutorial A2 Introduction to Glitch Attacks (including Glitch Explorer)]] and will make extensive use of the Glitch Explorer and scripting. It is assumed that you have read and understood this material before coming here.
== Background on Code Read Protect ==
To help protect proprietary code from being dumped via a bootloader or a debugging interface, many microcontrollers include some mechanism that locks down the flash and prevents reads. In the case of NXP's LPC1114, this is done by reading a value from flash during the boot sequence, with different values corresponding to different levels of protection. As is shown in the figure below, there are 4 levels of read protection, with the rest of the values representing an unlocked device. This makes this a great target for glitching, as corrupting one bit from this read will unlock the device and give us full access. Since higher CRP levels are harder (or in the case of CRP level 3, "impossible") to remove, we'll be using the device in CRP level 1.
== Hardware Setup ==
=== ChipWhisperer-Lite (CW1173) with 909-LPC-P1114 Development Board ===
To allow the ChipWhisperer-Lite to interface with this board, we'll need to make some small modifications to the board:
# Short jumper BLD_E to put the device in bootloader mode
# Solder a wire from GND to P0_3 (Second column from the left, fourth row from the bottom) to put the bootloader in UART mode
# Remove C1 and C4 from the board
# Cut the traces on 3.3V_CORE and 3.3V_IO_E
# Add an SMA connector to the board and connect Vcc to the center pin and GND to one of the outside pins
# Add a header pin/wire to RST (First column from the left, third row from the bottom). The CW-Lite needs two connection points, as we'll be both resetting this pin and triggering off of it.
Next, we'll need to connect the CW-Lite to the connect pins on the dev board to pins on CW-Lite's 20 pin header:
# Connect pin 1 of UEXT (Vcc) to pin 3 on the CW-Lite
# Connect pin 2 of UEXT (GND) to pin 2 on the CW-Lite
# Connect pin 3 of UEXT (TXD) to pin 8 on the CW-Lite
# Connect pin 4 of UEXT (RXD) to pin 10 on the CW-Lite
# Connect RST to pins 5 (nRST) and 12 (GPIO3) or 14 (GPIO4) on the CW-Lite
Finally, attach an SMA cable between the one you added to the board and the GLITCH connector on the CW-Lite
=== ChipWhisperer-Lite (CW1173) with CW308 Target Board ===
Coming soon!
== Communicating with the Bootloader ==
Before actually glitching the bootloader, we'll need to be able to communicate with it, both to check the read protect status and to read contents of the flash once we're in. The bootloader is described in Chapter 26 of the LPC111x User Manual. [https://www.nxp.com/docs/en/user-guide/UM10398.pdf] In UART mode, the device can communicate at a variety of baud rates in 8n1. The bootloader uses flow control, but communication will work fine without it. This is the default setup for the CW Capture software.
Before we can do any read operations, we'll need to properly initialize the bootloader. Note that the bootloader will echo back what is sent to it by default.
# Reset the device. This can be done by pulling the RST pin low from the CW Capture, or by pressing the RESET button on the dev board/CW308.
# Send a "?" to the device. It will use this to detect the baud rate. From now on, all messages should be terminated by "\r\n".
# The device will send "Synchronize\r\n".
# Respond with "Synchronize\r\n". The device will respond with "OK\r\n", though it will probably be "Synchronize\rOK\r\n" due to the echo.
# Send the frequency of the external clock in KHz. The dev board uses a 12MHz clock, so we should respond with "12000\r\n".
# The device will respond with "12000\rOK\r\n".
The device is now properly setup, so you can begin sending it commands. For example, to read 4 bytes from address 0, send "R 0 4\r\n". The device will respond with an error code (0-19, with 0 representing no error). If the read was ok, the device will respond with the memory in UU-Encoded format, along with a checksum. You should now respond with "OK\r\n" to let the device know its read was alright.
This read can fail for a variety of reasons, but the one we are most interested in is error 19, which is returned when the read fails due to the device being in RDP mode.
== Setting up the Glitch ==
=== Firmware Setup ===
Since we're only attacking the bootloader, no firmware setup is required for this tutorial; however, if your device is not already in CRP mode 1, you'll need to put it into this mode.
=== Software Setup ===
# Connect to the ChipWhisperer Device by running the "connect_cwlite_simpleserial.py" script.
# Under the Scope Settings tab, setup the CLKGEN Module to generate a 100MHz clock:
## Under CLKGEN Settings, change "Desired Frequency" to 100MHz.
## Under ADC Clock, change "Source" to "CLKGEN x1 via DCM". If "DCM Locked" isn't checked, click "Reset ADC DCM" until it is.
# Set UART up:
## Under Target IOn Pins, set "Target IO1" to "Serial RXD" and "Target IO2" to "Serial TXD".
# Set the Vcc glitch up and make it trigger off an external trigger:
## Under CW Extra Settings/Trigger Pins, check "HS-Glitch Out Enable (Low Power)".
## Under Glitch Module, set "Glitch Trigger" to "Ext Trigger:Single-Shot".
## Set "Output Mode" to "Enable Only".
# Under the Target Settings tab:
## Set "Version" to 1.0
## Clear all of the Commands
## Set "Output Format" to "$GLITCH$54". This allows the glitch explorer to see when is being sent by the bootloader and limits the response to 54 characters.
# CW Capture records and stores traces by default. Since we don't need this functionality, we can speed up the glitch process by telling it not to record and display traces:
## Under the Generic Settings tab, set "Trace Format" to "None".
## Under the Results tab, set "Input" to "None".
# Since we may have to glitch over a long period of time, instead of changing the settings after every glitch attempt, we'll instead automate this by using a script to update the necessary glitch parameters, as well as do the setup for the bootloader.
=== Script Setup ===
==== Initial Settings ====
To make the Software Setup faster, the above settings can be set in your script. An example of this is shown in this tutorial's example script.
==== Automating the Glitch ====
First, create an object class to hold all of the methods that you'll be using to automate glitching. For this tutorial, we'll need access to the glitch explorer window, as well as the api:<syntaxhighlight lang="python">
class LPC_glitch(object):
def __init__(self, ge_window, api):
self.ge_window = ge_window
self.api = api
</syntaxhighlight>Add 2 methods, one for setting the reset pin low, and one for setting the reset pin high. Having two methods will help make triggering off the glitch more precise:<syntaxhighlight lang="python">
def turn_off(self, scope, target, project):
self.api.setParameter(['CW Extra Settings', 'Target IOn GPIO Mode', 'nRST: GPIO', 'Low'])
def turn_on(self, scope, target, project):
self.api.setParameter(['CW Extra Settings', 'Target IOn GPIO Mode', 'nRST: GPIO', 'High'])
</syntaxhighlight>Add a method to update the glitch parameters and tell the glitch explorer window about them. In this case, we care about the repeat (will determine how wide the glitch is) and the offset of the glitch from the trigger (how long after resetting the glitch happens). The following method covers a wide range, so you'll probably want to narrow things down a bit. Glitches between 5000 and 6000 (on the board we used, glitching at 5211 with a repeat of 10 produced a lot of successes) seem to bypass the bootloader the best:<syntaxhighlight lang="python">
def update_parameters(self, scope,taret,project):
scope.glitch.ext_offset += 1
if scope.glitch.ext_offset > 8000:
scope.glitch.ext_offset = 1000
scope.glitch.repeat += 1
if self.ge_window:
self.ge_window.add_data("Glitch Offset", scope.glitch.ext_offset)
self.ge_window.add_data("Glitch Repeat", scope.glitch.repeat)
</syntaxhighlight>Create a method that checks the read protect status of the device. In this case, we'll need to setup the bootloader as described earlier and try a read. We can tell if the glitch is successful based on what is returned when we try to do a read command. To get access to the CW-Lite's UART, we'll need to use the target's serial driver via self.api.getTarget().ser.
Note that the delays are used to allow time for the device to respond. If you wanted to make this communication more reliable, you could read what is sent back and check it against what you expect:<syntaxhighlight lang="python">
def check_read_protect(self, scope, target, project):
driver = self.api.getTarget().ser
driver.terminal_flush()
driver.terminal_write("?")
time.sleep(0.05)
driver.terminal_write("Synchronized\r\n")
time.sleep(0.05)
driver.terminal_write("12000\r\n")
time.sleep(0.05)
driver.terminal_write("R 0 4\r\n")
</syntaxhighlight>Finally, you'll need to create your class and register its methods with the aux module. In this case, we're want to update the glitch parameters before the trace is taken, set the reset pin low before we arm, set it high after we arm, and check the read protect after we do the glitch:<syntaxhighlight>
glitcher = LPC_glitch(self.glitch_explorer, self.api)
self.aux_list.register(glitcher.update_parameters, "before_trace")
self.aux_list.register(glitcher.turn_off, "before_arm")
self.aux_list.register(glitcher.turn_on, "after_arm")
self.aux_list.register(glitcher.check_read_protect, "after_trace")
</syntaxhighlight>
==== The Completed Script ====
At the end, you should have something that looks like this:<syntaxhighlight lang="python">
import time
try:
scope = self.scope
target = self.target
except NameError:
pass
# Glitcher
class LPC_glitch(object):
def __init__(self, ge_window, api):
self.ge_window = ge_window
self.api = api
def update_parameters(self, scope, target, project):
scope.glitch.ext_offset += 1
if scope.glitch.ext_offset > 8000:
scope.glitch.ext_offset = 1000
scope.glitch.repeat += 1
if self.ge_window:
self.ge_window.add_data("Glitch Offset", scope.glitch.ext_offset)
self.ge_window.add_data("Glitch Repeat", scope.glitch.repeat)
def check_read_protect(self, scope, target, project):
driver = self.api.getTarget().ser
driver.terminal_flush()
driver.terminal_write("?")
time.sleep(0.05)
driver.terminal_write("Synchronized\r\n")
time.sleep(0.05)
driver.terminal_write("12000\r\n")
time.sleep(0.05)
driver.terminal_write("R 0 4\r\n")
def do_glitch(self, scope, target, project):
self.api.setParameter(['CW Extra Settings', 'Target Power State', False])
time.sleep(0.01)
self.api.setParameter(['CW Extra Settings', 'Target Power State', True])
scope.glitch
def turn_off(self, scope, target, project):
self.api.setParameter(['CW Extra Settings', 'Target IOn GPIO Mode', 'nRST: GPIO', 'Low'])
def turn_on(self, scope, target, project):
self.api.setParameter(['CW Extra Settings', 'Target IOn GPIO Mode', 'nRST: GPIO', 'High'])
#Create and register glitcher
glitcher = LPC_glitch(self.glitch_explorer, self.api)
self.aux_list.register(glitcher.update_parameters, "before_trace")
self.aux_list.register(glitcher.turn_off, "before_arm")
self.aux_list.register(glitcher.turn_on, "after_arm")
self.aux_list.register(glitcher.check_read_protect, "after_trace")
#Initial Setup
scope.adc.samples = 10000
scope.adc.offset = 0
scope.clock.adc_src = "clkgen_x1"
scope.trigger.triggers = "tio3"
scope.io.glitch_lp = True
scope.io.hs2 = None
scope.glitch.width = 40
scope.io.tio1 = "serial_rx"
scope.io.tio2 = "serial_tx"
scope.adc.basic_mode = "rising_edge"
scope.clock.clkgen_freq = 100000000
scope.glitch.clk_src = "clkgen"
scope.glitch.trigger_src = "ext_single"
scope.glitch.output = "enable_only"
target.baud = 12000
target.key_cmd = ""
target.go_cmd = ""
target.output_cmd = "$GLITCH$54"
self.project.setTraceFormat(None)
</syntaxhighlight>
== Using the Glitch Explorer ==
The last thing we need to do before beginning our glitches is to setup the Glitch Explorer to detect successful glitches. Since the bootloader sends back a specific error message when read protect is enabled, we can use that to tell if our glitch was successful or not. For example, you could search the string for "\r\n19\r\n" for a normal response, and search for "\r\n0\r\n for a successful response. Setup your Acquisition Settings to run for a while, and check back for successful glitches. If you're lucky, you'll find some glitches and can start reading flash memory.
== Background on Code Read Protect ==
To help protect proprietary code from being dumped via a bootloader or a debugging interface, many microcontrollers include some mechanism that locks down the flash and prevents reads. In the case of NXP's LPC1114, this is done by reading a value from flash during the boot sequence, with different values corresponding to different levels of protection. As is shown in the figure below, there are 4 levels of read protection, with the rest of the values representing an unlocked device. This makes this a great target for glitching, as corrupting one bit from this read will unlock the device and give us full access. Since higher CRP levels are harder (or in the case of CRP level 3, "impossible") to remove, we'll be using the device in CRP level 1.
== Hardware Setup ==
=== ChipWhisperer-Lite (CW1173) with 909-LPC-P1114 Development Board ===
To allow the ChipWhisperer-Lite to interface with this board, we'll need to make some small modifications to the board:
# Short jumper BLD_E to put the device in bootloader mode
# Solder a wire from GND to P0_3 (Second column from the left, fourth row from the bottom) to put the bootloader in UART mode
# Remove C1 and C4 from the board
# Cut the traces on 3.3V_CORE and 3.3V_IO_E
# Add an SMA connector to the board and connect Vcc to the center pin and GND to one of the outside pins
# Add a header pin/wire to RST (First column from the left, third row from the bottom). The CW-Lite needs two connection points, as we'll be both resetting this pin and triggering off of it.
Next, we'll need to connect the CW-Lite to the connect pins on the dev board to pins on CW-Lite's 20 pin header:
# Connect pin 1 of UEXT (Vcc) to pin 3 on the CW-Lite
# Connect pin 2 of UEXT (GND) to pin 2 on the CW-Lite
# Connect pin 3 of UEXT (TXD) to pin 8 on the CW-Lite
# Connect pin 4 of UEXT (RXD) to pin 10 on the CW-Lite
# Connect RST to pins 5 (nRST) and 12 (GPIO3) or 14 (GPIO4) on the CW-Lite
Finally, attach an SMA cable between the one you added to the board and the GLITCH connector on the CW-Lite
=== ChipWhisperer-Lite (CW1173) with CW308 Target Board ===
Coming soon!
== Communicating with the Bootloader ==
Before actually glitching the bootloader, we'll need to be able to communicate with it, both to check the read protect status and to read contents of the flash once we're in. The bootloader is described in Chapter 26 of the LPC111x User Manual. [https://www.nxp.com/docs/en/user-guide/UM10398.pdf] In UART mode, the device can communicate at a variety of baud rates in 8n1. The bootloader uses flow control, but communication will work fine without it. This is the default setup for the CW Capture software.
Before we can do any read operations, we'll need to properly initialize the bootloader. Note that the bootloader will echo back what is sent to it by default.
# Reset the device. This can be done by pulling the RST pin low from the CW Capture, or by pressing the RESET button on the dev board/CW308.
# Send a "?" to the device. It will use this to detect the baud rate. From now on, all messages should be terminated by "\r\n".
# The device will send "Synchronize\r\n".
# Respond with "Synchronize\r\n". The device will respond with "OK\r\n", though it will probably be "Synchronize\rOK\r\n" due to the echo.
# Send the frequency of the external clock in KHz. The dev board uses a 12MHz clock, so we should respond with "12000\r\n".
# The device will respond with "12000\rOK\r\n".
The device is now properly setup, so you can begin sending it commands. For example, to read 4 bytes from address 0, send "R 0 4\r\n". The device will respond with an error code (0-19, with 0 representing no error). If the read was ok, the device will respond with the memory in UU-Encoded format, along with a checksum. You should now respond with "OK\r\n" to let the device know its read was alright.
This read can fail for a variety of reasons, but the one we are most interested in is error 19, which is returned when the read fails due to the device being in RDP mode.
== Setting up the Glitch ==
=== Firmware Setup ===
Since we're only attacking the bootloader, no firmware setup is required for this tutorial; however, if your device is not already in CRP mode 1, you'll need to put it into this mode.
=== Software Setup ===
# Connect to the ChipWhisperer Device by running the "connect_cwlite_simpleserial.py" script.
# Under the Scope Settings tab, setup the CLKGEN Module to generate a 100MHz clock:
## Under CLKGEN Settings, change "Desired Frequency" to 100MHz.
## Under ADC Clock, change "Source" to "CLKGEN x1 via DCM". If "DCM Locked" isn't checked, click "Reset ADC DCM" until it is.
# Set UART up:
## Under Target IOn Pins, set "Target IO1" to "Serial RXD" and "Target IO2" to "Serial TXD".
# Set the Vcc glitch up and make it trigger off an external trigger:
## Under CW Extra Settings/Trigger Pins, check "HS-Glitch Out Enable (Low Power)".
## Under Glitch Module, set "Glitch Trigger" to "Ext Trigger:Single-Shot".
## Set "Output Mode" to "Enable Only".
# Under the Target Settings tab:
## Set "Version" to 1.0
## Clear all of the Commands
## Set "Output Format" to "$GLITCH$54". This allows the glitch explorer to see when is being sent by the bootloader and limits the response to 54 characters.
# CW Capture records and stores traces by default. Since we don't need this functionality, we can speed up the glitch process by telling it not to record and display traces:
## Under the Generic Settings tab, set "Trace Format" to "None".
## Under the Results tab, set "Input" to "None".
# Since we may have to glitch over a long period of time, instead of changing the settings after every glitch attempt, we'll instead automate this by using a script to update the necessary glitch parameters, as well as do the setup for the bootloader.
=== Script Setup ===
==== Initial Settings ====
To make the Software Setup faster, the above settings can be set in your script. An example of this is shown in this tutorial's example script.
==== Automating the Glitch ====
First, create an object class to hold all of the methods that you'll be using to automate glitching. For this tutorial, we'll need access to the glitch explorer window, as well as the api:<syntaxhighlight lang="python">
class LPC_glitch(object):
def __init__(self, ge_window, api):
self.ge_window = ge_window
self.api = api
</syntaxhighlight>Add 2 methods, one for setting the reset pin low, and one for setting the reset pin high. Having two methods will help make triggering off the glitch more precise:<syntaxhighlight lang="python">
def turn_off(self, scope, target, project):
self.api.setParameter(['CW Extra Settings', 'Target IOn GPIO Mode', 'nRST: GPIO', 'Low'])
def turn_on(self, scope, target, project):
self.api.setParameter(['CW Extra Settings', 'Target IOn GPIO Mode', 'nRST: GPIO', 'High'])
</syntaxhighlight>Add a method to update the glitch parameters and tell the glitch explorer window about them. In this case, we care about the repeat (will determine how wide the glitch is) and the offset of the glitch from the trigger (how long after resetting the glitch happens). The following method covers a wide range, so you'll probably want to narrow things down a bit. Glitches between 5000 and 6000 (on the board we used, glitching at 5211 with a repeat of 10 produced a lot of successes) seem to bypass the bootloader the best:<syntaxhighlight lang="python">
def update_parameters(self, scope,taret,project):
scope.glitch.ext_offset += 1
if scope.glitch.ext_offset > 8000:
scope.glitch.ext_offset = 1000
scope.glitch.repeat += 1
if self.ge_window:
self.ge_window.add_data("Glitch Offset", scope.glitch.ext_offset)
self.ge_window.add_data("Glitch Repeat", scope.glitch.repeat)
</syntaxhighlight>Create a method that checks the read protect status of the device. In this case, we'll need to setup the bootloader as described earlier and try a read. We can tell if the glitch is successful based on what is returned when we try to do a read command. To get access to the CW-Lite's UART, we'll need to use the target's serial driver via self.api.getTarget().ser.
Note that the delays are used to allow time for the device to respond. If you wanted to make this communication more reliable, you could read what is sent back and check it against what you expect:<syntaxhighlight lang="python">
def check_read_protect(self, scope, target, project):
driver = self.api.getTarget().ser
driver.terminal_flush()
driver.terminal_write("?")
time.sleep(0.05)
driver.terminal_write("Synchronized\r\n")
time.sleep(0.05)
driver.terminal_write("12000\r\n")
time.sleep(0.05)
driver.terminal_write("R 0 4\r\n")
</syntaxhighlight>Finally, you'll need to create your class and register its methods with the aux module. In this case, we're want to update the glitch parameters before the trace is taken, set the reset pin low before we arm, set it high after we arm, and check the read protect after we do the glitch:<syntaxhighlight>
glitcher = LPC_glitch(self.glitch_explorer, self.api)
self.aux_list.register(glitcher.update_parameters, "before_trace")
self.aux_list.register(glitcher.turn_off, "before_arm")
self.aux_list.register(glitcher.turn_on, "after_arm")
self.aux_list.register(glitcher.check_read_protect, "after_trace")
</syntaxhighlight>
==== The Completed Script ====
At the end, you should have something that looks like this:<syntaxhighlight lang="python">
import time
try:
scope = self.scope
target = self.target
except NameError:
pass
# Glitcher
class LPC_glitch(object):
def __init__(self, ge_window, api):
self.ge_window = ge_window
self.api = api
def update_parameters(self, scope, target, project):
scope.glitch.ext_offset += 1
if scope.glitch.ext_offset > 8000:
scope.glitch.ext_offset = 1000
scope.glitch.repeat += 1
if self.ge_window:
self.ge_window.add_data("Glitch Offset", scope.glitch.ext_offset)
self.ge_window.add_data("Glitch Repeat", scope.glitch.repeat)
def check_read_protect(self, scope, target, project):
driver = self.api.getTarget().ser
driver.terminal_flush()
driver.terminal_write("?")
time.sleep(0.05)
driver.terminal_write("Synchronized\r\n")
time.sleep(0.05)
driver.terminal_write("12000\r\n")
time.sleep(0.05)
driver.terminal_write("R 0 4\r\n")
def do_glitch(self, scope, target, project):
self.api.setParameter(['CW Extra Settings', 'Target Power State', False])
time.sleep(0.01)
self.api.setParameter(['CW Extra Settings', 'Target Power State', True])
scope.glitch
def turn_off(self, scope, target, project):
self.api.setParameter(['CW Extra Settings', 'Target IOn GPIO Mode', 'nRST: GPIO', 'Low'])
def turn_on(self, scope, target, project):
self.api.setParameter(['CW Extra Settings', 'Target IOn GPIO Mode', 'nRST: GPIO', 'High'])
#Create and register glitcher
glitcher = LPC_glitch(self.glitch_explorer, self.api)
self.aux_list.register(glitcher.update_parameters, "before_trace")
self.aux_list.register(glitcher.turn_off, "before_arm")
self.aux_list.register(glitcher.turn_on, "after_arm")
self.aux_list.register(glitcher.check_read_protect, "after_trace")
#Initial Setup
scope.adc.samples = 10000
scope.adc.offset = 0
scope.clock.adc_src = "clkgen_x1"
scope.trigger.triggers = "tio3"
scope.io.glitch_lp = True
scope.io.hs2 = None
scope.glitch.width = 40
scope.io.tio1 = "serial_rx"
scope.io.tio2 = "serial_tx"
scope.adc.basic_mode = "rising_edge"
scope.clock.clkgen_freq = 100000000
scope.glitch.clk_src = "clkgen"
scope.glitch.trigger_src = "ext_single"
scope.glitch.output = "enable_only"
target.baud = 12000
target.key_cmd = ""
target.go_cmd = ""
target.output_cmd = "$GLITCH$54"
self.project.setTraceFormat(None)
</syntaxhighlight>
== Using the Glitch Explorer ==
The last thing we need to do before beginning our glitches is to setup the Glitch Explorer to detect successful glitches. Since the bootloader sends back a specific error message when read protect is enabled, we can use that to tell if our glitch was successful or not. For example, you could search the string for "\r\n19\r\n" for a normal response, and search for "\r\n0\r\n for a successful response. Setup your Acquisition Settings to run for a while, and check back for successful glitches. If you're lucky, you'll find some glitches and can start reading flash memory.