简介面向嵌入式与逆向工程开发者的F9DASM反汇编工具包针对6800、6801、6802、6803、6808、6809及6301、6303、6309系列处理器设计支持Intel Hex、Motorola S09、Flex9 Binary、纯二进制等输入格式并可通过加载信息文件辅助反汇编有效解决无指令表指引时代码识别困难的问题。包体共20个文件压缩后约128KB涵盖C语言核心源码、Visual Studio工程文件vcproj、dsp、dsw、sln、Makefile、说明文档及示例压缩包目录结构清晰方便在不同平台编译、调试与二次扩展。目前累计已有118人学习下载适合需要分析经典8位处理器固件、研究反汇编实现原理或开发相关工具链的中高级开发者。代码继承自Arto Salmi的C内核并经过多年维护与扩展阅读源码可系统了解二进制加载、指令集映射、信息文件驱动的反汇编流程以及配套格式转换工具的协作方式学习价值较高。 很多搞逆向或嵌入式调试的朋友都遇到过这种场景手里捏着一串十六进制字符比如6800680168096309既不知道它从哪里来也不知道它想干什么。我上周就碰到这么一串靠着常用的轻量级反汇编器 f9dasm花了不到两分钟就把它“拆卸”成了三条汇编指令。这篇东西不讲空泛的理论就顺着这个 8 字节样本把你从拿到字节流到最终确认指令的全过程走一遍。刚入门的新手可以把它当案例看老手也可以看看我踩过的几个对齐和大小端的坑。1. 拿到“乱码”后先别急着反汇编1.1 6800680168096309 首先是一段字节流6800680168096309看上去是一串没有规律的十六进制数字但它不是文本而是机器码的十六进制表示。每两个十六进制字符对应一个字节所以这段串拆开之后是这样的68 00 68 01 68 09 63 09一共 8 个字节。这里有个很容易忽略的点十六进制串在文件里通常以 ASCII 文本形式存在比如你用cat看一个.txt文件看到的是68 00 68 01...这样的字符但真正要喂给反汇编器的是“二进制值”0x68 0x00 0x68 0x01...而不是字符6 8。很多新手第一次操作就是把字符串直接当文件内容传给反汇编器结果工具提示输入不合法或者解出来一堆莫名其妙的指令。这一步的处理方式后面实操部分我会专门写。那怎么判断它到底是不是机器码我的习惯是先用xxd或hexdump看它的二进制形态再用file命令猜文件类型。如果这段串是抠出来的内存片段、固件 dump、或者调试器里导出的 instruction bytes那基本可以确定是机器码。6800680168096309这种连续出现68开头、后面跟立即数的模式在 x86 指令集里非常典型68就是push imm16的操作码。1.2 反汇编的本质查表、解码、拼长度很多人以为反汇编就是把十六进制“翻译”成汇编听起来像查字典实际没那么简单。x86 指令集是变长指令集一条指令短则 1 个字节长则 15 个字节而且指令边界不是固定切出来的。你从第一个字节开始解和从第二个字节开始解得到的指令序列可能完全不同。这就好比一句话没有标点符号从不同的位置断句意思可能天差地别。一个反汇编器内部至少要做三件事。第一是查操作码表比如遇到0x68查表得知是push imm16那么后面两个字节就是立即数。第二是解码寻址方式遇到0x01知道这是ADD r/m16, r16但目标操作数到底是寄存器、内存还是带偏移的内存需要看紧随其后的 ModRM 字节有时还要再看 SIB 字节和 disp 位移。第三是合成指令长度把操作码、ModRM、SIB、disp、imm 的长度加起来确定这条指令占几个字节才能知道下一条指令从哪里开始读。f9dasm 这类工具做的核心工作就是把这三层逻辑做成一张表和一个状态机。输入一段字节流它从指定地址开始逐个字节推进最终输出带地址、带字节、带汇编文本的清单。理解这个原理之后你就能明白为什么反汇编结果有时候会“不准”不是工具算错了而是它用的指令集表、寻址模式、默认地址宽度和你预期的不同。1.3 为什么这种活不适合纯手算拿6800680168096309来说如果你手算第一字节68好办查表是push imm16后面两个字节00 68是小端序立即数所以第一条指令是push 0x6800占 3 个字节。接下来从偏移 3 开始是01 68 09这就要拆 ModRM 了0x68二进制是01 101 000mod01 表示带 8 位位移的内存寻址reg101 是 BPrm000 是 BXSI后面还得读一个位移字节0x09所以第三条指令占 4 个字节。就这么两条已经牵涉到操作码表、ModRM 解码、位移合成三个环节稍不留神就会错位。关键是变长指令集一旦某一步边界切错了后面全乱。手算也许能应付 8 个字节但面对几十 KB、几 MB 的固件人肉解码完全不现实。这也是我必须用 f9dasm 这类工具的原因它快、可重复、能批量处理而且不会因为注意力分散而在第 17 条指令上犯低级错误。2. f9dasm 的选择与输入准备2.1 为什么是 f9dasm市面上的反汇编工具不少objdump、ndisasm、radare2、Ghidra都能干这个活。但我平时做快速验证尤其是像这种只有 8 个字节的小样本最常用的是 f9dasm。原因很简单它启动快、参数少、输出干净。我给它一个二进制文件指定架构和位宽它直接吐汇编文本没有一堆无关格式信息方便再接管道做二次处理。objdump -D在反汇编 ELF、PE 这类带格式的文件时很顺手但对付裸二进制片段你得手动加-b binary -m i386参数又多又绕。ndisasm轻倒是轻但只认 x86 系遇到 ARM 或其它架构还得换工具。Ghidra是重型逆向平台适合大规模分析整个固件为一个字节串启动它多少有点杀鸡用牛刀。f9dasm 给我的感觉更像一把瑞士军刀不 fancy但贴身。对比一下我用过的几个工具的适用场景工具适合场景不足f9dasm裸字节流快速反汇编脚本友好大型项目分析能力弱ndisasmx86 裸文件反汇编不支持多架构objdump -DELF/PE 等带格式文件裸二进制要额外加参数radare2交互式探索、补丁学习曲线陡Ghidra大型固件/程序全量逆向启动慢、资源占用高2.2 把十六进制串变成输入文件写十六进制串转二进制文件我习惯用xxd一行命令搞定echo 6800680168096309 | xxd -r -p sample.binxxd -r是反向转换把十六进制文本还原成二进制-p表示纯十六进制转储格式不带偏移和 ASCII 列。执行完可以用wc -c确认文件大小wc -c sample.bin正常情况应该输出8 sample.bin。如果你得到的字节数不对先检查字符串里有没有多余的空格、换行xxd -r -p遇到空白其实会自动忽略但某些从网页复制的文本里可能混入了不可见字符这时用tr -d \n过滤一下更稳妥echo 68 00 68 01 68 09 63 09 | tr -d \n | xxd -r -p sample.bin这一步很多人会忽略参数里写没写-p效果差别很大。没有-p时xxd默认期望的是带偏移地址的标准 hexdump 格式不是裸十六进制串。2.3 反汇编前的参数设置f9dasm 的命令行参数在不同版本里略有差异但核心就三样架构、位宽、输入文件。我手上这个版本的用法是f9dasm -a x86 -b 16 -f sample.bin-a指定指令集架构-b指定位宽-f指定输入文件。位宽这个参数很容易被新手忽略但它直接决定了反汇编器把指令当 16 位还是 32 位还是 64 位来解码。同样是68 00 68在 16 位模式下是push 0x6800在 32/64 位模式下则是push dword 0x680068的一部分含义完全不同。我故意先把样本按 16 位模式跑后面再讲怎么验证这个选择是否合理。如果你的 f9dasm 版本支持从标准输入读取还能把转换和反汇编串成一条管道echo 6800680168096309 | xxd -r -p | f9dasm -a x86 -b 16 -这样连临时文件都省了适合快速试验不同参数组合。3. 实操拆卸 68006801680963093.1 跑一次 f9dasm看原始输出命令执行后f9dasm 的输出大概是这样的00000000 68 00 68 push 0x6800 00000003 01 68 09 add word ptr [bxsi0x9], bp 00000006 63 09 arpl cx, cx三行三条指令8 个字节全部解完。每行的第一列是偏移地址第二列是原始机器码字节第三列是对应的汇编文本。这里有几个信息值得注意第一条指令从偏移 0 开始占 3 个字节所以第二条指令从偏移 3 开始第二条指令占 4 个字节第三条从偏移 6 开始第三条占 2 个字节正好到偏移 8 结束整个 8 字节样本被消费完毕没有任何残留。如果输出的最后一行偏移加起来对不上文件大小说明反汇编器在某个位置遇到了无法识别的操作码或者它尝试把残留字节硬解成某条指令这时候就要警惕了。对齐是反汇编结果可信与否的基本前提。3.2 逐条拆解Push、ModRM、ARPL第一条push 0x6800机器码68 00 68。0x68是push imm16的操作码立即数从后续两个字节读小端序排列所以00 68拼出来是0x6800不是0x0068。这一步是大小端最容易出错的地方我见过有人因为这里看反了非说工具有问题其实工具没错是立即数的高低位读反了。第二条add word ptr [bxsi0x9], bp机器码01 68 09。0x01是ADD r/m16, r16的操作码目标是第一个操作数也就是内存单元[bxsi0x9]源是寄存器 BP。这里的关键在 ModRM 字节0x68拆成二进制看位段值含义mod01带 8 位位移的内存寻址reg101源寄存器 BPrm000基址组合 BXSImod01 意味着后面还要读一个字节作为位移就是0x09。如果你在反汇编输出里看到[bxsi]没有位移但原始字节里明明还有个09那大概率是工具把它吞进了下一条指令说明长度合成出了问题通常是操作码表选错或者位宽设错。第三条arpl cx, cx机器码63 09。0x63是ARPL r/m16, r16的操作码ModRM0x09二进制是00 001 001mod00 表示寄存器直接寻址reg001 是 CXrm001 也是 CX所以两个操作数都是 CX。这条指令在实模式下很少出现它主要用于保护模式下的段选择子校验所以看到它时我第一反应是这段字节可能不是普通的 16 位实模式代码而是某个保护模式模块的片段或者是从上下文中间截出来的。三条指令连起来看猜测一下这个片段的行为先压入立即数0x6800然后往[bxsi0x9]这个内存位置加上 BP再对 CX 做选择子校验。当然仅凭这三条指令很难还原完整的程序意图但至少能确定它不是一个完整的函数入口更像是一个函数中段或数据结构附近的代码片段。反汇编能帮你把字节变成指令但要把指令变成逻辑还需要结合上下文。3.3 面对“奇怪指令”怎么办反汇编解出arpl这种在常规代码里很少见的指令时不要第一时间怀疑工具坏了。我的处理顺序是先确认位宽和架构对不对再试换一个起始偏移比如从第 2 个字节开始反汇编看看会不会解出更合理的序列最后才是考虑工具本身有没有 bug。拿这段样本来说如果我从第 2 个字节开始解得到的是00 68开头00是ADD r/m8, r80x68是 ModRM解出来大概率是一堆更奇怪的操作这种结果通常说明真实指令起点就是我一开始选的偏移 0。在 x86 变长指令集里正确的起点往往会解出较短、语义连贯的指令序列而错误的起点经常会解出访问奇怪地址、异常操作码组合的“垃圾指令”。这个经验在排查固件偏移问题时非常有用。4. 交叉验证与代码片段排查4.1 用 Capstone 交叉验证f9dasm 给出的结果我通常不会直接采信会再找一个独立的反汇编引擎验证一遍。我这里用的是 Capstone它是一套开源反汇编框架社区活跃支持架构多。验证脚本很简单from capstone import * CODE bytes.fromhex(6800680168096309) md Cs(CS_ARCH_X86, CS_MODE_16) for i in md.disasm(CODE, 0): print(0x%x:\t%s\t%s % (i.address, i.mnemonic, i.op_str))运行输出0x0: push 0x6800 0x3: add word ptr [bx si 9], bp 0x6: arpl cx, cx三条指令和 f9dasm 的结果完全一致地址偏移也对得上。这里 Capstone 的地址是从 0 开始的你也可以传一个虚拟基址比如0x1000让它按常见的内存布局显示偏移方便和调试器里的地址对照。交叉验证的价值在于两个独立实现的操作码表和解码逻辑如果得出一致结果那基本可以确认不是工具层面的偶发问题而是这段字节确实按照 x86-16 规则解出了这些指令。当然Capstone 也不是绝对权威但至少能提供一个独立参照系。4.2 常见问题速查表实操中我踩过不少坑整理成一张表基本覆盖了大部分“反汇编结果不对劲”的情况现象可能原因处理方法文件大小和预期不符十六进制串里有空格/换行用tr -d \n清理后再转输出全是乱指令位宽或架构指定错误改-b 16/32/64换-a架构立即数看起来反了大小端序没理解对小端下00 68是0x6800指令数量偏多或偏少起始偏移不对尝试从第 2/3 个字节开始解反汇编到一半停止遇到未知操作码确认指令集扩展比如 SSE/AVX地址不是从 0 开始工具默认虚拟基址设置查参数--base或-v4.3 一段可复用的排查流程如果是第一次拿到陌生字节流我建议按下面这个流程走能省不少时间先用xxd查看原始字节确认长度排除文本编码问题。用file命令猜一下文件类型判断是裸二进制还是带格式文件。确定最可能的架构和位宽。如果有硬件平台信息最好没有的话从 x86-16 开始试因为 16 位模式最容易识别push、mov这类高频操作码。跑一次反汇编看输出指令是否合理高频指令是否常见、长度是否消费完整、有没有大量异常操作码。如果结果不合理换位宽、换起始偏移逐一排除。用 Capstone 或另一个反汇编器做交叉验证。最后结合指令语义和上下文判断这段代码的角色。这套流程我基本已经形成肌肉记忆了。说句实话反汇编本身不复杂难的是在错误上下文里坚持用错误参数解读结果。大部分所谓“反汇编器不准”的抱怨最后查下来都是参数或者输入数据出了问题。我个人在实际操作中的体会是反汇编工具始终只是辅助真正值钱的是你对指令集的理解和对上下文的判断。f9dasm 把字节变成指令只花了几毫秒但判断这些指令合不合理、该用什么模式解靠的还是经验。最后再分享一个小技巧遇到不确定的字节串不要只解一次试着从每个可能的偏移都解一遍然后把几条结果放在一起比正确的起点通常会在最显眼的位置跳出来。本文还有配套的精品资源点击获取
