ボリューム・ブート・レコード（VBR）：構造、位置、および起動プロセス
A ボリューム・ブート・レコード（VBR） ファイルシステムのボリュームの先頭に格納される、ブートに関連するデータ構造です。これには、ボリュームのレイアウトを記述する情報が含まれており、レガシー起動時に使用されるブートストラップコードが含まれる場合もあります。VBRは一般的にパーティションの最初のセクタに関連付けられていますが、その正確な構造や役割は、ファイルシステムやブートアーキテクチャによって異なります。.
この区別が重要なのは、VBRはMBRとは異なるものであり、最新のUEFIベースのWindowsシステムでは、通常、起動時に従来のVBRブートストラップコードを実行しないためです。.
目次
ボリューム・ブート・レコードとは何ですか？
A ボリューム・ブート・レコード これは、ボリュームの起動に関連する初期構造です。一般に「ボリューム・ブートセクタ」とも呼ばれ、多くのPCストレージの文脈では「パーティション・ブートレコード（PBR）」とも呼ばれます。.
VBRには、2つの関連する目的があります：
- 巻の特定および説明： このファイルには、セクタサイズ、クラスタサイズ、ボリューム長、ファイルシステム固有のメタデータの保存場所など、ソフトウェアがファイルシステムを解釈するのに役立つパラメータが格納されています。.
- Bootstrap のサポート： ファイルシステムや起動環境によっては、オペレーティングシステムの起動プロセスの次の段階へ制御を移す実行可能コードが含まれている場合があります。.
具体的な内容は一様ではありません。FAT32のブートセクタ、NTFSのブートセクタ、およびexFATのメインブートセクタは、それぞれ独自の方法でボリュームを記述しています。.
たとえば、FAT32のブートセクタにはBIOSパラメータブロック（BPB）が含まれていますが、exFATのブートセクタでは次のようなフィールドが使用されます。 巻数・長さ, FatOffset, そして ClusterHeapOffset. これらの構造は関連する目的を果たしますが、互いに置き換え可能というわけではありません。.
VBR、ボリューム・ブート・セクタ、およびパーティション・ブート・レコード
用語 ボリューム・ブート・レコード, ボリューム・ブートセクタ, そして パーティション・ブート・レコード 技術的な資料によって用語の定義は異なるものの、これらはしばしば同じ意味で使用される。.
ここで役立つ区別は次の通りです：
- ボリューム・ブートセクタ： 通常、ファイルシステムのボリュームの最初のセクタを指します。.
- ボリューム・ブート・レコード： 多くの場合、そのボリュームの先頭に格納されているブート関連の構造体を指します。ファイルシステムによっては、単一のセクタ構造体ではなく、より大きなブート領域を定義しているものもあります。.
- パーティション・ブート・レコード： 通常、パーティションの先頭にあるブートセクタを指します。.
パーティションが、同じアドレスから始まるボリュームを直接含む従来のベーシックディスクでは、PBRとVBRは通常、同じセクタを指します。.
ただし、これらの用語は異なるストレージの概念を表しています。パーティションはディスク上の領域を定義するのに対し、ボリュームはファイルシステム用に構成されたストレージ領域を表します。すべてのストレージ構成において、これらに一対一の関係があるとは限らないことに留意する必要があります。.
ボリューム・ブート・レコードはどこにあるのか？
について VBR そのファイルシステムボリュームの先頭に位置しています。.
従来のパーティション分割されたディスクでは、ボリュームはパーティションの開始論理ブロックアドレス（LBA）から始まります。したがって、VBRは通常、そのパーティションの最初の論理セクタに位置しています。.
例として、次のようなディスクレイアウトを考えてみましょう：
ディスク領域 | LBAの開始位置 | 目的 |
MBR または 保護型 MBR | 0 | ディスクレベルの互換性とパーティション情報 |
メインのGPTヘッダー | 1 (GPTディスク) | GPTのレイアウトについて説明します |
パーティション 1 | 2,048 | 最初のパーティションの作成を開始します |
パーティション 1 の VBR | 2,048 | 第1巻のブートセクタ |
パーティション 2 | 別のパーティションの開始 | 第2の分割が始まる |
パーティション 2 VBR | パーティション 2 の開始 | 第2巻のブートセクタ |
この例では、各パーティションが直接ボリュームを含み、論理セクタサイズが 512 バイトであると仮定しています。実際の開始 LBA は、ディスクのレイアウトによって異なります。.
LBA 2,048 から始まるパーティションの場合、VBR は物理ディスクを基準として LBA 2,048 にあり、LBA 0 にはありません。.
パーティションが割り当てられていないデバイスにも、ファイルシステムのボリュームが含まれている場合があります。その場合、ボリュームはデバイスの最初の論理セクタから始まる可能性があるため、必ずしも個別のMBRやGPTパーティションテーブルが存在するとは限りません。.
VBRが必ずしもディスクのLBA 0にあるとは限らない理由
ディスクの最初の論理セクタと、ボリュームの最初の論理セクタは、異なるアドレス位置にあります。.
- ディスクのLBA 0は、ディスクの先頭を指します。.
- ボリューム相対セクタ 0 は、ボリュームの先頭を識別します。.
- 従来のパーティション分割されたディスクでは、パーティションの開始LBAがこれら2つのアドレス空間を結びつけます。.
これらの場所を混同すると、ディスクエディタや診断ツールが誤ったセクタを検査してしまう原因となります。.
ディスクレベルの構造についてより詳しく知りたい場合は、 MBRパーティションテーブル.
VBRとMBR：その違いとは？
ととのいの主な違いは、 VBRとMBR それは、それぞれの保管レベルと責任の範囲です。.
MBRはディスクレベルのパーティション構造に属します。VBRはファイルシステムのボリュームに属します。.
特徴 | マスタブートレコード | VBR |
ストレージレベル | ディスクレベル | 音量レベル |
代表的な設置場所 | ディスク LBA 0 | この巻の第1セクター |
主な内容 | ブートストラップコード、パーティションエントリ、ディスクシグネチャ | ファイルシステムパラメータ、およびフォーマットによってはブートストラップコード |
主な目的 | レガシーディスクのパーティション構成を説明し、ブートエントリポイントを提示してください | 適用可能なブートプロセスのボリュームとサポートについて説明してください |
ファイルシステムの依存関係 | 個々のファイルシステムのレイアウト全体を定義するものではない | その構造はファイルシステムによって異なります |
バックアップ体制 | 標準のバックアップMBRがない | ファイルシステムによって異なります |
従来のMBRパーティション方式のディスクでは、MBRには4つのパーティションエントリが含まれており、それぞれがパーティションの位置とサイズを記述しています。そのブートストラップコードは、選択されたブートパーティションを特定し、そのパーティションのブートセクタに制御を移すことができます。.
その後、VBRはボリューム固有の情報を提供し、従来のBIOSブートチェーンでは、次のブートストラップ段階を実行する場合があります。.
について Amagicsoft MBR パーティションテーブルガイド ディスクレベルのパーティションエントリについて、より詳しく説明しています。.
VBRはGPTとどのように関連しているのでしょうか？
GPTとVBRは、ストレージアーキテクチャの異なる部分を表しています。.
GPTは、ディスクのパーティション構成を定義します。これには、プライマリGPTヘッダー、パーティションエントリ配列、および対応するバックアップ構造が含まれます。また、GPTディスクには通常、LBA 0の位置に保護用MBRが含まれています。.
対照的に、VBRはパーティション内のファイルシステムボリュームに属しています。.
GPTディスクのレイアウトを簡略化すると、次のようになります：
- LBA 0 にある保護用 MBR。.
- LBA 1 にあるプライマリ GPT ヘッダー。.
- プライマリ GPT パーティションエントリ配列。.
- パーティションが含まれる使用可能なディスク領域。.
- ディスクの末尾付近にあるGPT構造をバックアップします。.
ファイルシステムのボリュームは、そのパーティションの先頭、つまりブートセクタまたはブート領域がある場所から始まります。.
したがって、GPTディスクには、それぞれ独自のボリュームブート構造を持つNTFS、FAT32、およびexFATのボリュームを含めることができます。.
GPTはVBRに代わるものではありません。GPTはパーティションの開始位置と終了位置を定義するものであり、一方、ファイルシステムはボリューム内のデータがどのように構成されるかを定義するものです。.
「」を参照してください Amagicsoft GPT ガイド GPTヘッダーおよびパーティションエントリに関するより詳しい説明については。.
VBRがWindowsの起動プロセスにどのように組み込まれているか
インタラクティブなブートパスエクスプローラー
ファームウェアモードを選択して、Windows がどのようにブートマネージャに到達するか、またその経路に従来の VBR ブートストラップコードが含まれているかどうかを確認してください。.
-
1ファームウェア BIOS プラットフォームを初期化し、起動デバイスを選択します。.
-
2ディスクレベルのブートレコード · LBA 0 MBRブートストラップコード 従来のパーティション情報を使用して、選択されたブートパーティションを特定します。.
-
3ボリュームレベルのブートレコード · パーティションの開始位置 VBR / PBR ブートストラップコード 従来のBIOS/MBRチェーンで制御を受け取り、次の起動段階を開始します。. 従来のVBRコードの実行
-
4Windows ブートマネージャー
bootmgrブート設定を読み込み、Windowsローダーを選択します。. -
5オペレーティングシステムのローダー
winload.exeWindowsカーネルと、起動時に必要なドライバを読み込みます。.
-
1ファームウェア UEFI ブートマネージャー ファームウェアの起動オプションを使用して、デバイスとEFIアプリケーションを識別します。.
-
2ディスクのパーティション構成 GPTとEFIシステムパーティション ファームウェアはシステムパーティションを識別します。Windows UEFI システムディスクは GPT を使用しており、その ESP は FAT32 です。.
-
3ESP上のEFIアプリケーション
\EFI\Microsoft\Boot\bootmgfw.efiUEFIは、ファイルシステムサービスを通じてこのファイルを読み込みます。MBRやVBRにある従来のx86ブートストラップコードは実行しません。. EFIファイルが読み込まれました -
4Windows OS ローダー
winload.efiWindowsカーネルと、起動時に必要なドライバを読み込みます。.
従来のレガシーBIOS/MBRによるWindowsの起動では、パーティションのブートレコードは起動チェーンにおける実行段階の一つです。その位置はディスクのLBA 0ではなく、ボリュームレベルにあります。.
ESPはフォーマット済みのボリュームであるため、依然としてFAT32ファイルシステムのブートセクタを持っています。しかし、通常のUEFI Windowsのパスでは、EFIアプリケーションがファイルとして読み込まれるだけで、レガシーなVBRブートストラップコードは実行されません。.
一般的な Windows の起動パスの教育用モデルです。実際の起動構成には、リカバリエントリ、追加のブートマネージャー、またはベンダー固有の段階が含まれる場合があります。このモジュールは物理ディスクを検査しません。.
VBRの役割は、WindowsがレガシーBIOS経由で起動するか、ネイティブUEFI経由で起動するかによって異なります。.
これらの環境では、Windows ブートマネージャーを特定して読み込むために、それぞれ異なる仕組みが使用されています。.
従来のBIOSおよびMBRの起動シーケンス
MBRパーティション方式のシステムディスクを使用する従来のLegacy BIOSシステムでは、起動プロセスは概ね以下の順序で進行します：
- BIOSはコンピュータを起動し、ブートデバイスを選択します。.
- BIOSは、ディスクのLBA 0からMBRを読み込みます。.
- MBRブートストラップコードは、選択されたブートパーティションの位置を特定します。.
- パーティションの最初のセクタ（一般にVBRまたはPBRと呼ばれる）が制御を受けます。.
- VBRブートストラップコードは次のブート段階を開始し、それがWindows ブートマネージャーへとつながります（
bootmgr). - Windows ブートマネージャーが読み込まれます
winload.exe. - Windowsのローダーは、カーネルと起動時に必要なドライバを初期化します。.
この構成では、VBRは従来のブートチェーンにおける実行段階となります。.
パーティションのブートセクタは、ディスク全体のレイアウトを定義する役割を担っているわけではありません。これは、ディスクレベルのブートコードがブートパーティションを特定した後に動作します。.
UEFIの起動シーケンスとEFIシステムパーティション
ネイティブのUEFI版Windowsのインストールでは、異なる起動プロセスが使用されます。.
UEFIファームウェアは、従来のMBRやVBRのブートストラップコードを実行する代わりに、独自のブートマネージャーを使用してEFIアプリケーションを検索し、読み込みます。.
Windowsの一般的なUEFIブートシーケンスは以下の通りです：
- UEFIファームウェアがプラットフォームを初期化します。.
- ファームウェアはブートオプションを読み取り、EFIシステムパーティション（ESP）を特定します。.
- ファームウェアはESPのファイルシステムにアクセスし、読み込みを行います
\EFI\Microsoft\Boot\bootmgfw.efi. - Windows ブートマネージャーが読み込まれます
winload.efi. - Windowsのローダーは、カーネルと起動時に必要なドライバを初期化します。.
について Microsoft Windows の起動に関するトラブルシューティングのドキュメント BIOSとUEFIの起動フェーズを区別し、WindowsブートマネージャーとOSローダーの異なるパスを特定します。.
また、UEFI仕様書では、そのブートマネージャが、従来のレガシーMBRブートストラップコードを実行するのではなく、ファイルからUEFIアプリケーションをロードすることも説明されています。詳しくは、 UEFI仕様：概要 そして GPT ディスク構成.
UEFIにはまだVBRがあるのでしょうか？
はい。UEFIシステムであっても、ボリュームブートセクタが含まれている場合があります。.
標準的な Windows UEFI/GPT インストールでは、EFI システムパーティションは FAT32 でフォーマットされます。したがって、このパーティションには FAT32 ファイルシステムのブートセクタと、それに関連するファイルシステム構造があります。.
しかし、通常のUEFIブートプロセスでは、そのVBRに格納されている従来のx86ブートストラップコードは実行されません。その代わりに、ファームウェアはFAT32ファイルシステムにアクセスし、EFIブートマネージャーをファイルとして読み込みます。.
この区別は重要です：
- ESPのVBRは、FAT32のボリューム構造の一部として存在します。.
- EFIアプリケーションは、ネイティブUEFI起動で使用される実行可能エントリポイントです。.
- VBRが存在しても、その従来のブートストラップコードが必ず実行されるわけではない。.
マイクロソフトの UEFI/GPT ベースのハードドライブのパーティション設定に関するガイド Windows EFI システムパーティションの FAT32 要件を規定しています。.
ボリューム・ブート・セクタの構造：VBRには何が含まれているのか？
唯一の普遍的なものなど存在しない ボリューム・ブートセクタの構造 すべてのファイルシステムに共通するものです。.
一般的なブートセクタには、いくつかの種類の情報が含まれている場合があります：
コンポーネント | 目的 |
ジャンプ命令 | 該当する場合、実行をブートストラップコードに移行する |
ファイルシステム識別子 | ファイルシステムのフォーマットを特定または説明する |
BIOSパラメータブロック（BPB）または同等のフィールド | セクタサイズ、クラスタサイズ、ボリュームサイズ、およびその他のパラメータについて説明します |
ファイルシステム固有のフィールド | 重要な構造物やその位置を特定する |
Bootstrapのコード | 互換性のあるブート環境の設定手順を説明します |
署名またはチェックサム情報 | 構造の特定の部分を特定または検証するのに役立ちます |
具体的なフィールド、バイトオフセット、長さ、および検証ルールは、ファイルシステムによって異なります。.
たとえば、FAT仕様ではBPBが定義されているのに対し、exFATでは独自のメインブートセクタフィールドが定義されています。これらのフォーマットを同一のものとして扱うと、ディスクの生データが誤って解釈される恐れがあります。.
BIOSパラメータブロック（BPB）
BIOSパラメータブロックは、ファイルシステムの基本的なパラメータを記述するフィールドの集合です。.
FATファイルシステムでは、BPBはボリュームの最初のセクタに配置されています。これには、次のような情報が含まれています：
- 1セクタあたりのバイト数。.
- クラスタごとのセクター数。.
- 予約済みセクタの数。.
- FAT構造体の数とサイズ。.
- セクターごとの総量。.
- 該当する場合、ルートディレクトリに関する情報。.
FAT32では、ルートディレクトリクラスタ、FSInfoセクタ、およびバックアップブートセクタ用の追加フィールドがBPBに追加されています。.
BPBはVBR全体ではありません。これはブートセクタの構造の一部に過ぎません。.
について Microsoft FAT 仕様書 FAT12、FAT16、およびFAT32のフィールド定義とバイトオフセットを記載しています。.
なぜ「55 AA Signature」ではVBRの有効性が証明されないのか
多くの従来のブートセクタ形式では、2バイトの 55 AA オフセット 510～511 の位置に、ブート署名として格納されています。.
このマーカーはセクターを検査する際に役立ちますが、構造全体が有効であることを確認するには不十分です。.
あるセクターには、期待されるシグネチャが含まれているにもかかわらず、次のような状態にある場合があります：
- セクタまたはクラスタのパラメータが正しくありません。.
- ボリュームの長さの情報が不正です。.
- ファイルシステム固有のフィールドが、許容範囲外となっています。.
- 他のファイルシステム構造への参照に一貫性がない。.
- ブートストラップコードが破損しているか、不完全です。.
有効な署名は、その特定のマーカーが存在することを確認するにすぎません。それだけでは、そのボリュームがマウント可能であること、すべてのメタデータが完全であること、あるいは起動プロセスが完了できることを証明するものではありません。.
一部のファイルシステムでは、追加の検証メカニズムも定義されています。たとえば、exFATでは、メインブート領域とバックアップブート領域に対してブートチェックサムを使用しています。.
NTFS、FAT32、exFATにおけるVBR構造の違い
NTFS、FAT32、exFATはいずれもボリュームの先頭にブート関連の構造体を持っていますが、そのレイアウトやバックアップの仕組みは大きく異なります。.
NTFSブートセクタ
NTFSボリュームは、ファイルシステムパラメータやブートストラップ関連のフィールドを含むNTFSブートセクタから始まります。.
Linux-NTFSのディスク上の構造定義に記載されている、一般的な512バイトのNTFSブートセクタのレイアウトには、以下のものが含まれます：
バイトオフセット | フィールド | サイズ | 目的 |
| ジャンプ命令 | 3バイト | Bootstrap の開始手順 |
| OEM ID | 8バイト | 以下を使用してNTFSを識別します |
| BPB | 25バイト | 基本的な体積パラメータ |
| セクタ数 | 8バイト | ボリュームごとのセクター数 |
|
| 8バイト | マスターファイルテーブルの論理クラスタ番号の開始値 |
|
| 8バイト | MFTミラーの論理クラスタ番号の開始値 |
| MFTレコードあたりのクラスタ数 | 1バイト | MFTレコードサイズのエンコーディングを定義します |
| インデックスレコードあたりのクラスタ数 | 1バイト | インデックス・レコード・サイズのエンコーディングを定義します |
| 巻番号 | 8バイト | ボリュームを特定します |
| チェックサムフィールド | 4バイト | ブートセクタのチェックサムフィールド |
| Bootstrap エリア | 426バイト | ブート関連のコードと予約領域 |
| セクタ終了マーカー | 2バイト |
|
ブートセクタとパーティション末尾の予備領域
参考画像 · NTFS1 GiB のサンプル · 512 B/セクタ · 4 KiB/クラスタ · パーティションはディスクの LBA 2,048 から始まる
デコードされたフィールド
レイアウト、サンプルノート、およびソース
NTFS。. ここでの従来の NTFS の「総セクタ数」フィールドは、最後の予備セクタを除いて 2,097,151 であり、このパーティションにはさらに 1 セクタが追加されています。 したがって、スペアセクタはフィールド値から1を引いた位置ではなく、ボリュームセクタ2,097,151に位置します。$Bootは16セクタからなる初期領域として示されており、パーティションの末尾ではその最初のセクタのみが複製されます。$MFTMirrは独立したメタデータミラーです。 符号付きレコードサイズバイト F6 は、−10 → 2¹⁰ = 1,024 バイトを意味します。未使用のバイトおよび未使用のレガシーチェックサムは 0 であり、ブートストラップフィラーは F4 です。.
ディスクのキャプチャやマウント可能なイメージではなく、人工的に作成されたティーチングバイトです。オフセットはセクタ単位の16進数で、整数フィールドはリトルエンディアン形式でエンコードされています。ディスクLBA = 2,048 + ボリュームセクタ。すべてのセクタ範囲は端数を含むものとし、マップは概略図です。 フィールドを選択するか、そのバイトをクリックしてください。ASCIIのドットは、印刷不可能なバイトを示しています。ブートストラップの内容は、教育用の埋め草です。.
この表は、Linux-NTFS実装によって文書化されたレイアウトを説明したものです。これはディスク上の構造に関する有用な参考資料ですが、Microsoft NTFS仕様の完全な代替となるものではありません。.
特に重要な分野の一つは $MFT LCN。.
LCNとは、Logical Cluster Number（論理クラスタ番号）の略です。これは、物理ディスクのLBAではなく、NTFSボリュームに対するクラスタを識別するものです。.
もし $MFT LCNがわかっている場合、マスターファイルテーブルの開始位置は、ボリュームのクラスタサイズを用いて計算することができます：
MFTのバイトオフセット = MFTのLCN × クラスタあたりのバイト数
これは、すべてのファイルの場所を特定するものではありません。これは、 $MFT 構造になっている。.
について $MFTMirr このフィールドは、重要な初期MFTレコードの限定的なミラーの保存場所を示します。これは、マスターファイルテーブルやユーザーファイルの完全なバックアップではありません。.
この関係についてより詳しく知りたい場合は、以下の Amagicsoft マスターファイルテーブルガイド.
Linux-NTFSのディスク上のレイアウトに関する文書によると、Windows NT 4.0以降ではパーティションの最終セクタにバックアップブートセクタが配置されていますが、それ以前のNT 3.51などのシステムでは別の場所に配置されていました。これは実装および歴史的な参考情報であり、バックアップの場所を想定する前に、実際のボリュームレイアウトを確認する必要があります。.
FAT32 ブートセクタ、FSInfo、およびバックアップ・ブートレコード
FAT32では、ボリュームの「予約領域」の最初のセクタにBPBが配置されます。.
特に重要な項目がいくつかあります：
フィールド | バイトオフセット | サイズ | 目的 |
| 11 | 2バイト | 1セクタあたりのバイト数 |
| 13 | 1バイト | クラスタあたりのセクター数 |
| 14 | 2バイト | 予約領域のサイズ |
| 36 | 4バイト | 1つのFATが占めるセクタ |
| 44 | 4バイト | ルートディレクトリの最初のクラスター |
| 48 | 2バイト | FSInfoセクタの位置 |
| 50 | 2バイト | バックアップブートレコードの場所 |
BPB、FSInfo、およびバックアップ・ブート・レコード
参考図 · FAT321 GiB のサンプル · 512 B/セクタ · 4 KiB/クラスタ · パーティションはディスクの LBA 2,048 から始まる
デコードされたフィールド
レイアウト、サンプルノート、およびソース
FAT32。. このサンプルでは、0～2セクターにあるMicrosoft形式の3セクター構成のブートレコードを、32個の予約セクター内の6～8セクターにコピーしています。セクター1はFSInfo、セクター7はその初期コピーです。正規のFSInfoアドレスは1のままです。ブートコードセクターにはF4フィラーが使用されています。残りの予約セクターはゼロで埋まっています。 2,048セクタからなる2つのFATがあり、データは4,128から始まります。floor((2,097,152 − 4,128) / 8) = 261,628クラスタとなり、FAT32のしきい値である65,525を上回っています。 各FATは262,144エントリを保持しており、必要な261,630エントリを十分に収容できる。FSInfoの割り当てヒントについては、明確に不明である。.
ディスクのキャプチャやマウント可能なイメージではなく、人工的に作成されたティーチングバイトです。オフセットはセクタ単位の16進数で、整数フィールドはリトルエンディアン形式でエンコードされています。ディスクLBA = 2,048 + ボリュームセクタ。すべてのセクタ範囲は端数を含むものとし、マップは概略図です。 フィールドを選択するか、そのバイトをクリックしてください。ASCIIのドットは、印刷不可能なバイトを示しています。ブートストラップの内容は、教育用の埋め草です。.
について BPB_FSInfo このフィールドは通常、セクタ 1 を指します。このセクタには、最後に確認された空きクラスタ数や、次の空きクラスタのヒントなどの情報が格納されています。.
について BPB_BkBootSec このフィールドは、バックアップブートレコードの位置を指定します。Microsoft FAT仕様では、その値は0または6です。6に設定された場合、バックアップ構造はボリューム相対セクター6から始まります。.
重要な点として、FAT32のブートレコードは単なる1セクタのコピーではないということです。マイクロソフトの仕様書によると、ブートレコード全体は3セクタの長さであり、それに対応するバックアップシーケンスが存在します。また、FSInfo構造体のコピーもバックアップシーケンス内に保持されています。.
これらの構造は、それぞれ異なる目的を果たしています：
- ブートセクタには、BPBおよびブート関連情報が格納されています。.
- FSInfoには空き領域のヒントが保存されます。.
- バックアップブートレコードは、重要なブート情報の代替コピーを提供します。.
FSInfoは2つ目のVBRではなく、その空きクラスタ数は必ずしも正確で、継続的に更新される値とは限りません。.
exFATのメインおよびバックアップブート領域exFATでは、「ブート領域」と呼ばれる、より広範な構造を採用しています。.
によると、 Microsoft exFAT ファイルシステム仕様, 、このボリュームにはメイン・ブート領域とバックアップ・ブート領域が含まれており、それぞれ12セクタを占めています。.
体積相対セクター | メインブート領域 | バックアップブート領域 |
0 / 12 | ブートセクター | ブートセクタのバックアップ |
1–8 / 13–20 | 拡張ブートセクタ | 拡張ブートセクタのバックアップ |
9 / 21 | OEMパラメータ | OEMパラメータのバックアップ |
10 / 22 | 予約 | バックアップ用（予約済み） |
11 / 23 | ブートチェックサム | バックアップブートチェックサム |
メインブートセクタには、exFATボリュームを記述するために使用される主要なパラメータが含まれています。.
重要な項目には、以下のものが含まれます：
フィールド | バイトオフセット | サイズ | 目的 |
| 0 | 3バイト | ブートストラップ・ジャンプ命令 |
| 3 | 8バイト | ファイルシステムを exFAT として識別します |
| 64 | 8バイト | メディア相対のパーティションオフセット |
| 72 | 8バイト | セクタ単位のボリューム長 |
| 80 | 4バイト | 最初のFATの開始セクタ |
| 84 | 4バイト | 各FATの長さ |
| 88 | 4バイト | クラスターヒープの開始セクタ |
| 92 | 4バイト | クラスタ・ヒープ内のクラスタ数 |
| 96 | 4バイト | ルートディレクトリの初期クラスタ |
| 106 | 2バイト | ファイルシステムのステータスフラグ |
| 108 | 1バイト | セクタサイズエンコーディング |
| 109 | 1バイト | クラスタサイズの符号化 |
| 110 | 1バイト | FAT構造体の数 |
| 112 | 1バイト | 割り当てられたクラスタの報告された割合 |
メインおよびバックアップのブート領域
参考画像 · exFAT1 GiB のサンプル · 512 B/セクタ · 4 KiB/クラスタ · パーティションはディスクの LBA 2,048 から始まる
デコードされたフィールド
レイアウト、サンプルノート、およびソース
exFAT。. セクタ0～11および12～23は、それぞれ独立した12セクタからなるブート領域を形成しています。 チェックサムは、各領域の直前の11セクタから、ブートセクタのバイト106、107、および112をスキップして計算され、そのチェックサムセクタ内で128回繰り返される。このサンプルでは、メインとバックアップの開始部分は同一である。バックアップフラグおよび使用率は、リーダーによって古いデータとして扱われる。 ブートストラップは提供されていません。メインのブートコードのバイトは F4、拡張コードは 0 です。OEM パラメータは null、予約バイトは 0 です。ヒープには 261,632 クラスタがあり、ルートクラスタ 12 にはビットマップおよび大文字メタデータ用の領域が確保されていますが、その内容については本実習の範囲外です。.
ディスクのキャプチャやマウント可能なイメージではなく、人工的に作成されたティーチングバイトです。オフセットはセクタ単位の16進数で、整数フィールドはリトルエンディアン形式でエンコードされています。ディスクLBA = 2,048 + ボリュームセクタ。すべてのセクタ範囲は端数を含むものとし、マップは概略図です。 フィールドを選択するか、そのバイトをクリックしてください。ASCIIのドットは、印刷不可能なバイトを示しています。ブートストラップの内容は、教育用の埋め草です。.
従来のFAT BPBとは異なり、exFATは独自のパラメータレイアウトを定義しています。その MustBeZero また、このフィールドはFAT12/16/32のBPB領域に対応する範囲も占めており、これにより、古いFAT実装がexFATボリュームを誤ってFATボリュームと解釈してしまうのを防ぐのに役立っています。.
exFATのブートチェックサムの仕組み
exFATブートチェックサムは、署名の確認だけを行う場合よりも強力な検証メカニズムを提供します。.
本仕様書では、以下のプロセスを定義しています：
- メインブート領域の最初の11セクタを読み取ります。.
- を除外する
VolumeFlagsオフセット 106～107 にあるバイトと、使用率オフセット 112 にあるバイト。. - 残りのバイトを順番に処理してください。.
- 各バイトについて、現在の32ビットのチェックサムを1ビット分右回転させ、そのバイトの値を加算します。この際、結果は32ビット以内に収まるようにします。.
- 算出されたチェックサムを、ブートチェックサムセクタ全体にわたって繰り返される4バイトのパターンとして格納します。.
バックアップ・ブート領域には、それに対応する独自のチェックサム計算が設けられています。.
の除外 VolumeFlags そして 使用率 これは意図的な仕様です。これらのフィールドは、ブートチェックサムの再計算を行わずに更新することができます。また、仕様書では、バックアップブートセクタ内の対応する値は、古いものとして扱う必要があると規定されています。.
つまり、メイン・ブート領域とバックアップ・ブート領域をバイト単位で比較することは、普遍的な検証方法としては適切ではないということです。.
その代わりに、各領域は、それぞれ固有のチェックサムおよびフィールドの妥当性に関するルールに従って検証されなければなりません。.
ボリューム・ブート・レコードの検査と検証方法
VBRを検査するには、ボリュームがどこから始まるか、またそのレイアウトを定義しているファイルシステムがどれかを把握しておく必要があります。.
RAWセクタは、まずボリュームのフォーマットを特定せずに、汎用テンプレートを使用して解釈すべきではありません。.
手順 1：ボリュームの開始 LBA を特定する
信頼できるディスク構成情報に基づいて、パーティションまたはボリュームの開始位置を特定します。.
従来のベーシックディスクでは、パーティションの開始LBAは通常、そのパーティションに含まれるボリュームの開始位置となります。.
すべてのボリュームがLBA 0から始まる、あるいはドライブ文字が物理ディスクのオフセットを示す、と決めつけないでください。.
ステップ 2：バイトオフセットを計算する
生のディスクイメージ内でボリュームの最初のセクタを特定するには、次のように実行します。
バイトオフセット = ボリュームの開始LBA × 論理セクタサイズ
たとえば、パーティションがLBA 2,048から始まり、デバイスが512バイトの論理セクタを使用している場合：
2,048 × 512 = 1,048,576 バイト
その例示用のディスクイメージにおいて、VBRはバイトオフセット1,048,576の位置から始まります。.
4,096バイトの論理セクタの場合、同じLBAでもバイトオフセットは異なります。すべてのディスクが512バイトのセクタを使用していると仮定するのではなく、常にそのデバイスの実際の論理セクタサイズを使用してください。.
ステップ 3：16 進エディタを使用して構造を確認する
ディスクエディタや16進エディタを使用すると、セクターの生のバイトデータとそのオフセットを表示することができます。.
読み取り専用の検査を行う場合は：
- 適切な16進エディタを使用して、ディスクイメージまたは該当する物理デバイスを開きます。.
- 計算されたバイトオフセットの位置に移動します。.
- 先頭のバイトとファイルシステム識別子を確認してください。.
- 対応するファイルシステム仕様を用いて、関連するフィールドを解釈してください。.
- フィールドの値に内部的な整合性があるかどうかを確認してください。.
たとえば、NTFSのブートセクタはNTFSのフィールドレイアウトに基づいて解釈すべきであり、FAT32のセクタはFAT32のBPB定義に基づいて解釈すべきです。.
検査中は、ソースディスクを編集しないでください。ソースに重要なデータが含まれている場合は、読み取り専用のイメージを使用することをお勧めします。.
ステップ 4: ファイルシステム固有の一貫性を確認する
VBRは、単一の指標ではなく、複数の指標を用いて評価すべきである。.
確認すべき事項としては、次のようなものがあります：
- 報告された「1セクターあたりのバイト数」の値が、そのフォーマットに対して有効であるかどうか。.
- 「クラスターあたりのセクター数」が有効な値であるかどうか。.
- ボリュームの長さが、利用可能なパーティションまたはボリュームエクステントの範囲内に収まるかどうか。.
- ファイルシステム固有のオフセットが、妥当な場所を指しているかどうか。.
- バックアップ構造が、関連するフォーマットで指定された場所に配置されているかどうか。.
- 必要なチェックサムおよび署名が有効かどうか。.
FAT32の場合は、BPBフィールドと、ブートセクタ、FSInfo、およびバックアップブートレコードとの関係を調べてください。.
NTFSの場合は、ボリュームのセクタ数とMFTに関連するクラスタの位置を確認してください。考えられる $MFT LCNだけでは、MFTが正常であることを証明するものではありません。.
exFATの場合は、メインおよびバックアップのブートチェックサムを個別に検証し、関連するフィールドが指定された範囲内にあることを確認してください。.
ステップ5：結果を慎重に解釈する
署名チェックが成功したからといって、そのボリュームが正常であることを証明するものではありません。.
同様に、有効なバックアップブート構造が存在しても、すべてのファイルシステムのメタデータやユーザーデータが無傷のままであるとは限りません。.
適切な評価では、以下の点を区別すべきである：
- 読み取り可能なブートセクタ。.
- 構造的に有効なファイルシステムパラメータ。.
- 適切なバックアップ構成。.
- マウント可能なファイルシステム。.
- 実行可能で完全なオペレーティングシステムのブートチェーン。.
これらは関連しているものの、異なる状態です。.
ボリューム・ブート・レコードが破損するとどうなるのか？
～への損傷 ボリューム・ブート・レコード システムの起動を妨げたり、ボリュームの識別やマウントを困難にしたりする可能性があります。.
具体的な影響は、どのフィールドや構造体が影響を受けるか、またオペレーティングシステムがそれらをどのように使用しているかによって異なります。.
ダメージ | 考えられる結果 |
Bootstrap コードの破損 | 従来のBIOSによる起動に失敗する場合があります |
BPB、あるいは体積パラメータによる損傷 | ファイルシステムが正しく認識されない、またはマウントされない可能性があります |
無効な NTFS ブート情報 | NTFS ボリュームの解析に失敗する可能性があります |
FAT32のブートセクタの破損 | FAT32のマウントや起動操作に影響が出る可能性があります |
exFAT ブート領域の不整合 | ファイルシステムの識別または検証に失敗する場合があります |
メインブート構造に損傷があるが、有効なバックアップがある場合 | ファイルシステムに応じた適切な手順を用いれば、復元が可能である可能性があります |
VBRの破損は、必ずしもファイルの削除を意味するわけではありません
VBRには、構造情報やブート関連情報が格納されています。通常、一般のユーザーファイルの内容は格納されません。.
したがって、VBRが破損したからといって、写真、文書、動画、その他のファイルの内容が自動的に消去されるわけではありません。.
たとえば、NTFSボリュームでは、ブートセクタが破損している一方で、MFTレコードやユーザーデータクラスタの一部またはすべてが読み取り可能なままの場合があります。.
ただし、復旧の可否は、他のファイルシステム構造の状態、ストレージデバイスの物理的な読み取り可能性、および追加の書き込みによって重要なメタデータやファイルの内容が上書きされていないかどうかに左右されます。.
起動できないボリュームであっても、復元可能なデータが含まれている可能性があります。逆に、VBRが読み取れるからといって、ファイルシステムの残りの部分が正常であるとは限りません。.
VBRの破損とMBRまたはGPTの破損の比較
これらの障害は、さまざまなストレージ層に影響を及ぼします。.
- MBRの損傷： レガシーのブートストラップコードや、ディスクのLBA 0に保存されているパーティションエントリに影響を与える可能性があります。.
- GPTの損傷： パーティションのレイアウト、GPTヘッダー、またはパーティションエントリ配列に影響を与える可能性があります。.
- VBRによる損傷： 特定のボリュームの初期起動に関連する構造に影響を与えます。.
- EFIシステムパーティションの破損： UEFIファームウェアがWindows EFIブートマネージャーを検出または読み込むことを妨げる可能性があります。.
修理手順は、損傷した部品に合わせて行う必要があります。.
例えば、こうだ、, bootrec /fixmbr MBRのブートコードを書き換えます。ただし、破損したNTFSのVBRの再構築、GPTヘッダーの修復、および失われたパーティションエントリの復元は行いません。.
ディスクレベルの起動に関する問題についての解説については、以下を参照してください。 AmagicsoftのMBR破損対処ガイド.
重要なファイルにアクセスできない場合は、書き込みベースの修復を試みる前に、元のデータを保護してください。適切なバックアップやイメージを確保するまでは、フォーマット、初期化、パーティションの再分割、またはファイルシステムを変更する修復コマンドの実行は避けてください。.
まとめ
A ボリューム・ブート・レコード これは、ファイルシステムのパラメータとブート関連情報を結びつける、ボリュームレベルの構造体です。通常、その位置はボリュームの最初の論理セクタですが、正確なレイアウトはファイルシステムによって異なります。.
MBR、GPT、VBRの違いを理解することは極めて重要です。MBRとGPTはディスクレベルのパーティション構成を記述するものであるのに対し、VBRはファイルシステムのボリュームに属するものです。レガシーBIOSによる起動ではVBRのブートストラップコードが実行される場合がありますが、ネイティブUEFIによる起動では、EFIシステムパーティションからEFIアプリケーションが読み込まれます。.
NTFS、FAT32、exFATのブート構造の違いを理解しておくことは、ブートレコードの破損と、より広範囲にわたるファイルシステムの破損や実際のユーザーデータの損失とを区別する上でも役立ちます。.
よくあるご質問
ボリューム・ブート・レコードとパーティション・ブート・レコードは同じものですか？
VBRは常にLBA 0に位置するのでしょうか？
GPTディスクにはボリュームブートレコードがありますか？
UEFIはボリューム・ブート・レコードを使用しますか？
ブートセクタにおける「55 AA Signature」とは何を意味するのでしょうか？
55 AA いくつかの従来のブートセクタ形式で使用されるブート署名です。これが存在することは構造上の有用な指標となりますが、BPB、ファイルシステムパラメータ、ブートストラップコード、またはバックアップ構造が有効であることを証明するものではありません。.バックアップVBRはどこにあるのですか？
BPB_BkBootSec, 、多くの場合セクター6です。Windows NTの新しいバージョンでは、NTFSのレイアウトにおいて、バックアップブートセクタが通常、ボリュームの最終セクタに配置されます。exFATでは、ボリューム相対セクタ12から始まる独立した「バックアップブート領域」が使用されます。.VBRの破損により、データが永久に失われることはありますか？
