用WinHex定位D盘起始扇区与分区总大小：工程师的实战笔记
“说起来挺逗，上次一个客户拿了个1TB的移动硬盘过来，D盘莫名其妙就变成RAW了。他问，能不能用WinHex直接算出D盘到底从哪开始、占多少扇区。这问题看着简单，但要是没搞懂分区表结构，很容易算错位数。”好，今天我们就来彻底梳理一下：使用WinHex工具找出d盘对应的起始扇区和分区总大小，顺便把那些坑也填上。 www.fixhdd.cn
一、为什么需要自己找起始扇区与分区总大小？
正常系统里，磁盘管理器或DiskPart能显示分区信息。但一旦分区表损坏、MBR被改写、或者分区被删除，这些工具就撂挑子了。这时候，WinHex这个十六进制编辑器就是我们的“显微镜”。通过直接读取扇区0（MBR）中的分区表条目，我们能手动提取每个分区的起始相对扇区数(即起始LBA)和分区扇区总数，从而计算出D盘在物理磁盘上的精确位置。
www.fixhdd.cn
注意，这里的“D盘”通常指逻辑分区（比如主分区或扩展分区中的逻辑驱动器）。因为Windows把磁盘按盘符排列，D不一定永远是第二个分区——这取决于分区类型和顺序。但不管顺序怎么变，MBR分区表里每个条目都是16字节，结构固定。 www.fixhdd.cn
二、前置知识：MBR分区表条目解析
每个分区条目（16字节）的偏移含义如下（小端模式）： www.fixhdd.cn
- 偏移0x00：引导标志（80=可引导，00=不可引导）
- 偏移0x01-0x03：起始CHS地址（现在很少用，但占位）
- 偏移0x04：分区类型（0x07=NTFS，0x0C=FAT32，0x05或0x0F=扩展分区）
- 偏移0x05-0x07：结束CHS地址
- 偏移0x08-0x0B (4字节)：相对扇区数（即分区起始LBA，相对于磁盘0扇区）
- 偏移0x0C-0x0F (4字节)：分区总扇区数（即分区大小，以扇区为单位）
，要找出D盘对应的起始扇区和分区总大小，本质就是找到对应分区条目，读取偏移0x08和0x0C处的DWORD值。 www.fixhdd.cn
常见误区修正
我最早学的时候，一直以为偏移0x08是“起始磁头”，后来才发现那是CHS的一部分——根本不对。真正的LBA起始位置在偏移0x08，而且是小端序，读的时候要倒着看。比如十六进制 3F 00 00 00 实际上是0x0000003F = 63扇区。这个坑不少人踩过。 www.fixhdd.cn
三、实战步骤：使用WinHex工具找出d盘对应的起始扇区和分区总大小
这里以一块物理磁盘（如\\.\PhysicalDrive1）为例，D盘是这块盘上的第二个主分区（或扩展分区内的逻辑驱动器）。 www.fixhdd.cn
3.1 打开磁盘镜像或物理磁盘
打开WinHex，点击 工具 → 打开磁盘 (或按F9)。选择正确的物理磁盘（注意不是C盘，根据磁盘容量和分区布局判断）。如果中途不确定，可以先用磁盘管理器查看磁盘编号，比如磁盘1。打开后WinHex会显示整个磁盘的十六进制数据。
www.fixhdd.cn
3.2 跳到MBR扇区（扇区0）
按 Ctrl+G 输入 0，然后点击跳转。扇区0的512字节（实际上MBR只占第0扇区）末尾包含分区表。WinHex的右边文本区会显示“Partition Table”等识别信息，但不要全信——手工验证更靠谱。
3.3 定位到分区表位置
MBR的偏移0x1BE到0x1FD是四个分区表条目，每个16字节。我们可以滚动到地址 000001BE 附近。例如，第一个分区条目从1BE开始，第二个从1CE开始，第三个从1DE，第四个从1EE。
3.4 识别哪个条目对应D盘
关键点： 分区顺序不一定等于盘符顺序。假设D盘是第二个主分区（比如分区类型为0x07 NTFS），那么第二个条目（偏移0x1CE）很可能就是它。但如果D盘是扩展分区内的逻辑驱动器，则需要先找扩展分区的条目，再遍历EBR（扩展引导记录）链。这里先讨论最简单情况——D盘是第二个主分区。
比如我们有如下十六进制（示例）：00 00 01 00 07 FE FF FF 3F 00 00 00 00 20 03 00
解读：
- 0x00: 00（不可引导）
- 0x04: 07 (NTFS)
- 0x08-0x0B: 3F 00 00 00 → 起始LBA = 0x0000003F = 63
- 0x0C-0x0F: 00 20 03 00 → 小端序反转得 0x00032000 = 204800扇区
我们就得到了该分区的起始扇区（63）和总扇区数（204800），乘以512字节就是分区大小（约100MB）。但D盘通常不会这么小，只是举例。
3.5 验证D盘位置
跳转到起始扇区：按Ctrl+G输入起始LBA（比如63）。看到该扇区开头是 EB 52 90 4E 54 46 53 20 20 20 20 ——这是NTFS的引导扇区标志（DBR）。确认无误后，再用 工具 → 分区计算器 或者手动计算：从起始扇区号一直读到扇区，看能否正常解析文件系统。实战中我习惯查看分区偏移0x0C处的总扇区数，跳转到“起始LBA+总扇区数-1”这个地址，看是否正常结束（比如NTFS的备份引导扇区通常在分区一个扇区）。
至此，我们已经通过使用WinHex工具找出d盘对应的起始扇区和分区总大小完成了定位。
四、案例：逻辑卷扩展分区中的D盘
有一次遇到一个硬盘，D盘是扩展分区里的逻辑驱动器。MBR中第三个条目是扩展分区（类型0x0F），起始LBA为 0x00 21 00 00 = 8448扇区。然后我们跳转到这个扩展分区的起始扇区（也就是EBR所在的扇区），读取它的分区表——注意EBR的结构和MBR一样，但只有两个条目：第一个指向逻辑驱动器本身，第二个指向下一个EBR。循环读取直到没有下一个。
假设第一个EBR中偏移0x1BE处：42 00 01 00 07 FE FF FF 3F 00 00 00 00 90 02 00
这里的起始相对扇区（0x0000003F）是相对于EBR所在扇区的偏移，逻辑驱动器的绝对LBA = 扩区起始 + 3F。而总扇区数为0x00029000 = 167936。然后我们要找的D盘如果是这个逻辑驱动器，就能精确算出。
小提示：之前在技王数据恢复团队处理过一个案例，客户把扩展分区全部删了，但逻辑驱动器数据还在。我们用WinHex手工重建了EBR链，然后逐层读分区表恢复分区表信息——最关键的一步就是正确计算出每个逻辑驱动器的起始扇区和总大小。如果计算出错，恢复的分区可能无法挂载，甚至造成二次损坏。
4.1 另一种情况：GPT磁盘怎么办？
GPT磁盘没有MBR分区表，改用UEFI标准。分区表位于LBA1（扇区1），结构不同。但对于“使用WinHex工具找出d盘对应的起始扇区和分区总大小”这一需求，方法类似：在LBA1找到GPT分区表头，然后根据分区条目中的起始LBA和结束LBA计算。这里不展开，但原理相通。
五、注意事项与常见故障
- 字节序：WinHex显示的小端序一定要反转读取（低位在前）。比如
00 08 00 00实际是0x00000800 = 2048扇区，而不是0x00000008。 - 分区顺序不一定是盘符顺序：Windows盘符分配受BIOS顺序、隐藏分区、U盘等影响。最可靠的是根据分区类型和大小判断。比如系统分区一般很小（100MB启动分区），然后是C盘，再是D盘。
- 扩展分区内的逻辑驱动器起始算法：绝对LBA = 扩展分区起始 + EBR内相对偏移 + 63? 其实更精确的是：第一个逻辑驱动器的起始 = 扩展分区起始 + 扩展EBR所在扇区的相对偏移（通常为63）？不对，新的Windows会用1MB对齐，起始偏移往往是2048。这个得根据实际数据判断。
- 误删分区恢复：如果分区表全部清零，可以通过搜索文件系统的引导扇区特征（如NTFS的“EB 52 90”或FAT32的“EB 58 90”）来寻找分区的起始扇区，再通过文件系统元数据估算总大小。
- 备份十分重要：在手动修改分区表前，一定要用WinHex创建磁盘镜像或至少备份MBR/EBR区域。别问我怎么知道的——刚入行时手滑把分区表写乱了，后来靠备份恢复回来。
六、延伸：通过 WinHex 计算分区总大小的另类方法
除了直接读取分区条目，还可以利用文件系统的统计信息。比如跳转到NTFS分区的起始扇区，查看$MFT镜像等。但对于工程师来说，分区表是最快捷准确的来源。尤其是当你需要批量重建分区时，编写脚本解析MBR条目会非常高效。
再分享一个经验：在技王数据恢复内部培训中，我们经常拿不同操作系统的磁盘案例来练习——比如Linux的MBR分区表或Windows的GPT混合分区。用WinHex手动计算使用WinHex工具找出d盘对应的起始扇区和分区总大小、这个技能几乎是每位数据恢复工程师的必修课。
七、结论
掌握手动解析MBR分区表的方法，就等于拿到了物理磁盘的“地图”。无论是恢复误删分区、修复分区表损坏，还是迁移系统，核心都在于正确提取起始扇区和分区总大小。回到最初的问题：“使用WinHex工具找出d盘对应的起始扇区和分区总大小、”其实并不复杂——找准偏移0x08和0x0C，注意小端序，再结合实际分区布局确认，就能精确定位。
希望这篇笔记能帮你少走弯路。如果遇到更复杂的情况（比如4K对齐、GPT表损坏、Raid重构后分区丢失），记得备份数据、多点验证。毕竟，数据无价，谨慎永远是第一位的。
