REA Hopper 桥接层完整解析冷启动与缓存失效【免费下载链接】reaReverse engineer anything with agents, from app behavior down to native binaries.项目地址: https://gitcode.com/GitHub_Trending/rea2/rea第一条请求发出后3 秒内没有任何窗口弹出——但 REA 的 Hopper 桥接其实已在后台把分析器悄悄拉起来了串行队列也已就位等着接收下一个操作。你以为启动是隐藏的其实不是 你以为open --hide --background就能让 Hopper 完全隐藏启动实际上做不到。Hopper 官方的hopper命令行助手内部会发一条 AppleScriptactivate所以窗口仍可能被拉回前台。REA 在类注释里把这事挑明了不替换官方 launcher 就无法可靠地抑制这次激活调用方应把它当作上游约束而不是分析失败BridgeLauncher.ts。这里还有两道硬边界。平台只放行darwin与linux其他系统直接返回unsupported_hostHopperProvider.ts。macOS 上保存的 Hopper database 目标被直接拒绝——launcher 打开.db时没法同时跑桥接脚本HopperProvider.tsDOS MZ/COM 则被指去 Ghidra 的 16 位适配器HopperProvider.ts。从进程拉起走到健康握手要几步 你观察到的是一段静默等待。代码实际做的分四步BridgeLauncher.ts用ps -ax -o command探测 Hopper 可执行文件是否已在运行是则跳过冷启动BridgeLauncher.ts冷启动时执行/usr/bin/open --hide --background -a Hopper.app固定等待常量HOPPER_BACKGROUND_STARTUP_MS 5_000给应用留足加载时间BridgeLauncher.ts进入握手HopperClient 创建/tmp/rea-*私有目录生成randomBytes(32)的十六进制令牌。为什么这么设计冷启动昂贵且有状态先探测再拉起能避免重复唤醒同一个应用。握手本身是认证注入launcher 把令牌写进0o600权限的bootstrap.pyBridgeLauncher.tsHopper 以-Y bootstrap.py加载目标脚本 exec 注入到 Hopper 进程内的hopper_bridge.py后者监听同目录下的bridge.sockUnix 套接字。第一条业务请求是health超时取整个启动截止时间的剩余毫秒数HopperClient.ts。收到正常回应会话才算建立。请求在 FIFO 队列里到底怎么排 底层限制是Hopper 内嵌的 Python 脚本 API 单线程串行同一时刻只能处理一个请求。REA 不去并发它而是把它显式建模成队列类注释写得很直白FIFO that keeps the wire serialized until Hopper actually repliesHopperRequestQueue.ts。类比来说这就像只有一个柜台的银行对应到代码里就是#drain()只有在#active为空时才从队列取下一条HopperRequestQueue.ts。排队时的反馈是可感知的后到的请求会收到queued behind N Hopper request(s)HopperRequestQueue.ts进入执行后每 1 秒播报一次is still running in Hopper (X ms elapsed)的心跳HopperRequestQueue.ts。线路上每一行 JSON 形如{ id, token, method, params }id自增响应按 id 精确关联HopperClient.ts。取消只取消自己排队中的条目被摘除进行中的请求仅在调用侧标记cancelled不打断 Hopper 正在执行的操作。上层可调用activity()拿实时快照——当前 id、操作名、已耗时、排队数HopperRequestQueue.ts。昂贵的 decompile 为什么只算一次 ⚡贵在哪procedure.decompile()是 Hopper 中最昂贵的操作之一而上层对同一函数常做无数次有界投影取签名、取局部变量、取调用者。桥接脚本用两张缓存摊平它hopper_bridge.py伪代码缓存_pseudocode_cache键为(id(document), procedure.getEntryPoint())同一函数无论查多少次decompile()只执行一次搜索清单缓存_search_inventory_cache键为(id(document), kind)存的是不可变、按地址排序的元组快照hopper_bridge.py。缓存键为什么带文档 id同一个进程里可能并存多个文档(id, kind)才能保证互不串键。失效策略是文档粒度的任何分析标注变更都触发_invalidate_pseudocode与_invalidate_search_inventory按id(document)前缀批量删除hopper_bridge.py。一个容易被忽略的点set_address_name等写操作把失效放在finally里即使写入半途失败旧缓存也一定会被清掉hopper_bridge.py。失效为什么是可信底线若不失效重命名之后搜到的还是旧名字反编译出的伪代码也不反映新标注——对一个以证据可追溯为卖点的平台过期缓存比没有缓存更糟。谁拥有哪个进程关什么不关什么 ️所有权划得很清REA 只拥有短命 launcher 的进程组不声称拥有 Hopper GUI 主进程关闭时也只终止明确标记为 owned 的启动进程HopperClient.ts。归属凭据写在ownership.json里记录run_id、进程组 id、父 pid权限0o600HopperClient.ts。前三节的东西在这里汇合握手阶段的私有目录隔离了套接字与 bootstrap排队阶段每条请求强制携带的令牌在桥接端用hmac.compare_digest比对缺令牌直接拒收hopper_bridge.py。并发冲突由目标租约兜底acquireHopperTargetLease 防止两个会话同时打开同一个二进制先失败的一方拿到去关闭那个会话的明确指引。收尾走cleanupHopperSessionHopperCleanup.ts先落定在途请求再删除会话产物全程受HOPPER_SHUTDOWN_TIMEOUT_MS 30_000约束HopperSessionValues.ts。关什么launcher 进程组、私有目录、在途请求。不关什么macOS LaunchServices 管理的 Hopper 应用本体。这套机制把一个交互式 GUI 反汇编器驯化成了可被 Agent 稳定驱动的分析后端。详见docs/native-investigation.md实现集中在src/hopper/。【免费下载链接】reaReverse engineer anything with agents, from app behavior down to native binaries.项目地址: https://gitcode.com/GitHub_Trending/rea2/rea创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考