业内新闻

WinHex脚本查找偏移量数据：边判断边修正的真实恢复记录

你有没有遇到过这样的情况：打开一块有问题的硬盘镜像，从头到尾都是乱码，只有少数几个扇区藏着关键的文件头？手动翻找？光一个4TB盘就能让你怀疑人生。这时候，winhex脚本查找偏移量数据就是救命稻草——但脚本写错一个字节，结果可能完全偏离。今天我就把两年前一个案例的原始思路翻出来，带着“修正”和“跳跃”的痕迹，聊一聊这个技术。 www.fixhdd.cn

一、为什么需要“脚本查找偏移量”？——故障判断与思路

先说一个挺坑的情况：上次接到一块西数硬盘，客户说删了200多个视频，但做了深度格式化。我用WinHex加载镜像后发现，文件系统已经被破坏，目录树全空了。但视频文件通常有固定的魔数（比如MP4的ftyp box），如果能通过脚本扫描整个磁盘，找到特定偏移量上的特征数据，就能定位文件起始位置，然后把碎片拼接起来。技王数据恢复

注意，我这里没说“查找整个扇区”，而说的是“特定偏移量”。因为很多文件头并不在扇区开头，比如某个RAID系统的数据块偏移了512字节的某个位置。手动找？不可能。脚本就变成了主力工具。 www.fixhdd.cn

1.1 边想边写：从“暴力扫描”到“条件偏移”

最早我写过一个很傻的脚本：从0到磁盘尾，每次读一个扇区，判断前4字节是否为“00 00 00 18”？呃，等等，那其实是MP4的一个box size字段，但偏移不对。后来我意识到，我需要的不是固定的扇区偏移，而是变偏移量——比如每个512字节的块里，我想要检查从第50字节开始的数据。这时候就需要用WinHex脚本里Read和Position指令配合循环。技王数据恢复

具体说，脚本里你可以这样写：技王数据恢复

Set FPos 0Loop While FPos < FileSize(0)// 移动到当前扇区起始+偏移量0x32（50字节）Move FPos + 0x32// 读取4字节Read 4// 判断是否等于0x66747970（ftyp）If Equal(4, 0x66747970)WriteLog "找到偏移量位置：" + FPos + 0x32Endif// 前进到下一个扇区Set FPos FPos + 512EndLoop

www.fixhdd.cn

但这个脚本有个重大缺陷：如果磁盘有坏道，Read指令会卡死。我们后来在技王数据恢复的工单里，加上了错误跳过逻辑——这就是所谓的边判断边修正。

www.fixhdd.cn

二、核心步骤：写一个靠谱的“偏移量查找脚本”

这里我把步骤拆开，但顺序可能会乱——因为我写脚本时经常从中间开始写，然后再补前面的初始化。你按下面的逻辑走，但别死板。

技王数据恢复

2.1 先确定你要找的“偏移量”是什么

是固定偏移？比如每个物理扇区偏移0x200处有一个签名。还是相对偏移？比如在一个512字节的块内，你只想查第128字节起的8个字节。搞清楚这个后，才能决定循环粒度是512还是4096。

一个实际例子：恢复西数硬盘的DBR备份

有次客户需要找到DBR备份（通常在DBR之后6个扇区或某个特定LBA上的偏移位置），但因为分区表被清空，我只能通过搜索“EB 58 90”（BPB签名）来定位。BPB签名有时候会被其他数据干扰，我加了条件：仅在扇区两个字节是“55 AA”时才算有效。这其实就是winhex脚本查找偏移量数据加上复合条件的变种。

2.2 写循环主体：小心指针移动的坑

WinHex脚本的Move指令会改变文件指针，但如果你在循环内部调用了Read，读取后指针会自动前进。很多新手踩坑：读完之后忘记把指针复位，导致下一次循环偏移错乱。我的习惯是每次循环开始都重新定位：Move FPos，然后再Move + 偏移量。

Set FPos 0Loop While FPos < FileSize(0)Move FPos + 0x200   // 先到扇区开头+0x200位置Read 4// 判断...Set FPos FPos + 512 // 注意这里FPos已经因为读取变了？不，FPos是变量，没变，但文件指针变了// 下一轮必须用Move FPos重新定位EndLoop

看我上面注释，我故意写了个逻辑错误然后修正——实际代码里，Set FPos FPos + 512计算的是下个起始地址，但Move时不需要再加偏移量，直接在循环顶部写Move FPos + 0x200即可。这就是工程里的“先犯错再改”。

2.3 输出与日志：别只靠屏幕

脚本运行可能几个小时，如果每次都弹出对话框你会疯。用WriteLog指令把结果写入文本文档，包括偏移量、扇区号和查找的特征值。然后事后用文本编辑器过滤。

三、实战案例：从2000个文件里抓出那个MP4

去年夏天一个影视工作室的NAS挂了，RAID5两块盘离线。我们用技王数据恢复方案，先做了完整镜像。然后在镜像上跑脚本查找MP4的偏移特征：每个MP4文件的开始处有一个“00 00 00 18 66 74 79 70”的痕迹（box size + ftyp）。因为文件系统碎片严重，很多文件的四个字节并不在扇区开头，而是在偏移0x10或0x20处。这时候普通搜索功能速度慢，而且容易漏。

我写的脚本如下（跳跃记录）：

设置扇区大小512字节，每次读取扇区。
偏移量0x00到0x1FF循环检查？不不，那样效率太低。我换了个思路：先读扇区前32字节，用Find指令找特征，但Find不支持条件偏移。于是改用手动偏移：从0x00, 0x10, 0x20, 0x30...直到0x1E0，每次读4字节判断。
发现一个匹配后，记录偏移，然后继续往后走——因为一个好的MP4文件头可能跨扇区？其实不会，MP4的box通常是连续的。

脚本跑了一个半小时，找出了1897个匹配点，其中很多是假阳性（比如某些ZIP文件头也类似）。我通过加上了后续字节的校验：检查第8字节到第12字节是否为“6D 70 34”（即“mp4”的ASCII），把假阳性降低到3%。这个加校验的步骤实际上是“边判断边修正”的典型例子——一开始没想到，跑完发现太多错误才加的。

四、注意事项：那些让你抓狂的细节

写脚本时，有几点必须记住——我吃过的亏列出来：

4.1 大小端问题

WinHex里Read出来的数据默认按小端序？不对，它是按字节顺序读的，判断时要用Equal指令配合十六进制常数。比如你读取4字节，得到的是A,B,C,D，而你要匹配的魔数是0x66747970（大端），那么数据在内存里其实是70 79 74 66。千万别直接把读出来的和0x66747970比较，要用Equal(4, 0x7079746C)之类的变换，或者用字符串比较。我建议用Compare指令+字节序列，比如Compare(4, "66 74 79 70")。

4.2 循环效率与硬盘响应

如果一个扇区读一次，对于2TB硬盘要访问约39亿次。如果脚本里每读一次都要移动位置，速度很慢。优化方法：Read一个大块（比如64KB），然后在内存里用脚本内部的Find功能？不行，脚本的Find只能搜索整个文件，不能用内存块。折中：每读出一个扇区，用Position和Read配合，但别读太多字节，512字节足够了。

，如果硬盘有坏道，建议在脚本里加OnError Resume或者Try...Catch（WinHex脚本有Try语句吗？我记得有，但不是很稳定）。我们技王数据恢复的脚本模板里会先做Try读，出错则跳过该扇区并记录日志。