UEFI BIOS修正パート1：UEFIToolの紹介

半神話的な「セキュリティ」と「単純なユーザーをブートキットから保護する」の背後に隠れて、 UEFIメーカーは製品の新世代ごとにネジを締めています。 同時に、前世代のサポートはすぐに消滅し、ユーザーはこのサポートを自分の手に委ねるしかありません。 もちろん、ソースコードがない場合、いくつかの変更を加えることは非常に困難ですが、それなしで多くのことを行うことができます。

UEFIについての以前の 記事では、メーカーが定めたいくつかの制限を克服するのに役立つさまざまな便利な修正を説明する予定でしたが、それらは手に届かず、今がその時です。

この記事の最初の部分では、UEFIイメージを変更するために作成したツールでの作業について説明し、2番目の部分では変更自体に専念します。

エントリー、免責事項

USB BIOS Flashback、Dual BIOS、Flash Recoveryなどのさまざまなテクノロジーが存在するにもかかわらず、最新のマザーボード上のUEFI BIOSファームウェア -まだ宝くじ。 変更されたイメージのファームウェアは二重宝くじです。

そのため、ハードウェアSPIプログラマーを使用してファームウェアの実験を開始する前に、マイクロサーキットの内容の完全なダンプを作成するようにお願いします。そうしないと、失敗したファームウェア（および遅かれ早かれ発生します）からの回復に時間がかかり、費用がかかり、痛みを伴います

SPIプログラマーは現在、抵抗とコンデンサのペア（ SPIPGM ）からArduinoまたはRaspberry Piまで、自宅で組み立てることができます。 安くて高速なSPIプログラマーの私のバージョンをここで説明します 。 このプロジェクトに注意を払うために、いくつかのボードをエッチングするファン、およびこのプロジェクトにオールインワンデバイスのファンを勧めます。

さらに本文では、プログラマー、ファームウェア障害から回復する能力、および実験する意欲があることを信じています。 もちろん、勇敢な人の狂気に合わせて歌を歌うこともできますが、後で警告しなかったと言わないでください。

伝統的に、あなたがここで読むすべては教育目的のために書かれており、作者はあなたの機器への損害、利益の損失、時間の損失、人類への信仰について責任を負いません。

ウエフィツール

UEFIイメージを操作するための既存のユーティリティの制限にうんざりして（心の中でNIH症候群に打たれた）、私はオープンソースのクロスプラットフォームユーティリティ-UEFIToolを書きました 。

これはUEFIイメージエディターで、C ++ \ Qtで記述されており、BSDライセンスの下で配布されています 。既製のアセンブリはここにレイアウトされています 。

プロジェクトは活発に開発されているので、コードは美しく輝いておらず、バグはありませんが、いくつかあります。 あなたが出くわした場合-私は報告してうれしいです。

ユーティリティを使用した通常の操作については、UEFIイメージの構造に関する以前の記事を読む価値があります。そうしないと、何が起こっているのかまったくわかりませんが、いくつかのポイントを説明しようとします。 これは、今後のドキュメントでは空白であると想定しています。

記事の両方の部分の例として、Zotac Z77-ITX WiFi（AMI Aptio4）およびDell Vostro 3360（Phoenix SCT 2.3）でフルダンプを使用します。 残念ながら、Insyde H2Oプラットフォームにはテストベンチがないため、それについて何も話すことができません。 おそらく、 Falseclockはそれらについてもう少し知っています。

UEFIToolの観点から見ると、異なるメーカーのUEFIイメージに実質的に違いはないため、パッチを説明する際に焦点を当てます。

したがって、UEFIToolを実行し、イメージを開き（Ctrl + O）、次のようなものを確認します。



ツリーの形で開かれた画像の構造はウィンドウの左側に表示され、選択されたツリー要素の情報は右側に表示され、ファイル形式のエラーを示すメッセージは下部に表示されます。この場合、Phoenix開発者はタイプ0xF0のセクションを使用します。 PI メッセージをダブルクリックするとツリーが開き、このメッセージが呼び出した要素自体またはその親要素のいずれかでツリーが表示されます。 検索結果は同じウィンドウに表示でき、Ctrl + Fを押すことで呼び出すことができます（両方のオプションが同じ画像にあります）。



ここで用語を少し明確にする必要があります。 UEFIイメージのほとんどすべての構造要素にはヘッダーがあり、GUID、属性、チェックサムなどのサービスデータ、および本体が格納されます。データ自体はその中に格納されます。 テキストはヘッダーに保存されないため、このような選択は必要ありません。

ツリーの最初のレベルには、フラッシュ領域、この場合は記述子、ME、およびBIOSがあります。



記述子領域を選択すると、領域のアクセス設定、この場合はフルアクセスを見つけることができますが、そのような設定は非常にまれです。 インテルは、機器メーカーが読み取り/書き込み用のME領域と書き込み用の記述子領域へのアクセスをブロックすることを推奨しています。そのため、組み込みツールを備えたほとんどのボードでは、タンバリンと踊らずに完全なダンプを削除することはほとんど不可能です。 MEリージョンを選択すると、MEファームウェアのバージョンを確認できますが、表示されない場合、これは良くなく、そのようなイメージを縫わない方が良いです。

BIOS領域の内容に1つ下のレベルに行きましょう。



このレベルでは、ボリュームと空き領域の2種類の要素を見つけることができます。 この場合の無料は必ずしも空ではありません。たとえば、 ECファームウェアは、パディングの最初の段階でこのイメージに保存されます。

ボリュームは、通常のボリューム（ファイルシステム形式が既知）、ブートボリューム（FS形式が既知、セキュリティコアを含む、特別な注意を払って変更する価値があります）、および不明（FS形式が不明であるか、分析がまだ実装されていない）に分かれています。 私たちの場合、最初の空き領域の後の最初のボリュームは正常であり、2つの未知数（実際、最初のボリュームはNVRAMを格納し、2番目はSecureBootのキーとデータベースを含みますが、これをプログラムにまだ説明していません）、最後のボリュームは起動可能です。

次に、通常のボリュームを開きます。この場合、DXEフェーズでロードされたファイルを保存します。



このような構造（圧縮セクション内のメインボリューム）は非常に頻繁に使用され、チップ内のスペースをかなり節約できます。 ボリューム全体ではなく、各ファイルを個別に圧縮する別のオプションがあります-これはスペースの面でやや経済的ではありませんが、そのようなUEFI BIOSはより高速に起動します アクセスされていないファイルを解凍しても意味がありません。

次に、ファイルの内部を確認します。



その中のすべてのデータは、GUID定義セクション内に保存され（EDSまたはチェックサムは、通常、このようなセクションのヘッダーに保存されます。この場合、CSに似ていますが、誰もチェックしない4バイト）、4つのセクションに分割されます： PE32-PE / COFF形式の実際の実行可能ファイル、DXE依存関係セクション-DXEドライバーのロード順序、UIセクションを決定します-テキスト「SystemCapsuleRt.efi」をUnicode形式で格納し、タイプ0xF0の不明なセクションを格納しますこれは、前述のCOPに関連しています。

もちろんこれはすべて良いことですが、編集はまだ表示されていません。 どんな要素でもコンテキストメニューを呼び出し、この要素で何ができるかを示します。



そして、次のことができます。

• 要素をファイル全体（そのまま抽出）で保存するか、データのみでヘッダーなし（本体を抽出）で保存します。
• この場合、変更された画像（およびそのすべての親要素）、サイズ、チェックサムが再計算され、位置合わせが修正されます。 画像構造はUEFI PI仕様に合わせて調整されます
• 選択した要素の前（前に挿入）、後（後に挿入）、またはその中（この場合、PE32セクションに何も挿入できない）に、ファイルから要素を挿入します。
• 要素全体をファイルの別の要素で置き換える（そのまま置き換える）か、本文のみ（本文を置き換える）

最後のアクションが最も役立つのは、 イメージ全体の構造に影響を与えることなく、UEFIの任意の部分を変更できます。

使用例

例として、PC上のMacOS Xユーザーにとって有用な変更を検討してください。レジスタMSR_PMG_CST_CONFIG_CONTROL（0xE2）のLOCKビット（0x0F）の設定をバイパスします。 このビットは、OSがこのレジスタに書き込むことによってCPU乗算器を制御できないように、PowerManagement DXEドライバーによって設定されます。 WindowsとLinuxの場合、これは大きな問題ではありませんが、MacOS XはUEFIからこのような厚かましさに耐えられません。 もちろん、AICPM.kextドライバー（10.8）またはカーネル（10.9）にパッチを適用できますが、DXEドライバーにパッチを適用し、次の自動更新によってダウンロードが中断されることを恐れないでください。 このパッチは、Intel SandyBridge、IvyBridge、およびHaswellプロセッサーとそれらの* -Eオプションに基づくシステムでのみ必要であり、次のように実行されます。

1. UEFIToolでダンプを開き、Ctrl + Backspaceを押してメッセージをクリアし、干渉しないようにします
2. 検索を開き、「Hex-pattern、Body only」を選択して、行「75080FBAE80F」を探します
   
   
3. 行が見つかったというメッセージをダブルクリックし、指定された要素の本文をファイルに保存します
   
   
4. 16進エディタで「75080FBAE80F」を「EB080FBAE80F」に修正し（JEはJMPになります）、変更を保存します
   
   
5. 選択した要素の内容を変更した要素で置き換えます。古い要素には削除のマークが付けられ（削除）、新しい要素には置換のマークが付けられ（置換）、ルートのすべての親要素が再構築されます（再構築）
   
   
   
   
6. 変更された画像を保存します（Ctrl + S）。保存が成功した場合、保存されたばかりの画像を開く要求が発行されます。そうでない場合、エラーメッセージが表示されます。

結果のイメージを、それが作成されたのと同じSPIプログラマーでフラッシュし、MacOS Xをロードするときにカーネルパニックが発生しないようにします。

詳細、その他の修正、結論

75080FBAE80Fマジックパターンの由来と注意すべきその他のパッチについて知りたい場合は、この記事の2番目の部分を読んでください。 その中で、修正する要素を削除する方法と挿入する方法を毎回厳密に調べることなく、「どのような修正、なぜそれが必要なのか、それを作る方法、誰が、どのように見つけたのか」という形式でより多くの例を準備しようとします。

この記事があまりにも退屈で退屈に見えないことを願っています。 ご質問やご提案がありましたら、可能な限り聞いて回答させていただきます。 バグレポートはさらに嬉しいです。 事前に感謝し、成功したファームウェア。



PS親愛なる管理とUFO個人的に、そのような投稿のためのUEFIハブを作ってください。