Frida学习笔记（二）：环境搭建一条龙

type

Post

status

Published

date

May 19, 2026

slug

summary

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

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

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

真机 vs 模拟器对比

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 的整体通信链路——后面所有报错都能用这张图定位到具体环节：

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、frida-ps、frida-trace 等命令行工具，你在终端中直接使用它们与设备通信。frida 是 Python 绑定库，当你需要编写 Python 自动化脚本时，你会 import frida 来使用它。

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

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

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

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

2.2 设备端安装（frida-server）

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

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

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

`getprop` 输出	下载版本	典型场景
`arm64-v8a`	`frida-server-X.Y.Z-android-arm64`	现代真机（2016年以后的手机几乎都是 arm64）；Apple Silicon Mac 上的 ARM AVD 也走这条
`armeabi-v7a`	`frida-server-X.Y.Z-android-arm`	旧款真机（较少见）
`x86_64`	`frida-server-X.Y.Z-android-x86_64`	x86 PC 上的 MuMu、雷电等主流模拟器
`x86`	`frida-server-X.Y.Z-android-x86`	部分旧版模拟器或 32 位模拟器

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：

第三步：启动 frida-server。

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

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

第四步：验证连接。

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

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

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

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

当 frida-tools 和 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 监听一个随机的非标准端口。

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

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

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

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

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

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

注意：这些只是基础的反检测手段。高级的 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 权限。

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

Gadget 注入流程：PC 文件改造 → 设备运行时加载 → 远程接入

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

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

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

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

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

性能与安全提示：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 即可。

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 注入的前置工具。

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 可以快速完成一些常见操作：

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

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

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

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

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

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

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

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

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

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

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

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

六、常见问题排查指南

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

常见问题排查流程

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

6.1 unable to communicate with remote frida-server

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

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

第二步，确认版本匹配：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 模式会拒绝这种非标准操作。

解决方法：

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

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

有两种可能。

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

第二种是 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() 指定参数类型来选择具体的重载：

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

6.5 frida-server 下载慢

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

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

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

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

7.1 启动 frida-server 的 Shell 脚本

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

7.2 快速 Hook 的 Shell 函数

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

使用提示：添加到 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，再考虑反检测。