Office OLE复合文档二进制格式“深潜”

1. Office OLE复合文档的前世今生

第一次用010 Editor打开.doc文件时，我被满屏的十六进制代码震撼到了——这哪是文档，分明是加密电报！其实这就是Office 97-2003时代沿用至今的OLE复合文档，它的二进制结构就像俄罗斯套娃，层层嵌套却暗藏玄机。

D0 CF 11 E0这个魔法数字是它的身份证，看到这个文件头就像发现古墓的洛阳铲，意味着我们挖到了OLE结构的入口。与现在常见的.docx这种"压缩包套XML"的OpenXML格式不同，老版Office文档是实打实的二进制结构，宏病毒最喜欢藏在这种文件里。有次我分析一个恶意文档，宏代码就藏在FAT表指向的第42号扇区，像地铁逃票的乘客混在人群中。

复合文档本质上是个微型文件系统，它的三大核心组件堪比操作系统：

• 文件头：512字节的"总控制台"，记录着扇区尺寸、FAT表位置等关键参数
• FAT表：相当于文件的"地铁线路图"，记录着数据扇区的跳转关系
• 目录流：就像图书馆的索引卡片，每个128字节的目录项对应一个存储对象

2. 解剖OLE文件头：512字节的密码本

用010 Editor打开样本文件，前512字节就是文件头的领地。这里每个字段都是通关文牒，我常备着CheatSheet对照解析：

import struct with open('malware.doc','rb') as f: header = f.read(512) sector_size = 2 ** struct.unpack('<H', header[30:32])[0] # 通常为512 fat_count = struct.unpack('<I', header[44:48])[0] # FAT表数量 first_dir_sector = struct.unpack('<I', header[48:52])[0] # 目录起始扇区

最容易被恶意利用的是扇区分配表（DIFAT），它控制着整个文件的寻址逻辑。曾有个APT样本故意构造异常的DIFAT链，导致解析器陷入死循环。安全研究时要特别注意这些字段的校验：

• 文件标识符必须为D0CF11E0A1B11AE1
• FAT表数量不得超过109
• 扇区大小只能是512、1024等2的幂次方

3. FAT表寻踪：数据版的"藏宝图"

FAT表是复合文档最精妙的设计，它用4字节的扇区ID串联起离散存储的数据。解析时要注意三个特殊标记：

• 0xFFFFFFFE：表示链式结尾
• 0xFFFFFFFD：表示DIFAT扇区
• 0xFFFFFFFC：表示FAT扇区本身

写解析脚本时我踩过这样的坑：某样本把FAT表项设为0xFFFFFFFF，导致工具误判为坏簇。正确的解析流程应该是：

1. 从文件头获取首个FAT扇区位置
2. 读取该扇区的128个FAT项（512字节/4字节）
3. 遇到DIFAT标记时跳转到下一个FAT扇区
4. 根据链式关系重组数据流

def parse_fat(header, file_data): fat_sectors = [] difat = [] # 解析文件头中的DIFAT for i in range(0, 109*4, 4): sector = struct.unpack('<I', header[76+i:80+i])[0] if sector == 0xFFFFFFFF: break difat.append(sector) # 收集所有FAT扇区 for sector in difat: pos = 512 + sector * 512 fat_sectors.append(file_data[pos:pos+512]) return fat_sectors

4. 目录流挖掘：128字节的档案室

目录流是解析OLE文档的"黄金矿脉"，每个Directory Entry包含：

• 对象名称（64字节Unicode）
• 对象类型（1表示存储，2表示流）
• 起始扇区ID
• 对象大小

有次分析钓鱼文档，发现目录流里藏着名为"恶作剧.txt"的流对象，实际却是VBA宏代码。解析目录流的关键步骤：

1. 根据文件头定位首个目录扇区
2. 遍历每个128字节的目录项
3. 通过左子树/右子树指针构建存储树
4. 特别检查"\x05SummaryInformation"等特殊流

def parse_directory(first_sector, fat, file_data): entries = [] current_sector = first_sector while current_sector != 0xFFFFFFFE: pos = 512 + current_sector * 512 sector_data = file_data[pos:pos+512] for i in range(0, 512, 128): entry = sector_data[i:i+128] if entry[0] == 0: break # 空条目 name = entry[0:64].decode('utf-16le').strip('\x00') obj_type = entry[66] left_sibling = struct.unpack('<I', entry[68:72])[0] right_sibling = struct.unpack('<I', entry[72:76])[0] start_sector = struct.unpack('<I', entry[116:120])[0] size = struct.unpack('<Q', entry[120:128])[0] entries.append((name, obj_type, start_sector, size)) current_sector = fat[current_sector] return entries

5. 实战恶意文档分析

去年分析某鱼叉邮件附件时，发现攻击者玩了个花招：他们在FAT表中构造循环引用，导致OffVis工具崩溃，但010 Editor却能正常解析。后来发现是工具对DIFAT校验不严导致的，这种对抗分析的手法越来越常见。

典型恶意文档特征：

1. 存在异常的存储对象命名（如"..\..\evil.dll"）
2. 目录流中存在隐藏的VBA项目
3. FAT表存在交叉链接或循环引用
4. 扇区实际大小与文件头声明不符

用Python自动化检测的代码片段：

def detect_malicious(doc_path): with open(doc_path,'rb') as f: data = f.read() header = data[:512] # 检查魔数 if not header.startswith(b'\xD0\xCF\x11\xE0\xA1\xB1\x1A\xE1'): return "非OLE复合文档" # 检查扇区大小 sector_size = 2 ** struct.unpack('<H', header[30:32])[0] if sector_size not in [512,1024,2048,4096]: return "异常扇区大小" # 检查目录流中的可疑对象 dir_entries = parse_directory(...) for name,_,_,_ in dir_entries: if 'vba' in name.lower() and name != 'VBA': return f"发现隐藏VBA对象:{name}" return "基础检查通过"

6. 解析工具链的军火库

工欲善其事必先利其器，我的工具箱里常备这些神器：

• 010 Editor：二进制查看利器，配合OLE模板能自动解析结构
• OffVis：微软官方工具，适合快速验证解析结果
• olefile：Python库，适合自动化分析
• oledump：专门提取OLE中的流对象

对于特殊样本，我会组合使用这些工具。比如先用olefile验证基础结构，再用010 Editor手动分析异常扇区。有个检测宏代码的实用命令：

oledump.py -s A -v malware.doc | grep "PROJECT"

遇到加密文档时，可以尝试用OfficeCat工具爆破密码。曾有个样本用"infected"作为密码，堪称最诚实的恶意文档。