我记得第一次接触frida的时候，总觉得"手动hook"是最初级的功能，不值得专门开一篇来聊。但真正用了半年之后发现，手动hook恰恰是效率最高的调试形态之一。它不需要写完整脚本，不需要重新编译，不用重启App，像给运行中的程序装了一个临时显微镜，想看哪里就照哪里。这篇记录就是frida之HOOK篇的第二篇，重点讲手动hook的完整玩法：从环境准备、连接方式，到核心API的拆解、实战案例和排错经验。适合刚入门动态插桩的读者，也适合那些一直写脚本、但很少在命令行里逐句调试的人。
"手动hook"的一个直观理解是：frida把一段JavaScript注入到目标进程里，你可以在命令行中逐句输入、回车执行、观察结果。和提前把脚本写进文件里再一次性注入相比，手动的好处是现场感强、反馈即时。尤其当你不确定目标App的内部结构时，手动hook能帮你像侦探一样一步步试探，而不是一上来就写一大堆可能全部跑偏的代码。
1. 为什么我还在用手动hook：快速验证场景下的效率真相
1.1 手动hook与脚本化hook的分界线
手动hook指的是在frida提供的交互式控制台（也就是REPL）里，逐句输入JavaScript脚本并立即执行。它和脚本化hook最大的区别不是能力，而是使用节奏。脚本化通常把逻辑写成.js文件，用frida -l或frida -U -f 包名 -l 脚本一次性加载，适合已验证好的固定逻辑、批量hook、监控统计这类重复性任务；手动hook则适合探索阶段——类名不确定、方法签名不确定、App里有多个同名类或者有各种重载，你先打印一遍看看，再决定下一步怎么处理。
我个人的分界线很简单：如果这个hook逻辑需要超过3分钟来思考怎么写，那说明我还不了解目标，先手动摸清楚；如果逻辑已经稳定，我会把它固化成脚本。这个顺序反过来会经常踩坑，因为一次性写完的脚本有大量猜测成分，猜错了整个会话都要重来，效率反而更低。所以我在讲手动hook的时候，特别强调"探索"两个字，这不是一种低级的用法，恰恰是动态调试最本源的做事方式。
1.2 手动hook的工作流：附加、选择、替换、观察
手动hook的工作流其实只有四步：附加（attach）——选择类（use）——替换方法（implementation）——观察/操纵。听起来简单，但每一步都有讲究。附加决定你要不要保留App当前运行状态；选择类决定你是否真的找对了类加载器；替换方法则涉及重载、入参、返回值、调用栈等细节。每一步的细节我都会在后面的章节里展开。
这里先说总览：输入frida -U -f 包名会用spawn模式冷启动App；输入frida -U 包名会附加到已经运行中的进程。进入控制台之后，看到的是frida的命令行提示符，此时就可以输入JS代码。比如先输入一个最简单的探针，确认当前环境通不通：
Java.perform(function () { console.log("[*] injected and running"); });如果控制台打印出了[*] injected and running，说明注入链路已经通了，可以开始下一步。如果连这一步都没输出，那问题多半出在环境或者连接上，先去检查版本和权限，而不是继续写脚本。这个"先跑通最小例子"的习惯，能帮你在手动hook阶段省下大量无效时间。
1.3 最简环境清单：版本、设备、目标App
环境准备这块我见过的坑比想象中多。最简配置是三样东西：电脑端frida、目标设备上的frida-server、能跑起来的测试App。电脑端frida通过pip安装，目标设备上的frida-server要按设备架构下载对应版本。
这里特别提醒：frida版本和frida-server的主版本号必须一致。比如电脑端是16.x，frida-server必须是16.x，小版本可以不完全一致但大版本一定要匹配。版本不一致的表现通常不是完全连不上，而是连接后立刻断开，或者报"connection closed"这类模糊的错。所以排查连接问题，第一步永远是检查版本。
设备选择上，真机和模拟器都可以。真机需要root或越狱权限，模拟器则要选带root的或者允许system权限的镜像。iOS那边另外有一套基于调试器的启动方式，原理类似，这篇文章先以Android为背景写，因为手动hook在Android上的应用最直观。初学阶段我强烈建议用一个自己写的小Demo来做目标，别一上来就拿商业App练手，否则环境问题和技术问题混在一起，真的很难判断是哪里出了错。
2. 附加进程前必须完成的三个准备：版本、连接、权限
2.1 frida与frida-server的版本对应关系
版本匹配是最常见但最容易被忽略的准备项。我的检查顺序是：
frida --version拿到电脑端版本号之后，再进设备执行：
./frida-server --version对比两个版本号，主版本不一致就替换frida-server。如果你用的是Python的frida-tools，还需要注意pip安装的frida和frida-tools其实是两个东西。frida是引擎库，frida-tools是命令行工具，安装完frida-tools之后frida命令就有了，但frida这个Python模块可能不是最新版。升级时最好一起升：
pip install -U frida frida-tools反过来，如果电脑端版本更新了，frida-server没有更新，就会出现连接上之后"connection closed"这种玄学问题。我特别强调这点，是因为大量求助信息都是这个原因引起的，但不是每个报错都会直接告诉你版本不匹配。我自己曾经在一个模拟器上连着三次连接中断，最后发现是模拟器镜像里的frida-server版本停留在15.x，而电脑端已经升到16.x。替换成对应版本之后，一路通畅，什么问题都没有了。
2.2 USB连接与远程连接的取舍
默认情况下，frida通过USB附加设备，命令是：
frida -U -f com.example.sampleapp其中-U表示USB设备。如果你的电脑同时连着多个设备，可以用-l指定设备ID：
frida -U -l emulator-5554 -f com.example.sampleapp远程连接则是把frida-server部署在一台机器上，本机通过网络连接：
frida -H 192.168.x.x:27042 -f com.example.sampleapp远程连接在实际调试中不多用，因为多了一层网络传输，不仅容易暴露行为，稳定性也受网络波动影响。在模拟器场景下倒是有一类特殊用法：模拟器本身的adb端口转发。我见过有人通过adb forward把设备端口映射到本机，再用-H连，这本质上还是USB，但确实能解决部分模拟器的兼容问题。
选择USB还是远程，我一直坚持能用USB就不用远程。不是因为配置复杂，而是手动hook讲究的是即时反馈，少一层网络中转，错误定位就少一个变量。尤其是你要观察多个方法之间的调用关系时，网络抖动带来的延迟会让人误判执行顺序。
2.3 权限不足与多进程附加的常见陷阱
frida-server启动时需要有足够的权限去读写目标进程内存。Android真机上，frida-server通常放在/data/local/tmp，然后用root权限启动：
adb push frida-server /data/local/tmp/ adb shell su chmod 755 /data/local/tmp/frida-server /data/local/tmp/frida-server &权限不足的直接表现是能启动frida-server，但附加进程时报"Failed to attach: permission denied"或者直接"process not found"。后者容易被误判为进程不存在，实际上进程在跑，只是你没权限访问。
模拟器场景稍有不同，很多模拟器自带root，不需要额外su，但要关注frida-server启动之后有没有被内部的清理机制杀掉。某些模拟器的内核会限制ptrace操作，frida本身又依赖ptrace完成注入，这时候附加会失败或者注入后无响应。我的建议是：真机优先，其次是公认对frida支持较好的镜像，最后再考虑特殊手段。
还有一个特别容易忽略的点：Android App经常是多进程架构。包名对应的可能是主进程，但目标逻辑运行在带后缀的子进程里，比如com.example.sampleapp:push。你附加主进程，却hook不到子进程里的方法，排查半天还以为是代码写错了。先执行一次frida -U -ps看看当前设备上到底挂着哪些进程，确认你要附加的是哪一个，再写hook逻辑，能省下大量弯路。
3. 核心API的一次完整实操：从命令进入控制台到打印调用栈
3.1 启动会话的两种方式：attach与spawn
手动hook的第一步不是写代码，而是决定用哪种方式启动会话。
# 附加到正在运行的进程 frida -U com.example.sampleapp # spawn方式：冷启动App并暂停在入口处 frida -U -f com.example.sampleappattach方式适合App已经在运行、你想在某个状态下手动hook的场景。比如App已经登录，你想hook后续的请求加密函数，这时候用attach，能保留当前所有内存状态和会话信息。
spawn方式的优势在于时机：App在启动早期往往就完成了大量初始化，包括各种SDK的检测、代码的加载。如果hook太晚，关键函数已经执行过一轮，你就错过了观察窗口。用-f参数冷启动，frida会在App启动的早期注入，等你在控制台输入%resume回车，App才开始继续跑。也就是说，你有充分时间在启动流程的关键函数上设置hook。
这里有个操作细节：spawn模式进入控制台之后，App其实是挂起状态。如果你忘记输入%resume，会发现App一直停在空白页，半天没反应。这不是脚本写错，而是App还等着你放行。我见过有人在这个状态下反复重启frida，其实是白费功夫。
3.2 Java.perform与Java.use：选择类与进入运行时
进入控制台之后，绝大多数手动hook操作都包在Java.perform里：
Java.perform(function () { var MainActivity = Java.use("com.example.sampleapp.MainActivity"); console.log("class loaded"); });为什么一定要包Java.perform？因为frida注入之后，并不保证你的JS代码运行在Java的线程上下文里。要操作Java层的类、对象，必须先切换到Java运行时环境。如果不包，可能会报找不到Java类，或者在调用某些Java API时行为异常。你也可以在控制台直接输入Java.perform(...)一整行，但手工换行很麻烦，所以我一般会先输入Java.perform(function() {，回车，再写里面的内容，最后补});。
Java.use是选择器，参数是完整的类名。包名必须完整，只写类名会报"not found"。值得提醒的是，有些类不在默认的类加载器里，尤其是插件化、热修复的App，类可能是运行中动态加载的。这种情况下Java.use直接找不到。手动hook阶段遇到这个情况，可以先Java.enumerateLoadedClasses跑一遍，看目标类到底存不存在，再决定下一步。
3.3 重载辨析：同名方法的唯一定位
Java里方法重载是常态。同一个方法名可能有多个签名，比如：
public void login(String username) public void login(String username, String password)调用Java.use之后直接写：
MainActivity.login.implementation = function (username) { console.log("login called"); return this.login(username); };只要存在重载，frida就会报"has more than one overload"，提示你要用.overload()指定签名。指定方式如下：
MainActivity.login.overload("java.lang.String").implementation = function (username) { console.log("[*] first login overload"); return this.login(username); }; MainActivity.login.overload("java.lang.String", "java.lang.String").implementation = function (username, password) { console.log("[*] second login overload"); return this.login(username, password); };overload括号里的参数就是Java方法的形参类型，用完整类名表示，基本类型则用小写的int、boolean、byte[]等。返回值类型不需要写，这一点和Smali签名不一样，别搞混。
判断到底有哪些重载，最省事的方法还是让frida帮你列：
MainActivity.login.overloads.forEach(function (overload) { console.log(overload); });这里会打印每个重载的参数列表。我在实际调试里，这个使用频率非常高，比去看Java代码还快，因为App经常做混淆，静态代码看到的签名和运行时的往往有出入。
3.4 修改参数、拦截返回值与打印调用栈
手动hook的一个核心价值就是"操纵"——不只是看，还能改。修改参数最常见的写法：
MainActivity.login.implementation = function (username, password) { var newPassword = "test123456"; console.log("[*] original password: " + password); return this.login(username, newPassword); };这里的关键是this.login(...)——在implementation函数内部，this指向原方法的Java实例，调用this.login就是调用原方法实现。如果你写的是MainActivity.login(...)，那就变成了自己调自己的死循环，直接栈溢出。这是新手最容易犯的错。
拦截返回值更直接：
MainActivity.checkLogin.implementation = function () { console.log("[*] checkLogin called, forcing true"); return true; };这种"无条件改写结果"的方式在验证逻辑、判断某个分支是否影响整个流程时特别有用。但我必须强调，本文讨论的只是技术验证层面的用法，用来确认某个判断点是否关键，而不是去实际绕过什么安全机制。
打印调用栈是理解调用链的高频需求，实现方式是在implementation里调用Java的异常栈：
MainActivity.checkLogin.implementation = function () { console.log(Java.use("android.util.Log").getStackTraceString(Java.use("java.lang.Exception").$new())); return this.checkLogin(); };或者直接打印Thread.currentThread()的栈信息。手动hook本身不持久，适合一次性观察调用链，抓完再固化到脚本里做长期跟踪。
4. 实战：手动hook登录校验函数，从打印参数到主动调用验证
4.1 先摸清目标方法：动态打印比静态分析更可靠
这一节用一个虚构的测试应用做案例。假设目标App的包名是com.example.sampleapp，登录入口在MainActivity里，有一个checkLogin方法，看起来是本地校验密码与服务器返回的session是否合法的。
在没有源码的情况下，第一步是确认这个方法是否存在。动态方式很简单：
Java.perform(function () { var MainActivity = Java.use("com.example.sampleapp.MainActivity"); console.log(MainActivity.checkLogin); });如果打印出类似<method: ... checkLogin()>，说明类和方法都能访问到。如果报错，先检查包名、类名是否写错，再看是不是有多个重载需要overloads。
我之前实际遇到过一个情况：静态分析工具导出的方法名是a()，但运行时的类已经做了字符串混淆，真正被调用的入口是另一个类。这时静态分析只能提供线索，真正要确认还是得靠动态打印。这个"以动态为准"的思路，在做手动hook时特别重要。
4.2 确认重载并hook：入参出参一次性确认
假设确认checkLogin有两个重载：一个无参版本，一个接收String参数。目标App调用的很可能是带参版本。我们可以把两个都打印出来看：
Java.perform(function () { var MainActivity = Java.use("com.example.sampleapp.MainActivity"); MainActivity.checkLogin.overload().implementation = function () { console.log("[*] checkLogin() with no params"); return this.checkLogin(); }; MainActivity.checkLogin.overload("java.lang.String").implementation = function (token) { console.log("[*] checkLogin(String) token => " + token); var ret = this.checkLogin(token); console.log("[*] checkLogin(String) ret => " + ret); return ret; }; });这种写法能同时观察两个重载，谁被调用一目了然。注意控制台里如果同时定义了多个implementation，前一个会被覆盖，所以每次修改后按Ctrl+R重新加载，或者重新定义整个函数块。
打印返回值这一步很关键。很多人在只打印参数的时候发现返回值异常，但不确定是自己改的还是App本来就这样。我的习惯是把原始返回值先打出来，再决定要不要改。手动hook最大的优势就是可进退，先观察，再干预，而不是一上来就改逻辑。
4.3 修改返回值：从观察到干预的技术验证
当确认了带参版本checkLogin的返回值是boolean之后，可以尝试强制返回true：
Java.perform(function () { var MainActivity = Java.use("com.example.sampleapp.MainActivity"); MainActivity.checkLogin.overload("java.lang.String").implementation = function (token) { console.log("[*] forcing return true"); return true; }; });这个操作会让调用方以为校验通过。在技术验证场景里，这是判断"本地校验是否真的影响流程"的最快方式。如果流程依旧走不通，说明校验逻辑在服务端，或者还有其他本地判断点，那就要继续往调用栈上层找。
但也要说一下，强制改返回值只适合验证"这个判断点是否关键"，不能当作一个通用解法。真实项目里的校验往往叠加了服务端验证、加密传输、完整性校验等多层逻辑，手动hook更多是帮你看清每一层，而不是跳过一整座山。
4.4 主动调用目标方法：Java.choose与实例级操作
有时候不只是想拦截某个方法，还想主动调用它来测试返回值。frida给了Java.choose这个入口，它可以在堆上查找指定类的实例：
Java.perform(function () { Java.choose("com.example.sampleapp.MainActivity", { onMatch: function (instance) { console.log("[*] found instance, calling checkLogin..."); console.log(instance.checkLogin("fake_token_123")); }, onComplete: function () { console.log("[*] scan done"); } }); });Java.choose的回调里，instance就是运行中的MainActivity对象，可以直接调用它的方法。注意onMatch可能匹配到多个实例，你要通过某种特征（比如某个字段值）过滤，否则会重复调用。
主动调用对手动hook来说是非常实用的能力：你可以构造任意参数、直接触发目标函数，观察返回值，不用真的去点App界面。这省去了大量UI操作时间，也让验证逻辑变得可重复。不过要小心主动调用如果内部会联网、会写文件，可能会产生副作用，测试场景最好用可控的测试账号或数据。
5. 手动hook阶段的排错实录：五个高频问题与排查链路
5.1 "unable to connect"：连接问题的四步排查法
手动hook遇到的第一类报错是"unable to connect to remote frida-server"。看到这个，先按顺序查：
首先，USB设备是否被电脑识别，adb devices有没有输出；其次，frida-server有没有在设备上运行，ps -A | grep frida-server；再次，两个版本是否匹配；最后，Android 9以上的某些设备需要关闭SELinux，否则注入被拦：
setenforce 0这四步按顺序查，几乎能覆盖九成连接类问题。很多人在第二步就卡住了——frida-server启动了，但被系统杀掉了或者根本没权限运行。判断方法很简单：启动后等两秒再ps一次，进程还在就说明没被杀。
5.2 "process not found"与spawn秒退：模式与进程的纠结点
attach失败常见提示是"Failed to attach: process not found"。这种情况有几种可能：App进程还没启动、进程名写错了、或者App处于多进程架构里而你附加错了进程。
Android App经常有多个进程，比如主进程、push进程、web进程。包名对应的可能是主进程，但目标逻辑运行在:push进程里。这时frida -U com.example.sampleapp会附加到主进程，你hook不到子进程的方法。解决方式是先看frida -U -ps列出当前所有进程：
frida -U -ps找到带后缀的进程名，比如com.example.sampleapp:push，再用完整进程名附加。之前A同学就卡在这里，反复确认代码没问题，最后一看附加的是主进程，而业务逻辑全在子进程里，换对了进程之后一次就过。
spawn失败的排查思路略有不同，特别是App有启动检测时，spawn往往导致App启动即崩溃退出。控制台表现为进程附加上了，但%resume之后进程秒退。这种时候先确认是不是系统服务问题，再看App是否做了反调试。如果在模拟器上spawn崩溃，优先换真机；如果真机上spawn崩溃，优先检查SELinux和ptrace权限。
5.3 类和方法找不到：包名、混淆与类加载器
"TypeError: ... is not a function"或者"unable to find class"是手动hook里最常见的脚本层报错。排查顺序：先确认类名完整，混淆过的App类名可能变成a、b这种单字母，别用静态分析里的原始名硬套；再确认当前是否真的加载了这个类，用Java.enumerateLoadedClasses过滤；最后确认是不是类加载器不同。
没有在该类上找到方法时，报错会提示"method not found"或"undefined"。这时用overloads打印一遍候选签名，往往会发现方法名大小写或者参数类型和你预期的不同。App经过混淆后，方法名和类名可能面目全非，但签名信息相对可靠。手动hook的好处就是可以随时打印、随时修正，不用反复编译。
5.4 脚本输错但不报错：控制台里的定位技巧
手动hook在控制台里输入错误JS时，不一定会让整个会话崩溃。常见表现是：你输完一大段代码，回车后什么都没有输出，或者报一个具体的JS异常。如果没有输出，多半是语法错误导致整段没执行，控制台不会逐行指错。
我的做法是把脚本拆成一块一块地执行。先输入Java.perform(function () {，回车，再输入里面的内容，最后补});。这样哪一步报错，错误位置就在哪一行附近。别一次性粘贴几十行，手动hook的精髓本来就是"一点点试探"。
另外，记得在关键位置都放console.log，frida控制台的输出是实时的，有日志能立刻确认代码是否执行到某一行。手动hook阶段的console.log打得越密，定位越快。
5.5 加固与反调试：不可附加时的判断顺序
还有一些App接入的安全模块比较强，frida-server启动后进程会主动退出，或者附加成功后，只要一执行Java.perform整个App就崩溃。这类现象常见于加固应用和部分高版本系统组合。我不建议在这篇文章里展开绕过方法，只提醒你：遇到这种情况，问题不一定是你的脚本写错了，而是当前测试环境的对抗强度太高。
我的处理顺序是：先换一个未加固的测试应用验证环境；如果环境没问题，再考虑是不是因为加固导致的功能不可用；如果是，那就该评估是否值得继续投入，还是换一个更可控的目标来做手动hook练习。初学者尤其容易在加固App上花费大量时间，结果环境问题和技术问题纠缠在一起，越排越乱。
手动hook做到最后，你会发现它不是一个单独的技术，而是一种调试习惯。我现在拿到一个陌生App，第一反应永远是开一个控制台，先attach，打印几个类，看看重载，然后顺着调用链往下摸。等摸清楚了，再决定哪些逻辑值得固化成脚本、哪些只是临时验证。这种"先手动，后脚本"的顺序，帮我省掉了大量反复编译和猜测的时间。
最后再分享一个小技巧：控制台里输入%resume、%exit这类命令时，注意区分命令前面的%，这是frida控制台的指令，不是JavaScript语法。我好几次在spawn模式下忘记输入%resume，App一直卡在启动状态，排查了半天还以为脚本写错了。先记住这几条基础指令，手动hook的体验会顺畅很多。
