HPラップトップでUEFIを変更する可能性をめぐる闘争の一環として、今回はより現代的な別の防御策を打ち破らなければなりませんでした。 どうやら、HPのファームウェア開発部門は、 以前の保護がそれほど熱くないことを認識していたため 、根本的に改善することを決定したため、以前の記事からDXEボリュームの保護をバイパスする方法が機能しなくなり、再度、分解器で武装し、 TEからPEへのコンバーターを開発する必要がありました同じ質問に答えます。デジタル署名はどこにあるのか、誰がそれを正確にチェックするのか、検証が常に成功して終了することを確認する方法。
回答と検索プロセスの説明に興味がある場合は、catの下でご確認ください。
簡単な背景
保護については、このテキストで説明しますが、約1年半前にHPによって導入され、（私の知る限り）まだ信頼できると考えられていました。 UEFIで保護されたHPラップトップのユーザーは、機器のホワイトリストを削除したり 、隠れたUEFIセットアップ設定を開いたりすることを望んでbios-mods.comフォーラムに定期的にアクセスしましたが、同じ頻度で回答を受け取りました-保護は安定していて、何もする必要はありません。 2014年の初夏、bios-modsの管理者の1人がこれにうんざりし、ハッキングイニシアチブを自分の手に委ねることに決めました。 プロセスは開始しましたが、非常に遅く、一般公開の結果はまだ出ていません。また、これらのラップトップに他のプロセッサ/ビデオカード/モデムを搭載して喜んでいる修理業者にとっては非常に必要です。 正常に動作するには、DXEドライバーの変更が必要であり、それ以降はファームウェアが起動しません。 その結果、私はこのナンセンスにうんざりしていたため、以前のHP保護よりも根本的に難しいものを思い付くことができなかったため、保護を自分で解除することにしました。
教育プログラムはありません
ここで何が起こっているのかわからない場合は、 前の記事を読んでください。作業コースの簡単な紹介と使用するツールのリストがあります。
与えられたものと見つけるために必要なもの
HPラップトップがあります。これは、DXEボリュームの変更に応答して、電源を入れた直後にリブートし、キーボードのライトを点滅させながら無限のサイクルに陥ります。 また、ファームウェアのダンプと 、次の変更されたファームウェアのパフォーマンスを確認するために時間を費やす準備ができている親切な修理スタッフもいます。
最終的な目標は、修正後にファームウェアが動作することです。
検索
UEFIToolでファームウェアを再度開き、メッセージパネルを確認します。 前の記事で得た経験のおかげで、ユーティリティは非標準データをツリーに表示できるようになり（つまり、DXEボリューム全体をアンパックしてそれらにアクセスする必要がなくなりました）、ボリュームの再構築時にそれらを保存します：
前回と同様、疑わしいデータはDXEボリュームの最後にありますが、ツリーから直接取得できるようになりました。これを行うために、 key.binファイルを取得し、Hexエディターで開きます。
繰り返しますが、サイズ100hの未知のデータ（RSA2048公開キーに類似）が目の前に表示されますが、今では署名- $ HSSがあります。 すでに書いたように、この種のデータは、署名、ボリューム内のオフセット、または絶対アドレスのいずれかで見つけることができます（SPIフラッシュチップの最後のバイトが起動時にアドレスFFFFFFFFhにあるという事実を考えると）。 まず、UEFIToolのテキスト検索を使用して、最初のオプションを確認します。
目的の文字列が4回出現し、そのうちの1つ（非UEFIデータ内の1つ）が見つかったので、残りを処理する必要があります。 最初はBiosImageInterfaceという名前でDXEドライバーに表示されますが、チェック対象のボリュームにあるため、メインチェックが存在する可能性はほとんどありません。 他の場所で見つからない場合は、そこに戻る必要があります。
最後の2つのエントリは、同じPEIモジュールの2つのコピーを示します。最初のエントリは、PEIボリュームのパックコピー（破損したPEIボリュームの自動修復に使用できます）、および「実際の」PEIボリュームにあります。 ここに私たちの容疑者がいます。すべてが整合性をチェックするのは彼であることを示しており、さらなる分析のためにその内容をhss.binファイルに入れる必要があります。
前回、この場所でファイルをIDAにアップロードして分析を開始しましたが、この場合、IDA 6.7以上の所有者のみがこれを実行できます。 PEIモジュールが格納されているTerse実行可能形式のネイティブサポートが登場したのは6.7でした。 この形式は、プロセッサキャッシュ内のスペースを節約するためにUEFI PI仕様の作成者によって開発されました。実際には、非常にトリミングされたヘッダーを持つPE32から、正しいイメージの読み込みに不可欠なフィールドのみが残されます。 さらに、大半のメーカーは、PEIフェーズで非常に原始的な実行可能ファイルローダーを使用していますが、これは再配置をサポートしていないため、ベースアドレスは物理アドレスと一致する必要があります。 もちろん、これはすべて素晴らしいことですが、理解できないTEではなく、PE32を理解する必要があるため、TEからPEへのコンバーターを作成する必要がありました。これにより、TEファイルで見つかったことが判明したデータからPEファイルのヘッダーを復元しようとしています。 このユーティリティは30分で特定のファイル用に作成されたため、以前に設定されたTEイメージを変換する正確性を保証することはできません。
これでpe.binファイルが作成され、IDAで開いて分析できます。 今回は少し違った方法で、エントリーポイントからではなく、 $ HSS署名が見つかった場所から始めます。 [検索]-> [テキスト...]に移動し（またはAlt + Tを押して）、$ HSSと入力し、[すべての出現を検索]ボックスをオンにして...何も検索しません。 少し考えて、LittleEndianマシンがあることを理解します。レジスタにロードされると、$ HSSはSSH $または53534824hのようになります。 このオプションと出来上がりを探しています。
メッセージをダブルクリックして、ここに到達します。
そして、ここにEBXからのアドレスが53534824hであるというチェックがあり、もしそれが本当にあるなら-EBX + 20hがスタックの変数に格納されます。 キーの最初のバイトのアドレスのみで、そうでない場合は、10hがEBXに追加され、再度チェックされます。 また、コードの別のブランチから、キーの最初のバイトの物理アドレスである値FFF3DF00hが同じ変数に分類されることもわかります。 これを確認できます。100000000hからFFF3DF00hを減算し、受信したC2100hバイトをファイルの最後から戻すだけで十分です。予想どおり、キーのあるブロックの先頭にいます。 キーが署名または絶対アドレスのどちらで見つかるかは、BootModeに依存します。 現在のモードが20hの場合、つまり BOOT_IN_RECOVERY_MODE-キーは絶対アドレスで検出されます。それ以外の場合は、署名によって検出されます。
さらに調査します。
そして、特定のHP PPIから関数が呼び出され、検証が実行されます。 この関数が0（つまりEFI_SUCCESS）を返した場合、この画面をそのままにして戻ります。検証が失敗した場合、すべてがBootModeに依存します。BOOT_IN_RECOVERY_MODEの場合、別のPPIから関数が呼び出されます（疑わしい、リカバリイメージからDXEボリュームを復元しようとします）。 次に、BootModeとは別に、2番目のPPIから別の関数が呼び出され、その後6と0CF9hがスタックにプッシュされ、短い関数が呼び出されます。この場合は次のようになります。
mov al, 6 mov dx, 0CF9h out dx, al
突然メイクで認識しなかった場合、これがIOポートを介してハードリセットする最も一般的な方法です。 そして、リセットが突然行われなかった場合、無限サイクルが発生し、すぐに続きます。
さて、リセットの理由を突き止めたので、今度はそれを回避する必要があります。そして、すべての関数からEFI_SUCCESSをEAXに返すようにします。 私の意見では、あなたが望むものを達成する最も簡単な方法は、最初のテストeax、eaxをxor eax、eaxに変更することです。その結果、EAXに0が表示され、JGEは100％の時間動作し、リセットはデッドコードになります
LANからの多数の要求に応じたUPD ：パッチの場所をすばやく見つけるには、GUID 86D70125-BAA3-4296-A62F-602BEBBB9081のファイルから実行可能セクションを取得する必要があります（TEまたはPEのいずれかで、両方のオプションがあります）、それを開きますHexエディターで、ライン$ HSSを見つけ、$ HSSの後のパターン85 C0の最初の出現を見つけます-非常に高い確率で、これがパッチの場所です。 そうでない場合は、自分で探す必要があります。
テストと結論
パッチ85 C0-> 31 C0と言われるとすぐに、ファームウェアを収集し（このファイルのコピーが2つあり、両方を交換する必要があることを忘れないでください）、テストのために修理担当者に送信します。 5分後、メッセージが到着します。「起動して動作します。ありがとうございます。」 これで、再び座って、クールなベンダーの防衛に関する記事を書くことができます。最初は1年半続き、その後1時間半で削除されます。
ご注意、ファームウェアの成功、修正に感謝します。
PSボーナスとして、DXEボリュームに保存されたブートロゴが置き換えられた実行中のラップトップの小さな写真。 保護が実際に削除されたことを示します。 