WinHex数据恢复：MBR到FAT32目录项的扇区定位与交叉校验-北京尧图网络

简介这份PPT课件围绕“用WinHex定位磁盘文件中第一个扇区”展开面向数据恢复、系统调试、安全分析初学者及需要补充磁盘底层知识的IT从业者帮助读者建立从物理磁盘到分区、文件系统再到具体文件的定位思路。课件以1个pptx文件交付压缩包约1.1MB内容以操作截图配合结构说明为主重点梳理MBR与分区表、DBR、FAT32根目录区、目录项字段以及簇号与扇区换算等关键概念并保留从磁盘选择到扇区跳转的完整演示线索。目前已有79人学习适合课堂讲解、自学复盘或实验参考。读者可借助其中的图解与标注理解分区起始扇区、FAT表大小、根目录首扇区及文件起始簇号之间的关系掌握在WinHex中核对偏移与扇区位置的思路对需要排查文件位置、辅助数据恢复或开展取证入门练习的人群这份课件能提供较直观的结构化参照。1. 从“文件就在这跳过去却是空的”说起数据恢复和取证分析里最常见的一幕镜像挂上去目录里明明看得见文件用 WinHex 按算出来的扇区号跳过去不是一片 00就是落进了另一个分区的地盘。翻车点通常不在工具而在坐标系——你算的那个号是分区内部的相对扇区还是整块盘上的绝对扇区。操作系统把存储切成“物理磁盘 → 分区 → 文件系统”三层每层各有自己的编号起点WinHex 的跳转框只认你当前打开的那一层。这篇笔记拆的就是这条链路从 0 号扇区 MBR 的分区表读出起始 LBA进 DBR 取 FAT32 的保留扇区数、FAT 表个数和大小推出根目录起始扇区再顺着 32 字节目录项抠出起始簇号最后换算成物理扇区。做数据恢复、镜像取证、或者单纯想搞明白“文件到底躺在盘上哪个位置”的运维和开发都能照着跑一遍。2. 对齐坐标系MBR 分区表里的 16 字节怎么读磁盘的第 0 号扇区LBA 0是整个盘的入口WinHex 打开物理磁盘后默认就停在这里。它的正式名字是 MBR主引导记录但真正跟找文件相关的只有中间那 64 个字节。很多人第一次读分区表会愣一下为什么 0x1BE 往后每 16 个字节里起始扇区号是“反着”的这是小端序低字节在前用十六进制编辑器看是一串颠倒的数字换成数据解释器里的 32 位无符号整数就正常了。搞不清这一点后面所有偏移都会连锁错位。2.1 0 号扇区那 512 字节的三段结构MBR 扇区固定 512 字节结构极其规整三段拼起来刚好 512偏移范围长度内容说明0x000 – 0x1BD446 字节引导代码有的是全 0有的是引导程序机器码0x1BE – 0x1FD64 字节分区表4 个表项每项 16 字节0x1FE – 0x1FF2 字节结束标识固定 0x55AA用来判断这真是 MBR四个分区表项按顺序排列第 i 个i 从 0 开始的起始偏移是0x1BE i * 16。单个 16 字节表项的字段分布是这样的表项内偏移长度字段取值示例01 字节引导标志0x80 活动分区0x00 非活动13 字节起始 CHS 地址老式寻址基本可忽略41 字节分区类型0x0B/0x0C 为 FAT320x07 为 NTFS/exFAT53 字节结束 CHS 地址同上可忽略84 字节起始 LBA 扇区号小端 uint32本例为 2048124 字节分区总扇区数小端 uint32找文件第一个扇区真正要用的就是 8 这 4 个字节。12 只用来判断这个分区有多大别读串了——把大小当起始扇区读是新手最常见的第一次翻车。提示如果 4 处的分区类型字节读到 0xEE说明这块盘是 GPT0x1BE 处只是保护性 MBR真正的分区表在 LBA 1 的 GPT 头里得换一套解析路径。本文的流程只适用于 MBR 分区表动手前先确认类型。2.2 WinHex 里把起始 LBA 读出来操作路径不复杂但要按顺序走中途选错对象后面全白搭启动 WinHex菜单选 Tools → Open Disk部分版本在 File 菜单下弹出磁盘列表。在 Physical Media 一栏里选整块物理磁盘不要选下面 Logical Drives 里的分区。这一步选错后面看到的 0 号扇区就是分区的 DBR不是 MBR。打开后光标默认在 0x00000000也就是 0 号扇区。菜单 View → Show → Data Interpreter 调出数据解释器面板它会实时显示光标所在位置的 8/16/32/64 位解释结果。把光标点到 0x1C6即0x1BE 8数据解释器里的 “32 bit unsigned” 一行就是这个分区的起始 LBA本例读到 2048。如果不想手点也可以直接用脚本把这一步固化下来用导出的镜像跑比对结果更放心import struct IMG disk.img # WinHex 里 Tools - Open Disk 之后另存的整盘镜像 with open(IMG, rb) as f: mbr f.read(512) # 结束标识校验不对说明这不是 MBR可能是 GPT 保护性 MBR 或文件不是整盘镜像 if mbr[510:512] ! b\x55\xaa: raise SystemExit(0x55AA 校验失败开头不是 MBR) for i in range(4): base 0x1BE i * 16 # 第 i 个分区表项的起始偏移 ptype mbr[base 4] # 分区类型 if ptype 0: continue # 空表项直接跳过 start_lba, sectors struct.unpack_from(II, mbr, base 8) print(f分区{i 1}: 类型0x{ptype:02X} 起始LBA{start_lba} 扇区数{sectors})这段脚本干的事和 WinHex 里手点完全等价先校验 0x55AA 确认扇区身份再按 16 字节步长遍历四个表项用II一次解出起始 LBA 和总扇区数两个小端 uint32。base 8是起始 LBAbase 12是大小这两个偏移写反了不会报错只会给你一个看着挺像那么回事的错数字所以脚本里用元组解包显式区分比手点更不容易看错行。跑出来的结果应该和你在数据解释器里看到的 2048 一致对不上就别往下走了先查是不是打开了分区而不是整盘。3. 进分区看 DBRFAT32 三个参数决定根目录在哪拿到起始 LBA 2048下一步是跳到这个位置——注意此时 WinHex 打开的是物理磁盘跳转框里输入的是绝对扇区号直接填 2048 就对了。这一扇区是分区自己的 0 号扇区叫 DBRDOS Boot Record也有人叫引导扇区或 BPB。它是文件系统的“说明书”每簇几个扇区、有几份 FAT 表、每份 FAT 表多大、根目录从哪开始全在里面。FAT32 的很多计算错误根子都是在这一步用了“经验值”而不是实际读出来的值。3.1 DBR 关键偏移速查DBR 里字段多但找文件只需要盯住其中几个。下面是 FAT32 场景下必须用到的偏移其他字段可以不管偏移长度字段本例取值用途0x003 字节跳转指令EB 58 90判断引导扇区特征0x038 字节OEM 名称MSWIN4.1 之类格式化工具标识0x0B2 字节每扇区字节数512扇区与字节换算0x0D1 字节每簇扇区数16簇→扇区的乘数0x0E2 字节保留扇区数3234FAT 表起点分区内相对0x101 字节FAT 表个数2通常是 2双备份0x1C4 字节隐藏扇区数2048应等于分区起始 LBA交叉校验用0x244 字节每 FAT 表扇区数14767FAT32 专属FAT16 这里是 00x2C4 字节根目录起始簇号2一般就是 20x528 字节文件系统类型FAT32文本可直接肉眼确认0x1C 处的隐藏扇区数是白送的校验位它记录“本分区之前有多少个扇区”正常情况下应该正好等于 MBR 分区表里的起始 LBA。本例读到 2048对得上说明分区表没读错、跳转也没跳错位置。这个检查花不了十秒但能挡掉一大半“数值看着对、其实跳错分区”的情况。3.2 根目录起始扇区的算式与一次完整验算FAT32 的布局是固定的三段式保留区 → FAT 表区 → 数据区。保留区在最前面紧跟着是 N 份 FAT 表N 就是 0x10 处的 FAT 表个数FAT 表之后就是数据区而根目录在 FAT32 里被当成数据区的第一个簇簇号 2所以根目录起始扇区就是数据区起点。公式只有一行根目录起始扇区分区内相对保留扇区数 FAT表个数 × 每FAT表扇区数代入本例3234 2 × 14767 3234 29534 32768。这个 32768 是分区内部的相对编号不是整盘上的绝对位置。这里有个容易想当然的地方3234 这个保留扇区数偏大常见的 FAT32 保留扇区是 32 或 36。不同格式化工具、不同簇大小会给出不一样的值所以永远以 DBR 里读到的为准别拿经验值硬套——套进去算出来的根目录位置会整体偏移跳过去大概率是一片空白。下一步换算成绝对扇区加分区起始 LBA绝对扇区分区起始LBA 分区内相对扇区 2048 32768 34816如果这时候你在 WinHex 里打开的是物理磁盘却直接跳到 32768看到的多半是另一个分区的内容或者一片零——因为 32768 这个号在整盘坐标系里对应的是别的地方。原文里那句“跳转到 32768 扇区什么都没有”坑就在这。补上 2048 跳到 34816才能看到根目录区的第一个扇区里面应该能认出卷标test以及test1、demo.txt这些目录项的名字片段。看到这些说明整条链路到目前为止是对的。4. 32 字节目录项从文件名一路走到起始簇号到了根目录区接下来的活是“在一堆二进制里认出文件”。FAT32 的目录本质上是一个数组每 32 字节一个目录项按顺序排下去遇到第一个字节为 0x00 的项就表示后面全空、目录结束。每个目录项描述一个文件或子目录里面既有名字也有它数据区第一个簇的簇号——这个簇号就是通向你想要的“文件第一个扇区”的最后一把钥匙。4.1 目录项的字段布局与属性位32 字节的字段排布如下重点是 26 和 20 这两个簇号位置项内偏移长度字段说明011 字节短文件名8.3前面补空格第 0 字节 0xE5 表示已删除111 字节属性0x10 目录0x20 归档0x0F 长文件名131 字节创建时间十分之一秒精度字段142 字节创建时间162 字节创建日期182 字节最后访问日期202 字节起始簇号高 16 位先读这个别丢222 字节最后修改时间242 字节最后修改日期262 字节起始簇号低 16 位284 字节文件大小字节目录项此处为 0属性字节是筛选的关键。一个文件如果名字超过 8.3 格式会在正式目录项前面挂若干个长文件名项属性固定为 0x0F这些项里的“簇号”字段是校验和与字符编码不是真正的簇号读进去就会得到一个荒谬的数字。所以遍历目录时必须先按属性过滤只处理非 0x0F 的项。4.2 簇号拼装与簇到扇区的换算簇号是 32 位的但在目录项里被拆成两段存低 16 位在 26高 16 位在 20。拼装公式起始簇号低16位高16位 × 65536本例中test目录的目录项算出来簇号是 6demo.txt的目录项算出来是 7。有了簇号还要转成扇区而簇号和扇区之间隔着“数据区起点”和“簇从 2 开始编号”这两件事分区内相对扇区保留扇区数 FAT表个数 × 每FAT表扇区数 (簇号 - 2) × 每簇扇区数绝对扇区分区起始LBA 分区内相对扇区代入test簇 6每簇 16 扇区32768 (6 - 2) × 16 32768 64 32832加上 2048 得绝对扇区 34880。代入demo.txt簇 732768 (7 - 2) × 16 32768 80 32848加 2048 得 34896。这个 34896 就是文件内容的第一个扇区。WinHex 里还有一条捷径双击打开这个分区逻辑驱动器在跳转对话框里可以直接输入簇号工具会自己按 DBR 参数换算。输入 6 跳到分区内 32832输入 7 跳到 32848。但要注意这时你处在“分区视图”显示的是相对编号切回物理磁盘视图后同一位置要显示成 34880 和 34896。原文里那个“34880 16 34896”的算法本质就是用相邻簇线性排列这一点走捷径——test目录项和demo.txt目录项在同一扇区目录项所在扇区加上一个簇的扇区数正好落到下一个簇。这招快但只在这两个对象的簇号连续时才成立。用脚本把这段逻辑固化下来比在十六进制里一个个数偏移可靠import struct IMG disk.img PART_LBA 2048 # MBR 分区表读到的起始 LBA def read_sector(f, lba, count1): f.seek(lba * 512) # 按 512 字节扇区定位 return f.read(512 * count) with open(IMG, rb) as f: dbr read_sector(f, PART_LBA) bytes_per_sector struct.unpack_from(H, dbr, 0x0B)[0] sectors_per_cluster dbr[0x0D] reserved struct.unpack_from(H, dbr, 0x0E)[0] num_fats dbr[0x10] fat_size struct.unpack_from(I, dbr, 0x24)[0] data_start reserved num_fats * fat_size # 分区内相对扇区 print(f每簇扇区{sectors_per_cluster} 数据区起点{data_start}) root read_sector(f, PART_LBA data_start, sectors_per_cluster) for off in range(0, len(root), 32): # 32 字节一个目录项 entry root[off:off 32] if entry[0] 0x00: # 目录结束标记 break attr entry[11] if attr 0x0F or entry[0] 0xE5: # 跳过长文件名项和已删除项 continue name entry[0:11].decode(gbk, errorsreplace).strip() hi struct.unpack_from(H, entry, 20)[0] lo struct.unpack_from(H, entry, 26)[0] cluster lo hi * 65536 # 低16位高16位 * 65536 sector PART_LBA data_start (cluster - 2) * sectors_per_cluster print(f{name:12} 簇号{cluster:6} 绝对扇区{sector})脚本里的每个参数都直接来自 DBR没有一个是写死的0x0B给出每扇区字节数0x0D给出每簇扇区数0x0E和0x24配合算出数据区起点0x10决定乘几份 FAT 表。目录项解析部分按 32 字节步长走遇到首字节 0x00 立即跳出——这一步不能省否则会把后面的空白当成一串名为乱码的“文件”。属性过滤放在读簇号之前0x0F和0xE5两种项都跳过前者是长文件名碎片后者是删除标记两种都会给出无效簇号。跑出来的demo.txt应该正好是 34896和手算一致如果不一致先去核对sectors_per_cluster是不是 16这个值读错会让所有簇号换算整体偏。5. 避坑五个让我重算一遍的扇区错位这条链路上每一步都能算错而且错得都很安静——不报错只是给你一个看起来合理的数字。下面五条是我在镜像分析里反复撞到的按“现象 → 原因 → 解决”记下来遇到类似症状可以直接对号。5.1 跳到根目录一片空白或者跳进了别的分区现象按公式算出相对扇区 32768在 WinHex 物理磁盘视图里跳过去内容完全不认识甚至能看到另一个分区的目录。原因混用了两套坐标系。32768 是“分区内相对扇区”物理磁盘视图要求“绝对扇区”两者差了分区起始 LBA 这一段。解决任何时候在物理磁盘视图下跳转都先加上分区起始 LBA。判断自己处在哪个视图看 WinHex 标题栏——写着 Physical Media 之类的是整盘视图写着具体分区的是逻辑视图。养成习惯每次跳转前默念一遍“这是绝对还是相对”。5.2 簇号算出来的扇区整体偏了两簇现象按公式起始扇区簇号 × 每簇扇区数算跳过去总是差 32 个扇区每簇 16 的话内容看着像文件的尾部而不是头部。原因FAT32 的数据区从簇号 2 开始编号簇 0 和簇 1 是保留的簇 0 是介质描述簇 1 是脏标志不落在数据区里。解决换算一律写(簇号 - 2)。这个 -2 是所有 FAT 系列文件系统换算的固定动作漏掉它整条链就平移两簇。5.3 簇号算出来是几百万明显不合理现象目录项解析出一个巨大的簇号按它换算出的扇区早就超出分区范围了。原因两个可能。一是把偏移 20 的高 16 位当成了完整簇号忘了乘 65536二是把 20 和 26 的位置记反了拿高 16 位当低 16 位用。解决固定读法先读 26 得低 16 位再读 20 得高 16 位簇号低高 × 65536。写脚本时变量名直接叫hi和lo别用cluster1、cluster2这种看不出顺序的名字。算完再做个合理性检查簇号乘每簇扇区数不应该超过分区总扇区数。5.4 目录里冒出一堆名字像乱码的“文件”现象遍历根目录输出了一长串奇怪的条目簇号也不正常。原因没过滤长文件名项。名字超过 8.3 格式的文件前面会挂一到多个属性为 0x0F 的目录项这些项的第 26 字节处放的是校验和不是簇号。解决读属性字节 11等于 0x0F 直接continue。同时把首字节为 0xE5 的已删除项也跳过这类项的簇号可能已经被回收重用拿来分析会指向错误的扇区。5.5 每簇扇区数用了默认值所有结果整齐地偏移现象手动跳簇号得到的位置和公式算出来的对不上但两者内部又各自自洽。原因凭经验默认“每簇 8 扇区”或“每簇 16 扇区”而实际分区的簇大小跟格式化时的参数、分区容量都有关。簇越大同样簇号对应的扇区跨度越大误差会随簇号线性放大。解决每簇扇区数只从 DBR 的 0x0D 读读完打印出来确认一次。同理保留扇区数、FAT 表个数、每 FAT 表扇区数也都不许写死全部从 DBR 取。本例这三个值是 3234、2、14767换一块盘就全变。6. 进阶用交叉校验把扇区号钉死单条路径算出来的扇区号错了也不会自己喊疼所以最后一步我一般做交叉校验用三个互相独立的信息源互相印证。第一个是目录项路径也就是前面那套 MBR → DBR → 目录项 → 簇号的算法得到demo.txt在 34896。第二个是 FAT 链表路径簇 7 这一项在 FAT 表里的位置是保留扇区 × 512 7 × 4字节FAT32 每项 4 字节读出来如果是一个大于 0x0FFFFFF7 的值说明这就是文件的最后一个簇如果是别的簇号说明文件不连续后面还挂着别的簇。拿 FAT 链上的簇号去比对目录项给的起始簇号两条路径必须指向同一个起点对不上就说明有一边读错了偏移。第三个校验点是 DBR 里的隐藏扇区数0x1C与 MBR 分区表里的起始 LBA 是否相等这个在第三章提过但值得在收尾时再跑一遍因为它一次性校验了“分区表读对了没有”和“DBR 跳对了没有”两件事。三个校验点全部吻合再去看扇区内容心里才有底。校验路径读取位置期望结果目录项路径根目录区 32 字节步长簇 7 → 绝对扇区 34896FAT 链表路径FAT1 起始 7 × 4 字节结束标记或后续簇号DBR 交叉校验DBR 偏移 0x1C等于 2048如果还想再稳一层可以用文件结束位置反推文件大小在目录项 28 处4 字节起始扇区 ceil(文件大小 / 512)应该落在文件最后一个扇区附近且不超过(簇号 - 2 1) × 每簇扇区数划定的范围。这个方法对小于一个簇的小文件特别管用因为小文件只占一个簇首扇区算对了整个文件的字节范围就是连续可读的。从那次把一个 4GB 镜像的根目录算错 2048 个扇区、白读了两小时之后我每次动 WinHex 都强制走一遍这套流程先看标题栏确认是整盘还是分区视图再核对 0x1C 和分区表是否一致最后用脚本把目录项和 FAT 链各跑一遍对答案。三步加起来不到一分钟但能挡掉后面绝大多数返工。希望帮到你。本文还有配套的精品资源点击获取

WinHex数据恢复：MBR到FAT32目录项的扇区定位与交叉校验

相关推荐

中美智能驾驶系统实测对比：本土化与算法优化成关键

Agent-Reach：度量智能体可达边界，从Demo到生产的关键

智能驾驶测试技术解析与行业格局变化

更多资讯

格式即协议：重构LLM智能体交互的结构化范式

AI原生数据库选型：AlloyDB与Cloud SQL实战指南

云计算实践：从基础架构到自动化运维全解析

网络创业实战指南：从避坑到盈利的全流程解析

【Python】实例方法

Representation-Space MMD：对齐语义空间的模型校准新范式

今日更新

基于YOLOv11的石油泄漏智能检测系统开发实践

AI行业变局：合规、Mod化与上下文管理的实战启示

计算机视觉与AI原生应用融合的技术实践

本周精选

防幻觉智能体架构：电源硬件设计中的大模型编排与工具化实践

OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析

全国计算机二级C语言真题PDF高效刷题指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？