Frida学习笔记(二):环境搭建一条龙

本篇目标：搭建一个完整、可用的 Frida 工作环境。不只是走一遍安装流程，而是理解每一步的原因、每个报错的根源，让你以后遇到问题能自主排查。

一、设备选择：真机还是模拟器

在正式安装 Frida 之前，你需要做一个选择——在真机上工作还是模拟器上工作。这个选择看起来无关紧要，实际上会影响你后续几乎所有的分析工作。

1.1 真机的优势与限制

真机（推荐 Google Pixel 系列或一加系列）运行的是原生 ARM 架构，和线上用户的设备完全一致。这意味着：App 加载的 SO 库是 ARM 编译的（arm64-v8a 或 armeabi-v7a），Native 层的行为和真实环境一模一样；设备的传感器、蓝牙、NFC、电池状态等硬件特征都是真实的，不会触发模拟器检测；网络环境也是正常的移动网络或 Wi-Fi，不存在模拟器特有的虚拟网络问题。

限制在于：你需要解锁 Bootloader（简称 BL，是设备启动时验证系统镜像签名的一道安全锁，解锁后才能刷入自定义系统和 Root 方案）并刷入 Root 方案（推荐 Magisk）。不同品牌的手机解锁 BL 的难度差异很大——Google Pixel 只需要一条 fastboot flashing unlock 命令就能完成，一加也相对简单；但华为在 2018 年之后关闭了 BL 解锁通道，小米需要申请并等待一段时间（通常 7 天）。另外，Root 后的手机不建议作为日常主力机使用，因为 Root 本身会引入安全风险——恶意 App 可以利用 Root 权限做任何事情。

设备推荐：如果你准备买一台专用逆向手机，首选 Google Pixel 系列（性价比高、BL 解锁方便、内核源码开放）。

1.2 模拟器的优势与限制

模拟器（推荐 MuMu、雷电、Android Studio 自带的 AVD）最大的优势是方便：不需要额外的手机、开箱自带 Root、可以创建快照随时回滚到干净状态、支持多开。对于学习阶段，模拟器完全够用。

但模拟器有几个你必须知道的技术限制。

第一个问题是 CPU 架构差异。大多数模拟器运行的是 x86 或 x86_64 架构，而绝大多数 Android App 的 Native 库是为 ARM 架构编译的。模拟器通过一个叫 libhoudini 的翻译层（由 Intel 开发，将 ARM 指令实时翻译为 x86 指令）来运行 ARM 代码，但这个翻译层并不完美——有些 Native 代码在翻译后行为会不同，极少数情况下甚至会崩溃。如果你的分析工作涉及 Native 层（特别是加密逻辑在 SO 文件中实现时），在模拟器上可能会遇到意想不到的问题。

注意一个容易混淆的点：模拟器的 CPU 是 x86 的，你安装的 frida-server 也应该选择 x86 或 x86_64 版本（匹配模拟器的架构），而不是 ARM 版本。frida-server 运行在操作系统层面，它需要与操作系统的指令集匹配，与 App 内部使用什么架构的 SO 无关。

第二个问题是 模拟器检测。很多 App（特别是金融、支付、游戏类）会检测运行环境是否是模拟器。常见的检测手段包括：

• 检查 Build.FINGERPRINT 中是否包含 "generic"、"sdk"、"google_sdk" 等关键字
• 检查传感器数量（模拟器通常没有加速度计、陀螺仪、磁力计等物理传感器）
• 检查电池状态（模拟器电量曲线静态，常常恒在某个固定值附近，部分模拟器永远是"充电中"）
• 检查电话号码和 IMEI（不同模拟器默认值不同——例如 Android Studio AVD 默认 IMEI 是 353490069873489，部分厂商模拟器为全 0 或其他固定串）
• 检查 /proc/cpuinfo 中的 CPU 型号（x86 架构的处理器型号与 ARM 不同）

1.3 决策建议

如果你是初学者，正在学习 Frida 的基本用法，用模拟器。省去了 Root 手机的折腾，快照功能也方便你在搞坏环境后快速恢复。如果你要分析的目标 App 有模拟器检测、Native 层加密、或者需要精确模拟线上环境，用真机。长期来看，买一部专门用于逆向的二手 Pixel 手机是值得的投资。

二、Frida 工具链的安装

Frida 的安装分为两部分：电脑端的 frida-tools 和设备端的 frida-server。上一篇说过，这两者的版本必须精确匹配。这一节我们一步一步来，同时解释每一步为什么要这样做。

在动手之前，先看一眼 Frida 的整体通信链路——后面所有报错都能用这张图定位到具体环节：

链路从左到右分三段：PC 端（你写的脚本和发起的命令）→ 传输层（USB / Wi-Fi / 自定端口走的 ADB 隧道）→ 设备端（frida-server 守护进程通过 ptrace 把 frida-agent.so 注入到目标 App 内的 QuickJS 引擎里执行）。本节先把 PC 端和 server 端搭起来，传输层用最常用的 USB 模式即可。

上图展示了完整的搭建流程：左侧是 PC 端的安装步骤，右侧是设备端的部署步骤，两条线在「版本匹配检查」处汇合，最终通过三步验证确认环境就绪。

2.1 电脑端安装（frida-tools + Python 绑定）

Frida 的电脑端工具通过 Python 的包管理器 pip 安装。建议使用 Python 3.7 或以上版本（Python 3.10+ 效果最佳，低于 3.7 的版本可能缺少 Frida 依赖的某些标准库特性）。

# 安装 frida-tools（命令行工具集）和 frida（Python 绑定库）
# frida-tools 依赖 frida，pip 会自动解析依赖关系
pip install frida-tools frida

这条命令实际上安装了两个包。frida-tools 提供了 frida、frida-ps、frida-trace 等命令行工具，你在终端中直接使用它们与设备通信。frida 是 Python 绑定库，当你需要编写 Python 自动化脚本时，你会 import frida 来使用它。

安装完成后，立刻确认版本号：

# 确认命令行工具的版本
frida --version
# 输出示例：16.5.2

# 同时确认 Python 绑定的版本（两者必须一致）
python3 -c "import frida; print(frida.__version__)"
# 输出应该与上面一致：16.5.2

这两个版本号必须完全一致。如果不一致（比如 frida-tools 依赖的 frida 版本与你之前安装的版本冲突），需要强制重新安装：

# 指定精确版本号，--force-reinstall 会强制覆盖已有安装
pip install frida==16.5.2 frida-tools==16.5.2 --force-reinstall

一个经常被忽略的问题：系统中如果有多个 Python（系统 Python / Anaconda 等），先用 which pip && which python3 确认两者指向同一个环境；混乱时直接用虚拟环境隔离：

python3 -m venv frida-env
source frida-env/bin/activate     # Windows: frida-env\Scripts\activate
pip install frida-tools frida
# 退出：deactivate

虚拟环境还顺便解决多项目用不同 Frida 版本的需求（项目 A 用 16.5.2，项目 B 用 16.3.0 各自独立）。

2.2 设备端安装（frida-server）

frida-server 是一个预编译的可执行文件，你需要从 Frida 的 GitHub Release 页面下载与你的设备架构和 frida-tools 版本完全匹配的版本。

第一步：确定设备的 CPU 架构。

# 查询设备的主 CPU 架构
adb shell getprop ro.product.cpu.abi
# 输出示例：arm64-v8a

# 如果你想查看设备支持的所有架构（按优先级排列）
adb shell getprop ro.product.cpu.abilist
# 输出示例：arm64-v8a,armeabi-v7a,armeabi

这条命令的输出决定了你应该下载哪个版本的 frida-server。对照表如下：

Apple Silicon Mac 用户特别注意：M1/M2/M3 系列 Mac 的 AVD 必须选 ARM64 镜像（x86_64 镜像在 ARM 主机上既无 Houdini 翻译也无 KVM 加速，几乎不可用）；因此模拟器架构仍是 arm64-v8a，frida-server 选 android-arm64，不要被"模拟器=x86"的惯性误导。MuMu Pro for Mac 同理也是 ARM 架构。

第二步：下载并部署。

假设你的 frida-tools 版本是 16.5.2，设备架构是 arm64-v8a：

# 从 GitHub Releases 下载
# 地址：https://github.com/frida/frida/releases/tag/16.5.2
# 找到文件：frida-server-16.5.2-android-arm64.xz

# 解压
xz -d frida-server-16.5.2-android-arm64.xz
# 解压后得到一个没有后缀名的可执行文件（约 40-50MB）

# 推送到设备的 /data/local/tmp 目录
# 选择这个目录有两个原因：
# 1. 它对 shell 用户可写（不需要 root 权限就能写入文件）
# 2. 它不受 SELinux 的 neverallow 规则限制（可以执行二进制文件）
adb push frida-server-16.5.2-android-arm64 /data/local/tmp/frida-server

# 赋予执行权限
adb shell chmod 755 /data/local/tmp/frida-server

第三步：启动 frida-server。

frida-server 必须以 root 权限运行，因为它需要使用 ptrace 系统调用来注入其他进程。

# 先确保没有旧的 frida-server 在运行
# 2>/dev/null 将错误输出丢弃（如果没有正在运行的进程，killall 会报错）
adb shell su -c 'killall frida-server 2>/dev/null'

# 以守护进程模式启动
# -D: daemon 模式，frida-server 自身 fork 两次脱离终端，进入后台运行
# &: 兜底用——即使某些设备上 -D 行为异常，& 也能让 adb shell 命令立刻返回而不阻塞
adb shell su -c '/data/local/tmp/frida-server -D &'

这里的 -D 参数表示以守护进程（daemon）模式运行，frida-server 会在后台持续运行并监听来自电脑端的连接请求。默认监听的端口是 TCP 27042。

第四步：验证连接。

# -U 表示通过 USB 连接设备（USB 模式）
# 如果有多台设备连接，需要用 -D <device-id> 指定设备
frida-ps -U

如果一切正常，你会看到设备上所有正在运行的进程列表：

  PID  Name
-----  ------------------------------------------
  312  adbd
  415  surfaceflinger
 1024  system_server
 2048  com.android.launcher3
 3072  com.example.someapp
  ...

如果看到了进程列表，恭喜——你的 Frida 环境已经搭建成功了。如果遇到错误，直接跳到第六节的排查指南。

2.3 版本匹配问题的深度排查

版本不匹配是 Frida 使用中遇到频率最高的错误，值得花篇幅把它讲透。

当 frida-tools 和 frida-server 版本不一致时，你可能会看到以下错误之一：

Failed to enumerate processes: unable to communicate with remote frida-server;
please ensure that major versions match and that the remote Frida has the
feature you are trying to use

或者：

Failed to spawn: unable to find process with name 'xxx'

排查步骤：

# 步骤 1：确认电脑端版本
frida --version
# 记下这个版本号，假设是 16.5.2

# 步骤 2：确认设备端版本
adb shell /data/local/tmp/frida-server --version
# 如果输出不是 16.5.2，就是版本不匹配

# 步骤 3：如果版本不匹配，有两个修复方向

# 方向 A：升级/降级电脑端以匹配设备端
pip install frida==<设备端版本号> frida-tools==<设备端版本号> --force-reinstall

# 方向 B：重新下载匹配电脑端版本的 frida-server
# 前往 https://github.com/frida/frida/releases/tag/<电脑端版本号>
# 下载对应架构的 frida-server，重新推送到设备

一个重要的细节：Frida 的版本号格式是 主版本.次版本.修订号（如 16.5.2），遵循语义化版本（Semantic Versioning）规范。严格三段对齐是稳态做法——不一致时尤其要警惕协议层差异（patch 版本之间偶尔会不兼容）。

版本管理建议：在开始一个新项目时，把当前使用的 Frida 版本号记录到项目文档中（比如 README 或 CLAUDE.md）。如果你同时在多台设备上工作，确保所有设备的 frida-server 都与电脑端版本一致。

三、高级部署方式：应对检测和特殊场景

基础安装方式适用于大多数情况，但在面对有 Frida 检测的 App 或无法 Root 的设备时，你需要了解一些替代方案。

3.1 自定义端口启动（规避端口扫描）

第一篇提到过，frida-server 默认监听 TCP 端口 27042。部分 App 会在启动时扫描这个端口——尝试连接 127.0.0.1:27042，如果能连通，就判定 Frida 正在运行并拒绝启动。

解决方案很简单：让 frida-server 监听一个随机的非标准端口。

# 设备端：指定非标端口启动
# -l: listen，指定监听地址和端口
# 0.0.0.0: 监听所有网络接口（包括 localhost 和 Wi-Fi 接口）
# 31337: 自定义端口号（可以换成任何 1024-65535 之间未被占用的端口）
adb shell su -c '/data/local/tmp/frida-server -l 0.0.0.0:31337 -D &'

在电脑端连接时，需要做一步额外操作——通过 ADB 建立端口转发：

# 在电脑和设备之间建立端口转发隧道
# 效果：电脑上的 127.0.0.1:31337 -> 设备上的 127.0.0.1:31337
adb forward tcp:31337 tcp:31337

# 然后通过 -H 参数指定连接地址和端口（替代 -U 的 USB 模式）
frida -H 127.0.0.1:31337 -f com.example.app -l script.js --no-pause

与 USB 模式（-U）相比，这种方式多了一个 ADB 端口转发的步骤，但换来了对端口扫描检测的规避。App 扫描默认端口 27042 时会发现它没有在监听，从而认为 Frida 不存在。

3.2 重命名 frida-server 二进制文件（规避进程名检测）

有些 App 不只扫描端口，还会遍历 /proc/ 目录检查是否存在名为 frida-server 的进程。具体做法是读取 /proc/<pid>/cmdline 文件，检查其中是否包含 "frida" 字符串。应对方法是把 frida-server 的文件名改成无关名称：

# 复制一份重命名后的可执行文件
adb shell su -c 'cp /data/local/tmp/frida-server /data/local/tmp/myservice'

# 使用重命名后的文件启动
adb shell su -c '/data/local/tmp/myservice -D &'

在 Linux 中，App 检测进程名通常会同时读两个位置：/proc/<pid>/comm（进程短名，最长 16 字节，对应 task_struct->comm）和 /proc/<pid>/cmdline（完整命令行，参数用 \0 分隔）。两者默认都来自可执行文件名——把二进制改名为 myservice 后，这两个文件读出来都是 myservice，绕过基于字符串匹配 frida 的简单检测。

你可以把自定义端口和重命名结合起来使用，进一步降低被检测到的概率：

# 组合使用：重命名 + 非标端口
adb shell su -c '/data/local/tmp/myservice -l 0.0.0.0:31337 -D &'

注意：这些只是基础的反检测手段。高级的 Frida 检测还会扫描进程内存中的特征字符串（如 "LIBFRIDA"、"frida-agent" 等），或者检测 frida-agent.so 在 /proc/<pid>/maps 中的映射。

3.3 Frida Gadget 模式（无需 Root）

如果你面对的设备完全无法 Root（比如公司提供的测试设备，或者特定型号的手机无法解锁 Bootloader），Frida 提供了一种叫 Gadget 的替代方案。

Gadget 的原理是把 frida-agent 打包成一个 SO 库（libfrida-gadget.so），注入到 APK 的 lib/ 目录中，然后修改 smali 代码让 App 启动时主动加载这个库。因为加载动作是 App 自身发起的（通过 System.loadLibrary），不涉及 ptrace，所以不需要 Root 权限。

整个流程分三个阶段，看图比读文字快：

操作步骤概要如下（每一步都有详细的原因说明）：

# 第一步：使用 apktool 解包 APK
# apktool 会反编译 APK 中的资源文件和 smali 代码（dex 的汇编形式）
# d: decode（解码/解包）
# -o: output directory（输出目录）
apktool d target.apk -o unpacked/

# 第二步：下载 Frida Gadget
# 从 https://github.com/frida/frida/releases 下载
# 版本号必须与你电脑上的 frida-tools 版本一致
# 架构选择目标设备的架构（arm64 对应 arm64-v8a）
xz -d frida-gadget-16.5.2-android-arm64.so.xz

# 第三步：将 Gadget SO 放入 APK 的库目录
# 文件名必须以 lib 开头、.so 结尾（Android 的 SO 加载机制要求）
# 如果 APK 同时包含多个架构的 SO（lib/arm64-v8a/ 和 lib/armeabi-v7a/），
# 每个架构目录都需要放入对应版本的 Gadget
cp frida-gadget-16.5.2-android-arm64.so unpacked/lib/arm64-v8a/libfrida-gadget.so

# 第四步：修改 smali 代码，让 App 启动时加载 Gadget
# 需要找到 App 的入口 Application 类或 MainActivity 类的 smali 文件
# 在其 <clinit>（静态初始化块）或 onCreate 方法的最前面添加：
#
#   const-string v0, "frida-gadget"
#   invoke-static {v0}, Ljava/lang/System;->loadLibrary(Ljava/lang/String;)V
#
# 这等同于 Java 代码中的 System.loadLibrary("frida-gadget")
# 注意 1：loadLibrary 的参数不带 "lib" 前缀和 ".so" 后缀
# 注意 2：上面这两行用了寄存器 v0，所以原方法头的 .locals N 必须 ≥ 1。
#         如果原方法是 .locals 0，要先把它改成 .locals 1（或更高），
#         否则 apktool b 重打包会报 "register v0 not defined"。

# 第五步：重新打包
# -b: build（构建/打包）
apktool b unpacked/ -o patched.apk

# 第六步：签名（重打包后原始签名失效，必须重新签名才能安装）
# uber-apk-signer（patrickfav/uber-apk-signer）自动处理 V1(JAR)/V2(APK)/V3 签名方案
java -jar uber-apk-signer.jar -a patched.apk
# 签名后会生成 patched-aligned-debugSigned.apk

安装重打包后的 APK 并启动，App 在初始化时会自动加载 libfrida-gadget.so。Gadget 默认以「等待连接」模式运行——App 会在启动画面暂停（通常表现为黑屏或白屏卡住），等待你从电脑端连接。此时你可以用以下命令连接：

# Gadget 模式下，进程名显示为 "Gadget"
frida -U Gadget -l script.js

Gadget 模式的代价是明显的：你需要重打包 APK，这会改变 APK 的签名。如果 App 内部有签名校验逻辑（很多 App 都有），它会在启动时检测到签名不一致而拒绝运行。此外，每次目标 App 更新版本，你都需要重新走一遍这个流程。

3.4 通过 Wi-Fi 连接（无需 USB 数据线）

在某些场景下（比如需要测试 App 在移动网络下的行为、USB 接口被占用、或者设备物理位置不方便连线），你可以通过 Wi-Fi 连接设备。

# 确保手机和电脑在同一个 Wi-Fi 网络下

# 第一步：通过 USB 连接设备（只需要做一次，用于切换 ADB 模式）
adb devices
# 确认设备已连接

# 第二步：让 ADB 切换到 TCP 模式
# 5555 是 ADB TCP 模式的默认端口
adb tcpip 5555

# 第三步：获取手机的 IP 地址
adb shell ip addr show wlan0 | grep "inet "
# 输出类似: inet 192.168.1.100/24 brd 192.168.1.255 scope global wlan0
# 记下 IP 地址: 192.168.1.100

# 第四步：拔掉 USB 线，通过 Wi-Fi 连接
adb connect 192.168.1.100:5555
# 输出: connected to 192.168.1.100:5555

# 之后的 Frida 命令和 USB 模式完全一样
# -U 会自动检测通过 TCP 连接的设备
frida -U -f com.example.app -l script.js --no-pause

性能与安全提示：Wi-Fi 连接的速度比 USB 慢（延迟通常高 5-10 倍），特别是在传输大量日志时可能会有明显的延迟。在性能敏感的场景（如 Stalker 指令追踪）中，建议还是使用 USB。

四、配套工具链的准备

Frida 是动态分析的核心，但实际逆向工作中你需要一组配套工具协同使用。这一节介绍每个工具的角色和它们之间的协作关系。

4.1 静态分析工具

jadx（必备，免费开源） —— 将 APK 中的 DEX 文件反编译成可读的 Java 源代码。这是你分析一个新 App 的第一步工具：打开 APK，浏览代码结构，搜索关键字定位目标类和方法。jadx 有命令行版本和 GUI 版本，推荐使用 GUI 版本（jadx-gui），它提供了交叉引用（查看谁调用了这个方法）、全局搜索、反混淆映射等功能。从 GitHub（skylot/jadx）下载最新 Release 即可。

# macOS 上可以通过 Homebrew 安装
brew install jadx

# 或者直接下载 Release 包
# https://github.com/skylot/jadx/releases
# 下载 jadx-x.y.z.zip，解压后运行 bin/jadx-gui

IDA Pro（分析 Native 层的首选，商业软件） —— 当关键逻辑在 SO 文件中时，你需要 IDA 来分析 ARM/ARM64 汇编代码。IDA 的反编译器（Hex-Rays Decompiler）可以将汇编代码转换为类 C 伪代码，大幅降低分析难度。IDA 中分析出的函数偏移地址，就是你在 Frida 中用 Interceptor.attach(module.base.add(offset), ...) 时需要的 offset。

4.2 抓包工具

Charles（推荐新手使用，GUI 友好） —— HTTP/HTTPS 代理工具，提供了直观的 GUI 界面来查看请求和响应的详细内容（headers、body、timing 等）。配合 Frida 的 SSL Pinning 绕过使用，可以看到 App 的所有网络流量。Charles 是商业软件但有免费试用（每次使用 30 分钟后自动关闭）。

mitmproxy（推荐进阶用户，支持脚本扩展） —— 命令行 HTTP/HTTPS 代理工具（pip install mitmproxy，默认 8080 端口），最大的优势是支持 Python 插件（addon）。你可以编写 addon 脚本自动修改请求/响应、解码 Protobuf 数据、记录特定 API 的调用频率等。

4.3 APK 操作工具

apktool —— APK 的解包和重打包工具。当你需要修改 APK 的资源文件、smali 代码、AndroidManifest 时使用。也是 Frida Gadget 注入的前置工具。

# macOS 安装
brew install apktool

# 或手动安装
# https://ibotpeaches.github.io/Apktool/install/

uber-apk-signer —— 一键签名工具，可以自动处理 V1（JAR 签名）、V2（APK 签名方案 v2）、V3（APK 签名方案 v3）签名。重打包后的 APK 必须签名才能安装到设备上。从 GitHub（patrickfav/uber-apk-signer）下载 Release 中的 JAR 文件即可——注意作者命名空间是 patrickfav，不要被同名仿冒仓库误导。

4.4 辅助工具

Objection —— Frida 的高层封装，提供了开箱即用的命令行界面。安装方式：pip install objection。Objection 可以快速完成一些常见操作：

# 安装 Objection
pip install objection

# 连接目标 App（自动注入 Frida agent）
objection -g com.example.app explore

# 常用命令示例
# 一键绕过 SSL Pinning
android sslpinning disable

# 列出所有 Activity
android hooking list activities

# 搜索已加载的类
android hooking search classes keyword

# 查看 App 私有目录的路径常量（filesDir / cacheDir / externalStorage 等）
# 注意：env 只输出路径，不下载文件；要导出私有数据请用：
#   android filesystem ls /data/data/<pkg>
#   android filesystem download <path> <local>
env

ADB（Android Debug Bridge） —— Android SDK 自带的调试桥接工具，几乎所有操作都需要它。如果你还没安装 Android SDK，最快的方式是只下载 platform-tools：

# macOS
brew install android-platform-tools

# 或手动下载
# https://developer.android.com/tools/releases/platform-tools
# 下载对应平台的压缩包，解压后将路径添加到系统 PATH

# 验证安装
adb version
# 输出: Android Debug Bridge version 1.0.41

五、第一次连接：验证环境可用

环境搭建完成后，我们来做一个最小化的验证，确认所有组件正常工作。这三个测试分别验证了 Frida 工作链路中的三个关键环节。

5.1 列出设备进程（验证通信链路）

# 列出通过 USB 连接的设备上所有正在运行的进程
frida-ps -U

# 如果你只想看第三方 App（过滤系统进程）
frida-ps -U -a | grep -v "com.android\|com.google\|com.qualcomm"

如果看到进程列表，说明 frida-tools -> USB -> frida-server 的通信链路正常。

5.2 附加到一个系统进程（验证注入能力）

选一个系统进程做测试，避免目标 App 的检测干扰。注意：这是 attach 模式（无 -f），所以需要目标进程已经在运行——先在手机上手动打开"设置"应用、停留在前台，再执行下面的命令：

# 附加到系统设置 App 并执行一段简单的 JS 代码
# -e: evaluate（执行一段 JS 表达式）
frida -U com.android.settings -e "
    // 打印 Frida 工作状态和进程信息
    console.log('Frida is working! PID: ' + Process.id);
    console.log('Architecture: ' + Process.arch);
    console.log('Platform: ' + Process.platform);
"

如果终端输出了 Frida is working! PID: xxxx，说明 Frida 的注入和 JS 执行链路也正常了。

如果遇到 unable to find process with name 'com.android.settings'，说明设置 App 没有在前台运行；先唤起它再重试即可。

5.3 用 Spawn 模式启动一个 App（验证 Java Hook 能力）

# 以 Spawn 模式启动系统计算器或任意 App
# -f: spawn 模式，由 Frida 负责启动目标 App
# --no-pause: 注入脚本后立即恢复 App 执行（不暂停在启动阶段）
frida -U -f com.android.calculator2 -e "
Java.perform(function() {
    // 如果能执行到这里，说明 JS 引擎已成功附加到 ART 虚拟机
    console.log('Java VM attached!');
    // 打印当前使用的 ClassLoader 信息
    console.log('Classloader: ' + Java.classFactory.loader);
});
" --no-pause

如果看到 Java VM attached! 和 ClassLoader 信息，说明 Java 层 Hook 的基础能力也正常了。

到这里，你的 Frida 环境已经完全就绪——通信链路、进程注入、Java 层 Hook 三个核心能力都已验证通过。

六、常见问题排查指南

把实际使用中最常遇到的问题和排查路径集中在这里，方便你以后遇到问题时快速查阅。

上图以流程图的形式展示了四大类常见错误的诊断路径，帮助你快速定位问题所在。

6.1 unable to communicate with remote frida-server

这是最高频的错误。排查路径：

第一步，确认 frida-server 正在运行：

# 检查设备上是否有 frida-server 进程
adb shell ps -A | grep frida
# 或者如果你重命名了进程
adb shell ps -A | grep myservice

# 如果没有进程输出，说明 frida-server 没有成功启动
# 常见原因：
# - 没有使用 su（缺少 root 权限）
# - 架构不匹配（下载了 arm 版本但设备是 arm64）
# - SELinux 阻止了执行
# - 文件权限不正确（忘记 chmod 755）

第二步，确认版本匹配：frida --version 和 adb shell /data/local/tmp/frida-server --version 输出的版本号必须完全一致。

第三步，确认 USB 连接正常：adb devices 应该列出你的设备。如果显示 unauthorized，需要在手机上点击允许 USB 调试。如果显示 offline，尝试拔插 USB 线或重启 ADB 服务（adb kill-server && adb start-server）。

6.2 Failed to spawn: unable to access zygote64 while spawning

这通常是 SELinux（Security-Enhanced Linux，Android 使用的强制访问控制系统）阻止了 frida-server 的操作。Spawn 模式需要 frida-server 与 Zygote 进程（Android 中所有 App 进程的父进程）交互，SELinux 的 Enforcing 模式会拒绝这种非标准操作。

解决方法：

# 临时将 SELinux 从 Enforcing（强制）模式切换到 Permissive（宽容）模式
# Permissive 模式下 SELinux 仍会记录违规但不会阻止操作
adb shell su -c 'setenforce 0'

# 确认当前状态
adb shell getenforce
# 应该输出 Permissive

注意：setenforce 0 只是临时修改，重启设备后会恢复为 Enforcing。如果你需要永久修改，可以在 Magisk 的设置中关闭 SELinux，但这会降低设备安全性。对于专用的逆向分析设备，这个安全风险通常是可以接受的。

6.3 Process crashed: Trace/BPT trap 或 App 闪退

有两种可能。

第一种是你的 Hook 脚本有 bug——比如方法签名不正确（参数类型写错）、返回了错误类型的值、或者在 implementation 中忘记调用原始方法（导致 App 的正常流程被中断）。排查方法是先把脚本简化到最小（只打印一条日志，不修改任何行为），确认简化后的脚本不会导致崩溃：

# 最小化测试：加载一个只打印日志的脚本
frida -U -f com.target.app -e "
Java.perform(function() {
    console.log('minimal test - app should not crash');
});
" --no-pause

第二种是 App 有反 Frida 检测。检测到 Frida 后，App 主动调用 exit() 或触发了一个故意的崩溃（如访问空指针）。这种情况的特征是：即使你加载一个完全空的脚本（frida -U -f com.target.app -e "" --no-pause），App 也会在几秒后闪退。应对方法参见第17篇（Frida 检测原理与深度对抗）；如果同时夹杂 Root 检测或反调试，再补看第16篇（Root 检测绕过）和第18篇（反调试绕过）。

6.4 Error: ambiguous overload 或 cannot find method

ambiguous overload 说明目标方法有多个重载版本（同名但参数类型不同），你需要用 .overload() 指定参数类型来选择具体的重载：

// 错误：直接 Hook 名为 encrypt 的方法，但有多个重载
// ClassName.encrypt.implementation = ...

// 正确：指定参数类型，明确 Hook 哪个重载版本
ClassName.encrypt.overload('java.lang.String', 'java.lang.String')
    .implementation = function(a, b) {
// ...
    };

cannot find method 说明方法名不存在——可能是拼写错误，也可能是代码被混淆后方法名变了（原来的 encrypt 被混淆成了 a 或 b）。这些问题会在第03篇和第04篇中详细讲解。

6.5 frida-server 下载慢

GitHub 在国内访问速度可能很慢。几个替代方案：

# 方案 1：使用代理下载
# export https_proxy=http://127.0.0.1:7890
# wget https://github.com/frida/frida/releases/download/16.5.2/frida-server-...

# 方案 2：使用 gh CLI 工具（配合代理）
gh release download 16.5.2 --repo frida/frida --pattern "frida-server-*-android-arm64*"

另外，一旦下载好 frida-server，建议保留一份备份——只要你不升级 frida-tools 版本，同一个 frida-server 文件可以反复使用。建议按版本号组织目录：

# 建议的本地存储结构
~/frida-servers/
  16.5.2/
    frida-server-16.5.2-android-arm64
    frida-server-16.5.2-android-x86_64
  16.3.0/
    frida-server-16.3.0-android-arm64

七、一键启动脚本：提升日常效率

每次手动输入一长串命令是很低效的。建议你准备以下自动化脚本，把重复性的操作固化下来。

7.1 启动 frida-server 的 Shell 脚本

#!/bin/bash
# start_frida.sh - 一键启动 Frida 工作环境
# 用法: chmod +x start_frida.sh && ./start_frida.sh

# ---- 颜色定义（让输出更清晰）----
GREEN='\033[0;32m'
RED='\033[0;31m'
NC='\033[0m'# No Color

echo"[*] 检查 ADB 连接..."
DEVICES=$(adb devices | grep -v "List" | grep "device" | wc -l)
if [ "$DEVICES" -eq 0 ]; then
echo -e "${RED}[!] 没有检测到设备，请检查 USB 连接${NC}"
exit 1
fi
echo -e "${GREEN}[*] 检测到 $DEVICES 台设备${NC}"

echo"[*] 停止旧的 frida-server..."
# 同时尝试 kill 原名和可能的重命名版本
adb shell su -c 'killall frida-server 2>/dev/null; killall myservice 2>/dev/null'
sleep 1

echo"[*] 启动 frida-server..."
adb shell su -c '/data/local/tmp/frida-server -D &'

echo"[*] 等待 frida-server 就绪（最多 10 秒）..."
# 轮询比固定 sleep 更可靠：慢手机 / 大模拟器上 server 起来要 3-5 秒
for i in $(seq 1 10); do
if frida-ps -U > /dev/null 2>&1; then
break
fi
    sleep 1
done

echo"[*] 验证 frida-server..."
if frida-ps -U > /dev/null 2>&1; then
echo -e "${GREEN}[*] frida-server 运行正常${NC}"
echo -e "${GREEN}[*] Frida 版本: $(frida --version)${NC}"
# 显示设备端版本用于确认匹配
    SERVER_VER=$(adb shell /data/local/tmp/frida-server --version 2>/dev/null)
echo -e "${GREEN}[*] Server 版本: ${SERVER_VER}${NC}"
echo -e "${GREEN}[*] 环境就绪！${NC}"
else
echo -e "${RED}[!] frida-server 连接失败${NC}"
echo"[*] 排查建议："
echo"    1. 确认 frida-server 版本与 frida-tools 版本一致"
echo"    2. 确认 frida-server 有执行权限 (chmod 755)"
echo"    3. 尝试 adb shell su -c 'setenforce 0'"
exit 1
fi

使用方式：chmod +x start_frida.sh && ./start_frida.sh。

7.2 快速 Hook 的 Shell 函数

你可以把以下函数添加到你的 ~/.bashrc 或 ~/.zshrc 中，实现快速操作：

# ---- Frida 快捷命令 ----

# 快速 Spawn 模式 + 加载脚本
# 用法: fspawn com.example.app script.js
fspawn() {
if [ $# -lt 2 ]; then
echo"用法: fspawn <package_name> <script.js>"
return 1
fi
    frida -U -f "$1" -l "$2" --no-pause
}

# 快速 Attach 模式 + 加载脚本
# 用法: fattach com.example.app script.js
fattach() {
if [ $# -lt 2 ]; then
echo"用法: fattach <package_name> <script.js>"
return 1
fi
    frida -U "$1" -l "$2"
}

# 快速列出设备上的第三方 App（过滤系统应用）
fapps() {
    frida-ps -U -a | grep -v "com.android\|com.google\|com.qualcomm\|com.samsung"
}

# 快速启动 frida-server（适合每天开工第一件事执行）
fstart() {
    adb shell su -c 'killall frida-server 2>/dev/null'
    adb shell su -c '/data/local/tmp/frida-server -D &'
# 轮询代替固定 sleep —— 慢手机/大模拟器上 server 起来要 3-5 秒
for i in $(seq 1 10); do
        frida-ps -U > /dev/null 2>&1 && { echo"frida-server OK"; return 0; }
        sleep 1
done
echo"frida-server FAILED"
return 1
}

使用提示：添加到 shell 配置文件后，运行 source ~/.zshrc（或 source ~/.bashrc）让配置生效。之后每次打开终端这些命令都可直接使用。

总结

回顾一下这一篇的核心内容。

设备选择：初学阶段用模拟器足够，涉及 Native 分析或模拟器检测时切换到真机。长期推荐购买一部专用的二手 Pixel 手机（500-800 元的投资，回报极高）。

安装流程：Frida 由电脑端（frida-tools + Python 绑定）和设备端（frida-server）组成。安装过程中最关键的是确保两端版本号精确一致（三段版本号全部匹配），以及 frida-server 的架构匹配设备的 CPU（真机用 arm64，模拟器用 x86_64）。

高级部署：通过自定义端口（规避端口扫描）和重命名 frida-server（规避进程名检测）可以规避基础的检测；Frida Gadget 模式可以在无 Root 设备上使用，代价是需要重打包 APK 并处理签名问题。

工具链：jadx（静态分析 Java 层）、IDA/Ghidra（静态分析 Native 层）、Charles/mitmproxy（网络抓包）、apktool/uber-apk-signer（APK 操作）与 Frida（动态分析）协同工作，形成完整的逆向分析能力。典型工作流是「静态定位 -> 动态验证 -> 深入分析 -> 交叉验证 -> 独立复现」。

排查要点：遇到连接问题先检查三件事——frida-server 是否在运行、版本是否匹配、USB/网络连接是否正常。SELinux 问题用 setenforce 0 临时解决。App 闪退先排除脚本 bug，再考虑反检测。