拿到一个来路不明的二进制文件时第一反应永远是“先跑起来看看它到底要干什么”。但直接在真机跑太冒险丢进虚拟机又重得离谱尤其是当目标还是 ARM、MIPS 这类非主流架构的固件片段时传统调试器根本无从下手。CEmu 这类多架构汇编模拟器恰好就是为这个场景设计的它不启动操作系统只模拟 CPU 和一小块内存把代码一段段喂进去边执行边观察寄存器、内存和反汇编结果。这篇文章我会从选择模拟器的底层逻辑开始讲清楚 CEmu 的定位、怎么搭环境、怎么做一次完整的恶意软件/二进制文件动态分析再把我踩过的坑和排查思路一并整理出来适合刚接触逆向、想做样本行为分析又不想被 QEMU 全家桶劝退的朋友。1. CEmu 到底解决了什么问题——模拟器选型背后的逻辑1.1 为什么动态分析要选汇编级模拟器而不是直接开虚拟机很多刚接触逆向的朋友会有一个疑问分析恶意软件Win10 虚拟机加 Procmon 不就行了能看进程行为、看网络请求、看文件操作为什么要绕一大圈去用 CEmu 这种只能模拟 CPU 的“半个计算器”。这个问题的答案得看分析的到底是什么。虚拟机适合分析完整、成型的恶意软件比如一个能运行的 EXE它需要操作系统、API、文件系统、网络栈。但实际逆向中你手里拿到的往往不是完整样本而是一段从 PDF 里提取出来的 JavaScript 解码后的 shellcode、一个固件里剥离出来的二进制 blob、一段只支持 ARM 指令集的引导加载代码。这些东西放到虚拟机里根本起不来因为它没有宿主环境、没有加载器、没有入口点上下文。还有一类样本非常现实带有反虚拟机检测。你开 VMware、VirtualBox 跑它它检测到设备特征直接跳转到正常逻辑你一整天都等不到恶意行为。汇编级模拟器回避了这两个问题。CEmu 这种工具只负责模拟指令执行不向样本暴露设备型号、系统版本、进程列表等特征。样本以为自己跑在裸机或某个嵌入式环境里实际上所有指令都在模拟器里被翻译执行。你要做的就是告诉它“内存从哪里开始、栈指针指到哪、从哪个地址开始执行”然后一步步观察它干了什么。1.2 CEmu 的定位站在 Unicorn 肩膀上的图形化分析界面从技术上说CEmu 的核心执行引擎是 Unicorn。Unicorn 是一个 CPU 模拟框架它能翻译执行 x86、x86-64、ARM、ARM64、MIPS、SPARC 等多架构指令但它本身没有界面也没有“方便人类操作”的工作流。你调用它的 Python/C API 时要自己管内存映射、寄存器、断点和写嵌入式系统代码差不多。CEmu 做的事情是把 Unicorn 封装成一整套能直接上手的分析工具。它自带图形界面左侧是内存和段的信息中间是反汇编窗口右侧是寄存器状态下方是运行控制区。你加载一个二进制文件后可以像用调试器一样单步执行、下断点、读写内存、修改寄存器。同时它还暴露了核心 API可以脱离界面写 Python 脚本做批量分析。如果做横向对比大概是这样工具层级优点局限QEMU 用户态/全系统全系统/用户态模拟能运行完整程序支持系统调用重速度慢反调试容易被影响UnicornCPU 指令模拟多架构、轻量、API 灵活无界面所有工作都得自己写代码Ghidra 模拟器静态分析内嵌模拟和反编译结果结合紧密定位偏静态分析脚本有一定上手门槛CEmuCPU 指令模拟 GUI开箱即用多架构适合样本代码分析不模拟操作系统 API复杂样本需配合其他工具从实际分析场景看CEmu 的市场定位很清晰它不追求“跑起一个完整的恶意程序”而是追求“精确观察一段可疑代码的执行路径”。你要研究蠕虫的 main 函数行为可能不如丢进虚拟机高效但如果目标是提取一段 ROP 链、定位混淆解码循环、分析一个只支持 MIPS 的路由器固件漏洞利用代码CEmu 比 QEMU 和 Ghidra 都顺手得多。1.3 CEmu 支持的架构与可加载格式CEmu 的架构支持跟随 Unicorn主流的都覆盖了x8632 位/64 位ARM32 位/64 位AArch64MIPS大端/小端32 位/64 位SPARC 等冷门架构也能碰文件格式方面CEmu 能直接解析 ELF、PE、Mach-O 等常见的可执行文件格式并对段进行加载映射。对于没有文件头的裸二进制数据比如一段 shellcode它也支持手动指定加载地址和架构直接把字节塞进内存。这里有个要点需要理解CEmu 的“加载”不等于真实操作系统的“加载”。真实环境里动态链接器会把依赖库解到内存、重定位、初始化 GOT但 CEmu 通常只把主模块的段按映射关系放到对应地址不处理动态链接。这意味着样本里如果有call [gotoffset]这种间接调用直接跑大概率会崩。后面第 3 节我会专门说怎么用 hook 来处理这类问题。2. 环境搭建与界面导航——把 CEmu 跑起来的正确姿势2.1 安装与依赖先装引擎再装 GUICEmu 是基于 Python 的桌面应用所以环境准备本质上就是把 Python 的依赖链捋顺。核心依赖有以下几个Python 3按当前主流版本使用即可PyQt5图形界面Unicorn模拟执行引擎Capstone反汇编引擎pefile、pyelftools解析 PE/ELF 文件头在大部分支持 pip 的虚拟环境里安装流程可以简化为pip install unicorn capstone pefile pyelftools PyQt5 git clone CEmu项目仓库地址 cd cemu python cemu.py这里建议直接新建虚拟环境比如用python -m venv cemu_env再激活避免和系统里已有的包冲突。我一开始偷懒直接装到全局后来和别的项目依赖产生了版本冲突排查半天才发现是 PyQt5 版本不兼容导致界面启动直接崩。依赖装好后启动 GUI第一次打开会比较朴素左侧没有加载任何文件。可以做一次快速自检在命令行里写个最小脚本调用from unicorn import *确认引擎正常再往 CEmu 里加载一个系统自带的 ELF 文件看看段加载对不对。注意如果启动时出现 Qt 平台插件相关的报错通常是 PyQt5 缺少libxcb之类的系统库。在多数 Linux 发行版上装xcb相关的开发包就能解决不用纠结是不是 Python 包的问题。2.2 主界面功能区速览别被一堆面板吓住CEmu 的界面布局初看有点密集但拆解开就几个核心区域。文件装载区/菜单选择要分析的文件选择架构x86/ARM/MIPS、文件格式PE/ELF/裸二进制、加载基址。这一步决定 CEmu 如何解析文件头、如何映射段。段与内存映射表显示所有已加载的区域包括基地址、大小、权限R/W/X。在这里可以手动添加一段内存比如额外开辟 0x10000 字节的栈空间、修改权限、将文件某个偏移映射到指定地址。反汇编窗口以 Capstone 的结果为基础展示当前指令和下一指令地址。CEmu 会随着单步执行自动刷新相当于可视化的调试器。寄存器面板展示当前架构所有寄存器值支持手动修改。这是分析中非常高频的操作——比如你想跳过某段解密逻辑直接把 PC 指到解密后的地址。运行控制栏包含单步Step Into、步过Step Over、运行到断点等按钮和调试器概念完全一致。日志输出区打印 Unicorn 执行期间的钩子信息、异常信息。几乎所有“为什么没按预期跑”的问题答案都在这个区域。2.3 沙箱化加载手动映射、基址调整、权限控制CEmu 一个跟普通调试器显著不同的地方是内存得“手动安排”。真实程序执行时操作系统已经帮它把代码段、数据段、栈都铺好了但 CEmu 只是个 CPU 模拟器这些事没人替你干。你需要根据目标文件的段表把代码、数据、堆栈一个个映射进去。加载后建议按如下顺序做一次初始检查查看段加载结果左侧映射表里代码段 RX 是否正常数据段有没有映射到预期地址。手动补一块栈内存ARM 和 x86 的栈位置差异很大我一般人为分配一块独立区域作为栈例如 0x7fffffff0000 起、大小 0x10000再把 SP/RSP 指过去。不然样本一开头就试图压栈立刻触发未映射内存异常。确认入口点如果文件有标准头CEmu 会帮你算出入口如果是裸二进制必须自己指定入口地址和起始 PC 值。提示把所有初始加载操作记下来。CEmu 支持把当前的映射和寄存器状态导出为脚本后面反复分析相似样本时能省掉大量重复操作。3. 恶意样本模拟执行实操——一个相对完整的分析流程3.1 静态预判先从文件头和导入表获取重要信息拿到样本不要立刻就往 CEmu 里塞。先用静态工具过一遍确定架构、入口点、可疑的导入函数才能让后面的动态分析有方向。以 Linux ELF 为例可以执行file sample.bin readelf -h sample.bin objdump -d -M intel sample.bin | head -50重点关注三件事一是Machine字段确认架构是 x86-64 还是 ARM二是Entry point地址这个值后面要填进 CEmu 的初始 PC三是从objdump输出里找有没有call/jmp到外部地址的指令——这类往往是需要动态解析的外部函数说明样本依赖某个环境才能完整执行模拟时就要设置断点专门观察。对 PE 文件来说objdump不太顺手可以用pedump或者自己写几行 pefile 脚本import pefile pe pefile.PE(sample.exe) for entry in pe.DIRECTORY_ENTRY_IMPORT: for func in entry.imports: if func.name: print(hex(func.address), func.name.decode())这一步的目的不是做完整静态分析而是制定动态分析策略哪些地址下断点、哪些函数需要 hook、哪些区域的内存变化值得观察。节省的是 CEmu 里盲目单步的时间。3.2 关键操作一加载文件与手动映射内存打开 CEmu在菜单里选择架构比如 x86-64、文件类型ELF然后加载样本。加载完成界面会展示 auto 解析出的各段信息。这里有一个常见坑CEmu 的段映射经常把文件里所有段都加载了但权限设置未必符合预期。比如某些数据段被标记成可执行有意或无意的文件头脏数据倒不影响观察但如果你后续要修改映射权限得知道这个段是拿来当代码还是当数据用的。接下来手动规划额外内存。以加载一个 shellcode 为例假设我已经从 PDF 中提取出的 shellcode 只有一个字节流没有文件头第一次加载时 CEmu 不知道该把它放哪。我会这么做在“内存映射”区域添加一段新内存基址选 0x400000大小 0x10000权限 RX。将 shellcode 字节写入 0x400000使用内存写入功能或者写脚本一次性灌入。在寄存器面板将RIP设置为 0x400000。分配另一段 RW 内存作为栈0x7fffffff0000大小 0x10000把RSP指过去。这样样本的环境就是一个“最低限度可执行”的状态有代码、有栈、有数据段。比直接在完整系统里分析轻量很多也足够观察逻辑了。3.3 关键操作二下断点、单步与关键地址观察模拟执行开始后CEmu 的调试器体验和常见调试器没有本质差别。但针对恶意软件分析有几类断点必须下入口点断点验证初始状态是否正确观察段加载结果便于修正。解密循环断点如果静态分析看到有循环 XOR 或者逐字节处理逻辑先跑一次到循环入口再单步几轮判断出密钥和长度。外部跳转断点样本执行到jmp [某寄存器]时很可能要跳到解密后的代码或内存中的数据区。在这里下断点观察寄存器指向的地址内容基本就能定位壳的 OEP。单步执行不是“点一下按钮看下一行指令”这么简单。更实用的做法是结合内存窗口在 CEmu 里切换内存视图的基址到当前指令附近单步后看[RSP]、[RBP]等地址处的数据变化。有一次分析一个混淆的加解密函数循环体很短但每次迭代都会改写一片内存我就是通过对比单步后内存窗口的前 64 字节差异推算出密钥其实是一个固定的 4 字节整数而不是逐字节复杂变换。遇到call指令时务必要时留意call的返回地址。多数恶意样本的call不是正常函数调用而是常见的call/pop定位技术用来计算自身在内存中的绝对地址。这个模式下你会看到call之后栈顶变成一个奇怪但连续的地址再一pop到某个寄存器。如果不清楚这个套路单步时容易误以为程序马上要跳转到错误地址了。3.4 用 CEmu Python API 做自动化批量分析GUI 适合人工分析但当你有一批同源样本时手动一个个加载就太慢了。CEmu 的核心层可以用 Python 脚本直接驱动形成一个半自动化的分析流水线。典型流程如下from cemu.core import Cemu, Arch, Os # 初始化模拟器指定架构与操作系统类型 emu Cemu(archArch.X86_64, osOs.LINUX, verboseTrue) # 加载二进制文件 emu.load(sample.bin) # 手动补一个可读写的栈区域 emu.map(0x7fffffff0000, 0x10000, rw) emu.reg(rsp, 0x7fffffff0000 0x8000) # 设置入口点 emu.reg(rip, emu.get_entry_point()) # 注册内存写钩子监控指定地址段的数据变化 emu.hook_mem_write(0x400000 0x2000, 0x400000 0x3000, callback) # 运行并设置超时避免死循环卡住 emu.run(timeout5000) # 结束后 dump 指定内存区域 open(decoded.bin, wb).write(emu.mem_read(0x400000 0x2000, 0x1000))注意上面的代码是简化示意实际 API 名称在不同版本间会有差异但思路是一致的初始化 → 映射 → 设寄存器 → 设置 hook → 限时执行 → dump 内存。批量分析时有个非常好用的技巧如果一批样本共享同一个解密函数你可以先手动逆向其中一个样本定位出解密函数的输入地址和长度然后用脚本对每个样本执行同样的解密逻辑再对 dump 出来的结果做哈希聚类。这样能在几分钟内判断这批样本是否只是换了密钥的同一族恶意代码。提示写自动分析脚本时一定要设置超时。恶意样本里普遍有基于时间或指令计数的反分析逻辑如果不设置超时脚本会卡在一个故意构造的死循环里。推荐先跑 2000~5000 毫秒如果没有任何 hook 触发再考虑延长。3.5 关键操作三手动模拟不支持的 API 调用前面提到 CEmu 不做动态链接不对操作系统 API 做处理。样本里如果直接call某个系统 API 的地址常见结果是执行到无效指令或跳到一个未映射的地址。这时候不能甩锅说工具没用而应该把它当成分析切入点——样本调用了什么 API说明它想做什么这正是恶意行为的关键线索。做法分两步第一步确定调用点。用静态分析找到call或者syscall指令的位置在 CEmu 里设一个断点运行到该地址后停下。第二步分析参数。看寄存器或栈里的参数理解调用语义。比如某个样本在 Linux 上通过syscall发网络请求参数里会有 socket 相关的文件描述符和地址结构体。你不希望真的让它发出网络请求所以停在 syscall 前直接改执行流程跳过它。对于 Windows PE 样本里的call [IAT]模式类似。多数 API 的实际功能在模拟器里没法实现比如VirtualAlloc要求返回一块可读写的内存。这时你可以用 hook 机制手动接管def hook_virtual_alloc(ctx): # 分配 0x1000 字节内存返回地址 addr emu.mmap(0x1000, rw) emu.reg(rax, addr) emu.reg(rip, emu.reg(rip) insn_len)所谓“模拟”本质上是建立一个最小可信环境让恶意代码在这个环境里以为自己在“正常工作”而实际上每个关键动作都在你的掌控之中。4. 常见问题定位与排查速查表4.1 运行即崩溃未实现指令与指令集扩展CEmu 最常见的报错大概就是 “Invalid memory read” 或 “Invalid instruction”。前者大多和内存布局有关后者多半和架构设置有关。有一次我加载一个 ARM 的固件片段选了 ARM 模式但一执行就报 “Invalid instruction”。排查后发现该固件里使用了 ARM Thumb-2 指令集而初始的处理器模式设置不对导致 Thumb 指令被按 ARM 指令解码。解决办法是在 CEmu 的寄存器/CPU 配置里切换 Thumb 模式通常是设置 CPSR 的 T 位或者直接改架构选项。类似地x86 样本里如果用到 AVX/SSE 扩展Unicorn 不一定完整支持也会出现非法指令。这类情况下我会先用静态定位把包含特殊指令的代码段跳过或者用 hook 把指令字节改成 NOP再继续观察后续逻辑。4.2 内存访问越界段映射和栈布局不合理“Invalid memory read at 0x... / write at 0x...” 是另一种高频报错几乎每次分析新样本都会遇到。原因通常是简单的程序访问的地址没在用 Unicorn 映射的内存范围内。排查路径固定三步看报错地址。如果地址接近 0往往是空指针解引用或者间接跳转没初始化。看上下文。如果是push或者call报错多半是栈没设置好。我习惯在入口分配 0x10000 字节栈并做页对齐避免 16 字节对齐相关的访问错误。如果是数据访问越界回头看是在哪个指令触发的用静态反汇编看偏移是不是从某个寄存器计算出来的然后检查寄存器里应该是索引还是绝对地址。有一类情况很阴险样本会故意访问一个很偏的地址比如读取[eax*4 0xFFFFFFF0]实际上是想绕过错位反汇编的干扰。这种要结合静态分析看清意图别急着改内存映射去“凑合”它。4.3 运行超时或疑似死循环恶意代码里死循环比想象中常见有些是反分析手段有些是因为样本倚赖某个前置条件才能进入下一段逻辑而这个条件在模拟环境里永远不会被满足。CEmu 里设置运行超时只是免于界面卡死的兜底手段想真正定位死循环要在日志里看 PC 是否在某段地址区间反复跳动。如果是说明它卡在一个固定循环里那就找到循环边界判断跳出条件手动修改寄存器强制跳出。经常需要检查的寄存器是计数器类的比如ecx表示循环剩余次数或者某个内存地址存的是循环状态。把那个值改成 0再单步一下看它是否跳过循环。4.4 排查速查表现象可能原因处理思路Invalid instruction架构/指令集不匹配切换 ARM/Thumb 模式或跳过不支持的指令Invalid memory read/write未映射对应内存区域添加内存映射、调整栈指针、确认访问地址来源执行到 0x0空指针跳转查看是哪条指令导致检查寄存器初值运行超时死循环或等待外部条件限制指令数定位循环地址强制修改跳出变量外部函数调用后崩API 未模拟设置断点识别调用点用 hook 手动模拟返回解密结果不对初始内存内容或入口地址错误重新核对文件偏移与入口点确认数据段加载完整5. 实战心得与工具边界5.1 CEmu 不能替代什么很多朋友看完上面的内容会有一个误解CEmu 是不是能模拟完整恶意软件的执行答案是“只能模拟单进程、单 CPU 内核级别的代码”它不能替代以下这些工具完整系统行为分析进程注入、注册表操作、文件系统写入需要专用沙箱。内核级恶意代码分析需要在内核调试环境里做。网络通信分析需要伪造协议栈或使用网络模拟工具。CEmu 的特长是“代码级行为”分析内存怎么变化、哪个算法被调用、解密后的数据长什么样、某段 shellcode 的执行流如何走。它不是万能的瑞士军刀更像是手术刀——针对一段代码做精准切割。5.2 给初学者的三条建议第一从 CEmu 自带样例或者自己构造的测试程序开始不要一上来就碰复杂的恶意样本。先写一个简单的 C 程序反汇编后观察自己的main函数怎么被 CEmu 执行能显著降低学习曲线的陡峭度。第二学会和 GDB/objdump 配合。CEmu 的反汇编结果只是一个瞬间的快照遇到复杂的循环逻辑先在 GDB 里确认目标指令的上下文再切到 CEmu 里动态验证效率比纯在 CEmu 里盲人摸象高得多。第三记录所有映射和偏移。分析复杂样本时地址偏移关系极其容易混乱。我用 CEmu 处理过大段解包样本当时没及时记录各个内存在哪一段被写入数据后面回头分析时花了好多时间重新定位。5.3 我的工作流参考最后分享一下我目前在恶意软件二进制分析里相对稳定的流程供参考静态检查file、readelf、import table 分析。提取可疑代码段按需求切成 1~4KB 的小块逐个在 CEmu 里加载。对每一块设置合理的初始环境栈、入口、数据指针执行并记录内存 diff。把执行结果与静态反汇编结果对照定位动态生成的关键数据。对解密后的数据重新生成样本通常是 dump 一段内存再重复分析。这套流程在分析依赖硬编码数据的混淆逻辑上有奇效。上下文越简单越容易看清代码在数据上的操作规律。CEmu 本身并不难学难的是建立“以代码为中心”的分析思维。很多人一上来就想着完整跑起一个恶意程序结果被各种环境问题劝退。先学会把大样本拆成小片段、把系统依赖替换成可控的 hook多碰几次真实的混淆逻辑你会慢慢发现汇编级模拟器的价值远不止“跑个代码”这么简单。对我来说分析一个恶意文件就像在做一场受控实验CEmu 就是那套精确到指令的测量仪器。真正的乐趣是在单调的字节流里逐步还原出藏在背后的意图。 
长河君 · 2026/10/21 17:01:07 · 阅读 1.2k 多架构二进制动态分析：用CEmu模拟器精准剖析恶意样本
拿到一个来路不明的二进制文件时第一反应永远是“先跑起来看看它到底要干什么”。但直接在真机跑太冒险丢进虚拟机又重得离谱尤其是当目标还是 ARM、MIPS 这类非主流架构的固件片段时传统调试器根本无从下手。CEmu 这类多架构汇编模拟器恰好就是为这个场景设计的它不启动操作系统只模拟 CPU 和一小块内存把代码一段段喂进去边执行边观察寄存器、内存和反汇编结果。这篇文章我会从选择模拟器的底层逻辑开始讲清楚 CEmu 的定位、怎么搭环境、怎么做一次完整的恶意软件/二进制文件动态分析再把我踩过的坑和排查思路一并整理出来适合刚接触逆向、想做样本行为分析又不想被 QEMU 全家桶劝退的朋友。1. CEmu 到底解决了什么问题——模拟器选型背后的逻辑1.1 为什么动态分析要选汇编级模拟器而不是直接开虚拟机很多刚接触逆向的朋友会有一个疑问分析恶意软件Win10 虚拟机加 Procmon 不就行了能看进程行为、看网络请求、看文件操作为什么要绕一大圈去用 CEmu 这种只能模拟 CPU 的“半个计算器”。这个问题的答案得看分析的到底是什么。虚拟机适合分析完整、成型的恶意软件比如一个能运行的 EXE它需要操作系统、API、文件系统、网络栈。但实际逆向中你手里拿到的往往不是完整样本而是一段从 PDF 里提取出来的 JavaScript 解码后的 shellcode、一个固件里剥离出来的二进制 blob、一段只支持 ARM 指令集的引导加载代码。这些东西放到虚拟机里根本起不来因为它没有宿主环境、没有加载器、没有入口点上下文。还有一类样本非常现实带有反虚拟机检测。你开 VMware、VirtualBox 跑它它检测到设备特征直接跳转到正常逻辑你一整天都等不到恶意行为。汇编级模拟器回避了这两个问题。CEmu 这种工具只负责模拟指令执行不向样本暴露设备型号、系统版本、进程列表等特征。样本以为自己跑在裸机或某个嵌入式环境里实际上所有指令都在模拟器里被翻译执行。你要做的就是告诉它“内存从哪里开始、栈指针指到哪、从哪个地址开始执行”然后一步步观察它干了什么。1.2 CEmu 的定位站在 Unicorn 肩膀上的图形化分析界面从技术上说CEmu 的核心执行引擎是 Unicorn。Unicorn 是一个 CPU 模拟框架它能翻译执行 x86、x86-64、ARM、ARM64、MIPS、SPARC 等多架构指令但它本身没有界面也没有“方便人类操作”的工作流。你调用它的 Python/C API 时要自己管内存映射、寄存器、断点和写嵌入式系统代码差不多。CEmu 做的事情是把 Unicorn 封装成一整套能直接上手的分析工具。它自带图形界面左侧是内存和段的信息中间是反汇编窗口右侧是寄存器状态下方是运行控制区。你加载一个二进制文件后可以像用调试器一样单步执行、下断点、读写内存、修改寄存器。同时它还暴露了核心 API可以脱离界面写 Python 脚本做批量分析。如果做横向对比大概是这样工具层级优点局限QEMU 用户态/全系统全系统/用户态模拟能运行完整程序支持系统调用重速度慢反调试容易被影响UnicornCPU 指令模拟多架构、轻量、API 灵活无界面所有工作都得自己写代码Ghidra 模拟器静态分析内嵌模拟和反编译结果结合紧密定位偏静态分析脚本有一定上手门槛CEmuCPU 指令模拟 GUI开箱即用多架构适合样本代码分析不模拟操作系统 API复杂样本需配合其他工具从实际分析场景看CEmu 的市场定位很清晰它不追求“跑起一个完整的恶意程序”而是追求“精确观察一段可疑代码的执行路径”。你要研究蠕虫的 main 函数行为可能不如丢进虚拟机高效但如果目标是提取一段 ROP 链、定位混淆解码循环、分析一个只支持 MIPS 的路由器固件漏洞利用代码CEmu 比 QEMU 和 Ghidra 都顺手得多。1.3 CEmu 支持的架构与可加载格式CEmu 的架构支持跟随 Unicorn主流的都覆盖了x8632 位/64 位ARM32 位/64 位AArch64MIPS大端/小端32 位/64 位SPARC 等冷门架构也能碰文件格式方面CEmu 能直接解析 ELF、PE、Mach-O 等常见的可执行文件格式并对段进行加载映射。对于没有文件头的裸二进制数据比如一段 shellcode它也支持手动指定加载地址和架构直接把字节塞进内存。这里有个要点需要理解CEmu 的“加载”不等于真实操作系统的“加载”。真实环境里动态链接器会把依赖库解到内存、重定位、初始化 GOT但 CEmu 通常只把主模块的段按映射关系放到对应地址不处理动态链接。这意味着样本里如果有call [gotoffset]这种间接调用直接跑大概率会崩。后面第 3 节我会专门说怎么用 hook 来处理这类问题。2. 环境搭建与界面导航——把 CEmu 跑起来的正确姿势2.1 安装与依赖先装引擎再装 GUICEmu 是基于 Python 的桌面应用所以环境准备本质上就是把 Python 的依赖链捋顺。核心依赖有以下几个Python 3按当前主流版本使用即可PyQt5图形界面Unicorn模拟执行引擎Capstone反汇编引擎pefile、pyelftools解析 PE/ELF 文件头在大部分支持 pip 的虚拟环境里安装流程可以简化为pip install unicorn capstone pefile pyelftools PyQt5 git clone CEmu项目仓库地址 cd cemu python cemu.py这里建议直接新建虚拟环境比如用python -m venv cemu_env再激活避免和系统里已有的包冲突。我一开始偷懒直接装到全局后来和别的项目依赖产生了版本冲突排查半天才发现是 PyQt5 版本不兼容导致界面启动直接崩。依赖装好后启动 GUI第一次打开会比较朴素左侧没有加载任何文件。可以做一次快速自检在命令行里写个最小脚本调用from unicorn import *确认引擎正常再往 CEmu 里加载一个系统自带的 ELF 文件看看段加载对不对。注意如果启动时出现 Qt 平台插件相关的报错通常是 PyQt5 缺少libxcb之类的系统库。在多数 Linux 发行版上装xcb相关的开发包就能解决不用纠结是不是 Python 包的问题。2.2 主界面功能区速览别被一堆面板吓住CEmu 的界面布局初看有点密集但拆解开就几个核心区域。文件装载区/菜单选择要分析的文件选择架构x86/ARM/MIPS、文件格式PE/ELF/裸二进制、加载基址。这一步决定 CEmu 如何解析文件头、如何映射段。段与内存映射表显示所有已加载的区域包括基地址、大小、权限R/W/X。在这里可以手动添加一段内存比如额外开辟 0x10000 字节的栈空间、修改权限、将文件某个偏移映射到指定地址。反汇编窗口以 Capstone 的结果为基础展示当前指令和下一指令地址。CEmu 会随着单步执行自动刷新相当于可视化的调试器。寄存器面板展示当前架构所有寄存器值支持手动修改。这是分析中非常高频的操作——比如你想跳过某段解密逻辑直接把 PC 指到解密后的地址。运行控制栏包含单步Step Into、步过Step Over、运行到断点等按钮和调试器概念完全一致。日志输出区打印 Unicorn 执行期间的钩子信息、异常信息。几乎所有“为什么没按预期跑”的问题答案都在这个区域。2.3 沙箱化加载手动映射、基址调整、权限控制CEmu 一个跟普通调试器显著不同的地方是内存得“手动安排”。真实程序执行时操作系统已经帮它把代码段、数据段、栈都铺好了但 CEmu 只是个 CPU 模拟器这些事没人替你干。你需要根据目标文件的段表把代码、数据、堆栈一个个映射进去。加载后建议按如下顺序做一次初始检查查看段加载结果左侧映射表里代码段 RX 是否正常数据段有没有映射到预期地址。手动补一块栈内存ARM 和 x86 的栈位置差异很大我一般人为分配一块独立区域作为栈例如 0x7fffffff0000 起、大小 0x10000再把 SP/RSP 指过去。不然样本一开头就试图压栈立刻触发未映射内存异常。确认入口点如果文件有标准头CEmu 会帮你算出入口如果是裸二进制必须自己指定入口地址和起始 PC 值。提示把所有初始加载操作记下来。CEmu 支持把当前的映射和寄存器状态导出为脚本后面反复分析相似样本时能省掉大量重复操作。3. 恶意样本模拟执行实操——一个相对完整的分析流程3.1 静态预判先从文件头和导入表获取重要信息拿到样本不要立刻就往 CEmu 里塞。先用静态工具过一遍确定架构、入口点、可疑的导入函数才能让后面的动态分析有方向。以 Linux ELF 为例可以执行file sample.bin readelf -h sample.bin objdump -d -M intel sample.bin | head -50重点关注三件事一是Machine字段确认架构是 x86-64 还是 ARM二是Entry point地址这个值后面要填进 CEmu 的初始 PC三是从objdump输出里找有没有call/jmp到外部地址的指令——这类往往是需要动态解析的外部函数说明样本依赖某个环境才能完整执行模拟时就要设置断点专门观察。对 PE 文件来说objdump不太顺手可以用pedump或者自己写几行 pefile 脚本import pefile pe pefile.PE(sample.exe) for entry in pe.DIRECTORY_ENTRY_IMPORT: for func in entry.imports: if func.name: print(hex(func.address), func.name.decode())这一步的目的不是做完整静态分析而是制定动态分析策略哪些地址下断点、哪些函数需要 hook、哪些区域的内存变化值得观察。节省的是 CEmu 里盲目单步的时间。3.2 关键操作一加载文件与手动映射内存打开 CEmu在菜单里选择架构比如 x86-64、文件类型ELF然后加载样本。加载完成界面会展示 auto 解析出的各段信息。这里有一个常见坑CEmu 的段映射经常把文件里所有段都加载了但权限设置未必符合预期。比如某些数据段被标记成可执行有意或无意的文件头脏数据倒不影响观察但如果你后续要修改映射权限得知道这个段是拿来当代码还是当数据用的。接下来手动规划额外内存。以加载一个 shellcode 为例假设我已经从 PDF 中提取出的 shellcode 只有一个字节流没有文件头第一次加载时 CEmu 不知道该把它放哪。我会这么做在“内存映射”区域添加一段新内存基址选 0x400000大小 0x10000权限 RX。将 shellcode 字节写入 0x400000使用内存写入功能或者写脚本一次性灌入。在寄存器面板将RIP设置为 0x400000。分配另一段 RW 内存作为栈0x7fffffff0000大小 0x10000把RSP指过去。这样样本的环境就是一个“最低限度可执行”的状态有代码、有栈、有数据段。比直接在完整系统里分析轻量很多也足够观察逻辑了。3.3 关键操作二下断点、单步与关键地址观察模拟执行开始后CEmu 的调试器体验和常见调试器没有本质差别。但针对恶意软件分析有几类断点必须下入口点断点验证初始状态是否正确观察段加载结果便于修正。解密循环断点如果静态分析看到有循环 XOR 或者逐字节处理逻辑先跑一次到循环入口再单步几轮判断出密钥和长度。外部跳转断点样本执行到jmp [某寄存器]时很可能要跳到解密后的代码或内存中的数据区。在这里下断点观察寄存器指向的地址内容基本就能定位壳的 OEP。单步执行不是“点一下按钮看下一行指令”这么简单。更实用的做法是结合内存窗口在 CEmu 里切换内存视图的基址到当前指令附近单步后看[RSP]、[RBP]等地址处的数据变化。有一次分析一个混淆的加解密函数循环体很短但每次迭代都会改写一片内存我就是通过对比单步后内存窗口的前 64 字节差异推算出密钥其实是一个固定的 4 字节整数而不是逐字节复杂变换。遇到call指令时务必要时留意call的返回地址。多数恶意样本的call不是正常函数调用而是常见的call/pop定位技术用来计算自身在内存中的绝对地址。这个模式下你会看到call之后栈顶变成一个奇怪但连续的地址再一pop到某个寄存器。如果不清楚这个套路单步时容易误以为程序马上要跳转到错误地址了。3.4 用 CEmu Python API 做自动化批量分析GUI 适合人工分析但当你有一批同源样本时手动一个个加载就太慢了。CEmu 的核心层可以用 Python 脚本直接驱动形成一个半自动化的分析流水线。典型流程如下from cemu.core import Cemu, Arch, Os # 初始化模拟器指定架构与操作系统类型 emu Cemu(archArch.X86_64, osOs.LINUX, verboseTrue) # 加载二进制文件 emu.load(sample.bin) # 手动补一个可读写的栈区域 emu.map(0x7fffffff0000, 0x10000, rw) emu.reg(rsp, 0x7fffffff0000 0x8000) # 设置入口点 emu.reg(rip, emu.get_entry_point()) # 注册内存写钩子监控指定地址段的数据变化 emu.hook_mem_write(0x400000 0x2000, 0x400000 0x3000, callback) # 运行并设置超时避免死循环卡住 emu.run(timeout5000) # 结束后 dump 指定内存区域 open(decoded.bin, wb).write(emu.mem_read(0x400000 0x2000, 0x1000))注意上面的代码是简化示意实际 API 名称在不同版本间会有差异但思路是一致的初始化 → 映射 → 设寄存器 → 设置 hook → 限时执行 → dump 内存。批量分析时有个非常好用的技巧如果一批样本共享同一个解密函数你可以先手动逆向其中一个样本定位出解密函数的输入地址和长度然后用脚本对每个样本执行同样的解密逻辑再对 dump 出来的结果做哈希聚类。这样能在几分钟内判断这批样本是否只是换了密钥的同一族恶意代码。提示写自动分析脚本时一定要设置超时。恶意样本里普遍有基于时间或指令计数的反分析逻辑如果不设置超时脚本会卡在一个故意构造的死循环里。推荐先跑 2000~5000 毫秒如果没有任何 hook 触发再考虑延长。3.5 关键操作三手动模拟不支持的 API 调用前面提到 CEmu 不做动态链接不对操作系统 API 做处理。样本里如果直接call某个系统 API 的地址常见结果是执行到无效指令或跳到一个未映射的地址。这时候不能甩锅说工具没用而应该把它当成分析切入点——样本调用了什么 API说明它想做什么这正是恶意行为的关键线索。做法分两步第一步确定调用点。用静态分析找到call或者syscall指令的位置在 CEmu 里设一个断点运行到该地址后停下。第二步分析参数。看寄存器或栈里的参数理解调用语义。比如某个样本在 Linux 上通过syscall发网络请求参数里会有 socket 相关的文件描述符和地址结构体。你不希望真的让它发出网络请求所以停在 syscall 前直接改执行流程跳过它。对于 Windows PE 样本里的call [IAT]模式类似。多数 API 的实际功能在模拟器里没法实现比如VirtualAlloc要求返回一块可读写的内存。这时你可以用 hook 机制手动接管def hook_virtual_alloc(ctx): # 分配 0x1000 字节内存返回地址 addr emu.mmap(0x1000, rw) emu.reg(rax, addr) emu.reg(rip, emu.reg(rip) insn_len)所谓“模拟”本质上是建立一个最小可信环境让恶意代码在这个环境里以为自己在“正常工作”而实际上每个关键动作都在你的掌控之中。4. 常见问题定位与排查速查表4.1 运行即崩溃未实现指令与指令集扩展CEmu 最常见的报错大概就是 “Invalid memory read” 或 “Invalid instruction”。前者大多和内存布局有关后者多半和架构设置有关。有一次我加载一个 ARM 的固件片段选了 ARM 模式但一执行就报 “Invalid instruction”。排查后发现该固件里使用了 ARM Thumb-2 指令集而初始的处理器模式设置不对导致 Thumb 指令被按 ARM 指令解码。解决办法是在 CEmu 的寄存器/CPU 配置里切换 Thumb 模式通常是设置 CPSR 的 T 位或者直接改架构选项。类似地x86 样本里如果用到 AVX/SSE 扩展Unicorn 不一定完整支持也会出现非法指令。这类情况下我会先用静态定位把包含特殊指令的代码段跳过或者用 hook 把指令字节改成 NOP再继续观察后续逻辑。4.2 内存访问越界段映射和栈布局不合理“Invalid memory read at 0x... / write at 0x...” 是另一种高频报错几乎每次分析新样本都会遇到。原因通常是简单的程序访问的地址没在用 Unicorn 映射的内存范围内。排查路径固定三步看报错地址。如果地址接近 0往往是空指针解引用或者间接跳转没初始化。看上下文。如果是push或者call报错多半是栈没设置好。我习惯在入口分配 0x10000 字节栈并做页对齐避免 16 字节对齐相关的访问错误。如果是数据访问越界回头看是在哪个指令触发的用静态反汇编看偏移是不是从某个寄存器计算出来的然后检查寄存器里应该是索引还是绝对地址。有一类情况很阴险样本会故意访问一个很偏的地址比如读取[eax*4 0xFFFFFFF0]实际上是想绕过错位反汇编的干扰。这种要结合静态分析看清意图别急着改内存映射去“凑合”它。4.3 运行超时或疑似死循环恶意代码里死循环比想象中常见有些是反分析手段有些是因为样本倚赖某个前置条件才能进入下一段逻辑而这个条件在模拟环境里永远不会被满足。CEmu 里设置运行超时只是免于界面卡死的兜底手段想真正定位死循环要在日志里看 PC 是否在某段地址区间反复跳动。如果是说明它卡在一个固定循环里那就找到循环边界判断跳出条件手动修改寄存器强制跳出。经常需要检查的寄存器是计数器类的比如ecx表示循环剩余次数或者某个内存地址存的是循环状态。把那个值改成 0再单步一下看它是否跳过循环。4.4 排查速查表现象可能原因处理思路Invalid instruction架构/指令集不匹配切换 ARM/Thumb 模式或跳过不支持的指令Invalid memory read/write未映射对应内存区域添加内存映射、调整栈指针、确认访问地址来源执行到 0x0空指针跳转查看是哪条指令导致检查寄存器初值运行超时死循环或等待外部条件限制指令数定位循环地址强制修改跳出变量外部函数调用后崩API 未模拟设置断点识别调用点用 hook 手动模拟返回解密结果不对初始内存内容或入口地址错误重新核对文件偏移与入口点确认数据段加载完整5. 实战心得与工具边界5.1 CEmu 不能替代什么很多朋友看完上面的内容会有一个误解CEmu 是不是能模拟完整恶意软件的执行答案是“只能模拟单进程、单 CPU 内核级别的代码”它不能替代以下这些工具完整系统行为分析进程注入、注册表操作、文件系统写入需要专用沙箱。内核级恶意代码分析需要在内核调试环境里做。网络通信分析需要伪造协议栈或使用网络模拟工具。CEmu 的特长是“代码级行为”分析内存怎么变化、哪个算法被调用、解密后的数据长什么样、某段 shellcode 的执行流如何走。它不是万能的瑞士军刀更像是手术刀——针对一段代码做精准切割。5.2 给初学者的三条建议第一从 CEmu 自带样例或者自己构造的测试程序开始不要一上来就碰复杂的恶意样本。先写一个简单的 C 程序反汇编后观察自己的main函数怎么被 CEmu 执行能显著降低学习曲线的陡峭度。第二学会和 GDB/objdump 配合。CEmu 的反汇编结果只是一个瞬间的快照遇到复杂的循环逻辑先在 GDB 里确认目标指令的上下文再切到 CEmu 里动态验证效率比纯在 CEmu 里盲人摸象高得多。第三记录所有映射和偏移。分析复杂样本时地址偏移关系极其容易混乱。我用 CEmu 处理过大段解包样本当时没及时记录各个内存在哪一段被写入数据后面回头分析时花了好多时间重新定位。5.3 我的工作流参考最后分享一下我目前在恶意软件二进制分析里相对稳定的流程供参考静态检查file、readelf、import table 分析。提取可疑代码段按需求切成 1~4KB 的小块逐个在 CEmu 里加载。对每一块设置合理的初始环境栈、入口、数据指针执行并记录内存 diff。把执行结果与静态反汇编结果对照定位动态生成的关键数据。对解密后的数据重新生成样本通常是 dump 一段内存再重复分析。这套流程在分析依赖硬编码数据的混淆逻辑上有奇效。上下文越简单越容易看清代码在数据上的操作规律。CEmu 本身并不难学难的是建立“以代码为中心”的分析思维。很多人一上来就想着完整跑起一个恶意程序结果被各种环境问题劝退。先学会把大样本拆成小片段、把系统依赖替换成可控的 hook多碰几次真实的混淆逻辑你会慢慢发现汇编级模拟器的价值远不止“跑个代码”这么简单。对我来说分析一个恶意文件就像在做一场受控实验CEmu 就是那套精确到指令的测量仪器。真正的乐趣是在单调的字节流里逐步还原出藏在背后的意图。