简介：这是一份面向Delphi开发者、逆向工程学习者与遗留系统维护人员的反编译参考资料，围绕Delphi编译生成的DLL与OCX控件展开，帮助读者在没有原始源码的情况下理解组件结构、定位兼容性问题并开展调试与安全分析。压缩包为rar格式，整体约532KB，上游未提供有效文件清单与类型明细，故具体文件数量暂无数据可依，但仍可作为反编译流程的入门与工具认知材料。资源已有1008人学习下载，说明其在Delphi逆向这一相对小众的方向上有一定参考价值。内容涉及符号解析、反汇编、源码重构与调试支持等环节，读者可据此建立从机器指令到函数、类、变量识别的分析路径，理解反编译结果为何只能近似还原源码，并注意编译优化带来的信息丢失。需要提醒的是，反编译他人代码可能触及版权与法律边界，使用前应确认授权范围并尊重原作者知识产权，适合具备一定Pascal与Windows组件基础的读者按需查阅。
1. Delphi 反编译工具落地：一个 exe 加半份文档，能还原到什么程度
接手一套跑了十几年的老业务系统，交付物只有一个 exe、一堆 dcu 和半份没人看得懂的说明，这在维护岗上不算稀奇。这时候能救场的往往就是 Delphi 反编译工具：它不像纯 C 程序那样只能对着汇编干瞪眼，Delphi 编译器把大量类型信息、窗体定义、published 方法名留在了二进制里，工具能顺着这些线索把界面、组件树、事件绑定甚至一部分函数名还原出来。但它也不是后悔药——变量名、注释、局部逻辑的原始写法回不来，被{$M-}关掉 RTTI 的单元同样回不来。这里拆的是这套工具包在真实维护场景里怎么落地：先判编译器版本，再抠窗体资源，然后读代码段，最后说清哪些地方注定还原不了、怎么验证自己没读错。
注意：反编译只在两种前提下动手——你自己拥有版权的二进制，或者拿到书面授权的审计目标。给别人加壳的商用软件做逆向，跟技术无关，是另一码事。
2. 编译痕迹识别：用节区名和入口点锁定 Delphi 版本
拿到一个 PE 文件，绝大多数人的第一反应是直接扔进工具等伪代码。我的习惯是先花五分钟做体检：这一步不产出任何"代码"，但决定了后面所有参数的取值方式——32 位还是 64 位、镜像基址是多少、资源表在哪个节区、有没有被壳动过手脚。跳过这一步直接反编译，后面的偏移量、地址换算、字符串解码会连环翻车。
2.1 为什么先看节区表，而不是直接按反编译
Delphi 和 C/C++ 编译出来的 PE 在结构上最直观的差别是节区命名。相当一部分版本用的是CODE、DATA、BSS、.idata、.tls、.rdata、.reloc、.rsrc这一套非标准名字，而不是链接器默认的.text/.data。看到CODE加DATA的组合，基本可以锁定 Borland 系工具链。较新的构建也可能回归标准名，所以节区名只是证据链的第一环，不能单独下结论。
第二个体征是导入表。Delphi 程序倾向静态链接运行时库，导入表通常很薄，集中在kernel32、user32、advapi32、oleaut32、ole32、comctl32这几项上，而文件体积却不小——大量逻辑在文件内部自己实现。这种"导入少、代码多"的比例，和典型的 MSVC 程序很不一样。
第三个是入口点位置。老版本 Delphi 的入口不是用户写的main，而是运行时单元的初始化序列：一段循环遍历单元表、逐个调用初始化过程，然后才跳到WinMain。入口点落在CODE节开头附近、前面有一小段固定的初始化循环，是很强的指纹。
提示：这三条命中两条以上再动手，比凭文件图标猜编译器靠谱得多。命不中也不代表不是，先按未知处理，别硬套参数。
2.2 一个不依赖第三方库的 PE 体检脚本
工具包自带的解析模块当然能用，但我一般先用一段纯标准库脚本独立跑一遍，用来交叉验证工具显示的镜像基址和节区偏移是不是对的。这段脚本不引任何外部依赖，复制出去就能跑，也方便塞进批处理里对一整个目录做筛查。
# pecheck.py —— 只用标准库，先给文件做一次体检 import struct, sys from pathlib import Path # Delphi/Borland 系常见的非标准节区名 SECTION_FINGERPRINT = {"CODE", "DATA", "BSS", ".idata", ".tls", ".rdata", ".reloc", ".rsrc"} def parse_pe(buf): lfanew = struct.unpack_from("<I", buf, 0x3C)[0] # DOS 头里的 PE 偏移 if buf[lfanew:lfanew + 4] != b"PE\0\0": raise ValueError("不是 PE 文件") coff = lfanew + 4 _machine, nsec = struct.unpack_from("<HH", buf, coff) opt_size = struct.unpack_from("<H", buf, coff + 16)[0] # 可选头长度 opt = coff + 20 is64 = struct.unpack_from("<H", buf, opt)[0] == 0x20B # 0x10B=PE32, 0x20B=PE32+ entry_rva = struct.unpack_from("<I", buf, opt + 16)[0] ib_off = opt + (24 if is64 else 28) # ImageBase 在两种头里偏移不同 image_base = struct.unpack_from("<Q" if is64 else "<I", buf, ib_off)[0] dd = opt + (112 if is64 else 96) # 数据目录起点 rsrc_rva, rsrc_size = struct.unpack_from("<II", buf, dd + 2 * 8) # 索引 2 = 资源表 secs, tab = [], opt + opt_size for i in range(nsec): o = tab + i * 40 name = buf[o:o + 8].rstrip(b"\0").decode("latin-1") vsize, vaddr, rsize, rptr = struct.unpack_from("<IIII", buf, o + 8) secs.append({"name": name, "vaddr": vaddr, "vsize": vsize, "raw": rptr, "raw_size": rsize}) return {"is64": is64, "entry": entry_rva, "image_base": image_base, "sections": secs, "rsrc": (rsrc_rva, rsrc_size)} def rva2off(pe, rva): """RVA 转文件偏移，后面所有资源解析都靠它""" for s in pe["sections"]: span = max(s["vsize"], s["raw_size"]) if s["vaddr"] <= rva < s["vaddr"] + span: return s["raw"] + (rva - s["vaddr"]) raise ValueError("RVA 不在任何节区内: 0x%X" % rva) if __name__ == "__main__": pe = parse_pe(Path(sys.argv[1]).read_bytes()) print("位数: %s 入口RVA: 0x%X 镜像基址: 0x%X" % ("PE32+" if pe["is64"] else "PE32", pe["entry"], pe["image_base"])) names = set() for s in pe["sections"]: names.add(s["name"]) print("%-10s RVA=0x%08X VSz=0x%08X Raw=0x%08X" % (s["name"], s["vaddr"], s["vsize"], s["raw"])) hit = names & SECTION_FINGERPRINT print("指纹节区命中 %d 个: %s" % (len(hit), ",".join(sorted(hit)) or "无"))逻辑上有三处值得说明。ImageBase的偏移在 PE32 和 PE32+ 下差了 4 个字节（28 对 24），这是 64 位脚本最容易写错的一行；数据目录的起点也差了 16 个字节（96 对 112），资源表是索引 2，按dd + 2*8取。rva2off用max(VirtualSize, SizeOfRawData)做区间判断，是因为有些加壳或特殊构建的节区虚拟大小小于原始大小，只按 VirtualSize 算会漏掉尾部数据。
参数上唯一要按需改的是SECTION_FINGERPRINT：如果你的目标全是新版本构建，标准节区名占多数，可以把它放宽成"命中任意大节区即可"；反过来如果筛出来一堆UPX0/UPX1这种名字，先别急着反编译，去第 5 章看脱壳那一条。
2.3 版本判定的三条证据链
判断大版本（老版 32 位 / 新版 32 位 / 新版 64 位）直接影响三件事：字符串头是 8 字节还是 12 字节、指针宽度、以及调用约定。我一般按这三条顺序核：
| 证据 | 观察点 | 能定到什么粒度 |
|---|---|---|
| 节区名组合 | CODE/DATA/BSS还是.text/.data/.rsrc | 区分老工具链与新工具链 |
| 资源里的版本类条目 | 是否存在许可证信息类 RCDATA 条目 | 确认是 Delphi 系而非 C++Builder |
| 系统单元函数签名 | 已知库函数开头的字节序列 | 缩小到具体大版本区间 |
第一条给的是粗分类，第二条只回答"是不是"，真正能缩小到版本区间的是第三条：拿几个高频运行时函数（字符串拼接、内存分配、异常抛出）的入口字节序列去比对，命中率比看节区名高得多。工具包里通常带一份签名库，我在实际使用中会先用它跑一遍，再用脚本核对签名命中的地址是否落在CODE节内——落在节区外的命中一律当误报处理。
这一步做完，你应该能写出这样一行结论：PE32+、基址 0x140000000、入口位于.text起始、资源表在.rsrc、疑似新版 Delphi 编译。后面所有脚本的is64分支、地址换算、字符串解码参数，全部由这一行决定。
3. 窗体资源还原：把 DFM 从 RCDATA 里完整抠出来
如果只能保留工具的一个功能，我会留窗体还原。原因很实际：业务代码看汇编能猜个七八成，界面布局靠猜基本没戏——几十个控件的坐标、标题、事件绑定，人工对着截图复原的成本远高于读代码。而 Delphi 把窗体以二进制 DFM 的形式整块塞进资源段，类名、组件名、属性值、事件方法名全在里面，这是它相比其他编译器最大的"信息红利"。
3.1 Delphi 的 RTTI 为什么让反编译占便宜
Delphi 的对象模型默认给published段生成运行时类型信息：类名、父类、属性名、属性类型、以及 published 方法的名称与地址，全部以结构化数据存在二进制里。设计期需要这些信息来做对象检查器，运行期的属性编辑器、流化机制也依赖它们，所以除非显式用{$M-}关掉，否则这些信息一定在。
这带来两个直接收益。其一，组件树可以完整重建：DFM 里每个object块都带类名和实例名，父子关系靠嵌套表达，属性按名值对存储。其二，事件绑定可以直接对上代码：OnClick = Button1Click这种条目里的方法名，配合 published 方法表里"名字 → 地址"的映射，能一步跳到对应函数的入口，省掉在几千个函数里瞎找的时间。
代价也要说清楚：private/protected成员没有 RTTI，局部变量名和类型信息在编译期就丢了，泛型实例化后的名字会被改写。所以"还原出可编译的源码"这个预期从一开始就不成立，能做到的是"还原出可读、可改、可对照调试的结构"。
3.2 递归遍历资源目录，取出 RCDATA 里的窗体
资源段是三层树：类型 → 名称 → 语言，每一层都是IMAGE_RESOURCE_DIRECTORY加一组 8 字节条目，条目偏移的最高位标记"这是子目录还是数据"。窗体固定挂在类型 10（RCDATA）下，名称一般就是窗体类名的大写形式。下面这段脚本把整棵树走完，把每个候选块导出来，并且处理了 zlib 压缩的情况。
# dfm_extract.py —— 递归资源目录，导出 RCDATA 里的窗体块 import struct, zlib, sys from pathlib import Path from pecheck import parse_pe, rva2off # 复用上一节的体检脚本 RT_RCDATA = 10 def read_dir(buf, pe, base_rva, dir_rva): """返回 [(标签, 是否子目录, 相对资源基址的偏移)]""" off = rva2off(pe, dir_rva) named, ids = struct.unpack_from("<HH", buf, off + 12) out = [] for i in range(named + ids): e = off + 16 + i * 8 key, target = struct.unpack_from("<II", buf, e) label = key if key & 0x80000000: # 命名项：UTF-16 字符串 so = rva2off(pe, base_rva + (key & 0x7FFFFFFF)) n = struct.unpack_from("<H", buf, so)[0] label = buf[so + 2: so + 2 + n * 2].decode("utf-16-le") out.append((label, bool(target & 0x80000000), target & 0x7FFFFFFF)) return out def dump_dfm(buf, pe): base_rva = pe["rsrc"][0] got = [] for rtype, is_dir, off in read_dir(buf, pe, base_rva, base_rva): if rtype != RT_RCDATA or not is_dir: continue for rname, is_dir2, off2 in read_dir(buf, pe, base_rva, base_rva + off): if not is_dir2: continue for _lang, is_dir3, off3 in read_dir(buf, pe, base_rva, base_rva + off2): if is_dir3: continue de = rva2off(pe, base_rva + off3) data_rva, size = struct.unpack_from("<II", buf, de) start = rva2off(pe, data_rva) blob = buf[start: start + size] if blob[:2] in (b"\x78\x9c", b"\x78\xda"): # zlib 压缩流 blob = zlib.decompress(blob) if blob[:4] == b"\xFF\x0A\x54\x50": # FF 0A 'TP'，DFM 魔数 got.append((rname, blob)) return got if __name__ == "__main__": raw = Path(sys.argv[1]).read_bytes() pe = parse_pe(raw) for name, blob in dump_dfm(raw, pe): out = Path("dfm") / ("%s.bin" % name) out.parent.mkdir(exist_ok=True) out.write_bytes(blob) print("%-18s %6d 字节 头部: %s" % (name, len(blob), blob[:8].hex()))要点在三个地方。key & 0x80000000判断的是"名称字段是字符串还是整数 ID"，窗体名走的是字符串分支，必须按 UTF-16 读长度前缀，直接当 ASCII 读会得到空串。target & 0x80000000判断的是"指向子目录还是指向数据条目"，两层含义都压在同一批 8 字节条目里，写错一个位就会走进死胡同。DFM 的魔数是FF 0A后跟TPF0四个 ASCII 字符，只校验前两字节就够了，校验四字节反而容易把带填充的样本漏掉。
参数层面，RT_RCDATA = 10是固定的；zlib 头我按78 9C（默认压缩）和78 DA（最高压缩）判，实际样本里也见过78 01（最低压缩），如果你的样本解压报错，把判断放宽成"首字节 0x78 且第二字节通过(b0<<8|b1) % 31 == 0校验"更稳。
3.3 二进制 DFM 到文本：类型字节与结构校验
导出的.bin是二进制 DFM，得转成文本才能读。工具包一般自带这个转换，转换后的文本长这样：以object 实例名: 类名开头，以end收尾，中间是缩进嵌套的子对象和属性 = 值对。如果拿不到工具，也可以按二进制格式自己读：每个值前面有一个类型字节，标识整数、字符串、集合、二进制数据等，对象块以固定标记开头、后面跟两个 Pascal 短字符串（类名、实例名）。
我判断转换是否成功，不看工具有没有报错，而看四条结构性证据：
- 每个
object都有配对的end，缩进层级与嵌套深度一致； - 第一行类名以
T开头，且与资源条目名大体对应； - 事件属性（
On开头的那些）的值要么为空，要么是一个合法的 Pascal 标识符； - 集合类属性（
Anchors、Options、Style）后面的方括号能配对。
任何一条不成立，八成是窗体继承没处理：派生窗体在资源里只存增量属性，父类属性在父窗体的 DFM 里，必须沿继承链往上合并。这一点工具通常会自动做，但如果你的样本里出现"某控件明明在界面上有、DFM 里却找不到"的情况，先怀疑继承链断了，而不是怀疑资源没抠干净。
3.4 事件绑定怎么对上代码地址
DFM 里的OnClick = Button1Click只是一个名字，把它变成地址要靠 published 方法表：编译器为每个 published 方法生成一条紧凑记录，内容是该方法的入口地址和一个以长度字节开头的短字符串名字。表的位置可以通过类的 VMT 找到，VMT 里有一个字段指向方法表，遍历到地址为 0 或名字长度异常时结束。
这里有个必须记住的差异：32 位下地址字段是 4 字节，64 位下是 8 字节，而短字符串紧跟其后、没有对齐填充。同一份数据用错宽度去读，得到的名字会是乱码。我的做法是先按 4 字节读，如果连续三条记录的名字都不像标识符，再按 8 字节重读一遍，取看起来正常的那一组——这算不上优雅，但在没有版本签名库的情况下最省时间。
对上地址之后，把事件名写回伪代码的函数头（void __fastcall TForm1_Button1Click(...)这种形式），整份还原产物的可读性会明显上一个台阶：你不再面对sub_40A1C0，而是面对一个能对应到界面上某个按钮的函数。
4. 代码段还原：字符串头、方法表与伪代码可信度分级
窗体拿完，剩下的是逻辑。这一章说三件事：怎么把字符串常量干净地捞出来、函数名还能从哪里补、以及最关键的——伪代码里哪些部分可以信、哪些必须验证。
4.1 字符串头的两种布局与提取脚本
Delphi 的字符串不是裸的字符数组，前面带管理头，而且头长度随版本变化。老版本（Delphi 7 那一代）的AnsiString是 8 字节头：4 字节引用计数 + 4 字节长度，后面才是字符数据，末尾补一个#0。2009 之后统一成 12 字节头：2 字节代码页 + 2 字节单元素字节数 + 4 字节引用计数 + 4 字节长度，元素字节数在 Unicode 字符串上是 2，长度字段表示的是字符个数而不是字节数。
这个差异是字符串提取翻车的头号原因。用"扫描连续可打印 ASCII"的土办法，在 Unicode 程序上会得到一堆被00隔断的单字符碎片；用 8 字节头去解 12 字节头的数据，读出来的长度字段其实是引用计数，长度会离谱到直接越界。按头字段解码才对：
# str_scan.py —— 按 Delphi 字符串头布局提取常量 import struct, sys from pathlib import Path from pecheck import parse_pe CODECS = {1200: "utf-16-le", 65001: "utf-8", 936: "gbk"} def scan_strings(buf, lo, hi, min_len=4): out, i = [], lo while i < hi - 12: cp, elem, refc, ln = struct.unpack_from("<HHII", buf, i) # 12 字节头 if elem in (1, 2) and min_len <= ln <= 8192: body_end = i + 12 + ln * elem # 注意：长度是字符数，要乘元素字节数 if body_end <= hi and refc < (1 << 20): # 引用计数不合理说明不是头 enc = CODECS.get(cp) or ("utf-16-le" if elem == 2 else "latin-1") try: s = buf[i + 12: body_end].decode(enc) except UnicodeDecodeError: s = None if s and sum(c.isprintable() for c in s) / len(s) > 0.9: out.append((i, s)) i = body_end # 命中后跳过整块，避免重复 continue i += 1 return out if __name__ == "__main__": raw = Path(sys.argv[1]).read_bytes() pe = parse_pe(raw) for s in pe["sections"]: if s["name"] not in ("CODE", "DATA", ".text", ".data", ".rdata"): continue for off, text in scan_strings(raw, s["raw"], s["raw"] + s["raw_size"]): print("0x%08X %s" % (off, text[:80]))body_end = i + 12 + ln * elem这一行是全脚本的关键，elem取 1 还是 2 决定了字符串边界对不对；refc < (1 << 20)这个约束是用来过滤误命中的——真正的引用计数不会超过几百万，而随机的头字段经常是个天文数字。CODECS表按需补，中文环境里936很常见，遇到1252之外的代码页直接加一行就行。
跑完这一遍，中文界面里的提示语、SQL 片段、配置键名基本都能出来。业务逻辑里最值钱的信息往往就在这些字符串里，比读两百行汇编快得多。
4.2 published 方法表：函数名的唯一来源
除了事件绑定，方法表还能补出大量函数名——凡是published声明的方法、属性读写器，名字都在里面。我的做法是把整张表 dump 成"地址 → 名字"的 CSV，然后拿它去给反汇编视图里的地址打标签。表的遍历长度不好判定，实用做法是设一个上限（比如 512 条）加上三条终止条件：地址落不到代码节内、名字首字节大于 64、名字里出现不可打印字符。
补出来的名字有两类价值。一类是直接可用的，比如SetAmount、LoadConfig这种语义明确的；另一类是线索型的，比如一堆GetXxx/SetXxx成对出现，说明这块是属性访问器，真正的业务逻辑在它调用的私有方法里，顺着调用关系往下走就能找到。
剩下的无名函数只能靠交叉引用和字符串邻近性推。这一点没有捷径，我一般把"引用了某条特定字符串"的函数标出来，因为错误提示、日志文本往往是定位业务分支最快的锚点。
4.3 伪代码可信度分级表
工具生成的伪代码不能一视同仁地信。我按信息来源给它分了三档，读的时候心里有数：
| 还原产物 | 依赖的信息 | 可信度 | 使用建议 |
|---|---|---|---|
| 节区、入口、资源表 | PE 头 | 高，可复现 | 当事实用，可写进结论 |
| 窗体类名、组件树、布局 | DFM 资源 | 高 | 可直接重建界面 |
| published 方法名与地址 | RTTI 方法表 | 高 | 作为函数命名依据 |
| 字符串常量 | 字符串头 + 代码页 | 中高 | 编码判断错了会乱码，需抽样核 |
| 函数边界、参数个数 | 调用约定 + 栈帧分析 | 中 | 仅作参考，重要函数需动态验证 |
| 局部变量类型 | 无来源，纯推断 | 低 | 不要写进交付文档 |
| 变量名、注释、业务语义 | 无 | 无 | 只能人工补 |
一条血泪经验：不要拿着低可信度的产物去写维护文档。函数边界判断错一次，后面整条调用链的分析全歪，返工成本比一开始就老实做动态验证高得多。
5. 避坑排查：五类翻车现场的现象、原因与处置
这一章全部来自实际踩过的坑，按"现象 → 原因 → 解决"写。遇到工具行为反常时，先在这五条里对号入座，比在群里问"为什么反编译不出来"效率高。
5.1 把 DCU 当源码丢进去，出来只有汇编
现象：把
本文还有配套的精品资源，点击获取
