frida是一款基于JS代码编写的Hook框架，它是一款易用的、可跨平台的Hook框架，介绍我就不多做介绍了，我们直接讲这玩意该怎么用。至于frida的环境配置之类的我就不多讲了，大家可以移步去看看正己大佬的讲解：

《安卓逆向这档事》十三、是时候学习一下Frida一把梭了(上) - 吾爱破解 - 52pojie.cn

我们就直接步入正题，环境配置好后我们需要通过启动命令来注入hook脚本，这里提一个正己大佬没提到的启动命令：

当你觉得每次都要查看进程名麻烦时你可以通过-F代替进程名，因为-F是附加到前台应用，只需要将你要注入的APP处于最前端，然后将进程名替换为-F，这样就会附加到我们要注入的APP。
那么接下来我们开始编写hook代码，我们想要hook就必须拿到我们要hook的类，而要拿到要hook的类那就需要通过以下代码获取类：

我们通过Java.use这个API得到要hook的类后，通过var xxx的方式定义一个变量xxx用于接收这个API执行之后的返回值，也就是接收这个API执行后返回的类。

当我们调用 Java.use("类名") 时必须包裹在 Java.perform() 中，Java.perform(function() { ... }) 是 Frida 中用于操作 Java 环境的核心桥梁，它可以确保使用APP正确的类加载器，Java.perform() 是 Frida 操作 Java 的安全沙箱，所有涉及 Java.use()、Java.choose()、Java.scheduleOnMainThread() 等 Java 相关操作，必须包裹在 Java.perform() 回调中。代码如下：

接下来我们可以将要hook的方法替换为自定义函数，我举个例子：

以上代码当中将 java.util.Map 的 put 方法替换为自定义函数是通过这段代码实现的。注意：Map 是接口，实际运行时调用的是实现类（如 HashMap）的方法，若需拦截所有 put 调用，建议同时 Hook 具体实现类，例如 Java.use("java.util.HashMap")。

因为这段代码是对 java.util.Map 的 put 方法进行hook，function(key, value)当中的key和value就是调用put方法所要传入的两个参数，put方法在开发使用的时候大概是这样的：

可以见得一共两个参数，其中第一个参数为键，第二个参数为值。所以key就是表示put方法的第一个参数，value就是表示put方法的第二个参数，如果我们需要打印这两个参数的值，就可以通过console.log方法来打印参数的值。

当我们想要获取要hook方法的返回值，那就需要调用要hook的方法从而得到其返回值，我们可以通过this去引用当前的这个类，这样便可通过this.当前这个类下要hook的方法来调用要hook的方法从而得到其返回值，就像这样：

要注意的是this.put(key, value);这里是调用的原函数，而不是修改后的函数，其实就是在调用原函数前加点东西，调用原函数后，得到返回值也可以加点东西打印打印返回值。而要修改参数和返回值也很简单，在调用原函数前给参数重新赋值，在最后的return返回一个新的返回值即可。

众所周知Java是有重载函数的，那么当我们使用frida进行hook重载函数时是不是就要告诉它我们要hook哪个重载函数？如此便需要添加以下代码来指定：

这段代码一般是像下面一样添加和使用：

如果我们想要hook所有的重载函数该怎么样实现呢？其实也差不多，只不过将overload换成overloads而已，大致实现如下：

因为ClassName.MethodName.overloads是一个数组，包含了方法的所有重载版本。所以我们可以通过遍历这个数组，可以对每个重载版本进行 Hook。但你会发现function()当中是没有参数的，因为在js当中是没有可变的参数，所以其实需要在具体实现中去判断参数的个数和参数的类型，那这就需要引出arguments了，arguments是js内置的类数组对象，它包含了函数调用时传入的所有参数。如此我们便需要通过 arguments.length 判断方法调用时传入的参数个数，再根据参数个数进行对应的处理。

当我们遇到构造函数该如何hook呢？其实很简单，与Hook普通方法相比无非是方法名的改变，区别是通过$init来表示构造函数的。

当然如果构造函数有多个，那么我们就得添加overload来指定我们要hook哪个重载的构造函数。会了如何hook构造函数那自然少不了如何通过hook进行实例化对象，要实例化对象需要用到$new()，用法如下：

因为这是实例化对象，所以我们进行实例化后还可以调用该对象下的方法。

我们除此之外还可以主动调用某个方法，想要主动调用也十分的简单，如果是主动调用静态方法需要先通过Java.use() 获取目标类的包装对象，这个对象代表 Java 类本身，然后通过类对象直接调用静态方法，这里无需创建实例是因为静态方法属于类本身，代码如下：

参数传递是直接传递参数到方法调用，Frida 会自动处理 Java和JS 之间类型的转换。

而我们如果要主动调用非静态方法首先我们得知道Java 对象在堆内存中存在，每个对象是类的实例，非静态方法需要通过对象实例调用，这样我们便能理解主动调用非静态方法需要通过Java.choose在 Java 堆中扫描指定类的活动实例，参数为要查找的完整类名。

每找到一个匹配实例后都会调用一次下面的代码，参数instance为找到的 Java 对象实例，调用方法可以通过instance.方法名("传参")在实例上调用非静态方法并传递参数，最后将返回值赋给 ret。

在所有实例处理完成后会调用以下代码，它会执行清理操作、处理最终结果、通知扫描完成。

完整的主动调用非静态方法如下：

除了这种在 Java 堆中扫描指定类的活动实例外还有一种方法可以主动调用非静态方法，那就是新建一个实例对象去调用。这两种有什么区别呢？前面提到了上面那种主动调用非静态方法需要Java对象存在于堆内存当中，不然在堆内存中找不到Java对象，那自然也无法主动调用都没有实例化的Java对象，而下面这种方式就是我们主动实例化对象，得到对象后再主动调用对象下的方法。

这种方式和主动调用静态方法区别不大，也就多了个实例化对象的过程罢了。

现在我们学会了如何主动调用Java层的静态方法和非静态方法，这个方法也适用于调用静态native方法和非静态native方法，而主动调用so层方法待到下面讲so层hook时再讲。

接下来我们就开始讲如何hook静态字段与非静态字段，静态字段hook起来十分的容易，可以通过以下代码实现：

hook静态字段中frida其实是把ClassName.staticFieldName封装成了一个对象，我们要获取或者修改其值需要通过对象下的value实现。非静态字段的hook也非常简单，如下面所示：

我们现在对静态字段和非静态字段的hook都学会了，只不过还有一个情况需要注意，那就是当字段名和函数名重复的时候，这就需要在我们要hook的字段名前面加个下划线，就像这种情况：

接下来我们就讲解如何hook内部类和匿名类，这里再提一下什么是内部类，什么是匿名类，其实匿名类也是内部类的一种，又称匿名内部类，内部类其实就是在一个类里面再定义一个类，内部类可以访问其外部类的所有成员，包括私有成员。而我们要hook内部类和匿名类也非常简单，只需要用到$即可，如下所示：

而匿名类和内部类是差不多的，但匿名类是没有名字的，这就导致匿名类的类名表达方式和smali中的一致。我们举个例子：

当执行 new Animal() { ... } 时，实际上是在运行时创建了一个继承自 Animal 类的匿名子类。这个匿名子类没有显式的类名，其类名由编译器自动生成，通常类似于 Test$Test$1，这个Test1就表示Test类中的第一个匿名类，Test$2就表示Test类中的第二个匿名类，以此类推。

接下来就继续讲如何枚举所有的类与类的所有方法，frida提供了一个API可以同步枚举所有已经加载的类，这里的同步就是等把所有已经加载的类都枚举出来再将结果返回，得到返回值后才能继续往下执行代码；既然有同步那自然少不了异步，但在这之前我们先讲讲同步怎么实现：

可以看到在代码中使用到了Java的反射，先通过Java.use获取类的引用，然后代码中通过.class的方式获取类的class对象，有了类的class对象就可以调用下属的一些方法，代码中获取类的class对象的方法其实就是Java中通过类名.class来获取类的class对象是一致的，这里在获取到类的class对象后便调用了Java反射中的getDeclaredMethods方法得到类的全部成员方法。反射在hook当中还是很重要的，这些反射的方法我就不额外提了，有兴趣的可以自己去看看。

前面提到了还有异步枚举所有已经加载的类，以下代码可以实现：

可以看到代码的作用是异步枚举当前进程中已加载的所有 Java 类，筛选出指定包名下的类，并输出这些类的详细信息和所有声明方法的信息。这个和前面hook非静态字段一样都是通过这两个回调函数实现的，onMatch就是每枚举到一个类时就会将类的名字传入到onMatch: 后的函数并执行，而另外一个参数handle是类的句柄。

学会了如何实现枚举和Java中的反射，那我们就可以实现枚举所有方法并进行hook，代码如下：

代码中可以看到有mmkv[methodName]等的代码，这个其实就是mmkv.methodName，但因为直接.methodName这种方式methodName是标识符，如果是mmkv.方法名称那么该方法名称就必须出现在js代码中，而mmkv[methodName]方式方法名称是一个字符串，这是不需要出现在js代码中，也就可以从methodName这个变量中取出方法名称字符串来实现hook。

我们有时候会遇到动态加载的dex，遇到这种情况前面的hook方式是会找不到类的引用的，实现动态加载dex有基于 PathClassLoader 和 DexClassLoader，也有基于插件化框架实现的，还有基于热修复框架实现的，还有一种是基于动态代理 + Instrumentation来实现的。

第一种动态加载dex实现是基于Android 系统提供了 ClassLoader 的两个子类，PathClassLoader 和 DexClassLoader 来加载 dex 文件。其中PathClassLoader 主要用于加载已经安装应用的 dex 文件， 而 DexClassLoader 可以加载指定路径下的 dex、jar、apk 文件，并生成对应的 DexFile 对象，进而加载其中的类。其核心原理是通过 ClassLoader 的 findClass 方法去寻找并加载类。当调用 DexClassLoader.loadClass 时，它会先检查缓存，如果缓存中没有，就会去指定路径下的 dex 文件中查找对应的类字节码，然后通过 JNI 调用系统方法将字节码转化为可执行的形式，加载到内存中。

如果是开发者大概会这样实现动态加载的dex：

以上仅为示例，这种实现相对简单，是 Android 官方提供的方式，兼容性较好。但在 Android 5.0 之后，为了安全性，引入了 ART 运行时，直接使用 DexClassLoader 加载的 dex 文件不能直接运行，需要进行 dex 合并（multidex 机制），操作相对复杂；并且在加载 dex 时，对 dex 文件的合法性校验比较严格。

第二种是会先通过RePlugin自定义一个 ClassLoader，通过代理机制，在加载类时，优先从插件的 dex 文件中查找类。如果找不到，再委托给系统的 ClassLoader 去加载。因为插件中的资源（如布局、图片等）也需要进行管理。所以RePlugin 会通过 Hook 系统的资源加载机制，将插件的资源与宿主应用的资源进行整合，这样便使得插件能够正确地使用和显示资源。为了让插件能够像正常的 Android 组件一样运行，需要 Hook 一些系统方法，例如 ActivityManagerService 相关方法，在启动插件的 Activity 时，能够欺骗系统，让系统认为是在启动宿主应用内的正常组件。

这种方式首先引入 RePlugin 的依赖，然后在应用中进行初始化：

初始化完后需要加载插件并启动插件中的 Activity：

这种方式从开发的角度上来讲可以实现真正意义上的插件化，能够动态加载并运行插件中的组件，包括 Activity、Service 等；支持插件的热更新，对应用的功能扩展和维护非常方便。但是框架相对复杂，接入成本较高；由于大量使用 Hook 技术，可能会存在兼容性问题，特别是在一些定制化的 Android 系统上。

第三种热修复框架其原理是先dex 差量修复，Tinker 会对比应用的旧版本和新版本的 dex 文件，生成一个差量包（patch.dex）。在应用运行时，将这个差量包与应用已有的 dex 文件进行合并，生成一个完整的可运行的 dex 文件。然后类加载替换通过自定义 ClassLoader，优先加载修复后的类，从而实现对应用中存在问题的类进行修复。最后资源修复，对于资源的修复，Tinker 会通过资源映射表等方式，将修复后的资源与应用原有的资源进行整合，保证资源的正确使用。

这种方式在接入 Tinker 框架后，在构建时，会生成差量包。在应用中，当检测到有修复包时，进行加载：

这种方式从开发者的角度来说优点有可以快速修复应用中的 Bug，不需要用户重新下载完整的应用安装包；对应用的性能影响相对较小，因为只需要合并差量包。不过缺点也有，对应用的侵入性较大，需要在构建阶段进行较多的配置；在一些复杂的场景下，如多 dex 情况、资源冲突等，修复的成功率可能会受到影响。

最后一种动态代理 + Instrumentation实现的原理是自定义一个 Instrumentation 的子类，通过反射将系统默认的 Instrumentation 替换为自定义的。在自定义的 Instrumentation 中，重写启动 Activity 等方法。当加载动态 dex 文件中的 Activity 时，通过动态代理等方式，将 Activity 的生命周期方法等转发到实际的插件 Activity 中，从而实现插件 Activity 的正常运行。最后对于类的加载，同样可以结合自定义的 ClassLoader 来实现从动态 dex 文件中加载类。

我们来看一段这种方法的实现示例代码：

这种方式可以灵活地控制应用组件的启动和运行，对应用的侵入性相对较小。但对于开发者来说需要深入理解 Android 系统的组件启动流程和 Instrumentation 的工作原理，实现难度较大；并且在一些系统版本上可能会因为系统的变化导致兼容性问题。

市面上常见的是这四种动态加载dex的方式，那下面就讲讲如何hook动态加载dex，这是其中一种方式：

这段代码的主要功能是 Hook 动态加载的 dex 文件中的类和方法。代码中使用了Java.enumerateClassLoaders来枚举所有类加载器，它可以枚举当前进程中的所有类加载器。onMatch 回调函数当每找到一个类加载器时，调用函数，其中loader是类加载器对象。函数中 loader.loadClass("类名") 会尝试用该加载器加载指定类：若能加载则返回 Class 对象（在 if 中为真），若不能加载则会抛出 ClassNotFoundException，被外层的 try/catch 捕获并忽略。当某个加载器能成功加载目标类时，先执行 Java.classFactory.loader = loader，该代码用于设置当前类加载器，这样做可以确保后续的类加载操作使用此加载器，原因是因为加载同一个类不仅要类的路径和类名相同还要是同一个类加载器进行加载的，不然就算是类的路径和类名相同但类加载器不同也不是同一个类。

只不过动态加载在开发中一般常用于加固，所以动态加载也常见于加固，加固的话直接脱壳就好了，所以hook动态加载的dex下的类也就没那么常见了。关于动态加载dex的hook如果大家有兴趣可以自己去看看这两篇，或许有所帮助。

[原创]进阶Frida--Android逆向之动态加载dex Hook（三）（上篇）-Android安全-看雪-安全社区|安全招聘|kanxue.com

[原创]进阶Frida--Android逆向之动态加载dex Hook（三）（下篇）-Android安全-看雪-安全社区|安全招聘|kanxue.com

动态加载dex讲完了，下面我们就讲讲当我们遇到那些特殊类该如何进行hook，举个例子：

就比如这个方法的参数是Map，那我们遇到了这种参数如何打印或修改其参数与返回值，如果要 Hook 这种参数或返回值为特殊类型（如 Map、HashMap、Context等）的方法，需要结合 Java 反射 和 Frida 的 Java 层 API。

在frida的js代码中如果当我们得到Java的类型我们可以调用该Java类下的方法，你看代码中的map.entrySet();这个entrySet方法既不是frida的API也不是js的方法，而是Java中Map类下的entrySet方法，所以当我们遇到特殊类型的参数时是可以调用该类下的方法的。

现在我们需要知道几个比较好用也比较常用的方法，第一个就是通过hook获取调用堆栈，网上如何通过获取调用堆栈的方式方法很多，我这只是我列举出来的几种方式。

第一种是适用于Java层的获取调用堆栈，这种方式其实就是通过前面讲的主动调用去实现的。

可以看到先通过Java.use("android.util.Log")获取 Android 系统日志工具类Log的引用，然后调用Log类下的getStackTraceString方法，该方法可以生成可读性强的堆栈信息。

该方法需要传入一个java.lang.Throwable实例作为参数 ，这里通过Java.use("java.lang.Throwable").$new()创建了一个新的异常实例，其内部会自动记录当前的调用栈信息，最后getStackTraceString方法会将这个异常包含的调用栈转换为字符串返回，从而得到我们所需的 Java 层调用堆栈详情。

既然Java层可以打印调用栈信息，那么so层自然也可以，以下代码的作用是打印so层调用栈：

可以看到打印so层调用堆栈的核心是Thread.backtrace() 函数，在Frida的onEnter中，this.context包含了CPU寄存器的完整快照，这些寄存器保存了当前线程的执行状态，Backtracer.ACCURATE 模式通过栈帧指针遍历调用链。

第二种就是hook系统函数，当APP种的方法名被混淆的时候会对我们的hook增加不小的难度，这时我们就可以hook系统函数来帮助我们对抗混淆，毕竟系统函数并不会受到影响，除非它不使用系统函数而是使用自己实现的函数。比如说某个APP将加密前的键值对压入到了 HashMap 中，那我们就可以通过 hook HashMap 的 put 方法来获取到压入的键值对；put 是系统 API，就算 APP 混淆了，只要调用了该方法，我们就可以直接 hook 该方法获取压入的键值对而不受影响。

以上是一个示例，hook系统函数是一个比较好用也比较常用的方法，大家可以去多试试，以下是一些经常进行hook的系统函数：

第三种是协议头当中有的参数可能是启动的时候生成一次，但一般来说带有时间戳的参数是每次执行都会生成的。首先我们要明白时间戳是为了防止重复发送相同请求，若时间戳固定，攻击者可无限复用旧请求；若每次请求生成新时间戳，服务端可通过 “时间窗口验证”。

第四种是接触的比较少的，app有时需要判断页面是H5还是原生页面，要进行判断有很多方式可以判断，首先可以点击手机 设置 -> 开发者选项 -> 开启 “显示布局边界” ，如果是屏幕上有密密麻麻、细小的布局框，每个按钮、每段文字都有自己的边界，那这就是原生页面的特征，而H5页面特征则是整个屏幕或被一个巨大的绿色框框住，框内细节很少。

还可以开启 飞行模式 后打开 App 页面。显示404错误、网络异常或加载失败的页面就是H5页面，内容依然存在（如缓存、设置页）或显示 App 自带的静态占位图那就是原生页面。

还可以看加载进度条，仔细观察打开新页面时，顶部导航栏的位置，页面顶部常常会出现一条进度条，表示网页正在加载那就是H5页面，页面切换是“即点即开”的，没有加载进度条，除了下拉刷新那就是原生页面。

还可以在页面的文字或图片上长按，通常会出现系统自带的菜单，如“复制”、“粘贴”、“分享图片”等选项那就是H5 页面，如果长按后无任何反应，或触发 App 自定义的交互那就是原生页面。

可以尝试进入一个深层级页面后，看左上角的返回按钮。返回按钮旁边经常会出现一个 “关闭”或“X”按钮，用于直接退出网页 那就是H5 页面，如果通常只有一个返回箭头，没有多余的关闭选项那就是原生页面。

可以在下拉刷新的页面快速下拉，如果页面内容会有一个明显的“闪白”和重新渲染的过程，感觉像是整个网页刷新了那就是H5页面，刷新动画比较平滑，一般只出现原生的刷新头，页面内容不会“闪白”那就是原生页面。

可以在页面上下拉到底部或进行特定手势，有时下拉到底部会显示网页的版权信息或网址提供方，而app原生页面则不会出现任何与网址相关的信息。

如果以上方法还不能确认是不是H5页面，那将 APK 文件后缀改为 .zip 并解压，重点关注 assets 和 res资源文件夹，如果看到大量的 .html、.js、.css 文件，或者包含 cordova.js、ionic 等特定框架的文件，这几乎可以肯定是混合应用 。有时 H5 资源会被打包成离线包，逻辑类似。还可以使用Jadx等工具反编译 APK，在代码中搜索 WebView、WebChromeClient、WebViewClient 等类。如果 App 的代码中大量使用 WebView 来加载网址或本地文件，并且存在 JsBridge 相关的接口，那么它就是典型的混合应用 。

使用frida对Java层进行hook我们已经会了，那么接下来我们也该学习学习frida对so层的hook了。一般来说要完成对so层的函数进行hook首先要获取函数的地址，众所周知so层函数的地址是由so文件的基址加上函数在so文件中的偏移进行计算得到的。

我们可以通过Module类的findBaseAddress方法直接获取指定so文件的基址，再通过add方法进行基址+偏移的计算得到目标函数地址。

前面提到过Thumb指令集进行hook时地址是需要加一的，而arm指令集则不需要，所以当指令集为Thumb或Thumb2指令集时我们写hook代码时的add方法中的偏移地址是要加一的！

得到so层函数的地址后我们就可以通过Interceptor.attach() 直接附加到内存中的 Native 函数，Interceptor.attach() 需要传两个参数，第一个参数便是我们so层函数的地址，第二个参数是一个对象，这个对象中有几个回调函数，Interceptor.attach() 完整语法如下：

onEnter 会在 目标 Native 函数被调用的瞬间触发，它的核心作用是 获取函数的调用参数。其参数args 是一个 NativeArgumentPointer 数组，对应目标 Native 函数的参数列表。比如目标函数是 C 语言的 int add(int a, int b)，那么 args[0] 就是 a 的值，args[1] 就是 b 的值；再比如目标函数是 char* getString(const char* key)，那么 args[0] 就是 key 的字符串指针，这就需要手动解析成字符串。

在 onEnter 回调中，this 是一个 钩子上下文对象，包含当前函数调用的额外信息，比如this.threadId表示当前调用所在的线程 ID，this.returnAddress表示函数执行完成后要返回的地址，this.args等同于参数 args。还可以通过this.xxx在 onEnter 中定义自定义属性，将函数的参数或者变量保存到 this 中，供 onLeave 回调使用。

onLeave 会在 目标 Native 函数执行完成、即将返回给调用者的瞬间触发，它的核心作用就是处理函数的返回值，其参数retval 是一个NativeReturnValue对象，代表目标函数的返回值并支持读取和修改两种操作。但需要注意的是不能直接打印 retval，因为它只是一个指针值，就是一个 jstring 类型的句柄，这个句柄指向 Java 堆中的一个 java.lang.String 对象，指向的是 Java 虚拟机内部管理的对象，并非 C 字符串数据，所以我们不能直接解引用它来读取字符串。如果要打印 retval的话需要经过 JNI 函数转换成C 字符串数据才能得到可读的内容。代码如下：

可以看到代码首先在onLeave 回调中执行了var env = Java.vm.tryGetEnv();这一段代码，众所周知Java.vm 是 Frida 提供的 JavaVM 接口的封装，而tryGetEnv() 的作用是获取当前线程的 JNIEnv 指针。JNIEnv 是线程私有的，它本质上是一个指向函数表的指针，这个表里包含了所有的 JNI 函数（如 GetStringUTFChars, FindClass 等）。点击tryGetEnv函数跳转可以看到以下代码：

我们使用的是tryGetEnv函数这是因为如果当前线程还没有附加到 Java 虚拟机，tryGetEnv() 会返回 null，而 getEnv() 则会直接抛异常。这里要注意一点，tryGetEnv()要么需要被Java.perform(function(){});所包裹，要么就需要放在Interceptor.attach();中进行使用，不然的话是获取不到当前线程的 JNIEnv 指针的。我们获取JNIEnv后就执行了var cstr = env.getStringUtfChars(retval);代码，这是最核心的一步，env提供了一个 JavaScript 友好的 JNI 函数包装，而env.getStringUtfChars(jstring) 对应的是 JNI 中的 GetStringUTFChars 函数。当你调用这个方法时，Frida 内部会执行JNI函数GetStringUTFChars，JNI 函数接收 jstring 引用然后转换成C 字符串的指针cstr ，cstr 变量在 Frida 的 JS 环境中被表示为一个 NativePointer，它指向的就是这个可读的 C 字符串。既然可以将jstr转换为cstr，那么也就可以将cstr转换为jstr， env.newStringUtf("...")可以通过 JNI 函数 NewStringUTF 在 Java 堆上创建新字符串，返回 jstring 引用，说个常用的场景，转换为jstr后用 retval.replace(...) 替换原始返回值。流程大致如下：

前面提到过onLeave 会在 目标 Native 函数执行完成、即将返回给调用者的瞬间触发，而要修改返回值就要在onLeave 触发后通过 retval.replace(newJstr);来修改它，其中newJstr为返回值要修改的值。返回 jstring 引用的代码如下：

既然提到了在 onLeave 回调中修改返回值，这里retval.replace 不仅可以替换 jstring，它可以替换任何类型的返回值，包括基本类型、对象引用（jobject）、指针等，只要提供一个与原始返回值类型兼容的新值即可。有一点要注意转换为jstring之后如果还是想在so层打印值的话还是需要将jstring转换为cstr。

现在我们对so层的hook有了点了解，但具体要怎么去做可能并不清楚，我讲点比较常规的简单思路，首先当我们在分析时不用完全搞明白所有的执行流程，也不用搞明白每个方法在做什么，只要找到关键方法即可，当你分析时怀疑某个方法是我们要寻找的关键方法你可以去通过hook打印该方法的参数和返回值，再根据传进去的参数和传回来的返回值做一个简单的判断，最典型的就是当你通过hook获取到它传入的参数是一个明文，但得到的返回值是一个长度为32字节结果，那么我们就可以怀疑这个方法是进行了md5消息摘要。我们打印了参数和返回值，但如果有参数或返回值是地址我们就可以通过hexdump方法看一下结构，hexdump方法可以将指针指向的内存内容以十六进制 + ASCII 字符的格式打印，其实也就是我们常见到的左边是十六进制右边是ASCII字符的格式，这可以用于查看二进制数据的原始内容。如果确定ASCII字符是C语言字符串，那么我们就可以通过ptr(args[0]).readCString()将指针指向的内存解析为C 风格字符串，我们举例用args[0] 作为演示，先通过 ptr(args[0]) 转换为 NativePointer，再调用 readCString() 读取字符串。

ptr函数用于将参数转换为指针类型，args[0] 的原始类型是 NativeArgumentValue，也就是Frida 对函数参数的包装类型，其值本质是内存地址的整数表示（如 0x7f8a0000）。ptr函数可以将内存地址的整数包装成可操作的指针，后续可通过该指针读取 / 写入内存（如 readCString()、writeUtf8String() 等）。在修改so层函数参数时也会使用到这个ptr函数，前面提到在 Frida 的 Interceptor.attach 中，onEnter 回调的参数 args 是一个 NativePointer 对象的数组，每个元素代表目标函数的原始参数值，当我们想要修改某个参数时，需要将该参数设置为一个新的 NativePointer 对象，而不能直接赋一个 JavaScript 数字。而要将参数设置为一个新的 NativePointer 对象就需要通过ptr函数将修改值转换为指针类型，假设代码为args[2] = ptr(2000);那么ptr(2000)生成的 NativePointer 对象内部封装了整数 2000，赋值给 args[2] 后，Frida 会将该整数写入参数位置，从而改变函数实际接收到的参数值。

readCString函数是从指针指向的内存读取 C 风格字符串，从指针地址开始，逐个读取字节，直到遇到 0x00（终止符），将读取的字节转换为字符串返回。

除此之外还有readPointer函数用于从当前指针指向的内存地址，读取一个 指针类型的数据（本质是另一个内存地址）。当被 hook 的函数参数或者变量是二级指针时需用 readPointer() 读取指针指向的地址。首先二级指针其实就是在一级指针的基础上套了一层指针，假设变量a是一个指针，它存储了字符串"abc"的地址，而二级指针变量b就是存储了变量a的地址。那么在逆向的时候你得到的参数是一个二级指针，首先你将该参数通过ptr函数转换为指针类型，然后hexdump一下，可你发现没有看到什么有用的信息，ASCII字符的显示是杂乱无章的，那你怀疑该参数是二级指针，打算尝试使用readPointer函数从当前指针中读取一个指针类型的数据，读取到另一个指针的地址后再hexdump一下后你看到了有用的信息。其实第一次你看到的是二级指针存储的一级指针的地址，第二次使用readPointer函数后读取了一级指针的地址，得到一级指针的地址后hexdump一下就可以看到一级指针所指向的内容了。

既然讲到了hexdump那就详细讲讲这个函数，hexdump 函数的基本语法如下：

target参数是必需的，这是你要查看的内存区域。可以是一个内存地址，也可以是一个包含二进制数据的 ArrayBuffer（例如用 Memory.readByteArray() 读回来的数据）。

options是可选参数，其类型是一个对象，当中包含了以下属性：
options.offset默认是为0的，这个属性表示从 target 的哪个偏移量开始dump。
options.length默认为整个 target 的尺寸，也就是要dump多少字节。
options.header这个属性是布尔类型，默认为 true。是否显示表头，也就是是否显示显示偏移地址和ASCII列标题的那一行。
options.ansi默认为 false，这个属性决定是否在输出中使用ANSI颜色。

除了hexdump查看内存数据之外还可以通过readByteArray方法来读取内存数据，readByteArray函数有两种写法，分别是：

当可以看到内存数据后，我们还可以选择修改内存数据，这就需要用 Frida 提供的 Memory 系列 API，将我们准备好的新数据，写入到目标地址中去。

在继续将修改内存数据之前我们需要知道一个常见的情况，这也是在C语言当中特别喜欢用的方式，那就是在函数传递字符串、明文等数据时，通常会遵循 “输入数据指针 + 数据长度 + 输出缓冲区指针” 的这种参数设计模式。为什么要这么整呢？需要传入数据长度参数的直接原因是因为二进制数据（如图片、加密后的字节流）可能包含\0，若用strlen()计算长度会提前截断；函数无法区分 “输入数据的真实长度” 和 “意外包含的\0”，容易导致处理不完整。需要接收返回值的变量的原因是避免函数内部动态分配内存，比如函数返回char*，调用者需手动free，容易遗漏导致内存泄漏；可以由调用者根据需求分配足够大的内存，比如 Base64 编码后的数据长度是原长度的 4/3，需提前计算。还支持原地修改，如输入输出可以复用内存，可传入同一个指针。在C语言中通常还会额外传递 “输出缓冲区的最大长度”（size_t output_max_len），防止函数写入超出缓冲区范围的数据（避免缓冲区溢出漏洞）。

而修改内存数据最通用的就是Memory.writeByteArray(address, bytes)，写入的数据类型是字节数组，这个可以写入任何二进制数据。当我们要修改的目标是全局变量或已知的固定缓冲区，我们可以直接向那个地址写入新数据：

前面我们也详细讲了C语言中很常用的方式：native 函数通过指针参数返回数据，那么针对这一情况进行内存数据的修改就有必要了，假设 native 函数原型如下：

在 Hook 该函数时，我们可以在 onLeave 中拿到 outputBuffer 的地址（即 args[0]），此时函数已经将原始数据写入了该缓冲区。我们的目标是用自己的数据覆盖这块内存，从而改变调用者看到的结果。我们假设要修改内存的新数据有两种类型，分别是长度为16字节的string类型以及长度为32字节的hex类型，其实这两者的长度都是一样的，只是因为hex是四个二进制位表示一字节，而string是八个二进制位表示一字节而已。我们需要将这两种类型转换为字节数据，这就需要我们自己写转换代码了，将字符串的每个字符转换成对应的字节数组：

hex 字符串转换成字节数组：

我们在 onLeave 中覆盖这块内存。

如何修改内存数据我们有所了解，我们如果使用frida要hook so层的导出函数可以使用findExportByName方法，该方法在指定的.so文件中，根据「模块名 + 导出函数名」查找该函数的内存地址，所以该方法有两个参数，一个是目标 SO 文件名，另一个是要查找的导出函数名，两个参数都是string类型，其返回值是一个指针类型，找到时返回函数的内存地址；未找到时返回 null。这里要谨记导出函数名不是要的导出表中的名字，而是要汇编代码中导出函数的名字，当然也可以通过获取so的基址加方法偏移地址的方式来进行hook，比如下图中的偏移地址就为5328C，汇编代码中导出函数的名字为划红线的函数名称:

frida还可以枚举导出表的函数、导入表的函数、符号表的函数等等，我们现在就总结性的讲讲frida中的枚举：

枚举在frida hook中有举足轻重的作用，前面讲过枚举当前所有的类加载器可以应对动态加载dex的情况，我们接下来要讲的JNI函数hook就需要用到枚举libart.so的符号表，因为libart.so的符号表里面可以找到JNI的函数。这里直接用正己大佬Hook RegisterNatives函数的代码。

首先Module.enumerateSymbolsSync("libart.so"); 代码枚举libart.so 库中枚举所有符号，我们IDA反编译libart.so，下图红框框住的便是所谓的符号表：

首先符号表中符号名必须包含 "art"，libart.so 中除了 ART 自己的符号，还可能包含其他第三方库或编译器生成的符号。代码接下来筛选符号名包含 "JNI"的符号，因为 RegisterNatives 是一个 JNI 函数，属于 JNI 子系统。ART 内部还有其他名为 RegisterNatives 的函数，比如在编译器或解释器中，但它们与 JNI 无关。接下来筛选符号名包含 "RegisterNatives"的符号，这是我们要hook的函数。最后也是最关键的一步那就是筛选符号名不能包含 "CheckJNI"的符号，为什么呢？我们先在符号表中搜索RegisterNatives，然后会得到以下结果：

可以看到有三个不同的RegisterNatives函数，分别是art::JNI<true>::RegisterNatives带检查的正式版本，模板参数<true>表示启用 CheckJNI 模式。JNI<true>版本是调试/检查模式下使用的，它会在注册方法时执行大量额外的参数验证和错误检查。而art::JNI<false>::RegisterNatives是不带检查的正式版本，模板参数 <false>表示禁用 CheckJNI 模式。最后一种art:: (anonymous namespace)::CheckJNI::RegisterNatives是CheckJNI 的辅助包装器，这个函数是一个静态辅助函数，位于 CheckJNI 命名空间内。它通常由 JNI<true>::RegisterNatives 调用，负责完成具体的检查逻辑。如果不过滤掉 CheckJNI，我们可能会错误地 Hook 到 JNI<true> 版本，而这个版本在大多数运行环境中永远不会被调用，导致 Hook 失效。

大家自个有兴趣的话可以反编译libart.so去看看，Android 12 及更高版本libart.so 位于独立的 ART APEX 模块中，64位路径是/apex/com.android.art/lib64/libart.so，32位路径是/apex/com.android.art/lib/libart.so，在高于安卓10的系统里，64位的libart.so路径是/apex/com.android.runtime/lib64/libart.so，低于10的则在system/lib64/libart.so，32位就在lib目录下而不是lib64目录。

接下来要讲so层的主动调用，这个是很重要的，我们直接先看代码：

Module.findBaseAddress("libxxx.so") 遍历目标进程已加载的模块，返回指定 SO 的基址，libBase.add(0x906c0) 将基址加上偏移量，得到目标函数的绝对虚拟内存地址。

代码中new NativeFunction(funcAddr , 'pointer', ['pointer', 'pointer']);是 Frida 提供的核心 API用于声明函数指针，其中第一个参数为要主动调用函数的地址，第二个参数为返回值的类型，第三个参数为一个数组，数组里面存放的便是参数的类型，'pointer'表示参数或返回值是一个指针，其他常见类型有'void', 'int', 'uint', 'float', 'bool' 等。得到函数指针后我们可以传入两个指针参数，aesAddr(encry_text, key) 执行 Native 函数。而Memory.allocUtf8String(str) 在目标进程的堆上分配一块内存，将 JavaScript 字符串 str 转换为 UTF-8 编码的 C 字符串，并返回指向该内存的 NativePointer。函数执行完毕后，返回值被封装成一个 NativePointer 对象，最后通过 .readCString() 将该指针指向的内存作为 C 字符串读取并打印。

frida hook还可以写文件，有两种方式，第一种是通过Frida 的 File 类写文件，第二种是手动调用 libc 函数写文件。先看第一种写文件方式的代码：

File类是 Frida 内置的 JavaScript 类，它封装了对目标设备文件系统的操作。new File("/sdcard/xxx.txt", "w")需要指定路径和模式以打开文件。路径 /sdcard/xxx.txt 是 Android 设备上的一个常见可写路径，模式 "w" 表示写入模式。ios.write("hahahahaha!!!\n") 将字符串数据写入文件，Frida 会将该字符串转换为字节，并通过目标进程的文件描述符写入文件。写入的数据会先缓存在 Frida 内部缓冲区中，而flush() 强制将缓冲区数据写入磁盘，最后close() 关闭文件描述符，释放资源。

接下来我们看看第二种写文件方式的代码：

先获取函数地址，比如Module.findExportByName("libc.so", "fopen") 在目标进程的 libc.so 模块中查找导出函数 fopen 的虚拟内存地址。因为 libc.so 是每个 Android 进程都会加载的 C 库，所以这些地址是有效的。然后再声明函数指针用于主动调用fopen、fputs、fclose ，Memory.allocUtf8String(str) 还是在目标进程的堆上分配一块内存，将 JavaScript 字符串转换为 UTF-8 编码的 C 字符串，并返回指向该内存的 NativePointer。接下来调用 fopen，fopen(filename, open_mode) 执行后，会返回一个 FILE* 指针存储在 file 变量中，这个指针指向一个由 libc 管理的文件结构体，后续的 fputs 和 fclose 需要用到它。fputs(buffer, file) 将字符串写入文件。这里 buffer 是指向 "hahaha\n" 的指针，file 是之前打开的 FILE*。libc 内部会处理缓冲和写入。 最后fclose(file) 关闭文件，释放相关资源。

现在我们进行的hook主要还是针对于函数，除了hook函数之外我们还可以hook寄存器，之前讲arm汇编的时候讲过在 ARM64 架构中，函数参数和返回值通过特定寄存器传递，前8个寄存器X0到X7用于函数调用时传递参数，X0 同时用于函数返回值。下面代码就对寄存器进行hook：

这段代码所hook的汇编代码：

在 libsscronet.so 中找到偏移 0x406E98 的地址，该地址处是一条 BLR X23 指令。当程序执行到 0x406E98 时，触发 onEnter，this.context 是 Frida 提供的 CPU 上下文对象，包含了所有寄存器的值，通过 this.context.x23 获取即将调用的函数地址。Process.findModuleByAddress(addr) 返回该地址所在的模块信息，这样可以动态追踪这个函数指针指向的是哪个模块内的哪个函数。

当程序执行到被 Hook 的地址时，CPU 跳转到 Frida 的拦截器入口，拦截器保存当前 CPU 的所有寄存器到内存中，形成一个 CpuContext 对象，根据 Hook 类型onEnter 或 onLeave调用对应的 JavaScript 回调，并将上下文对象作为 this.context 传递给回调，回调中可以读取或修改 this.context 中的寄存器值，回调执行完毕后，拦截器将修改后的寄存器值写回 CPU，拦截器跳转到蹦床，执行之前保存的原始指令，这一段可能会有些迷糊，其实就是当调用 Interceptor.attach(address, callbacks) 时，从 address 开始，读取足够长的指令序列，保证至少能容纳一条跳转指令，将这些原始指令复制到一块 Frida 内部管理的内存区域，称为 蹦床，蹦床的作用是稍后执行原始指令并跳回原程序流。原始指令执行完后，再跳转回原程序的下一条指令。

当时hook寄存器X23的时候还遇到一个问题，简单来说X23寄存器存储的是一个地址，而这个地址不属于当前这个so，而是属于其他so的地址，这种情况该怎么处理呢？frida提供了对应的函数来解决这个问题， Process.findModuleByAddress方法可以根据给定的地址查找模块，X23 中存放的地址通常是导入函数的地址，在动态链接过程中，当前 SO 加载时，系统会先加载它所依赖的所有 SO，并将这些外部函数的真实地址填入全局偏移表（GOT表）或直接写入指令能访问的位置。最终，X23寄存器的值就是通过这种方式获得的。但需要注意的是在当前so加载时会先去加载导入表函数所属的so模块，也可以简单理解为导入表函数所属的so模块是当前so的依赖。代码如下：

Process.findModuleByAddress方法它接受一个内存地址，然后遍历当前进程加载的所有模块，如果找到，返回一个包含模块信息的对象，其中包含name、base、size、path 等；否则返回 null。

既然能hook获取寄存器的值，那么就可以通过hook修改寄存器的值，以下代码实现了修改寄存器的值：

这段代码所hook的汇编代码：

soAddr.add(0x2C35) 利用了so中已有的字符串，这些字符串通常位于只读数据段，在 so 加载时就已经存在于内存中，地址固定。将 x1 指向 so 内偏移 0x2C35 处的字符串。还可以通过类似以下代码修改为自定义的字符串：

关于寄存器hook大致如此了，关于frida hook的基础也差不多如此了，一些进阶操作和过frida检测之后再讲，江湖路远，后会有期！

传播安全知识、拓宽行业人脉——看雪讲师团队等你加入！