我们绕过了 GarudaDefender 整套 Frida 检测,但这已经不是重点了

近年来商业移动端 RASP 越来越卷。Garuda 系列从去年下半年开始在反作弊和金融风控圈子里频繁出现,把代码混淆、完整性校验、环境检测、反 Hook、网络保护、远程策略这一堆东西全栈打包,被很多团队当成新一代客户端防护的参考样本。前阵子接到一个 GarudaDefender 的分析需求,我用 Hermes Agent 当主驱动,花了两天时间,把它的告警链路从 Java 层 SystemAlert 弹窗一路追到 native 层 hash_crc 校验,绕过了它的全部 Hook Detected / Malicious framework detected / Root Detected 检测。能拿下这种规模(21MB 混淆 so、函数上万、双 SO 协作)的商业 RASP 当然有意义。然而,和我在此之后注意到的事情比起来,这次绕过就不算什么了。虽然不是重点,作为背景还是先简单说一下。GarudaDefender 的核心检测逻辑都在 libkikypspro.so 里,通过 libcrackme.so 的自定义 dlsym 跳板间接调用。Java 层 SystemAlert.onCreate 是 native 方法,真实业务在 libkikypspro.so + 0x37A754,后续经过 sub_68BD10 调度,最终由 sub_64B840 构造并显示 AlertDialog。所有弹窗的源头,是 sub_AB31A0 里的一处 hash_crc 一致性校验:把 X23 强制设为 X0 让校验恒等,再把 14 个环境检测函数的返回值统一替换为 0x64(在该样本族中是"通过"状态码),整个 RASP 就被静默了——主页面 root 检测正常,弹窗不再出现,Frida 注入完全无感。整个绕过过程并不简单。21MB 混淆 so、函数上万、间接调用一抓一大把,反编译经常因为混淆给出错的伪代码,光定位 SystemAlert 弹窗的真实入口按传统方法就可能耗掉一两天。但说到底,这仍然是任何有经验的逆向工程师都能做到的事情,谈不上有多新鲜。让我决定把这次分析认真写成长文的,是另一件事。时间紧,这次没按老办法走。我把 Hermes Agent 接进来当主驱动,自己只负责出假设、审证据、定方向,剩下查 xref、跑 decompile、写 Frida 脚本、对栈、改返回值这些事全部丢给 Agent 去做。事情的转折发生在分析的第三天下午。那天我在追 sub_61482C 的上游 caller,原本计划手动反编译十几个候选函数,根据形态判断哪个是真正的告警处理器。Hermes 跑完一轮工具调用之后,在日志里多出了一行我没下达过的命令:——难道 Hermes 自己创建了一个逆向方法论的 Skill?我打开那个文件:我反复确认了对话历史——之前我从来没让 Hermes 总结方法论,更没让它创建 Skill。它是自己做的。后面几天我顺着这套机制观察下去。Hermes 一共自主沉淀了 7 个跟 GarudaDefender 系列分析直接相关的 Skill:每一个 Skill 都不是"sub_61482C 在 0x61482C"这种一次性偏移结论,而是"如何在新版本中重新定位 sub_61482C 等价物"的可执行方法论。这意味着 GarudaDefender 下个版本 v4.5.x、v5.x 出来,符号重新混淆,本文里所有具体地址都会作废——但只要加载这 7 个 Skill,Hermes 会按方法论在新偏移上自动重新定位、自动生成新版本的 Frida 脚本。得出这个结论后,我非常震惊。但反复检查之后还是确认了:分析开始之前,这些 Skill 一个都不存在,~/.hermes/skills/reversing/ 目录甚至是空的;一切都是 Hermes 在分析过程中的自主行为。也就是说,没有人为提示,没有预置的方法论模板,没有外部审计——Hermes 在做完一次 RASP 逆向分析之后,自己把这次分析的全套方法论提取了出来,变成了下次面对同家族样本时可以直接复用的能力。兴奋之余,我开始想:这一切是怎么发生的?翻 Hermes 源码,run_agent.py 里有两个计数器:每当工具调用次数超过阈值,Hermes 会 Fork 一个 Review Agent 重新审视整段对话,把值得沉淀的经验写成 Memory 或 Skill。这套机制最初设计是给 Agent 积累用户偏好和工作流程用的——并不是为了逆向工程方法论沉淀。然而,用户偏好是经验,工作流程是经验,逆向方法论也是经验。由于我反复多次按相似模式定位 sub_61482C、sub_AB31A0、sub_81DDF0 这一类函数,机缘巧合之下,Hermes 忽然意识到"这套查 mutex + 筛 caller + 形态匹配的流程值得沉淀",于是自己调用 skill_manage 把它写成了 Skill。读过玄武实验室那篇 Hermes Agent 自主防御网络攻击的文章的人应该会觉得眼熟——同一套 Review 机制,同一个 skill_manage 工具。区别只在于:他们触发的是"安全免疫"——在反复遭受攻击后,Hermes 自己建立起了对网络攻击的免疫系统;而我触发的是"逆向方法论沉淀"——在反复执行同类逆向操作后,Hermes 自己把这些操作的共性抽取成了可复用的 Skill。换个说法,Hermes 的这套 Review 机制本质上不只是一套安全免疫系统,而是一套通用的经验适应性沉淀系统:安全是经验,逆向方法论是经验,任何在对话里反复出现的高价值模式都可能被它识别、提取、固化。这一次,我恰好把它用在了商业 RASP 对抗这个场景里,于是看到了它在另一个方向上的涌现行为。所以本文 1-19 章是这次跟 GarudaDefender 对抗的具体过程记录,但真正值得关注的是第 20 章——那里会详细展开 Hermes 自主沉淀出来的 7 个 Skill 是什么样的、怎么在新变体上跑的、以及为什么这套"Agent 自主方法论沉淀"的范式可能改变整个商业 RASP 对抗的工作流。我以为我在分析 GarudaDefender,但其实是这次分析,让我看到了 Agent 时代逆向工程的新形态。一个具体的绕过结果只对一个版本有效,但一套被 Agent 自己内化的方法论,只要 RASP 家族的行为模式没变,就能持续生效。和这比起来,绕过本身当然就不算什么了。本文章的分析过程使用 Hermes Agent 辅助记录分析日志、整理 IDA 静态分析结果，并配合 Frida 脚本进行动态验证。实验前需要先确认本地已经可以正常调用 hermes：本文章环境中使用的版本信息为：可以使用下面命令检查 Hermes Agent 运行环境：如果是首次使用，先完成 Hermes Agent 初始化和认证配置：动态分析时，通过 Hermes Agent 执行 Frida 命令，由 Frida 连接目标设备并注入脚本。本文实际运行脚本的方式为：其中 ok.js 是本文最终使用的 Frida 脚本，负责等待 libkikypspro.so 加载、安装检测绕过点，并 hook sub_61482C

...(已截断)

---
来源: 看雪论坛
原文链接: https://bbs.kanxue.com/thread-291158.htm

本文在r0ysue老师指导下完成

分析的很细致，思路很清晰。结果也明确。特别是结合Hermes，AI真的越来越能打了

非常牛x的文章，关键这篇文章代表了未来逆向的主要方向，很赞！！！

另外能提供ai的skill就更好了

看看

感谢分享

大佬牛逼！最想要的还是那份有价值的skill

先收藏，慢慢领会。

牛逼，感謝分享

tql

THX

很强

最近碰到个promon的 一样操作 分析巨费劲

感谢分享