組み込みデバイスに動的リバース エンジニアリングを使用する方法

ブログ

ホームページホームページ / ブログ / 組み込みデバイスに動的リバース エンジニアリングを使用する方法

May 21, 2024

組み込みデバイスに動的リバース エンジニアリングを使用する方法

IoT の普及に伴い、セキュリティの脆弱性も急増しています。 放っておくと、悪意のある攻撃者がこれらの弱点を利用して組織のシステムに侵入する可能性があります。 通常

IoT の普及に伴い、セキュリティの脆弱性も急増しています。 放っておくと、悪意のある攻撃者がこれらの弱点を利用して組織のシステムに侵入する可能性があります。

定期的な侵入テストは、セキュリティのベスト プラクティスとして長い間認識されており、セキュリティ チームが組み込みデバイスの脆弱性と弱点を特定して軽減するのに役立ちます。 しかし、多くの組織はペネトレーション テストをネットワークとインフラストラクチャの調査に限定しており、IoT デバイスは見落とされがちです。

セキュリティ チームが組み込みデバイスの侵入テストについて最新情報を得るために、サイバー リスクおよび金融サービスのコンサルタント会社であるクロールの上級副社長であるジャン ジョルジュ ヴァレ氏は、「実践的なハードウェア侵入テスト: IoT およびその他のデバイスの組み込みシステムの攻撃と防御のテクニックを学ぶ」を執筆しました。 。

次の第 10 章からの抜粋で、Valle 氏は、ペネトレーション テスターが動的リバース エンジニアリングを使用して、組み込みデバイスでの実行中にコードがどのように動作するかを確認する方法を詳しく説明しています。 Valle は、コードがどのように動作するかを観察する際に発生する可能性のある課題を侵入テスターに​​示すために、動的リバース エンジニアリングの例を示しています。

Valle 氏の組み込み侵入テストに関するインタビューをお読みください。これには、彼が使用する一般的なテスト手順、組み込み侵入テストの難しさ、今日の組織が組み込みデバイスをどのように保護しているかについての彼の意見が含まれます。

編集者注: 以下の抜粋は、Practical Hardware Pentesting, Second Edition の早期アクセス バージョンからのものであり、変更される可能性があります。

いくつかの課題を提示する前の例の変形を準備しました。 両方の場合に必要な労力を比較できるように、これらの課題を静的および動的の両方で克服する方法を示します。

動的アプローチと静的アプローチを比較するときの経験則は、99% の場合、動的アプローチの方が簡単であるため、可能であれば優先する必要があります (JTAG/SWD などにアクセスできない可能性があることを忘れないでください)オンチップ デバッグ プロトコル)。

このセクションでは、必要な場所でブレークする方法、GDB を使用してメモリを検査する方法、およびこれらすべての優れた機能についても学びます。

ターゲット プログラムは、クローンを作成したフォルダーの ch12 フォルダーにあります。

まず、Ghidra にロードして表面を検査してみましょう。 Ghidra の読み込みウィンドウで正しいアーキテクチャとベース アドレスを設定することに注意してください (その方法やベース アドレスの値を覚えていない場合は、前の章を参照してください)。

一見すると、main 関数は前の章の main 関数と非常によく似ています。 前の章と同様に PASSWORD 文字列を検索することで main 関数への参照を見つけ、その構造を分析することができます。

前の章で習得したスキルに取り組んで、さまざまな機能を見つけてもらいます。 この実行可能ファイルには、次のものが再び見つかります。

初めてのことなので、構造が似ているのは意図的なものです。 前の章とまったく同じ手順を繰り返したとしても、新たに学ぶことは何もありませんよね。

ここで、システムとの動的な対話を通じてこのパスワード検証をバイパスする複数の方法を見てみましょう。 皆さんが集中してノウハウを習得できるように、最も複雑なものから最も単純なものまで順に説明していきます (もしあなたが私と同じで、何かを回避する簡単な方法があるのなら、なぜ難しい方法を選ぶ必要があるでしょうか?)。

最初に行うことは、テストに合格するパスワードを生成する方法を理解するために、パスワードがどのように検証されるかを確認することです。

Ghidra によって出力される検証関数と同等の C コードを見てみましょう。

うーん...これはパラメーターを直接処理していません。 これは、0x47 (71) バイトの静的バイト配列の内容を RAM にコピーし (コピーするわけではありません)、それを関数として呼び出します。

これはおかしい。

またはそれは?

これは、コードを偽装するための非常に一般的な手法です (もちろん、その非常に単純なバージョンです)。 オペコードの明確なバージョンが .bin ファイルに存在しない場合 (つまり、MCU のフラッシュにも存在しない場合)、Ghidra のようなリバース エンジニアリング ツールは、それがコードであることを検出できません。 ここで、考えられるアプローチは 2 つあります。