[原创]Frida 集成工具-开源项目-看雪安全社区｜专业技术交流与安全研究论坛

# 基于Windows的Android Frida 动态调试工具

项目开源地址：

- <a href="elink@daeK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6y4k6h3&6Y4P5U0y4Q4x3V1k6t1L8$3!0C8k6i4u0K6">Mengz3/Hookers</a>

最近一直在整理自己平时做 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 界面

主界面如下：

![](upload/attach/202604/962430_DUP4X2SHFVT57AW.webp)

如果只是从界面看，这个工具最核心的是中间这块调试工具区：

![](upload/attach/202604/962430_WB697SWTEXFD3AE.webp)

这里主要对应三类动作：

- 脚本生成
- 对象分析
- 页面查询

比如：

- 输入 `com.demo.Test` 或 `com.demo.Test:onCreate`，可以直接生成 Hook 脚本
- 输入对象 ID、类名或 View ID，可以直接做对象 / View 信息查询
- 不输入额外参数，也可以直接看当前 App 的 Activity / Service 信息

这些动作底层都不是 GUI 自己拼字符串，而是统一走 `rpc.js` 和 `RpcService`。

---

## 4. 动态演示

GUI 主流程演示：

![](upload/attach/202604/962430_F3QB83N9PBM9GGW.webp)

Hook 注入过程：

![](upload/attach/202604/962430_42E2PB8S3G25ZXV.webp)

当前比较推荐的使用顺序是：

1. 启动 GUI
2. 点击“准备环境并刷新 App”
3. 选择目标 App
4. 如有需要，初始化工作目录并拉取 APK
5. 选择脚本，或者直接生成新的 Hook 脚本
6. 选择 `Attach` / `Spawn`
7. 点击“开始注入”
8. 在右侧日志区查看输出，或者继续做 Activity / Object / View 查询

---

## 5. 项目亮点

### 5.1 每个 App 一个工作区

项目会为每个包名生成独立目录，例如：

```text
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：

- `DeviceService`
- `WorkspaceService`
- `SessionService`
- `RpcService`

这样 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. 开源地址

项目开源地址：

- <a href="elink@5b5K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6y4k6h3&6Y4P5U0y4Q4x3V1k6t1L8$3!0C8k6i4u0K6">Mengz3/Hookers</a>

参考项目：

- <a href="elink@d54K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6o6M7X3g2V1K9i4c8f1L8$3&6W2i4K6u0r3K9r3!0G2K9$3g2J5">CreditTone/hooker</a>

如果大家平时也在做 Android Frida 调试，欢迎试用和提建议。  
如果某些常用分析动作值得继续工具化，我也可以继续往里补。

冰与火的战歌：Windows内核攻防实战高级班！从零到实战，融合AI与Windows内核攻防全技术栈，打造具备自动化能力的内核开发高手。

最后于 2026-4-30 16:01 被Mengz3编辑，原因：