WinHex查找File Entry —— 资深数据恢复工程师的实战笔记_业内新闻

WinHex查找File Entry：从迷茫到清晰的一次完整复盘

最近遇到一个活，客户拿着一个摔过的移动硬盘，说里面工作文档全没了。我一听，第一反应是：“盘还能认吗？” 插上电脑，磁盘管理里能识别，但显示RAW。行，至少硬件没完全跪，那就进WinHex看看。说到WinHex，很多朋友喜欢用它做底层分析，但真正到了要winhex查找file entry这个环节，不少人就卡住了——满屏十六进制，到底哪一段才是我们要找的文件记录？ www.fixhdd.cn

嗯，先纠正一个常见的误区：**file entry** 在NTFS里其实就是 $MFT （主文件表）里面的每一条记录。每个文件、目录都有一个对应的file entry，长度通常是1024字节（1KB）。当你对着硬盘扇区乱翻的时候，找file entry本质上是定位 $MFT 的起始位置，然后根据索引或文件名去匹配那条记录。这个思路得先拎出来，否则后面容易跑偏。 www.fixhdd.cn

第一步：定位$MFT——这是所有查找的前提

WinHex打开物理磁盘或分区镜像后，我一般会先看看分区引导扇区（PBR）里的 $MFT 起始簇号。就在偏移0x30的位置，8个字节，小端序。比如你看到一个值 0x000000000C0000，换算成十进制是786432，那就是说$MFT从第786432号簇开始。然后根据每簇扇区数（一般默认8）算出扇区号：786432 * 8 = 6291456，再乘以512字节就得到字节偏移了。当然更简单的方法是：直接用WinHex的“跳转到扇区”功能输入那个簇号×每簇扇区数。技王数据恢复

等等，这里有个坑——如果分区被格式化过，或者引导扇区损坏，这个起始簇号可能是错的。我上个月就栽过一次，怎么跳都跳不到$MFT的位置。用WinHex的“文件系统”→“NTFS解析”功能，让它自动扫描，才发现$MFT其实已经碎片化了，起始记录被搬到了别处。别盲目相信PBR里的数值，最好交叉验证：看偏移0x0处的文件签名是不是“FILE”，ASCII码是 46 49 4C 45。只要看到开头四个字节是 FILE，那恭喜你，已经找到了一条file entry。

技王数据恢复

第二步：在$MFT里精确查找某个文件的file entry

现在我们手上有了一整块$MFT区域，里面密密麻麻全是文件记录。那怎么只找出目标文件呢？两个常用方法： www.fixhdd.cn

按文件名搜索：WinHex的“搜索”→“查找文本”，输入文件名（注意大小写，NTFS是大小写敏感的）。因为每一条file entry里都有文件名属性（属性类型0x30），只要文件没被彻底覆盖，理论上能搜到。但注意：如果文件名是中文，记得选Unicode（UTF-16LE）编码，我经常看到有人用ASCII搜中文，搜到崩溃。
按父目录引用号搜索：这个稍微进阶一点。比如你知道文件所在目录的MFT记录号（比如目录索引为5），那么你可以搜索该记录号的小端序字节（8字节）。但一般不推荐新手这么做，容易搞混字节序。

记得有一次，客户要恢复一个叫“2024年报.pptx”的文件，我用WinHex扫描全盘，搜“2024年报”怎么都搜不到。后来换思路，先找它的上一级目录“工作报告”的file entry，然后在目录索引里找到了该文件的引用号（类似0x0000000000001A3F这样的）。再用这个引用号去$MFT里直接跳转到第0x1A3F个记录。结果发现——那个文件的file entry还在，文件名属性已经被标记为“已删除”。对，这就是我们常说的“文件被删除了，但MFT记录还没被覆盖”的情况。碰到这种，直接右键→“复制”→“复制整个扇区”就能把原始数据导出来。winhex查找file entry 的精髓其实就是通过文件名或引用号定位未删除的记录，然后提取数据。

技王数据恢复

注意事项：那些容易翻车的小细节

从事数据恢复十几年，我见过太多人在这一步折腾半天。大概列几个常见问题： www.fixhdd.cn

$MFT可能不连续。如果分区使用时间久了，$MFT会碎片化。这时候单纯的顺序跳转可能只看到一部分。需要利用$MFTMirr（MFT镜像）或者直接用WinHex的“文件恢复”功能里的“重建MFT”选项。技王数据恢复的工程师在处理大容量分区时，习惯先做一个完整镜像，然后专门用脚本扫描碎片，再重组——这个流程虽然慢，但稳。
File Entry的序列号（Sequence Number）。每条记录都有一个序列号，每次文件被创建或删除都会递增。如果你的目标文件被删除后又创建了同名文件，那么旧的file entry的序列号不匹配，直接提取可能会报错。这时候需要手工比较“序列号”字段（偏移0x10处的2字节），如果与$MFT索引里的期望值不一致，说明这条记录已经被“废弃”了，但数据内容可能还在——只是不能通过常规方式恢复。
属性列表（Attribute List）。如果文件特别大或者属性特别多，可能一条file entry装不下，会使用“属性列表”属性指向其他记录。这种时候单纯找一条file entry是不够的，还得把所有扩展记录找出来。WinHex的“解析NTFS”视图其实能自动把属性列表展开，但很多人只用十六进制看，就忽略了。

一个有点意思的案例：被覆盖的MFT也能找回一部分？

说个去年的事。有个客户的SSD突然蓝屏，重装系统后才发现旧分区不见了。我用WinHex直接偏移扫描，发现$MFT的前几百条已经被重装系统时覆盖了。一开始觉得没戏，但后来发现后部还有大量“残余”file entry。于是我用winhex查找file entry 功能，不是搜名字，而是搜特征——比如常见文档的固定签名（PDF的 25 50 44 46 或者DOCX的 50 4B 03 04），因为文件的数据区可能还在，即便MFT记录丢了，通过数据区的特征倒推也能找到部分。后来真找回来七八个PDF和Office文件。虽然不能用目录树恢复了，但至少文件内容出来了。这种“逆向定位”思路，其实还是基于对file entry结构的理解。如果你能识别出文件数据流（Run List）的编码方式，甚至可以直接把碎片拼起来。技王数据恢复

小贴士：如果你看到一条file entry中数据运行（Data Run）字段的起始簇号是0（空），或者长度不对，那很可能这个文件已经被彻底删除了，或者文件本身是稀疏文件。这时候就需要更专业的工具来处理。技王数据恢复的内部工具里有一个“X-Resolver”模块，专门用来处理非连续的数据运行，但这技术细节就不展开说了，有点复杂。

总结：WinHex查找File Entry的真正价值

回头再看，所谓的 winhex查找file entry 并不只是背诵几个偏移量。它要求你对NTFS的文件记录格式（从偏移0x00到0x3FF的每个字段含义）有直觉性的理解。比如：

偏移0x00～0x03：FILE签名，确认是有效记录。
偏移0x10～0x11：序列号，用于版本控制。
偏移0x14～0x15：第一个属性的偏移。
偏移0x30～0x37：父目录的文件引用号（包含序列号+记录号）。
各种属性：0x10（$STANDARD_INFORMATION）、0x30（$FILE_NAME）、0x80（$DATA）等等。

当你彻底掌握了这些，WinHex就不再是一个单纯的十六进制编辑器，而是一个能让你“看见”文件系统骨骼的透视仪。每次查找到一条关键的file entry，你都能读出那个文件的前世今生——它是何时创建的、一次修改是几秒前、数据到底在磁盘哪个位置。

再多说一句：winhex查找file entry 是一项基础但至关重要的技能，它能帮你绕过文件系统正常接口，直接从底层拿到元数据。无论你是初学数据恢复，还是已经做了五年的工程师，这个技能永远时。如果你在实操中遇到卡点，不妨回到最原始的方法：手工比对结构，多看几个例子。相信我，当你成功地从一堆看似杂乱的十六进制码里提取出完整文件时，那种成就感，比用一键恢复工具爽多了。