フォールトインジェクションとは？電圧グリッチでnRF52のプロテクションを破って学ぶ

まずは購入したnRF52840 Dongleでサンプルプログラムを作成しましょう。DongleはUSB端子がついており、USB経由でファームウェアを書き込めます。コンパイルし書き込むために環境は自由ですが、私はVSCodeにPlatformIOの環境を構築しています。

今回は次のコードを用いました。

#include <Arduino.h>

#define LED_RED PIN_SERIAL_RX

void setup() {
  printf("hello, world!\n");
  pinMode(LED_RED, OUTPUT);
}

void loop() {
  digitalWrite(LED_RED, HIGH);
  delay(500);
  digitalWrite(LED_RED, LOW);
  delay(500);
}

起動直後にシリアルに"hello, world!“を出力し、そのあと1秒ごとにLチカするコードです。書き込んだ後にLチカすることを確認します。

SWDを試す

はんだ付けが必要です。

Dongleのデータシートを確認し、SWDIO、SWDCLK、GND、VDD OUT、VBUSをケーブルに接続します。次の画像は基板とはんだ付けポイントをマッピングした図です。

はんだ付け対象のピン

SWDIO、SWDCLKはランドが複数あります。USB端子側を使ってもいいですが、ここに結線するとUSB接続時に干渉する恐れがあります。そのため基板裏のSWDコネクタ用ランドを使うといいでしょう。

VDD OUTの補足: VDD OUTは初期状態の回路では3.3Vの出力として用いることになっています。しかし、Dongleでは電源入力にUSB電源であるVBUSの5V入力のほかに、VDD OUTを3.3Vの電源入力として使えます。後述するグリッチのためにVDD OUTを使うため、あわせて結線しておいてください。参考URLによれば、VDD OUTを3.3Vの電源入力として利用するときは基板裏のSB1をショートさせ、SB2のパターンをカットする必要があります。ただ実際試してみたところSB1、SB2を変更せずとも電源入力として使えました（自己責任でどうぞ）。

参考: External regulated source

J-Linkに結線した場合はこんな感じになります。J-Linkは5Vを供給できるので、J-Linkの5V出力をVBUSに接続して駆動させています。

OpenOCDでのSWDデバッグ

次に、OpenOCDでSWDを用いたデバッグをします。まずはOpenOCDのインストールから。

Ubuntu 20.04で用意されているaptパッケージのバージョンではnRF52840に対応していません。他ディストリビューションのパッケージも古いようなので、Ubuntu以外を使っている人もGitHubにあるOpenOCDの最新ソースツリーからコンパイルして使ってください。

$ sudo apt install libusb-1.0-0-dev make libtool pkg-config porg
$ git clone https://github.com/openocd-org/openocd -b v0.11.0
$ ./bootstrap
$ ./configure
$ make
$ sudo porg -lp "openocd-0.11.0" "make install"
$ sudo cp /usr/local/share/openocd/contrib/60-openocd.rules /etc/udev/rules.d/
$ sudo useradd -G plugdev $(whoami)

OpenOCDのインストール後、Dongleに電源を供給し、SWD接続します。

$ openocd -f interface/jlink.cfg -c "transport select swd" -f target/nrf52.cfg
Open On-Chip Debugger 0.11.0-dirty (2021-11-19-18:00)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
swd
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : J-Link V11 compiled Nov 16 2021 11:59:06
Info : Hardware version: 11.00
Info : VTarget = 1.825 V
Info : clock speed 1000 kHz
Info : SWD DPIDR 0x2ba01477
Info : nrf52.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : starting gdb server for nrf52.cpu on 3333
Info : Listening on port 3333 for gdb connections

ファームウェアダンプ

この時点でのDongleはAPPROTECT=デバッグロックがかかっていないため、ブレークポイントの設定、レジスタ操作、メモリ操作が可能です。これを利用して先ほど書き込んだサンプルプログラムのファームウェアをダンプしてみます。

nRF52840のデータシートにはメモリマップが記載されています。メモリマップから、フラッシュ領域は0x0 ~ 0x00800000であることがわかります。

OpenOCDのコンソールに接続し、当該領域をdump_imageコマンドでダンプします。

$ telnet localhost 4444
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Open On-Chip Debugger
> halt; dump_image flashdump.bin 0x0 0x800000
dumped 8388608 bytes in 140.669281s (58.236 KiB/s)

ダンプしたファイルを確認すると、hello, worldという文字列も見つけられ、確かにダンプしたファームウェアであることがわかります。

$ hexdump -C flashdump.bin
00000000  00 00 01 20 f5 02 00 00  1d 03 00 00 1f 03 00 00  |... ............|
00000010  21 03 00 00 23 03 00 00  25 03 00 00 00 00 00 00  |!...#...%.......|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 27 03 00 00  |............'...|
00000030  29 03 00 00 00 00 00 00  2b 03 00 00 2d 03 00 00  |).......+...-...|
00000040  2f 03 00 00 2f 03 00 00  2f 03 00 00 2f 03 00 00  |/.../.../.../...|
*
00000080  2f 03 00 00 b9 05 00 00  2f 03 00 00 2f 03 00 00  |/......./.../...|
00000090  2f 03 00 00 2f 03 00 00  2f 03 00 00 2f 03 00 00  |/.../.../.../...|
(..snip..)
00001120  9e 46 70 47 68 65 6c 6c  6f 2c 20 77 6f 72 6c 64  |.FpGhello, world|

APPROTECTレジスタの確認

APPROTECTレジスタは0x10001208に存在します。データシートには当該アドレスの下位8ビットが0xFFのとき無効、0x00のとき有効と記載があります。

APPROTECTのデータシート

mdwで確認します。

> flash banks
#0 : nrf52.flash (nrf5) at 0x00000000, size 0x00000000, buswidth 1, chipwidth 1
#1 : nrf52.uicr (nrf5) at 0x10001000, size 0x00000000, buswidth 1, chipwidth 1
> mdw 0x10001208 1
0x10001208: ffffffff

値は0xFFであり、無効であることがわかります。

APPROTECTの有効化とデバッグの確認

このアドレスを0x00に設定し有効化します。

> halt; flash fillw 0x10001208 0xFFFFFF00 1
nRF52840-xxAA(build code: D0) 1024kB Flash, 256kB RAM
wrote 4 bytes to 0x10001208 in 0.269560s (0.014 KiB/s)

> mdw 0x10001208 1                         
0x10001208: ffffff00

ここでresetしてみると・・・

> reset
nrf52.cpu -- clearing lockup after double fault
Failed to enable the FPB
Polling target nrf52.cpu failed, trying to reexamine
Could not find MEM-AP to control the core
****** WARNING ******
nRF52 device has AP lock engaged (see UICR APPROTECT register).
Debug access is denied.
Use 'nrf52_recover' to erase and unlock the device.

Examination failed, GDB will be halted. Polling again in 100ms
> 
> mdw 0x0 1
Target not examined yet

APPROTECTの影響でデバッグができなくなりました。当然mdwなどでメモリを参照することもできません。この状態ではCPUのデバッグ用アクセスポートであるAHB-APに対するアクセスがすべて禁止されています。ただコントロール用アクセスポートであるCTRL-APはAPPROTECTの影響を受けないため、APPROTECTの状態を示すレジスタ（APPROTECTSTATUS）の参照や、APPROTECTの設定含む全てのフラッシュの初期化を伝えるレジスタ(ERASEALL)への書き込みが可能です。もしCTRL-APまで無効になってしまうと初期化もできなくなりますからね。

CTRL-APを用いたデバイス設定の初期化

CTRL-APを操作することで、APPROTECTの初期化を行ってみましょう。

APPROTECTSTATUSレジスタ(0xc)

APPROTECTが有効のとき、値は0になっています。これでCTRL-APでもターゲットのプロテクションが有効になっているかどうかがわかります。

> nrf52.dap apreg 1 0x0c
0x00000000

ERASEALLレジスタ(0x4)

Writeオンリーのレジスタです。このレジスタに1を設定することで、APPROTECTの設定を含む全てのフラッシュを消去します。

> nrf52.dap apreg 1 0x4 1

この状態で、resetすると・・・

> reset
nrf52.cpu: hardware has 6 breakpoints, 4 watchpoints

デバッグ機能が復活しています。mdwを利用したメモリ読み込みもできています。APPROTECTSTATUSレジスタを参照すると、0x1が格納されておりAPPROTECTが無効になっています。

> mdw 0x0 1
0x00000000: ffffffff

> nrf52.dap apreg 1 0x0c
0x00000001

また改めてフラッシュを確認すると、データが削除されていることがわかります。

> halt; dump_image flashdump_after_erase.bin 0x0 0x800000
dumped 8388608 bytes in 142.200241s (57.609 KiB/s)

$ hexdump -C flashdump_after_erase.bin |head
00000000  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00100000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00800000

APPROTECTを無効にするためにはフラッシュを全消去しないといけないわけですね。

プロテクションを有効にした機器では書き込まれているファームウェアでのデバッグができないし、デバッグできないとフラッシュの内容も読み取れない。APPROTECTを無効にするとフラッシュが消えるので初期化してデバッグも意味が無い。というセキュリティ対策になっているとわかります（既に破られているので完全な対策になっていないわけですが）。

最後に、またフラッシュにサンプルファームウェアを書き込んだうえで、APPROTECTを設定し、プロテクトがかかっている状態にしておきます。

関数	対応する機能
`target_reset()`	ターゲットのリセット
`sleep_count()`	一定時間のスリープ
`is_glitch_success()`	デバッグ可能か
`glitch_on()/glitch_off()`	CPU電圧をGNDに落とす/戻す

MOSFET	接続先
ゲート	グリッチャーのGPIO OUT
ドレイン	ターゲットのDEC1
ソース	GND

Shooting!!!

フォールトインジェクションとは？電圧グリッチでnRF52のプロテクションを破って学ぶ

Voltage Fault Injectionとは

APPROTECTバイパスとは

攻撃の脅威

APPROTECTバイパスの攻撃手法

検証環境

nRF52搭載のターゲット

グリッチャーボード

MOSFET

デバッガ

オシロスコープ

正常系の確認

SWDを試す

OpenOCDでのSWDデバッグ

ファームウェアダンプ

APPROTECTレジスタの確認

APPROTECTの有効化とデバッグの確認

CTRL-APを用いたデバイス設定の初期化

APPROTECTSTATUSレジスタ(0xc)

ERASEALLレジスタ(0x4)

グリッチャーの設計

「ターゲットのリセット」の方法

「一定時間のスリープ」の方法

「デバッグ可能か」確認する方法

「CPU電圧をGNDに落とす/戻す」方法

グリッチ回路の作成

前準備:DEC1への配線

グリッチ回路の作成

グリッチャーのファームウェア作成

実装:「ターゲットのリセット」

実装:「一定時間のスリープ」と「CPU電圧をGNDに落とす/戻す」

高速なグリッチをしたい場合

実装:「デバッグ可能か」

グリッチの実践

バイパスした状態でファームウェア抽出

対策

さいごに

参考文献

更新履歴