UEFI PEIモジュールの簡単なリバースエンジニアリング手法と有用な例

こんにちは、Habrの親愛なる読者。

あなたとの長い休憩の後、私とUEFIの内部を掘り下げます。 今回は、一部のHPラップトップのファームウェアを変更から保護するために設計された、古くて人気のあるPEIモジュールSecureUpdatingを使用して、実行可能なUEFIコンポーネントのリバースとデバッグを簡素化するいくつかの手法を示すことにしました。

背景はこうです：ある夜、ベラルーシのよく知られたラップトップの修理工が私に手紙を書いて、VideoBIOSを交換したラップトップが次に同じもので正常に起動するのになぜ起動しないのかを尋ねました。 答えは表面にあることが判明しました-変更後に起動しなかったラップトップには、UEFIの新しいバージョンがあり、HPの優秀な人々がDXEボリュームの変更に対する保護を統合しました（そして、UEFIコードの80％とともに必要なVideoBIOSが見つかります）。悪意のないユーザーは、誤ってそこで何かを壊しませんでした。 その後、古いUEFIバージョンから新しいバージョンにSecureUpdating PEIモジュールを転送することで問題は解決しましたが、2週間後、同じ人が再び向きを変えました。今回は同様のラップトップで古いバージョンのモジュールが機能しなくなり、私の助けが再び必要になりました。
逆アセンブラーとパッチされたトランジションを使用したUEFI PEIモジュールの世界での私のさらなる冒険に興味があるなら、catにようこそ。

教育プログラムへのリンクのカップル

あなたがほとんど何も理解していない場合-それは大丈夫です、私は用語を説明するいくつかの記事を持っています： 1、2、3 、読んで戻ってください。 オリジナルのドキュメントのファンのために、 UEFI PI 仕様は常に利用可能です。すべてがより詳細に書かれています。

必要なファイルとツール

上記のファームウェアを分解するには、次のものが必要です。

1. 実際にファームウェアを含むファイル、 これは私に送られました 。
2. UEFIイメージを操作するためのユーティリティはすべてUEFIToolを作成者として使用しますが、 uefi-firmware-parserやPhoenixToolなど、好みに応じて使用できます。これは重要ではありません。
3. お好みの16進エディタ、 HxDを使用します 。
4. PE32ファイルをサポートする逆アセンブラー。ここではIDA 6.6デモが理想的です。 ほとんどの場合、PEIモジュールは32ビットであり、デモバージョンの制限はそれほど害になりません。 親愛なるxvilkaがradare2の Cファイルから構造をロードする方法を示すことができれば、次のmodを作成しようとしますが、今のところ、IDAがすべてです。
5. efi-utilsバンドルには 、UEFIで使用されるほぼすべての可能なデータ構造の定義を含む多額のbehemoth.hファイルが必要です。 私たちの場合、必要なのはそれらのうちの数個だけです。

出発点

修理担当者の言葉から、次のことがわかります。DXEボリュームの変更は、Caps Lockでラップトップの点滅を引き起こし、画像の他の部分の変更はそのような結果にはなりません。 これは、チェックサムまたはEDSのいずれかが格納され、PEIモジュールのいずれかのコードによってチェックされ、収束する場合、制御はDXEフェーズに転送され、そうでない場合は、どこにも転送されないことを意味しますうれしい。

次のことを確認する必要があります。

1. CS / EDSは正確にどこに保存されますか？
2. 誰が彼女をチェックしていますか？
3. そして、最も重要なことは、検証が常に正常に終了することを確認する方法ですか？

行こう！

一度やってください！

UEFIToolのファームウェアでファイルを開き、注意深く見てください：

UEFIボリュームの1つの空き領域内に、仕様によればそこにあるべきではないデータがあったというメッセージを除いて、異常なことはないようです。 これは、（仕様を実際に信じていない人の）メーカーが通常、チェックサムまたはデジタル署名を隠す方法です。 メッセージをダブルクリックして、これらの同じデータが見つかったボリュームを選択し、その全体を分析のためにdxe.volファイルに抽出します。 UEFIToolは閉じる必要はありません-まだ便利です。

結果のファイルを16進エディタで開き、ボリュームの空き領域はそこにしか存在できないため、最後から検討します。

また、サイズ100h（赤でマーク）の非常に疑わしいデータがあり、その後ろに署名$ SIG 、ファームウェアバージョンF.50およびプラットフォームコード名68CPKがあります。 したがって、最初の質問に対する答えはおそらく受け取られます。

二回やる！

2番目に答えるには、このデータブロックにアクセスするPEIモジュールを探す必要があります。 これは簡単ではなく、多くの場合、いくつかのオプションを試す必要があります。 最も簡単な方法は、$ SIGシグネチャの他の出現を探すことですが、この場合、すぐに失敗します-画像内にそのような行の他の出現はありません。 ただし、ブロックが署名で検索されない場合は、オフセットまたは絶対アドレスで検索されます。 ボリューム内のオフセットは12FEE0hです。 UEFIToolに切り替えて、ヘッダーを考慮せずに16進パターンE0FF12を検索します（IntelプロセッサーはまだLittleEndianなので、バイト順を変更する必要がありました）。


Iiii ... BINGO、2つのエントリのみ、および両方が有望な名前SecureUpdatingを持つ同じPEIモジュールにあります。 さらに分析するために、 su.binファイルにヘッダーなしでそれを取り出します。

したがって、おそらく、2番目の質問に対する回答が受信されます。

３つやって！

第三に対処するために残っています。 これを行うには、逆アセンブラ、デバイスのPEIモジュールに関する知識が少し必要、忍耐力が必要です。 IDAを起動し、デモモードの条件に同意して、以前に受信したファイルを開きます。
[オプション]-> [コンパイラ]に移動し、次のように設定します。


次に、 [ファイル]-> [ファイルの読み込み]-> [Cヘッダーファイルの解析]に移動し、必要なファイルのリストにある上記のbehemoth.hファイルをUEFI構造の定義とともに読み込みます。

解析エラーに注意を払う価値はありません。この場合、エラーは発生しません。

[構造]タブを開き、[ 編集 ] -> [構造タイプの追加... ]に移動し（または[挿入]をクリックすると高速になります）、[ 標準構造を追加 ] をクリックします。

同時に、EFI_GUIDとEFI_FFS_FILE_HEADERを追加します-便利です。

EFI_PEI_SERVICES構造体（絶対に正確な場合、PEIカーネルによって作成されたインスタンスへのダブルポインター）は、パラメーターとして各PEIモジュールのエントリポイントとそのほぼすべての関数に渡されます。 これは、PEIの一部がフラッシュメモリから直接実行されることを強制されているためです。フラッシュメモリはその時点では読み取り専用であるため、このようなPEIモジュールのグローバル変数は使用できず、すべてを持ち歩く必要があります。 これはプログラマーにとって不快な制限ですが、次のようにPEIモジュールの調査とデバッグに役立ちます。 ダブルポインターの逆参照は、通常のコードではあまり一般的な手順ではないため、PEIサービスへの呼び出しのほとんどは、リストから直接追跡できます。 そのため、ここに戻りますが、最初にPEIモジュールへのエントリポイントがどのようなものかを思い出します（または調べます）。 グーグルに急がないでください、それは次のようになります：

EFI_STATUS EFIAPI PeimEntry( IN EFI_FFS_FILE_HEADER *FfsFileHeader, IN EFI_PEI_SERVICES **PeiServices ); 

EFI_STATUSはunsigned intのtypedef、EFIAPIはstdcallのtypedefです。最初のパラメーターは、呼び出されたPEIモジュールが配置されているFFSファイルを示します（モジュールがデータを近くに保存し、アクセスする必要がある場合） ）、および2番目は、既に上記で説明したPEIサービステーブルへのダブルポインターです。 この知識を武器に、開始関数のタイプを大胆に変更し（強調表示してYキーを押す）、次のようになります。


現在、リストには次のことが示されています。まず、PeiServicesが不要な一連の関数呼び出しがあります。 ほとんどの場合、それらはIOポートと他のこの種の魔法との間で入出力を行っています。最初に順番に移動してこの仮定を検証します。


実際、関数はポート24Ehへのデータ出力を実行します。 次のいくつか（これらは非常によく似た、読み書きIOポート）を省略し、PeiServicesがまだ使用しているものに進みます。
1つ目は簡単で、PeiServicesをグローバル変数に保存するだけです（PEIモジュールが既にRAMから実行されていることを示しますが、専門家の鋭い目はUEFIToolのPEファイルに関する情報からこれに気づいたでしょう）。


特に正しいパラメーターを設定し、その値のタイプを返す場合、以下はすでにはるかに大きく、はるかに興味深いものです。


プロローグとローカル変数のゼロ化の直後に赤で強調表示されたフラグメントは、上記で説明したダブルポインターの逆参照と同じ顕著なパターンです。 どのような種類のPEIサービスが呼び出されたかを理解するには、構造体の周りでこれらすべてのダンスが必要でした。[eax + 28h]にカーソルを置き、 Tを押して表示されるウィンドウでEFI_PEI_SERVICES.GetBootModeを選択します：


そのシグネチャを見ると、var_134は実際にはスタック上の変数であり、現在のブートモードの値が書き込まれると結論付けることができます。 次に、この値は11hと比較され、等しくない場合、計算はさらに進みますが、まだ等しい場合、eaxにゼロを入れて戻ります。 この場合の11hはBOOT_ON_S3_RESUME 、つまり システムがACPIスリープモードから起動すると、関数は常に0を返します（これはローカルの方言EFI_SUCCESSにあります）。 システムが別の状態から起動すると、実行が継続し、結果としてこの興味深い場所を通過します。


バ、古い友達！ このモジュールを見つけたのと同じ12FEE0hの出現。 そして、最初に、CopyMem関数を使用して、その疑わしいCS / EDSがバッファーにコピーされ、元の場所がFFhバイトで上書きされます。これは、最初にDXEボリュームの空きスペースを埋めるために使用され、次にこのCS / EDSをチェックする関数が呼び出されます
もちろん、今すぐ探索を開始できますが、システムがS3からウェイクアップする場合、コードのこの部分はまったく実行されません（S3のDXEボリュームには何も必要ないため、できるだけ早くウェイクアップする必要があるため、論理的です）あまり機能しないので、まず始めに、この特定のPEIモジュールに、永遠の夏があり、常にS3_RESUMEがあると考えさせ、チェックをスキップします。
これを行うには、cmp [ebp + BootMode]、11hをxor eax、eaxに変更するだけで、次のjnzは実行されませんが、完了しない場合は、遷移自体をいくつかのNOPに置き換える方が簡単です。


Hexエディターで選択したフラグメントを90 90に変更して完了です。

UPD

突然、いくつかの新しい状況が現れました。 この「古い」バージョンの保護には、システムがPEIボリュームの元の状態を復元するために使用できるPEIボリュームのコピーがあります。このコピーでは、SecureUpdatingモジュールもパッチを適用したものと交換する必要があります。 コピーは、タイプRAWのGUID 05B3AFFD-F7CC-4C0A-A19A-A9774E2675D7のファイルに保存されるため、このファイルの内容はUEFIToolの現在のバージョンでは表示されません。

実際、これはタイプFreeformのファイルであり、そのコンテンツにアクセスするには、 Extractからそのまま抽出する必要があります... 、 抽出されたファイルのオフセット12h（ファイルタイプ）のバイトを01から02に置き換え、Replaceを介して元のファイルの代わりに結果ファイルを挿入しますそのまま... ：

このファイル内には、PEIボリュームのコピーを含む圧縮セクションがありますが、そこにはSecureUpdatingの別のインスタンスがあり、これもパッチが必要です。 今では、以前は望んでいなかった場所でもすべてが確実に機能します。

おわりに

さらに技術の問題です。 Replace Body ...元のPE32セクションの内容を変更されたファイルで置き換え 、DXEボリュームに必要な変更を加え、変更を保存し、プログラマーに結果のイメージをフラッシュします。 私はこのラップトップを持っていなかったので、修正して結果をサプリカントに送信しました。 数時間後、「ありがとう、すべてが機能し、クライアントは満足しています」という答えが返ってきました。私はあなたが読んだばかりの記事を書くために明確な良心をもって行きました。
ご清聴ありがとうございました。