REA 逆向选型三步走：.hop、Windows PE 与 DOS MZ 各走哪条通道？

REA 逆向选型三步走.hop、Windows PE 与 DOS MZ 各走哪条通道【免费下载链接】reaReverse engineer anything with agents, from app behavior down to native binaries.项目地址: https://gitcode.com/GitHub_Trending/rea2/reaREA 是一个 AI Agent 驱动的逆向工程平台能从应用行为一路分析到原生二进制。它不内置反编译器而是接入你本地装好的 Hopper 或 Ghidra——.hop数据库、Windows PE、DOS 程序各走各的通道。选错通道的代价是一整轮白跑本文按“机器→文件形态→边界”的顺序把选型讲透。先看机器macOS 与 Windows 是两条不同的通道REA 的核心机制叫“自带分析器”Bring-your-own-Provider它自己不带反编译器接的是你本地已安装的 Hopper 或 Ghidra由 Agent 统一调度。所以机器上装了什么直接决定你能走哪条路。macOS 和 Linux 上Hopper 是默认主力Mach-O苹果平台可执行格式、ELF类 Unix 可执行格式都归它管Ghidra 也能接主要用来跑 16 位 DOS 目标。那 Windows 上呢没有 Hopper 通道原生 PE 分析全部走 Ghidra而且是一个明确的实验性 P0 边界。还有一条硬规则Provider 一旦选定之后不会自动切换到别的工具。失败会被明确抛给你而不是给出一个“看起来成功了”的假象。完整设计理由见 Provider 选择 ADR。小结论机器决定通道通道锁定后没有退路。开工前先确认这台机器上装的是哪个工具。再看文件形态Hopper .hop 数据库、PE 与 DOS 文件各归其主机器定了再看文件本身。.hop是 Hopper 生成的反编译分析数据库扩展名即分类REA 把.hop归为 analysis-database分析数据库只有 Hopper 适配器接受它Ghidra 不打开别人的项目领域层也不关心其内部格式。分类逻辑就在 BinaryTargetResolver.ts 里。✅ 有现成.hop交给 Hopper 通道Windows 上它没有去处。Windows PE 走 Ghidra 通道原生非托管、非 DLLx86 / x86-64 PE 落在 Windows Ghidra P0 只读边界内托管 PE/CLI 不在这里走独立的免执行 Provider。✅ 原生 PE 的通用调查方法见 native-investigation.md。DOS 古董文件也走 GhidraMZ 可执行文件自动识别.com无头文件必须显式声明。⚠️ 别省那个参数下节细说。小结论文件形态定适配器——.hop只认 HopperWindows PE 只认 GhidraDOS 文件显式声明后也归 Ghidra。Windows Ghidra 只读边界P0 里能做什么、不能做什么Windows 上的 Ghidra 支持是实验性 P0 只读边界能做与不能做的对照如下能做边界内不能做边界外Windows 10 x64本地 NTFSWindows 默认文件系统固定路径目标Ghidra GUI 状态、注释等写入类操作Ghidra 12.1.x验证过 12.1.4 JDK 21 或更新的 64 位完整 JDK托管 PE/CLI改走独立免执行 Provider原生 x86 / x86-64 PE 的 25 个只读清单、内存与函数分析操作其他架构、其他格式冷启动导入超 330 秒也能完整跑完验证通道允许Hopper 专有操作Windows 上没有 Hopper 通道加载镜像检查目前也只在独立验证中支持 DOS MZPE 会拿到明确的 unsupported不支持状态。安全机制全部自动生效你不用手动配置任何权限标志私有 DACL访问控制列表会话目录只放行当前用户与 SYSTEM127.0.0.1 回环监听加 256 位 bearer token令牌式访问凭证认证传输Job ObjectWindows 的进程组看门人托管 Ghidra 子进程关闭即全部终止。环境与配置细节见 windows-ghidra-p0.md。小结论Windows 通道 只读、实验性、边界清晰。注释、写库、GUI 联动都不在这条通道里。DOS MZ 反编译识别规则、.com 显式参数与那个地址坑16 位 DOS 程序由 Ghidra 的 MzLoaderDOS 镜像加载器完成语言固定x86:LE:16:Real Mode加载段固定0x1000这些设定写死在分析档案里不允许漂移。先认规则MZ 可执行文件自动识别分类器会校验页计数、重定位表边界与入口点❌ NE / LE / LX 格式明确不支持损坏的 Windows 头不会“悄悄变成” DOS❌ 只做静态反编译/反汇编不模拟 BIOS、DOS 中断与设备端口。.com文件没有可识别的文件头后缀不算数rea inspect /path/to/legacy.com --target-format dos-com --provider ghidra --json必须显式带上--target-format dos-com且文件长度要在 1~65280 字节内64KiB 段减去 256 字节 PSP 前缀PSP 是 DOS 给每个.com分配的运行时数据区。常用操作rea function /path/to/legacy.exe entry --provider ghidra --jsonrea inspect-native-load-image /path/to/legacy.exe --provider ghidra --json后一条做加载镜像的独立校验结果是verified/mismatch/unsupported三态之一。完整命令与 MCP 工具名见 ghidra-dos.md。最后一个坑必须记牢函数 body 证据里的地址是线性加载地址按segment * 16 offset计算。它不是文件偏移也不是真实 DOS 系统里的观察值。需要换算时走地址到文件偏移的命令rea address-to-file-offset别拿 body 里的地址直接去文件里找。小结论DOS 通道只给静态证据——MZ 靠文件头识别.com靠显式参数地址是线性值不是偏移。三问定通道如果你……就走……如果你手里是.hop数据库就走 Hopper——整个体系里只有它认这个格式如果你在 Windows 上分析原生 .exe就走 Ghidra P0 只读通道冷启动慢是正常现象如果你面对古董 .exe 或 .com就走 Ghidra 的 DOS 通道.com记得带显式参数。一句话收束机器选通道形态定适配器选定即锁定——边界之内照做边界之外不幻想。【免费下载链接】reaReverse engineer anything with agents, from app behavior down to native binaries.项目地址: https://gitcode.com/GitHub_Trending/rea2/rea创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考