REA 逆向工程平台选通道指南.hop 数据库、Windows Ghidra P0 与 16 位 DOS 分析避坑【免费下载链接】reaReverse engineer anything with agents, from app behavior down to native binaries.项目地址: https://gitcode.com/GitHub_Trending/rea2/rea手里有一个.hop文件却把它丢给了 Windows 上的 Ghidra或者拿到一个 1985 年的.com期待自动识别就能出反汇编——这类选错通道的起步是 REA 新手最常见的两类弯路。先说结论.hop只走 HopperWindows 10 x64 的原生 PE 交给 Ghidra 的 P0 只读通道16 位 DOS 的 MZ/COM 也走 Ghidra但必须切到 DOS 分析通道。REA 是 AI Agent 驱动的逆向工程平台按自带分析器思路接入你已安装的 Hopper、Ghidra 等工具统一调度。选通道前只需先回答一个问题你的目标文件到底是什么。你的场景推荐通道前置条件容易踩的坑已有.hop反编译数据库HoppermacOS / Linux本机装有 Hopper文件只认扩展名Ghidra 不会打开它Windows 10 x64 的原生 PEWindows Ghidra P0只读NTFS 固定路径Ghidra 12.1.x JDK 21冷启动导入可能超过 330 秒16 位 DOSMZ 或无头.comGhidra DOS 通道文件需可被 MZ 校验或显式声明为 COM.com后缀不会自动识别地址是线性加载地址拿文件之前先问它属于哪条通道判断顺序很简单两步就够。第一步看扩展名。后缀是.hop的它是 Hopper 生成的反编译分析数据库直接归 Hopper 通道后面不再讨论其他引擎。第二步看目标平台的年代和架构。Windows 下的原生 PE 应用走 Ghidra P0上古 16 位 DOS 程序走 Ghidra 的 DOS 通道macOS / Linux 上的 Mach-O、ELF 等现代目标由 Hopper 承担主力。注意REA 选定 Provider 之后不会自动回退。选定的引擎不可用时它直接报错而不是悄悄换一家再试——这条规则对三条通道全部适用。.hop数据库为什么只有 Hopper 能打开.hop是 Hopper 的反编译分析数据库。REA 的识别规则只看扩展名以.hop结尾的文件会被归为analysis-database类型。源码中这段分类逻辑位于 src/application/BinaryTargetResolver.ts 的kind database分支。接受方只有一个Hopper 适配器。Ghidra 不会打开用户提供的分析数据库。背后的设计原则是数据库由 Provider 私有管理领域层不关心其内部格式。所以实践结论是手里有现成的 Hopper 数据库就把它交给 REA Hopper 即可。在 Windows 上这条路不存在Windows 一律走 Ghidra 通道.hop文件在那里没有去处。Windows 上交给 Ghidra P0 之前要确认什么Windows 上的 Ghidra 支持目前处于实验性 x64 状态是一个边界清晰的只读 P0。环境不满足后面一切都白搭先按清单核对。主机Windows 10 x64目标放在本地 NTFS 的固定路径上。工具链Ghidra 12.1.x验证过 12.1.4 JDK 21 或更新的 64 位完整 JDK。目标文件原生非托管、非 DLL 角色之外的角色见下文、非托管的 x86 / x86-64 PE 应用程序。操作集一次只读操作的批量共 25 个覆盖清单、内存与函数分析。⏳ 冷启动提醒Ghidra 冷启动导入可能超过 330 秒验证通道会允许这个时长完整跑完。如果你的客户端超时设置偏短先调大再开始。安全配置不需要你动手。REA 会自动使用打包的 Windows 原生控件私有 DACL 会话目录、127.0.0.1 回环 256 位 bearer token 的认证传输、Job Object 托管的 Ghidra 子进程——无需手动配置任何权限标志。完整指南见 docs/windows-ghidra-p0.md。P0 边界之外同样明确Ghidra GUI 状态与注释、其他架构与格式、托管 PE/CLI它走独立的免执行 Provider、Hopper 专有操作Windows 上没有 Hopper 通道。另外加载镜像检查目前仅独立支持 DOS MZ 格式验证。16 位 DOS MZ 与 COMGhidra 是唯一引擎分析 16 位 DOS 程序时Ghidra 通过MzLoader导入语言固定为x86:LE:16:Real Mode加载段固定0x1000。支持情况分四种MZ 可执行文件自动识别并校验页计数、重定位表、入口点等字段。无头.com需显式指定--target-format dos-com。仅凭.com后缀不够文件还须落在 1~65280 字节范围内。NE / LE / LX 格式明确不支持且损坏的 Windows 头不会悄悄变成 DOS。模拟执行不做。全部是纯静态反编译与反汇编不模拟 BIOS、DOS 中断与设备端口。常用的 CLI 操作rea inspect打开并检查目标rea function/rea instructions做函数级反汇编rea read-bytes读字节rea address-to-file-offset做地址与文件偏移的互查rea inspect-native-load-image独立验证加载镜像结果分verified/mismatch/unsupported三态。细节见 docs/ghidra-dos.md。地址陷阱函数 body 证据里的所有地址都是线性加载地址segment * 16 offset既不是文件偏移也不是真实 DOS 系统的观察值。做交叉引用时别把两者混用。Hopper 对 DOS MZ 没有任何支持声明这条通道不存在第二选择。三个高频问题的直接回答问.hop数据库能交给 Ghidra 处理吗答不能。识别只看扩展名接受方只有 Hopper 适配器Ghidra 不打开用户项目数据库。问Windows 上分析.exeProvider 会帮我自动选吗答Windows 通道固定是 Ghidra P0。选定后不切换不可用时直接失败不存在静默降级到别家的情况。问.com文件后缀正确会自动按 COM 解析吗答不会。COM 没有识别头必须显式声明--target-format dos-com并且文件长度要在 1~65280 字节之间。把这套选择逻辑存进你的工作流下次接到一个目标按这个顺序走先查扩展名.hop直接进 HoppermacOS / Linux别无分号再看平台Windows 10 x64 的原生 PE 交给 Ghidra P0 只读通道遇到 16 位 MZ 或.com仍用 Ghidra 但切到 DOS 通道——MzLoader加x86:LE:16:Real Mode.com记得显式声明格式。延伸阅读docs/windows-ghidra-p0.mdWindows Ghidra P0 完整指南环境、安全机制与验证通道docs/ghidra-dos.mdDOS MZ 与 COM 分析的命令与边界细节docs/native-investigation.md原生二进制调查的完整文档src/application/BinaryTargetResolver.ts目标文件分类的源码实现【免费下载链接】reaReverse engineer anything with agents, from app behavior down to native binaries.项目地址: https://gitcode.com/GitHub_Trending/rea2/rea创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
