The PocketGlitcher

This blogpost presents a modding system, called PocketGlicher.
It provides an automated way to perform voltage glitching, without any expensive electronic equipments or any “hardware” skills.
As proof of concept, the nRF52 Debug Resurrection Attack presented at BlackHat EU 2020 can be reproduced easily using this plug-and-play solution.

Introduction

I recently found back my PocketBeagle in a box, bought three years ago. It is a 5 cm-board, 25 $, ARM-based… Exactly the type of hardware I like.
Consequently, I have decided to develop a fully-automated and integrated fault-injection system, based on this nice little board.

PocketBeagle

PocketBeagle is an ultra-tiny-yet-complete open-source USB-key-fob computer.

Ken Shiriff’s blog is a perfect introduction to understand the PocketBeagle’s capabilities. You can find more information available on the PocketBeagle Wiki.

The PocketBeagle requires an SD Card storing the latest available firmware image (select Buster IoT for pocketBeagle). The board can then be accessed via SSH (USB tethering).
Just follow this quick start guide if you are not familiar.

$ ssh debian@192.168.6.2
debian@beaglebone:~$ uname -a
 Linux beaglebone 4.19.94-ti-r42 #1buster SMP PREEMPT Tue Mar 31 19:38:29 UTC 2020 armv7l GNU/Linux

Octavo Systems

The board is based on the OSD3358-SM System-in-Package (SiP), integrating:

• Texas Instruments Sitara AM335x CPU (ARM Cortex-A8),
• 512MB DDR3 RAM,
• 4KB EEPROM,
• PMIC (power/battery management)
• No eMMC (It is why the PocketBeagle requires an SD Card)

TI Sitara AM335x Processor

Inside the OSD335x-SM System-in-Package, there is a Texas Instruments Sitara AM335x System-on-Chip (SoC). Here is the block diagram:

Among all the functionalities offered by the Sitara AM335x, I am particularly interested in the PRU-ICSS block.

Programmable Real-time Unit (PRU)

PRU-ICSS is the Programmable Real-time Unit and Industrial Communication SubSystem:

The PRU0 and PRU1 are dedicated proprietary TI RISC Core, running at 200MHz. They are programmed with a small, deterministic instruction set. Each PRU can operate independently or in coordination with each other. The PRUs can also work in coordination with the host CPU (Cortex-A8), via shared memory (we will use it later).

That means you can use them to deal with time-constraints tasks, protocol implementation… offloading these from the main Cortex-A8(and without being worried about interrupts, context switches in Linux).
Due to the deterministic characteristics, the executed code on the PRU will always take the exact amount of CPU clock Cycles (quite interesting for a limited glitch system).

More infos:

• Texas recently removed the PRU-ICSS Wiki from the internet…unbelievable (Why?)
• The TI Training Series about PRU are still available.
• The best reference to start coding with PRU is PRUCookBook.

How does it work?

The way to program the PRU has constantly involved, depending on the Linux Kernel version and TI drivers.

Right now, for the PocketBeagle running Linux beaglebone 4.19.94-ti-r42, the simplest way is to compile (or cross-compile), without TI Code Compiler Studio, via one of the installers here.

I compile directly on the PocketBeagle. I download the ti_cgt_pru_2.3.3_armlinuxa8hf_busybox_installer.sh installer and run as sudo:

debian@beaglebone:~$ sudo ./ti_cgt_pru_2.3.3_armlinuxa8hf_busybox_installer.sh 
 Installing PRU Code Generation tools version 2.3.3 into /
   please wait, or press CTRL-C to abort
Extracting archive
 Installing files
 [####################] 100%  
 Installed successfully into /

Hello World from PRU

The example is available on GitHub. Download and extract the archive on the BeagleBoard. Follow the instructions to compile the C code and you should see some encouraging kernel messages:

debian@beaglebone:~$ dmesg
...
[ 741.152748] remoteproc remoteproc1: Booting fw image PRU_gpioToggle.out, size 31364
[ 741.152782] remoteproc remoteproc1: remote processor 4a334000.pru is now up

Probing the P1_36 (near to the SD Card Slot) to verify the behaviour:

I have now a good understanding of how the PRU works (reading Texas Documentation and guide was helpful). I can start developing my low-cost system.

The PocketGlitcher Project

This section describes the design of the PocketGlitcher, starting by its Block diagram.

System Block Diagram

PRU Code Development

This chapter presents an overview of the main software components developed for this project.

Pulse generation

A dedicated piece of C code managing the PRU0 output (R30 register) is written to generate a pulse controlling the following parameters:

• Delay (1 Clk Cycle => 5 ns)
• Width (1 Clk Cycle => 5 ns)

The PRU Pulse output will be on P1_36.

Input Trigger

The PRU0 has to synchronise the pulse generation depending on an input signal (trigger_input), via the R31 register.

This signal can be:

• Option 1: A signal from an external source like an oscilloscope (preferred option when you need power analysis).
• Option 2: A signal from the target itself (VDD, Reset Signal, Enable…), which will be adapted before feeding the PRU input pin the PocketGlitcher (this option does not require an oscilloscope).

The trigger input will be on P1_29.

A dedicated script is available to configure the required GPIOs:

config-pin P1_36 pruout
config-pin -q P1_36
config-pin P1_29 pruin
config-pin -q P1_29

ARM Code Development

The host CPU (ARM Cortex-A8) is executing a dedicated piece of code to set the pulse delay and pulse width values for the PRU via shared memory:

 ./pwm-arg $delay $width

Analog Development

The Analog stage is based on level shifter, Mosfet and resistors, designed to produce a powerful negative glitch (also known as crowbar technique) once triggered by the Pulse_Output (P1_36).
It has to be reliable, able to drive a large amount of current with a very fast response Time Ton.

Adding extra-Features

USB port

I add a USB port to the PocketBeagle on P1 header, in order to connect a USB flash drive or a USB-Ethernet Adapter (or Wi-Fi dongle).

debian@beaglebone:/$ lsusb
Bus 002 Device 002: ID 1e3d:2093 Chipsbank Microelectronics Co., Ltd CBM209x Flash Drive (OEM)
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
debian@beaglebone:/$ sudo mkdir -p /media/usbkey
debian@beaglebone:/$ sudo mount /dev/sda1 /media/usbkey/

OpenOCD and ST-LINK

Sadly, I could not install OpenOCD on the PocketBeagle. It is why I keep it connected to the main PC running x86_64 Ubuntu.

For this project, I have decided to use a ST-LINK V2 as SWD probe. (You cannot be cheaper than this…)

The Segger J-Link debugger is also supported by the PocketGlitcher.

Target Reset Control

One solution is to use the Ykush from Yepkit. It is a Switchable USB hub to control the power ON and OFF of the USB ports. It can be controlled from the shell via command application, or integrated to python via the pykush library.

The ST-LINK, connected to the USB Hub, is providing the 3.3V DC Supply to the nRF52 module.

UPDATE: An other solution is to use a dedicated GPIO on the PocketBeagle to supply the nRF52. It works perfectly (due to the fact that most of the modules are very low-power).

debian@beaglebone:/$ config-pin P2_02 gpio
debian@beaglebone:/$ echo out > /sys/class/gpio/gpio59/direction

So it is now possible to fully control the power on/power off of the device via the PocketGlitcher without the use of a Switchable USB Hub.

Reaching the Full Automation

By extracting previous parameters (from the nRF52 investigation), I developed some python scripts to configure the PocketGlitcher, the YKush and the ST-Link for various scenarios (minimal, typical, etc).
These script files connect to the PocketGlitcher via SSH and handle everything to reproduce the nRF52 Debug resurrection attack, (once the hardware setup is properly connected to the target).

New scripts can also be written to adapt the PocketGlitcher to different targets and to support other equipments. It can then be used as a cheapwhisperer.

PCB Integration

I design a cape to integrate the external circuitry and to add external Ports to the PocketBeagle (which is a little bit limited in term of connectivity…) After drawing a schematic on Kicad, placing and routing the PCB, trying different approaches…. PocketGlitcher v0.0 is born.

The prototype works as expected. The next one will be based on SMD, with enhanced connectors…

The Results

Let’s hack an nRF52 (again).

The (unmodified) Target

This nRF52832 module is supplied by a 3.3V.
SWCLK and SWDIO signals are connected to the JLink Debugger.

The APPROTECT is then activated to disable the SWD Debug on the nRF52.

For this PoC, the target is not modified. (I don’t remove the decoupling capacitors like I use to do for the vulnerability identification phase).

Solder-Less Glitching

Whenever I have to spy data, monitor analog signals or perform glitching session, I use to solder wires or micro-wires. Why? Simply, there is no risk of bad electrical conductance and nothing moves.

Nevertheless, I found the sensepeek probes very useful for probing few signals on a board (4 maximum). They include a pogo-pin connected to pin header. The probe has a flexible metal arm and a powerful magnet in the base for positioning (the stability is OK.)

I had to test it and associate them with the PocketGlitcher, in order to provide a solder-less glitch solution:

I confirm it is efficient and one probe can be used to probe the signal input_trigger and a second one to connect to VDD_DEC1 to inject the fault.

Final Setup

First, it is necessary to load the PRU firmware and to configure the PRU inputs/outputs.

sudo ssh_PRUGlitcher_activate.py

Then, I can launch a dedicated python script, setting a minimal configuration to attack the nRF52 and dump its firmware:

sudo python Minimal_nRF52.py

The SWD debug interface is then reactivated (100% guarantee):

Discussion

Why you don’t use FPGAs?

I just wanted to do something different, based on TI PRU cores (and find an ultimate goal for my PocketBeagle). Check the icestick-glitcher for an affordable FPGA-based Glitcher based on Yosis (in the FPGA world, free software is not so common 🙂)

How can I get a PocketGlitcher?

The PocketGlitcher is available on Tindie, in the LimitedResults Shop. I can also propose customised sets on demand. Limited Price 🙂

Are you going to open-source the project?

I don’t know yet…

Conclusion

This PocketGlitcher is a Glitching mod-device. It uses the Texas Instruments PRU to create deterministic signals (5ns precision, not so bad), associated with determined configs. An analog PCB Cape is then plugged to the PocketBeagle to provide a sufficient glitching effect, once connected to the VDD target.
As a result, it is now possible to reactivate the nRF52 debug with a low-cost plug-and-play solution. And the most important, the system fits in a pocket 🙂

Besides, a low-cost Solderless Glitching technique based on pogo-probe has been demonstrated too. It is a perfect association with the PocketGlitcher, to avoid any soldering on the target.

Todo List

• Improve the PCB v1.0 (improved design)
• Write the User Manual
• Integrate the reset target control feature directly to the PocketGlitcher (v2)
• Improve trigger capabilities (It works but a little bit limited right now)
• Add several attack configuration to reproduce my previous (and maybe future) glitching exploits