UEFI互換ファームウェアのNVRAMデバイス、パート1

こんにちは親愛なる読者。 むかしむかし、ほぼ3年前に、私は UEFI互換ファームウェアで使用されるデータ形式に関する記事を いくつか 書きました 。 それ以降、これらの形式はほとんど変更されていないので、これらについて再度説明しません。 それにもかかわらず、それらの記事には深刻なギャップがありました。NVRAMとそれを保存するために使用されるフォーマットについては言及されていません。 NVRAM分析は、 dmpstoreコマンドを1つ使用するだけで、稼働中のシステムのUEFIシェルから同じデータを取得できるため、興味を引くものではありませんでした。

3年後、NVRAMストレージはさまざまな理由でバラバラになる可能性があり、ほとんどの場合、このイベントは「レンガ」につながります。 前述のコマンドを利用することは不可能であり、データ（またはそれらの残り）を取得する必要があります。 Hexエディターでいくつかの折りたたまれたNVRAMを手動で組み立てたので、「 やめろ！ 」と言い、 UEFITool NEでNVRAM形式の解析のサポートを追加し 、これらの形式に関する一連の記事をホットトラッキングとフレッシュメモリで書くことにしました。

最初の部分では、このNVRAMの概要について説明し、VSS形​​式とそのバリエーションを検討します。 興味があれば、猫へようこそ。

免責事項

すでに確立された伝統に違反することを敢えてせずに、ここで収集できるすべての情報は、不注意または不適切な使用により、NVRAM、ファームウェア、システム、および人類への信仰を破壊することにつながることを余儀なくされています。 著者は何に対しても一切責任を負わず、あなた自身の危険とリスクで知識を使用し、運動を行い、よく食べ、より多く眠ります。



この記事に記載されているすべての情報は、UEFI互換ファームウェアのさまざまなイメージをリバースエンジニアリングすることによって取得されたものであり、100％完全または真であると主張するものではありません。 間違いを見つけた場合は、コメントで報告してください。修正させていただきます。

はじめに

そもそも、誰もが冷静にCMOS SRAM設定をバッテリーに保存し、話題にならなかったことを考えると、このNVRAMとは何なのか、そしてUEFI仕様の著者が突然それを必要としたのはなぜですか？ NVRAMの「論理」レベルについてはすでに少し説明しましたが、ここでは「物理」についてさらに詳しく説明します。

したがって、NVRAMは、不揮発性属性が設定されたUEFI変数を格納する特別なデータ領域です。 この種の最も一般的な変数は、BIOSセットアップからの現在の設定のほとんどを保存するSetupであり、 BootXXXX / BootOrder / BootNextは、ブート順序を制御します。PK/ KEK / db / dbx / dbtは 、 SecureBootの操作を担当します。 -前の5つの攻撃、および他の多くの攻撃では、特定のリストはベンダー、ボードのモデル、およびファームウェアのバージョンによって異なります。



ほとんどの場合、NVRAMは実行可能なファームウェアコードと同じSPIチップ上にありますが、これは1つの単純でありふれた理由です-ほとんど無料です（8 MBチップで100-200 Kbがほとんどの場合に見つかるため、 128 Kbはかなり具体的なお金がかかります）。 これは無料で、いくつかの非常に深刻なリスクにつながります。

1. NVRAMドライバーにエラーがある場合、そのデータだけでなく、コードが保存されているものを含む近隣のデータも破壊する可能性があり、マシンを再起動した後、ステークを取得し、この状態から復元することは非常に困難になります。
2. NVRAMの各エントリ（および通常、電源を入れてリブートするたびに数回行われます）は、SPIチップのリソースを削減し、特定の条件（たとえば、工業用PCで珍しいことのない絶え間ない高温）で3〜5年後にリソースを削減しますこれは完全に開発されており、システムは非常に奇妙な動作を開始します。 同時に、第25シリーズのSPIチップのメーカーは、SMART、EXT_CSD、または自動摩耗レベリングの類似物を提供していません。また、チップが動作不能になり「変更」されて変更されなければならなかったシステムを何度か見ました。
3. ジャンパーを使用したり、バッテリーを取り外したりして、損傷した、または誤ったNVRAMをリセットすることはできません;ストレージに関連して外部SPIデバイスを使用して消去する必要があります。 一部のメーカーは、特別なDXEドライバーを使用するユーザーになじみのあるCLEAR_CMOSジャンパーの動作を模倣し、CMR SRAMフラグ（まだ存在していますが、クロックといくつかのフラグのみを保存するため、今でははるかに小さくなっています）NVRAM_IS_VALIDを保存します。 次回の起動時にこのフラグがクリアされると、 セットアップなどの変数のデフォルト値の復元が実行されます。 残念ながら、非常に多くの場合、これは役に立ちません。なぜなら、 このドライバーをロードする前に、全体のPEIフェーズがあり、NVRAMへの要求を含むモジュールもあり、要求が満たされなかった場合、ダウンロードが早く停止するため、何も復元されません。

NVRAMの要件

NVRAMの「物理」レベルを実装する場合、ファームウェアメーカーは多くの質問を解決する必要がありました。読み取り用の変数にすばやくアクセスする方法（ブート中に非常にアクティブに読み取ります）、記録中のフラッシュメモリの負荷を減らす方法、変数をそのように保存する方法複数の変数（ベンダーGUIDなど）に共通するデータの複製、障害後に少なくとも一部のデータを回復する方法など。 同時に、EFI 1.10標準のリリース中にIntelによって提案されたIntel NVRAMデータストレージ形式はシンプルであることが判明しましたが、上記の要件をすべて満たすわけではなく、その形式はUEFI PI仕様に記載されていませんでした。 NVRAM実装の選択は、最終的なベンダーに委ねられました。



その結果、 後でZeroVectorで拡張ヘッダーといくつかの議論のあるフィールドを受け取った1つのFFSv2形式の代わりに、標準のままでしたが、ベンダーはNVRAMに対して3つの根本的に異なる形式を実装することができたため、解析が非常に興味深いものになりました。

フォーマットは何ですか

フォーマットについて話す前に、その名前について少し話しましょう。 各ベンダーは、国を「国」または「土地」と呼び、その人々を「人々」と呼ぶ長い伝統に従い、その形式を「NVRAMストレージ形式」と呼びます。 しかし、私たちは幸運でした： NVRAMは通常、比較的任意の構造を持つ特殊なボリューム内に格納され、 ストレージヘッダーに署名があり、各形式のこれらの署名は異なることが判明しました。 この用語はまだ確立されていませんが、ここでは署名でそれらを呼び出します。



歴史的に最初の普及率は、EFIの開発の夜明けにIntelによって提案されたVSS形式でした。これは、UEFI 2.3.1C規格でSecureBootの実装に使用される保護変数をサポートするように拡張され、ファームウェアでのみ使用されるいくつかの拡張機能もAppleから受け取りました。 FTWブロックは、VSS形​​式のデータの隣に保存できます。データは、記録が異常に終了していない場合にNVRAMを復元するのに役立ちます（「コンピューターの電源をいつでもオフにできる」 ことに注意してください）。 SecureBootを実装した後、変数のデフォルト値を保存する必要がありました。一部のベンダーは、これらの「デフォルト」が保存されているのと同じフォーマットにFDCブロックを追加しました。



ほとんどすぐに、NVRAMをVSS形式のみで保存する必要がないことが判明したため、ベンダーの1つ（最初は誰であったか正確にはわかりませんが、フェニックスだと思います）をEVSA形式に置き換えました。EVSA形式では、GUIDと変数名ですが、FTW機能はなくなりました。 この形式はあまり配布されていませんが、UEFI 2.1の時点から古いファームウェアで見つかることがあります。 EVSAは、ストレージとしてVSSと同じプライマリおよびセカンダリNVRAMボリュームを使用するため、これらのボリュームの構造の分析は、既に述べたように非常に興味深い演習です。



Appleはさらに進んで、同じ2つのデータブロックを同じ苦しむボリュームに追加しました。SVSは、通常のVSSと署名を一致させる形式であり、 Fsysは、Appleがゼロから発明した形式です。



リストの最後の形式はNVARであり 、 AMIによって開発され、Aptio4の最初の実装から使用され、その後2つの更新が行われました。1つは変数に格納されたデータのチェックサムを追加し、2つ目はSecureBoot保護変数のサポートを追加しました。 形式自体は非常に興味深いもので、GUID重複排除を使用し、変数名の文字サイズを最適化します（仕様によれば、UCS2でエンコードされます）。すべてがシングルバイトエンコードに配置されている場合、クラッシュに対して比較的耐性がありますが、定期的なガベージコレクションが必要です。 残念ながら、更新は彼に最良の方法で影響を与えなかったため、その後の分析ははるかに複雑になり、エラーが発生する可能性が増加したため、AMIがVSSを使用しないという決定から利益を得たかどうかは不明です。



リストは非常に印象的であることが判明しましたが、通常は仕様がベンダーに選択の自由を与えすぎており、彼らはこの自由を皮肉に使用しています。

VSS形式とそのバリエーション

私が見たすべてのUEFI互換ファームウェアのNVRAMデータは、AMIコード（NVAR形式の部分で説明します）を除き、GUID FFF12B8D-7696-4C8B-A985-2747075B4F50（別名EFI_SYSTEM_NV_DATA ）を使用して1つ以上のボリュームに保存されます、「プライマリ」と呼びます）、またはGUID 00504624-8A59-4EEB-BD0F-6B36E96128E0（「オプション」と呼びます）と呼びます。

両方のボリュームはまばらな構造を持っているため、ストレージとブロックの署名を検索する際に、それらをバイトごとに見る必要があります。 VSSリポジトリヘッダーは次のとおりです。

struct VSS_VARIABLE_STORE_HEADER { UINT32 Signature; //  UINT32 Size; //       UINT8 Format; // ,   ,       (0x5A) UINT8 State; // ,   ,        (0xFE) UINT16 Unknown; //  ,     Apple SVS UINT32 : 32; //   };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

誰もがその場でC言語構造を解析する方法をまだ知っているわけではないので、スクリーンショットで同じ構造を表示することは理にかなっています。



対応する署名があり、合計サイズが 0xFFB8バイトのVSSリポジトリヘッダーがあり、正しくフォーマットされており、正しいデータであることがわかります。

Appleは、同じヘッダーを使用する場合がありますが、署名が異なります- $ SVS 。 なぜこれが行われるのでしょうか？

ストレージヘッダーの直後に、ヘッダーに格納されている変数が開始されます。 それらは次々に配置され、IA64（別名Itanium）を除くすべてのアーキテクチャ上にあります。IA64（別名Itanium）では、8バイト境界に沿って変数の先頭を揃える要件が言及されていますが、このステートメントを検証するためのこのアーキテクチャのファームウェアイメージはありません。



VSSの10年の歴史を通じて、3種類の変数形式が蓄積されました.UEFI 2.3.1Cより前に使用されていた古いもの、CRC32用の追加フィールドを持つAppleからの拡張、およびSecureBootをサポートするために実装が必要な新しいものです。 おそらく他にもいくつかありますが、これまでに私は彼らと一緒に画像を見つけることができませんでした、おそらく読者は成功するでしょう。

標準

この形式は、SecureBootの導入が必要になるまで、約7年間、AMIを除くUEFI互換ファームウェアのほぼすべてのメーカーで広く使用されていました。 「標準」変数の見出しは次のようになります。

 struct VSS_VARIABLE_HEADER { UINT16 StartId; //    (0xAA 0x55) UINT8 State; //   UINT8 : 8; //   UINT32 Attributes; //   UINT32 NameSize; //   ,    0-   UCS2 UINT32 DataSize; //  ,    EFI_GUID VendorGuid; // GUID  };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

今回は、スクリーンショットにいくつかの変数を一度に表示できます。



より正確には、1.5： PchInitおよびSetupの一部。 状態は 0x7F（VARIABLE_HEADER_VALID）、 属性は 0x07（ NV + BS + RT ）、 名前の長さは 0x10と0x0C、 データの長さは 0x04と0x2B0、 GUID E6C2F70A-B604-4877-85BA-DEEC89E117EBと4DFBBADE-1392-4BBBAB-1392-4BB-1ABABABABABABABABABABABABABABABABABABABABABABABABABABAB392ABそれぞれC41CC5AD7D5D。



手動で何かを分解したくない場合は、最新のアルファ版のUEFITool NEを使用できます。上記のスクリーンショットのNVRAMボリュームは次のようになります。

Apple CRC

約2年前、Appleは変数にチェックサムがないと判断したため、上記のヘッダーに変数データブロックのCRC32チェックサムを格納する別のフィールドを追加しました。 Appleは今日までこの形式を使用しており、今後も引き続き使用する可能性があります。 タイトルは次のようになります。

 struct VSS_APPLE_VARIABLE_HEADER { UINT16 StartId; //    (0xAA 0x55) UINT8 State; //   UINT8 : 8; //   UINT32 Attributes; //   UINT32 NameSize; //   ,    0-   UCS2 UINT32 DataSize; //  ,    EFI_GUID VendorGuid; // GUID  UINT32 DataCrc32; // CRC32-   };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

私はスクリーンショットを適用せず、すべてが完全に類似しています。Appleは追加属性0x80000000（CRC_USED）を使用してそのタイトルを標準のものと区別しているとしか言えません。

認証済み

UEFIフォーラムがNVRAMを使用してSecureBootテクノロジーで使用されるキーを保存することを決定した後、フォーマットを改良する必要がありました。 新しい変数には、次のようなヘッダーがあります。

 struct VSS_AUTH_VARIABLE_HEADER { UINT16 StartId; //    (0xAA 0x55) UINT8 State; //   UINT8 : 8; //   UINT32 Attributes; //   UINT64 MonotonicCounter; // ,   replay- EFI_TIME Timestamp; //  ,     replay- UINT32 PubKeyIndex; //     ,  0,      UINT32 NameSize; //   ,    0-   UCS2 UINT32 DataSize; //  ,    EFI_GUID VendorGuid; // GUID  };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

スクリーンショットでは、このような変数は次のようになります。



マーカーは通常の変数と同じです。この場合の状態は0x3F（VARIABLE_ADDED）、 属性は0x27（BS + NV + RT + TA ）、 カウンターは使用されませんが、 タイムスタンプは EFI_TIME形式で、公開キーデータベースのインデックスも関連する、 名前のサイズは0x08、 データのサイズは0x64D、 GUIDはD719B2CB-3D3A-4596-A3BC-DAD00E67656F、この変数名は dbxです。



UEFIToolでは、この同じ変数は次のようになります。

おわりに

さて、VSS形​​式については多かれ少なかれ理解しました。次回は、Fsys、EVSA、NVAR形式、およびメインNVRAMの横にあるさまざまなデータブロックについて説明します。

最初の部分が気に入ってくれたことを願っています。注意してくれてありがとう、そして第2部でお会いしましょう。