-
-
[原创]Frida 集成工具
-
发表于: 3天前
-
基于Windows的Android Frida 动态调试工具
项目开源地址：
最近一直在整理自己平时做 Android 动态调试时的重复劳动，最后把它们收敛成了一个本地工具：Hookers。
它不是一个“通用 APK 分析器”，也不是单纯的 Frida 脚本集合，而是把下面这条常见链路工程化了：
- 连接 ADB 设备
- 检查 root / Magisk
- 启动匹配架构的
frida-server - 部署
radar.dex - 刷新 App 列表
- 选择目标 App
- 初始化该 App 的独立工作区
- attach / spawn 注入 Frida JS
- 查询 Activity / Service / Object / View
- 生成指定类或方法的 Hook 脚本
平时这些步骤单看都不复杂，但一旦你连续分析多个目标 App，就会出现几个很烦的问题：
- 每次都要重复准备环境
- 每次都要重新整理脚本目录
- 不同 App 的脚本、APK、输出文件容易混在一起
- attach / spawn、页面查询、对象查询这些动作没有统一入口
- 想把这套流程交给别人复现时，口头说明成本很高
所以我做了这个工具，把“设备准备 -> 选 App -> 建工作区 -> 注入 -> 查询 / 生成脚本”串成了一套可复用的工作流。
1. 这个工具适合谁
更适合这些场景：
- rooted Android 设备上的 Frida 动态调试
- 经常需要对单个目标 App 持续分析的人
- 希望把脚本、APK、输出结果按包名独立管理的人
- 需要 GUI 辅助，而不是全程手敲命令的人
不适合这些场景：
- 非 root 设备
- 只做静态分析
- 想找一个跨平台、零环境依赖的方案
2. 当前已经能做什么
基于当前代码，这个项目已经支持：
- 自动连接 ADB 设备并检测 root / Magisk
- 按 CPU 架构选择并启动
frida-server - 部署
radar.dex - 枚举设备上的 App，并把目标 App 拉到前台或以 spawn 方式准备注入
- 为每个包名生成独立工作区
workspaces/<package>/ - 自动复制内置 Frida JS 模板并拉取目标 APK
- 通过 GUI 或 CLI 发起 attach / spawn 注入
- 通过
rpc.js查询 Activity / Service / Object / View 信息 - 通过类名或
类名:方法生成 Hook 脚本
对我自己来说，最有价值的不是“它也能 Hook”，而是：
- 每个 App 有自己的工作目录
- 切换目标时不容易把脚本和产物搞混
- 常见调试动作在 GUI 里能直接点
- 这套流程更容易复现、更容易交给别人用
3. GUI 界面
主界面如下：
如果只是从界面看，这个工具最核心的是中间这块调试工具区：
这里主要对应三类动作：
- 脚本生成
- 对象分析
- 页面查询
比如：
- 输入
com.demo.Test或com.demo.Test:onCreate，可以直接生成 Hook 脚本 - 输入对象 ID、类名或 View ID，可以直接做对象 / View 信息查询
- 不输入额外参数，也可以直接看当前 App 的 Activity / Service 信息
这些动作底层都不是 GUI 自己拼字符串，而是统一走 rpc.js 和 RpcService。
4. 动态演示
GUI 主流程演示：
Hook 注入过程：
当前比较推荐的使用顺序是：
- 启动 GUI
- 点击“准备环境并刷新 App”
- 选择目标 App
- 如有需要，初始化工作目录并拉取 APK
- 选择脚本，或者直接生成新的 Hook 脚本
- 选择
Attach/Spawn - 点击“开始注入”
- 在右侧日志区查看输出，或者继续做 Activity / Object / View 查询
5. 项目亮点
5.1 每个 App 一个工作区
项目会为每个包名生成独立目录，例如：
workspaces/
└─ com.example.demo/
├─ attach.bat
├─ spawn.bat
├─ kill.bat
├─ objection.bat
├─ hooking.bat
├─ SomeApp_1.2.3.apk
└─ js/
├─ okhttp.js
├─ url.js
└─ ...
这样做的好处很直接：
- 不同目标 App 的脚本不混
- APK 不混
- 输出产物不混
- 后续回头看历史分析时更清楚
5.2 GUI 和 CLI 共用同一套核心能力
我没有把 GUI 写成一套独立逻辑，而是把核心能力拆成了几个 service：
DeviceServiceWorkspaceServiceSessionServiceRpcService
这样 GUI 和 CLI 只是两种入口形式，底层能力是一套。后面如果继续做 agent 接口或者 MCP，也更容易接。
5.3 GUI 里的查询动作已经不只是“摆设”
目前 GUI 里这些按钮都已经能直接工作：
- 生成 Hook 脚本
- 对象信息
- 对象解释
- View 信息
- 查看 Activity
- 查看 Service
- 重启 App
也就是说，它不是一个“只能选脚本然后启动”的启动器，而是已经承接了一部分常见调试动作。
5.4 最近还补了一个细节修复
之前在 spawn 注入后点击 查看 Activity，有些 ROM/时序下会误判“目标 App 不在前台”。这个问题最近已经补过：
- 如果当前 GUI 已经有活动 Hook 会话，并且 PID 有效
- 那么页面查询类动作会优先复用当前上下文
- 不再一律强依赖新的前台检测
这个改动对 spawn 场景下的稳定性帮助比较明显。
6. 当前边界和限制
先把边界说清楚，避免误解：
- 当前主要面向 Windows
- 强依赖 rooted Android 设备
- 当前
frida-server资源内建主要覆盖arm/arm64 - 项目仍然偏“个人逆向工作台”，不是大而全的平台
- GUI 虽然已经可用，但我还在持续整理结构
所以它更像是：
把我自己平时的 Android Frida 动态调试流程，整理成了一个可复用、可扩展的本地工作台。
7. 后面准备继续做什么
接下来我比较想继续补这几件事：
- 让核心能力更结构化，方便 agent / MCP 接入
- 增加更标准的非交互接口
- 继续收编 GUI 中高频分析动作
- 增加环境自检和一键启动脚本
- 继续优化 README / 演示材料 / 使用文档
如果后面把这层能力彻底结构化，我希望它不只是“人手点 GUI”，而是 agent 也能稳定理解并调用。
8. 开源地址
项目开源地址：
参考项目：
如果大家平时也在做 Android Frida 调试，欢迎试用和提建议。如果某些常用分析动作值得继续工具化，我也可以继续往里补。
[培训]《冰与火的战歌：Windows内核攻防实战》！从零到实战，融合AI与Windows内核攻防全技术栈，打造具备自动化能力的内核开发高手。
|
|
|---|---|
