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

これは、さまざまなメーカーのUEFI互換ファームウェアで使用されるNVRAMフォーマットに関する私のストーリーの3番目の部分です。 最初の部分では、NVRAM全般と「標準」VSS形式について、2番目では 、この形式のNVRAMの横にある興味深いブロックについて説明しましたが、この記事では、Phoenixプラットフォームのファームウェアで使用されるさまざまな形式について説明しますSCT ：FlashMap、EVSA、Intel uCode、CMDB、SLIC pubkeyおよびSLICマーカー。

フェニックスの開発者がVSSを置き換えるために何を思いついたかに興味があるなら、カットへようこそ、私はあなたにすぐに警告します、記事は非常に長いことが判明しました。

免責事項3

最初の2つの「失敗」の後、ここに何を書くべきかさえもわかりません。ただし、作者は、NVRAM、ファームウェア、システム、その他すべての機能の損失に対する一切の責任から再び解放されます。 自分の責任で情報を使用し、自分で行動し、すべてがうまくいくでしょう。

偶然この記事を偶然見つけて、ここで何が起こっているのかが明確でない場合、著者が何も説明せずに頭でいくつかの形式に飛び込む理由と、彼がどのように勇気を持っているのか- 最初と2番目の部分があなたを待っています。 残りは私のものです！

フェニックスフラッシュマップ

Ivy Bridge上の古いDell Vostro 3360のファームウェアからメインNVRAMボリュームの内容を最初に開いたとき、私は非常に驚きました。 そこに見つからないもの-最初に、Intelマイクロコードのセット全体、文字列を含むブロック、その半分はNoLongerUsed文字列のコピー、RSA署名を含む漠然と馴染みのあるブロック、約5つのEVSAストレージ、カーテンの下署名_FLASH_MAP。 要するに、Phoenixのメンバーは、NVRAMに非常に多くのものをダンプすることができたため、カードなしでは理解できませんでした。 彼女から始めましょう。

カードのヘッダーは16バイトで、次のようになります。

struct PHOENIX_FLASH_MAP_HEADER { UINT8 Signature[10]; //  _FLASH_MAP UINT16 NumEntries; //   UINT32 : 32; //   };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

見出しの直後に、追加のアライメントなしで、次のようなレコードが隣り合っています。

 struct PHOENIX_FLASH_MAP_ENTRY { EFI_GUID Guid; // GUID ,    ,      UINT16 DataType; //  ,    -  (0)     (1) UINT16 EntryType; //  ,   ,       UINT64 PhysicalAddress; //   ,     UINT32 Size; //  ,     UINT32 Offset; //  ,    ,  ,      };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

カードの最大サイズは、その位置によって決まります。 メインNVRAMボリュームの最後から0x1000バイトに配置されています。最大でちょうど113エントリであり、十分な余裕があります。



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



署名とレコード数を含むヘッダーがすぐに表示され、直後にGUIDがゼロ、 データタイプ 0（つまりボリューム）、 レコードタイプ 6、 物理アドレス 0xFF980000、 データサイズ 0x20000、 オフセット 0のレコードが続きます（まだオフセットがあります） 、それ自体に関して、最初のボリュームはどこにもシフトされません。そうでない場合、ファイルまたはスペースメトリックのいずれかで何かが非常に間違っています。



さまざまな画像で見つけることができたすべてのGUID値を引用してデータ型と関連付けることができましたが、これはUEFITool NEの 1つのスクリーンショットで実行できます。



GUIDに加えて、いくつかのネタバレも表示されます。RSAの漠然と馴染みのあるブロックは、 SLICテーブルの公開キーおよびマーカーであることが判明し、何らかの理由で行のあるブロックはCMDBと呼ばれました。 これらすべてに戻りますが、カードについてはすべて明確です。リストされたこれらすべてのブロックのフォーマットを解析する方法を学ぶことは残っており、Phoenix SCTに基づいたファームウェアのNVRAM構造を多少理解していると仮定できます。 行こう！

Intelマイクロコード

リストの最初は、マイクロコード付きのブロックです。 残念ながら、NVRAMにAMDマイクロコードを含むイメージがないため、Intelのみを検討します。 マイクロコードヘッダーには最大12バイトの空きバイトが含まれているという事実にも関わらず、怪しげな署名すらありません。そのため、NVRAMボリュームのコンテンツからそのようなデータブロックを見つけることは依然として課題です。 プロセッサを開発します-マイクロコードの署名について考えてください！ いずれにせよ、Intelマイクロコードの主要な見出しは文書化されており、私の記憶では、まったく変わっていません。 ここにあります：

 struct INTEL_MICROCODE_HEADER { UINT32 Version; //   (1) UINT32 Revision; //   UINT32 Date; //   UINT32 CpuSignature; //   UINT32 Checksum; //  ,           0 UINT32 LoaderRevision; //   ,     UINT32 CpuFlags; //   UINT32 DataSize; //     UINT32 TotalSize; //      UINT8 Reserved[12]; //    };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

理論的には、まだ拡張ヘッダーがありますが、さらに分析するための最も重要なことは、すでに受け取った合計サイズです。 ボリュームの最初のマイクロコードのヘッダーを見てみましょう。



バージョン 1は有効、 リビジョンは0x28、 リリース日は04.24.2012、 プロセッサータイプは0x206A7、 チェックサムは0xF3E9935D、 ローダーリビジョンは1、 プロセッサーフラグは0x12、 データサイズは0x23D0、 合計サイズは0x2400です。



UEFITool NEの同じマイクロコードでは、マイクロコードを持つブロックが5つあったことがわかります。

CMDB

マップが参照する次のブロックはCMDBです。 その目的は私にはあまり明確ではなく、おそらく複数のボードに適したファームウェアの適切な構成を一度に選択したり、SMBIOSテーブルを作成したりするために使用されましたが、現在は使用されていません。 このブロックには、その開発者が考えた「麻薬中毒者」としか呼べない形式があります-これは大きな謎です。 自分で見てください：

 struct PHOENIX_CMDB_HEADER { UINT32 Signature; //  CMDB UINT32 HeaderSize; //   UINT32 TotalSize; //      };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

タイトルはまったく奇妙に見えませんが、全体のサイズはありません。まあ、解析中にブロックの終わりを見つけることができます。楽しみは、すぐにスクリーンショットに表示しやすいチャンクで始まります。



CMDB 署名 、 サイズ 0x0C、 合計サイズ 0x23のヘッダーの後に、3バイトのゼロチャンクがあります： 開始バイト 0x42（それをTheAnswerと呼びたいという苦労にまだ苦しんでいます ）、ヘッダーの後の最初の行のオフセット （常に0です）および行のブロックの開始のオフセット （これは常にTotalSize-HeaderSizeです）。 合計-3つのフィールドのうち3つはまったく使用されていません。このチャンクが必要な理由は明らかに理解できません。 その他はゼロチャンクに従います。これらはすでに5バイトで構成されています。使い慣れた開始 0x42、 キー文字列オフセット 、理解できない2バイトフィールド 、常に0x205および値文字列オフセットです。 両方の行の長さはどこにも保存されておらず、明らかに計算されていません。 行のあるブロックでは、 BiosInfo ヘッダー行が個別に格納され、ゼロチャンクが参照し、他のチャンクが参照する残りのすべての行を参照します。 合計ブロックサイズは常に0x100であるため、どこにも保存されません。 私はそれを発明した人が喫煙したものを尋ねたいですか？

なぜなら この構造は長い間使用されておらず、同時に目ですぐに分解されるため、UEFITool NEでの分析のサポートを追加し始めませんでした。 急に必要になった場合は、コメント欄またはここに書いてください。

SLICパブキーとマーカー

CMDBの直後に、Windows Vista / 7/2008のOEMアクティベーションに必要なPubkeyおよびMarkerブロックが続き、これらは特別なドライバーによってSLIC ACPIテーブルに転送されます。 この記事のDMCAテイクダウンを防ぐためにこれらのブロックの形式については説明しませんが、長い間逆アセンブルされており、すべてのフィールドの説明はRW Everythingユーティリティによって表示され、UEFITool NEはそれらをサポートしていますので、これらのブロックの形式が必要な場合は、見てくださいnvram.hで 。

EVSA

マップの最後のフォーマット。 （ 最後に！ ）NVRAM変数を保存するために使用されます。 VSSと比較して、この形式は変数名とそのGUIDの重複排除によりNVRAMのスペースをもう少し効率的に使用しますが、EVSAストレージを台無しにする方がはるかに簡単であり、NVRAMからデータを回復する私のケースのほとんどは、大規模な使用にもかかわらずこのチェックサム形式。 データ（リポジトリ自体のヘッダーを含む）は、次のように共通ヘッダーと異なる追加フィールドを持つレコードの形式で保存されます。

 struct EVSA_ENTRY_HEADER { UINT8 Type; //   UINT8 Checksum; //   UINT16 Size; //  ,      }; struct EVSA_STORE_ENTRY { EVSA_ENTRY_HEADER Header; //   UINT32 Signature; //  EVSA UINT32 Attributes; //   UINT32 StoreSize; //      UINT32 : 32; //   }; struct EVSA_GUID_ENTRY { EVSA_ENTRY_HEADER Header; //   UINT16 GuidId; //  GUID // EFI_GUID Guid //  GUID    ,     };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

スクリーンショット：



ここには、 タイプ 0xEC（「ストレージヘッダー」）のストレージヘッダー、シングルバイトチェックサム 0x2C、正しいEVSA 署名付きのサイズ 0x14、 属性 0x01（「デフォルト値はここにあります」）およびストレージサイズ 0x2B65があります。 ヘッダーの直後に、位置合わせなしで、 サイズ 0x16、 識別子 0および1、 GUID 4FEE3D67-18F4-4217-BA7B-BC538148382Aおよび1E1F1797-2CCEのチェックサムがそれぞれ0x35および0xB3のタイプ 0xED（「GUID」）の2つのエントリがあります。 -49D6-A6CE-4012F338A76E

UEFITool NEでは、同じリポジトリは次のようになります。





上記のタイプ0xEC（「ストレージ」）および0xEC（0xE1、「GUID」）に加えて、さらに3つあります-0xEE（0xE2、「変数名」）、0xEF（0xE3、「データ」）、および0x83 （「削除されたデータ」）。 私が理解しているように、「GUID」や「変数名」などのエントリを削除できるのは、ドライバがガベージコレクションを実行してリポジトリを完全に再構築する場合のみです。

タイプが「変数名」のエントリは次のようになります。

 struct EVSA_NAME_ENTRY { EVSA_ENTRY_HEADER Header; //   UINT16 VarId; //    //CHAR16 Name[]; //     UCS2 };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

写真：



チェックサムが 0x39、 長さが 0x20、 識別子が 0のタイプ 0xEEのレコード。UCS2のDellVariable 文字列が含まれます。 UEFITool NEに表示する意味はありません。そのため、すべてが明確です。



レコードの最後のタイプであるデータを考慮する必要があります。 実際、次のような2つの形式があります。

 struct EVSA_DATA_ENTRY { EVSA_ENTRY_HEADER Header; //   UINT16 GuidId; //  GUID UINT16 VarId; //   UINT32 Attributes; //  // UINT8 Data[]; //  } EVSA_DATA_ENTRY; struct EVSA_DATA_ENTRY_EXTENDED { EVSA_ENTRY_HEADER Header; //   UINT16 GuidId; //  GUID UINT16 VarId; //   UINT32 Attributes; // ,   0x10000000      UINT32 DataSize; //   ,  ,    // UINT8 Data[]; //  };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

スクリーンショットでは最初のもののみを表示します。2番目のものは非常にまれであり、追加のフィールドが1つだけあるためです。



ここには、 タイプ 0xEFの2つのレコードがあり、最初のレコードには 0x84、 サイズ 0x5F、 GUID 0、 名前識別子 0および属性 0x03（ NV + BS ）のチェックサムがあり、2番目にはそれぞれ0xEA、0x11、1、1、および0x03があります。 最初の例では、GUID 4FEE3D67-18F4-4217-BA7B-BC538148382Aの上記のDellVariable変数のデータが正確に保存されていることがわかりました。



UEFITool NEの場合：

おわりに

さて、Phoenix SCTコードベースファームウェアがNVRAMボリュームに保存できるデータ形式が少し明確になりました。 AMI Aptioで使用されているNVAR形式については、この記事の次の最後の部分で説明します。

ご清聴ありがとうございました。通知された伝票をL / Cに送信し、少なくとも何らかの形で手動でNVRAMを復元しないようにランダムに保存してください。