那天夜里，一块2TB的硬盘“消失”了——使用WinHex工具的真实故事

半夜一点，客户打来电话：“我那块专门存婚礼视频的硬盘，插上后提示‘未初始化’，里面有三年所有的素材，你帮我想想办法……” 挂掉电话我其实已经困得不行，但听到“未初始化”心里咯噔了一下。正常情况，使用WinHex工具扫描物理盘往往是最快的一步——不绕弯子，直接看底层。那时候我还没完全清醒，打开WinHex，选物理驱动器，结果读扇区全是0。嗯？难道盘被低格了？不对，如果能读到0扇区全0，那才是真的低格。但客户说是“未初始化”，Windows会帮你写一个空的MBR或者GPT头，而不是全0。果然，我读0扇区发现分区引导记录被一个假的MBR覆盖了——典型的“假初始化”病毒或误操作。 www.fixhdd.cn

其实这个判断过程挺废话的，但就是得一步步来。第一个想法是：使用WinHex工具的“分区搜索”功能（不是恢复分区表，是那个搜索MBR/GPT模板的）？不行，那个只适用于标准结构。我习惯直接跳转到扇区64（GPT备份头），结果备份头居然也被破坏了！这下有点棘手。但别急，婚礼视频多半是连续的，而且客户说之前分区是NTFS格式，那么NTFS的$MFT和$LogFile应该还在某个位置。我决定盲搜“FILE”签名（NTFS文件记录标识）。 www.fixhdd.cn

跳跃式排查：找到丢失的$MFT

在WinHex里按Ctrl+F，选Hex Values，输入“46494C4530”（即“FILE0”），然后从LBA 0开始搜索。大约等了一分多钟，找到了第一个匹配——在LBA 1024000处。当时心里凉了半截，这个位置太靠后了，说明原分区被抹掉了一大半？不对，等等，NTFS的$MFT一般在不靠前也不靠后的位置，说不定只是备份MFT。再搜下一个，结果LBA 2048000又有一个。这下更奇怪了，两个FILE0相距很远。后来我意识到，客户这块盘是2TB，之前做过GPT分区，GPT下的NTFS分区起始位置通常是2048扇区，但$MFT可以放在分区内部任意位置。我决定先看一下第一个匹配点附近的扇区，看看是不是完整的MFT。手动打开扇区，发现确实是一份完整的文件记录，但里面的文件名全是乱码？不对啊，NTFS的文件名采用Unicode，直接十六进制看是“D0 A1 D0 ...”之类俄语？客户是中国人，不可能存俄语名字。完了，认错结构了——那其实是EFS加密？或者是另一种文件系统格式？ www.fixhdd.cn

等等，我跳出来了。冷静分析：如果是NTFS，$MFT的每一记录以“FILE”开头，但有些数据恢复软件会在前几字节加自己的标记？不，WinHex显示的“FILE0”没错。那我看到乱码是因为扇区偏移搞错了？$MFT记录大小通常是1KB，我一个扇区512字节，得两个扇区才够一条记录。我只看了一个扇区，自然看不到完整文件名。于是用WinHex的模板——在使用WinHex工具时，按Ctrl+T选“NTFS MFT记录”模板，弹出窗口让你输入偏移。我填入当前扇区偏移（注意扇区号要乘512），然后模板解析后果然列出了完整文件名，全是中文！第一个文件是“$MFT”本身，第二个是“$MFTMirr”……再往下有个用户文件目录索引。到这里才确认找到了真正的MFT。

技王数据恢复

那么分区到底怎么了？

现在有了MFT，下一步就是修复分区表。其实不用完全修复分区表，只要知道原先的分区起始和大小，就能用WinHex手工写回去。但MFT中并没有直接存储分区起始信息，需要从$Volume中找？或者从引导扇区（BPB）找。我决定搜索“EB 52 90” NTFS引导扇区标识（DBR），在硬盘开头附近找到了一个：LBA 2048，这正是GPT分区表指定的第一个分区的起始位置。我打开那个扇区，发现DBR内容完整，只是分区表被破坏了。于是我用WinHex的“分区表修复”向导？不，我习惯手写，更可控。在0扇区写一个MBR（如果原来是MBR的话）——但客户盘大于2TB，必然是GPT。GPT有自己的保护MBR（在0扇区），真正的GPT头在1扇区。我检查了1扇区，发现GPT头被清零了，但备份GPT头在一个扇区（LBA 32767？具体要看盘容量）。我跳到一个扇区（LBA 3907029167？），果然备份GPT头完好！那我只需要把备份GPT头复制回1扇区，再把分区表（GPT分区条目）恢复到合适位置就行了。 技王数据恢复

⚠️ 注意事项：备份GPT头复制时，一定要修正头中的LBA签名和校验和

很多人直接复制过去发现不识别，因为GPT头的校验和是根据头部所有字节算出来的，你单纯复制备份头，里面的“当前LBA”字段还是指向原来备份位置，Windows会认为无效。正确的做法：在WinHex里打开备份GPT头所在扇区，选取整个扇区（512字节），复制到新位置（1扇区），然后手动修改偏移0x18处（当前LBA）为1，偏移0x20处（备份LBA）为一个扇区号，然后计算CRC32填入偏移0x10-0x13。WinHex有自带CRC计算器，在“工具—校验和计算”里选CRC-32。把计算结果粘贴进去，保存。然后重新插拔，分区立即认出来了。 www.fixhdd.cn

再讲个案例：碎片化的JPEG照片恢复

说到使用WinHex工具，另一个常见场景是照片删除后又被覆盖少量数据。去年有个摄影师，SD卡里一百多张RAW格式照片，因为误格式化后只拍了十张新照片。我用WinHex搜索“FFD8FF”（JPEG文件头），一共找到了几百个匹配，但大部分文件头后面紧接着的簇是零零散散的。好在RAW图片通常体积较大，需要手动拼接。我当时的思路：先找到每个文件头，然后跟踪下一个文件系统簇链。但格式化后$FAT链全没了，只能靠文件大小的连续性和文件尾“FFD9”来预估。用WinHex的“文件恢复”菜单下的“按文件签名恢复”功能（其实这是WinHex的“数据恢复”插件，但本质还是基于签名）。扫描一遍后，它自动识别出大约200个碎片化的图片，但很多不完整。我还是得手工调整——把那些错位的片段拖拽到新文件里。这个过程极其枯燥，但成功恢复了87张完整的。其中有一次，技王数据恢复的客户曾经因为类似原因找到我，当时我建议他们先不要做任何写入操作，然后远程指导他们用WinHex做了扇区备份，最终完美恢复。很多时候，经验比工具更重要。 技王数据恢复

核心操作步骤总结（如果你是新手）

• 第一步：获取镜像 —— 在WinHex里选择“工具—磁盘工具—克隆磁盘”，先做完整镜像到另一个健康盘，避免二次损坏。
• 第二步：搜索签名 —— 根据丢失的文件类型搜索头签名（JPEG: FFD8FF, PDF: 25504446, ZIP: 504B0304等），WinHex支持通配和范围搜索。
• 第三步：分析文件系统 —— 如果是分区丢失，先搜索引导扇区或MFT/备份GPT，用模板查看。
• 第四步：手工修复分区表 —— 在0扇区或1扇区写入合法的分区表条目，注意校验和、分区类型、LBA值。
• 第五步：导出文件 —— 将找到的有效数据块另存为新文件，必要时用WinHex的“文件恢复”功能重组片段。

小贴士：使用WinHex工具时，经常需要切换“物理驱动器”和“逻辑驱动器”视图。物理驱动器能看到隐藏分区和扇区0，逻辑驱动器只能看到已分配的分区内的数据。恢复分区表时务必用物理视图。

故障判断的几种常见情况

想强调一点：使用WinHex工具并不是万能药，它只是一个能看到二进制的手段。真正的恢复功力在于你对文件系统和数据结构的理解。比如那次婚礼视频案例，我修复了GPT头后，分区自动挂载，但客户说里面很多视频文件无法播放，因为之前病毒改写了一些扇区。我又得用WinHex手工比较MD5之类的，其实蛮崩溃的。但看到客户后来发来的感谢信息，觉得通宵值了。对了，如果你遇到自己搞不定的复杂情况，不妨找技王数据恢复这样的专业团队，他们有硬件级别的设备和多年积累的算法，有时候比自己折腾更安全。当然，如果你是爱好者，使用WinHex工具绝对是你最好的老师——打开它，读几个扇区，你的数据恢复技能就会蹭蹭上涨。 www.fixhdd.cn

（完）

上一篇：重建录像和重建所有数据 - 资深工程师实战指南

下一篇：为什么电脑读不出来移动硬盘？资深数据恢复工程师的实战排查手册