はんだごてのハッキング方法

フレーズは少し奇妙に聞こえますか？ 技術的な進歩のおかげで-それほど昔ではないが、「電話で写真を撮る」ことはそれほど奇妙ではなかった。









昨年の終わりに、すでに「フォーク」というラベルを取得したはんだ付けステーションを購入しました。 その利点：便利なT12チップカートリッジ、まともな電力（理論的には最大72W）、高速加熱（秒単位）、低価格。 （このシックなレビューで駅に慣れることができます ）



最新バージョンのハードウェア2.1を購入しましたが、ファームウェアが古いことを知って少し気が動転しました。 もちろん、彼の手はcombかれて更新されました。 はんだ付けステーションの「心臓部」がSTM32F103C8（STMicroelectronics製の人気のARM Cortex-M3マイクロプロセッサ）であることを知っている-掘り下げるのがもっと面白かった STM32F4DiscoveryのLEDを一度点滅させました。



その後、SWDインターフェースの4本のワイヤーがはんだ付けされ、プログラマーが接続され、ファームウェアがアップロードされました。

そして...ステーションはアクティベーションを要求しました！



わかりやすくするために、このステーションの開発者についていくつかの言葉を話します。 すべての情報はインターネットから取得されます（一部はファームウェア自体から取得されます）。 鉄とファームウェアは、2014年頃に中国の特定の友人ZhongGuoxin（38827251@qq.com）によって開発されました。 いくつかの中国のフォーラムの非公開グループで活発に開発が行われていました。 彼の「カントリーマン」によるクローン化から開発を保護する試みの無益さを認識しているように、彼はファームウェアで保護を行いました。 ファームウェアはバイナリモジュールの形式で配布され、だれでもそれをはんだ付けしたばかりのクローンで埋めることができました。



なぜそうですか？ 結局、既にフラッシュされたMKを配布し、暗号化されたBLOBで更新する、はるかに信頼性の高いスキームがあります。 知りません どうやら時間、利便性、人気と収入の間の微妙なバランス。 起動時に、ファームウェアはコードID1とID2を生成し、作成者は、9元（〜80ルーブル）の象徴的な量のアクティベーションキーRG1とRG2と交換します。



しかし、攻撃者がアクセスできる場合、どうすればファームウェアを保護できますか？ 今、私たちは見つけます。



残念ながら、デバイスでアクティベーションコードを正直に購入することはできませんでした。 今後、これらのコードは、更新に加えて、マイクロプロセッサ（脚を火傷した場合）またはEEPROMを交換することで再はんだ付けできます。 そして、そのようなケースはすでに繰り返し発生しています。



なぜなら 私は自分のコピーを正当に所有し、その後アートに完全に従っています。 ロシア連邦民法典1280年、「プログラムの機能に必要な行動を実行できる」

最初のパンケーキはゴツゴツしている

ファームウェアがIDAにダウンロードされました。 アクティベーションコードが入力された場所を非常にすばやく見つけました。 私が正しい軌道に乗っていることを確認するために、DisplayStringという関数の引数にパッチを適用しました。 パッチを当てたバージョンを埋めました。 始まらない！



まあ、それは大丈夫です、私はおそらく機能の目的を誤解しました。 変更をロールバックします。 表示されたテキストにパッチを適用します。 始まらない！



すごい 整合性チェックがあります。 デバッガが必要です。 そして、ハードウェアブレークポイントで彼女をキャッチします！ デバッガーとしていくつかのオプションを分類し、IDA gdb + OpenOCDの束に決めました。 IDAデバッガー自体は不便でバグがありますが、デバッガーで直接disasmをインタラクティブに編集する機能は、デバッガーを上回りました。



OpenOCDを起動し、変更されたコードのバイトを読み取るようにウォッチポイントを設定します。 私はそれを始めています。 ウォッチポイントが機能しない...どうして？ 結局、完全な整合性チェックが存在します！

そして、ここで私は本当に興味があります。

データを調査します

ファームウェアのフルサイズは75,512バイトです。 これはかなりたくさんあります。 データのコードはすでにIDAによって分離されています。 ARM Thumbの機能である、関数間のコードにあるローカルデータの小さなスポットを除く、48128バイトのコードと27384バイトのデータが判明しました。



ここで、このデータの意味を理解しておくといいでしょう。



最も単純なのはテキストデータです。 メニュー項目の名前、ヒント、著作権。 彼らは6kb以上であることが判明しました。 メニューテキストの中に、FLASHセグメントの32ビットアドレスに非常に類似したバイトが見つかりました。 これらのアドレスには、以前に見つかったDisplayStringへの呼び出しを含む大量のルーチンがありました。 したがって、これらはメニュー項目ハンドラーです。 適切な量​​のコードが認識されます。



続けます。 ステーション画面はモノクロであるため、グラフィックデータはビット（モノクロ）形式で表示されると想定するのが論理的です。 ZX-Spectrumの子供時代を思い出して-列にバイトを表示することが決定されました。90年代にゲームでグラフィックを探していましたが、データやコードとは著しく異なりました。



Viewbinはpythonで書かれています。 便宜上、256バイトの各ブロックは隣接するブロックから分離されています。 合計で、正確に1キロバイト（4ブロック）が1列に垂直に配置されます。 次の列は、次のキロバイトを指します。









グラフィックの波線が右側にはっきりと見えます。 しかし、写真では彼らはひどく合算します。 そして、頭を右に傾けると？ 最初に、フォント8 * 16（x * y）に気付くことができます。最初の8バイトは文字の上半分を形成し、2番目はその下半分を形成します。









残りのキャラクターは同じ原理で構築されています。 大きなフォントサイズは16 * 32、象形文字のグリフは16 * 16









さらに、さらにいくつかのサービスシンボル（摂氏アイコン、温度計、矢印、チェックボックス）があります。 合計で約16 kbがグラフィックで占められています。



27 kbのデータのうち、22 kbがすぐに認識されました。 悪くない。



コードに移りましょう-48キロバイトのタイトなTHUMBコード。 とてもコンパクトです。 たとえば、頻繁に発生する操作v1＆（〜v2）は、1つの「BTC」命令です。

ARM Cortex M3とは何ですか？

MKには、ARMコアに加えて、多数の周辺モジュールが含まれています。 このすべての経済は、メモリにマップされたレジスタによって制御されます。 これらのレジスタは数千あります。 それらは機能属性に従ってグループ化され、各グループは整列されます。



プラスいわゆる BitBanding- ワード （32ビット）へのアクセスは、単一ビットのアトミックインストールまたはリセットを意味します 。 1つの32ビットレジスタがBitBand領域で128バイトを占有すると推定するのは簡単です。 合計レジスタは、完全に狂った量のアドレス空間を占有します。



周辺機器の操作は、これらのレジスタの書き込みまたは読み取りです。 ARMのCMSISライブラリは、SIコードの薄い層を備えた裸のレジスタと、周辺機器の製造元（この場合はSTM32F10x_StdPeriph_Driver）の付属ライブラリをカバーしています。



Cコードから、周辺機器の操作は、周辺機器の名前付きレジスタを変更するように見えます。



アセンブラーでは、この作業はいくつかのレベルの間接アドレス指定のように見えます。 通常のCPUレジスタ。 r2からr1を取得し、それから別のr0を取得し、オフセット0x0Cで再びr0を取得しました。 それが何であるかは完全に不明です。

コードを調べる

登録コードを入力すると、いくつかの関数が呼び出されます。 画面がクリアされます。 碑文が表示されます（中国語で！）。 その後、さらにいくつかの関数が呼び出されます。 2つの値がチェックされます。 そして、いずれかのメッセージが表示されます（中国語で！）。 その後、ステーションがハングします。



これがコードチェックであると仮定して、条件を置き換えました。 何も変わっていません。 呼び出された関数とその内部にブレークポイントを設定します。 これらは、まったく異なる引数で多数の場所から呼び出されます。



明確ではありません。 最初に戻ります。 では、なぜWatchPointの整合性監視が機能しないのですか？



理由はDMA（Direct Memory Access）コントローラーにあると推測しました。 さらに、STM32にはハードウェアCRCカウントモジュールがあります-タスクを与えると、DMAを介してメモリからバイトを読み取り、アドレスをインクリメントし、チェックサムを読み取ります。 実行が完了するまで待って、レジスタから結果を読み取るだけで十分です。



ただし、ペリフェラルの動作を調査するには、すべてのレジスタをその番号で正確に判断する必要があります。 数千のレジスタがあり、その数値形式はライブラリコードのレイヤーによってプログラマから隠されています。 逆アセンブラで定数を見つけました-それがどのようなレジスタであるかを見てください。 ジャンプデータシートの逆アセンブラーはすぐに退屈しました。 そして、IDA用のPythonスクリプト（ GitHubへのリンク ）を作成しました。これは、大量のレジスターを生成します。 同時に、割り込みベクターのテーブルを定義し、ハンドラーに名前を付け、開始点を作成し、SRAMセグメントを作成します。

少し明確になりました。



作業のロジックを復元するには、小さな機能から始めることを好みます。 これらは理解しやすく、有用なものもよく使用されます。



多くのビット演算を使用する関数は、「ブルートフォース」を使用して「浮動小数点」として定義されました。命令ポインターは関数の先頭に配置されました。 浮動小数点の16進表記がレジスターに入力されました（例えば、数字「100.0」および「30.0」）。 （便利なオンラインコンバーターへのリンク）。 関数の結果は、フローティングビューに変換されます。 出力に「70.0」や「3.3333」など、意味のあるものがある場合は、安全に名前を付けることができます。 関数の一部がfloatで動作し、一部がdoubleであることが判明しました。



私は非常に幸運で、周辺機器を扱うために、著者は標準ライブラリを使用しました。SIコードは逆アセンブラと完全に一致しました。



私はいくつかのnoreturn関数につまずきました。その入力では、lrは値0xFFFFFFFFで「ノーウェイ」を示し、スタックは0x12121212、0x09090909などの奇妙な定数で満たされていました。 GoogleはそれがFreeRTOSだと主張しました（何？！

リアルタイムオペレーティングシステム... A SOLDER-IN？）。



しかし、バイナリコードはソースと比較できませんでした。 10.0.0（2018）から3.2.4（2005）までの10バージョンを確認しました。 どこでも、類似性は表面的なものにすぎませんでした。 そのため、そのような関数の名前をTaskXXXXXに限定し、それらを渡す一般的なコードはTaskCreateとして制御します。

周辺機器の探索またはデバッグの自動化

標準ライブラリの認識されている関数には、DMAInit、DMACmd、DMAGetCurrentDataCounterがありました。 問題は、彼らがあまりにも頻繁に呼ばれたことでした。 そして私は怠け者です。



そのため、OpenOCD関数を操作するためのPython APIを作成しました： GitHubへのリンク 。 コマンドは、telnetプロトコルを使用してOpenOCDサーバーに送信されます。 ディレクトリ「examples / dbgbot」での使用例として、ロボットのコードがあります。これについては以下で説明します。



このAPIに基づいて、DMA呼び出しを調査するロボットを作成しました。 ロボットは、DMA_Init関数でDMA操作の初期化に応答します。 ペリフェラルのアドレス、メモリ、送信の方向、送信された要素の数とサイズ、およびソースと受信者のアドレスの自動インクリメントのオプション機能を記録します。



しかし、これに加えて、受信したデータを確認したいと思いました。 たとえば、CRC計算が要求された場合、そこで正確に計算されたものを知りたいです。 これを行うには、呼び出しのチェーン全体を調べます：Init-> Command "enable"-> Wait。 つまり 状態マシンが必要です。 状態間の位置に応じて、ブレークポイントを動的に設定および削除します。



Waitの場合、ハードウェアカウンターがリセットされるまで待つ必要があります。 （まだ割り込み信号がありますが、これは私たちの場合ではありません。）コマンドを実行し続けている間、待たなければなりません。 JTAGデバッグは、マイクロプロセッサコアを完全に停止します。



問題は、著者が少量のデータのコマンドをDMAに与えた場合、待機することに煩わされなかったことであることが判明しました。必要な時までに、チップはすでにすべてを行っていました。 私にとって、この決定は、転送の終了を追跡するためにDMAGetCurrentDataCounterを呼び出すことを望んでいなかったことを意味していました。 そして、彼らがこれらのデータの使用を開始したとき、私も知りませんでした-あなたがそれらを受信するのが遅すぎる場合、それらはすでにコードの残りによって破損しているかもしれません。



したがって、ヒューリスティックを適用する必要がありました。転送サイズが32バイトを超える場合、明示的なチェックが使用されます。 それ以外の場合、転送コマンドを発行した後、送信のために要求されたバイト数と同じ数の指示に従います。



これが唯一の「ハック」ではありません-予想のコード全体を検討した結果、DMAGetCurrentDataCounterを呼び出した後は常に4バイトかかるという結論に達しました。

したがって、このブレークポイントの最初の操作の後、戻りアドレスを取得し、ブレークポイントを4バイト後に再配置します。 待ち時間は終わりました！





DMA操作の分析を含むロボットのビデオ：





8つのCRC関連機能がありました（EIGHT！）。 それらのいずれにも明示的なパラメーターは含まれず、華やかな計算が使用されます。 これらの関数の一部では、計算に再帰を使用しているため、理解がさらに複雑になっています。



ロボットが作成したダンプから、定数（私はMasterCRCと呼びます）がフラッシュからRAMにコピーされ、次にRAMからRAMにコピーされていることがはっきりとわかります。 フラッシュの2つの半分のCRCと見なされます：この定数の前とこの定数の後の最後、つまり 空いている場所でも。 そして、これは、フラッシュする前にチップがクリーニングされない場合、チェックサムが収束しないことを意味します！



完全なCRCカウントが4回実行されます。 ホラー！ 次に、CRCからCRCと見なされます。 そして、CRC to CRC to CRC。 ホラー！ CRCの操作に強く、私は掘り下げませんでした。

DMAは最初の成功をもたらします

CRCとメモリからメモリへの奇妙な動きの計算に加えて、ログは一意のチップIDを受け取ることが判明しました。 DMAを使用します。 これは非常に疑わしい チップIDは生産中に設定され、クリスタルごとに固有です。これは、regcodeを生成するためのデータソースの役割の優れた候補です。

興味深い情報：12バイトのチップIDには、バッチ番号、プレート番号（ウェーハ）、さらにはこのウェーハ上のxyチップ座標さえ含まれています！

チップIDを受け取った後のコードの分析では、同じ関数が2回呼び出され、最初はIDの最初の6バイトで、次に2回目で呼び出されることが示されました。 この関数は、256桁の配列のインデックスとしてバイトを使用して、渡されたバッファーを処理し、結果を破損およびシフトします。



疑いが確認されました-コールは私のID1とID2コードを返しました。

新年

標準の周辺機器ライブラリから関数を定義すると、アドレス0x800C23Cの奇妙なテーブルの処理に気付きました。 7つのGPIOポートすべての16ピンのそれぞれの状態を説明しました（呼び出しはひどいコピーペーストです）。 どのピンが何のために使用されているかが興味深くなりました。





EEPROMフラッシュ接続に注意してください。 I2Cラインは足に巻き付けられており、ハードウェアI2Cはありません。 奇妙な決断ですね。



まあ、すべてが良い。 I2Cで働いたことはありません。 そして、MKの足の信号を手動で制御するレベルでそれを感じる機会がありました！ TIのWebサイトからドックをダウンロードし、状態テーブルを作成して、ロボットのコードをスケッチしました。 そのため、彼は転送をデコードするためにピンを変更します。



そして、残念なことに私を待っていました。 EEPROMはデバッガーによって停止されません。 そして理論的には彼女はマスターを待つことができましたが、実際にはすべてが完全にバラバラになります。



プロトコルの動作を知っているので、関数に名前を付けて、レベルの高いFlash_ReadData / Flash_WriteData関数にレベルを上げていきます。

リンクを見てください。読み取りと書き込みは、コード入力の場所から呼び出されます。 おもしろい！ 入力がフラッシュによって書き込まれた後、4バイトの応答コードが判明します。 そして、そこから読み取られます。 検証のためにこれらの操作を期待しました。 そして、中国語の2つの異なるメッセージ-あなたが書いたものを読んだ場合、そうでない場合（ハードウェアエラー？）。



コードを入力した後、チェックされないことがわかります。 ステーションの開始時に常にチェックされます。 検証エラーが発生すると、メインのRTOSはんだごてタスクの代わりに、コードを入力してフラッシュに書き込む別のRTOSタスクが作成されます。 まあ、それは論理的です。



さらに、隣接するフラッシュ機能では、堅固なデータが読み書きされます。 サイズは0x3AEバイトです。 設定のように見えます。 それらを読み取った後、データバッファによってコードを計算する関数が呼び出されます。 歯磨きに、ID1とID2の計算機能を連想させます。 さらに、データテーブルもまったく同じです。 なぜそのようなコードを使用して設定の整合性を検証するのですか？ より良いCRCが必要です！ 待って、どうしたら...？ 私はテーブルからGoogle定数を操作します-確かに。 これはCRCです。 より正確にはCRC16_CCIT。 同じ機能の2つのコピー。 テーブルの2つのコピー。 敵には推測しませんでした。

最後のステップ

そのため、フラッシュからの読み取りを制御します。 「初期化をリセット」。 ブレークポイントは、記録されたばかりの回答が読み取られる場所にすぐにつながります。 読み取りデータにウォッチポイントを置きます。 「再開」ステーションは、何も起こらなかったかのように、コード入力インターフェースを表示します。



再びDMA？ ログを確認します。 読み取りコードをフラッシュからコピーした直後に、32バイトの2つのブロックがコピーされます。 DMA操作からのリターンアドレスで逆アセンブラを確認します。 コードで32バイトをコピーした後、内部にxorの束を持つ奇妙な関数呼び出しがあります。 ブレークポイントを配置します。



この関数を呼び出すと、いくつかのデータを含むバッファーが表示されます。最後の4バイトは、すでにおなじみのID1およびID2ステーションです。 関数の終了時に、16ビットの数値が表示されます。 別の呼び出しは他のデータを含むバッファで、最後にはID1とID2もあります。

好奇心が強い情報：各32バイトバッファーのデータは、対応する文字の画像です。 イメージの最後の4バイトは、バッファー内でID1 + ID2に置き換えられます。 これらはどのような象形文字ですか？ たぶん開発者の名前？ 私は知らない、私は中国語が苦手です。

しかし、関数の結果が目的の応答コードである場合はどうでしょうか？ ステーションを起動し、デバッガで受け取った番号を入力して再起動します-コードが受け入れられます！



この神秘的な関数が正確に計算するものを理解することは残っています。 そして彼女はこれをします：

1. 明示的に定義された定数間のXORの束。 最終的な値を取りました。 それを「manyXorValue」と呼びましょう。
2. 自身の先頭からCRC16_CCITを計算します。 また、すでに計算された値を使用します。 「xorCodeCrc16」と呼びましょう。
3. CRC16は、結果（manyXorValue xor xorCodeCrc16）を初期値とみなし、CRC16テーブルの既によく知られている2つのコピーの代わりに、別のテーブルを考慮します。 非常に似ていますが、まだ異なります。

元のテーブルは8つの要素に分割され、混合され、再び接着されたようです。 たとえば、最初のスライスが0番目になりました。 5番目はまだここにあります。 そして4位は現在31位です。 比較のために短いコードを作成します。この奇妙なテーブルを組み立てるために必要な順列は次のとおりです：1、2、3、4、31、5、6、7、8、9、10、11、12、0、13、25、14、 15、16、17、18、19、20、21、22、23、24、26、27、28、29、30



Pythonでの書き換え。 チェック-動作します。 デバッグのために、同じステーションを持つインターネットの数人にIDを渡して、生成されたRGをチェックするように頼みました。 さらに5駅でチェック。 結果は正しいです。

おわりに

• 防御の基礎は、大量の複雑で複雑なコードであることが判明しました（確かにそれを数えませんでしたが、10-15％を垣間見ると）、鉄の仕事に深く関わっています。 RTOSマルチスレッドも重要な役割を果たしても驚かないでしょう。 幸いなことに、実装の微妙な点をすべて理解するつもりはありませんでした。
• ステーションは新しいファームウェアで獲得しています。 最終的に私は彼女のためにタオと一緒にシックなアルミ製のハンドルを組み立てました。 同じステーションではんだ付け。
  
  更新：コメントでは、このペンについて既に2回質問されています。 ここに素晴らしいレビューがあります。
• ARM Cortex M3およびSTM32周辺機器に関する多くの新しい情報を学びました。
• 中国のファームウェアの品質に率直に失望しました。 ゼロから書き直してオープンします。

そして、防御が簡単だったら？ 私はおそらくコードを入力し、それを忘れていたでしょう...



ストーリーの継続について学ぶことに興味があるかどうか、コメントを書いてください。はんだ付けステーションの動作アルゴリズムの逆と、私のバージョンの開発の進捗。



PS：特にこの記事では、javascriptのキー生成コードを書き直しました。 オンラインバージョン 、Pythonバージョンへのリンクもあります。 説明がどこか理解できない場合-コードから詳細を描画できます。 そしてもちろん、鉄の更新や修理によってブロックされた自分のステーションを復活させます。