我们在讨论动态注入技术的时候，APIHook的技术由来已久，在操作系统未能提供所需功能的情况下，利用APIHook的手段来实现某种必需的功能也算是一种不得已的办法。在Windows平台下开发电子词典的光标取词功能，这项功能就是利用Hook API的技术把系统的字符串输出函数替换成了电子词典中的函数，从而能得到屏幕上任何位置的字符串。无论是16位的Windows95，还是32位的Windws NT，都有办法向整个系统或特定的目标进程中“注入”DLL动态库，并替换掉其中的函数。

但是在Android上进行Hook需要跨进程操作，我们知道在Linux上的跨进程操作需要Root权限。所以目前Hook技术广泛地应用在安全类软件的主动防御上，所见到的Hook类病毒并不多。

Android系统在开发中会存在两种模式，一个是Linux的Native模式，而另一个则是建立在虚拟机上的Java模式。所以，我们在讨论Hook的时候，可想而知在Android平台上的Hook分为两种。一种是Java层级的Hook，另一种则是Native层级的Hook。两种模式下，我们通常能够通过使用JNI机制来进行调用。但我们知道，在Java中我们能够使用native关键字对C/C++代码进行调用，但是在C/C++中却很难调用Java中的代码。所以，我们能够在Java层级完成的事基本也不会在Native层去完成。

8.1　什么是Hook技术

还没有接触过Hook技术读者一定会对Hook一词感觉到特别的陌生，Hook英文翻译过来就是“钩子”的意思，那我们在什么时候使用这个“钩子”呢？我们知道，在Android操作系统中系统维护着自己的一套事件分发机制。应用程序，包括应用触发事件和后台逻辑处理，也是根据事件流程一步步地向下执行。而“钩子”的意思，就是在事件传送到终点前截获并监控事件的传输，像个钩子钩上事件一样，并且能够在钩上事件时，处理一些自己特定的事件。较为形象的流程如图8-1所示。

Hook的这个本领，使它能够将自身的代码“融入”被勾住（Hook）的程序的进程中，成为目标进程的一个部分。我们也知道，在Android系统中使用了沙箱机制，普通用户程序的进程空间都是独立的，程序的运行彼此间都不受干扰。这就使我们希望通过一个程序改变其他程序的某些行为的想法不能直接实现，但是Hook的出现给我们开拓了解决此类问题的道路。当然，根据Hook对象与Hook后处理的事件方式不同，Hook还分为不同的种类，如消息Hook、API Hook等。

图8-1　Hook原理图

8.1.1　Hook原理

Hook技术无论对安全软件还是恶意软件都是十分关键的一项技术，其本质就是劫持函数调用。但是由于处于Linux用户态，每个进程都有自己独立的进程空间，所以必须先注入到所要Hook的进程空间，修改其内存中的进程代码，替换其过程表的符号地址。在Android中一般是通过ptrace函数附加进程，然后向远程进程注入so库，从而达到监控以及远程进程关键函数挂钩。

Hook技术的难点，并不在于Hook技术，初学者借助于资料“照葫芦画瓢”能够很容易就掌握Hook的基本使用方法。如何找到函数的入口点、替换函数，这就涉及了理解函数的连接与加载机制。

从Android的开发来说，Android系统本身就提供给了我们两种开发模式，基于Android SDK的Java语言开发，基于AndroidNDK的Native C/C++语言开发。所以，我们在讨论Hook的时候就必须在两个层面上来讨论。对于Native层来说Hook的难点其实是在理解ELF文件与学习ELF文件上，特别是对ELF文件不太了解的读者来说；对于Java层来说，Hook就需要了解虚拟机的特性与Java上反射的使用。

8.1.1.1　Hook工作流程

之前我们介绍过Hook的原理就是改变目标函数的指向，原理看起来并不复杂，但是实现起来却不是那么的简单。这里我们将问题细分为两个，一个是如何注入代码，另一个是如何注入动态链接库。

注入代码我们就需要解决两个问题。

• 需要注入的代码我们存放在哪里？
• 如何注入代码？

注入动态共享库我们也需要解决两个问题：

• 我们不能只在自己的进程载入动态链接库，如何使进程附着上目标进程？
• 如何让目标进程调用我们的动态链接库函数？

这里我也不卖关子了，说一下目前对上述问题的解决方案吧。对于进程附着，Android的内核中有一个函数叫ptrace，它能够动态地attach（跟踪一个目标进程）、detach（结束跟踪一个目标进程）、peektext（获取内存字节）、poketext（向内存写入地址）等，它能够满足我们的需求。而Android中的另一个内核函数dlopen，能够以指定模式打开指定的动态链接库文件。对于程序的指向流程，我们可以调用ptrace让PC指向LR堆栈。最后调用，对目标进程调用dlopen则能够将我们希望注入的动态库注入至目标进程中。

对于代码的注入（Hook API），我们可以使用mmap函数分配一段临时的内存来完成代码的存放。对于目标进程中的mmap函数地址的寻找与Hook API函数地址的寻找都需要通过目标进程的虚拟地址空间解析与ELF文件解析来完成，具体算法如下。

• 通过读取 /proc/<PID>/maps文件找到链接库的基地址。
• 读取动态库，解析ELF文件，找到符号（需要对ELF文件格式的深入理解）。
• 计算目标函数的绝对地址。

目标进程函数绝对地址= 函数地址 + 动态库基地址

上面说了这么多，向目标进程中注入代码总结后的步骤分为以下几步。

（1）用ptrace函数attach上目标进程。

（2）发现装载共享库so函数。

（3）装载指定的.so。

（4）让目标进程的执行流程跳转到注入的代码执行。

（5）使用ptrace函数的detach释放目标进程。

对应的工作原理流程如图8-2所示。

图8-2　基于Ptrace的Hook工作流程

8.1.1.2　ptrace函数

说到了Hook我们就不能不说一下ptrace函数，ptrace提供了一种使父进程得以监视和控制其他进程的方式，它还能够改变子进程中的寄存器和内核映像，因而可以实现断点调试和系统调用的跟踪。使用ptrace，你可以在用户层拦截和修改系统调用（这个和Hook所要达到的目的类似），父进程还可以使子进程继续执行，并选择是否忽略引起终止的信号。

ptrace函数定义如下所示：

int ptrace(int request, int pid, int addr, int data);

• request是请求ptrace执行的操作。
• pid是目标进程的ID。
• addr是目标进程的地址值。
• data是作用的数据。

对于ptrace来说，它的第一个参数决定ptrace会执行什么操作。常用的有跟踪指定的进程（PTRACE_ATTACH）、结束跟踪指定进程（PTRACE_DETACH）等。详细的参数与使用方式如表8-1所示。

表8-1　ptrace函数使用详情表

参数与形式	说明
ptrace(PTRACE_TRACEME,0 ,0 ,0)	本进程被其父进程所跟踪。其父进程应该希望跟踪子进程
ptrace(PTRACE_PEEKTEXT, pid, addr, data) ptrace(PTRACE_PEEKDATA, pid, addr, data)	从内存地址中读取一个字节，pid表示被跟踪的子进程，内存地址由addr给出，data为用户变量地址用于返回读到的数据
ptrace(PTRACE_POKETEXT, pid, addr, data) ptrace(PTRACE_POKEDATA, pid, addr, data)	往内存地址中写入一个字节。pid表示被跟踪的子进程，内存地址由addr给出，data为所要写入的数据
ptrace(PTRACE_PEEKUSR, pid, addr, data)	从USER区域中读取一个字节，pid表示被跟踪的子进程，USER区域地址由addr给出，data为用户变量地址用于返回读到的数据。USER结构为core文件的前面一部分，它描述了进程中止时的一些状态，如寄存器值，代码、数据段大小，代码、数据段开始地址等
ptrace(PTRACE_POKEUSR, pid, addr, data)	往USER区域中写入一个字节，pid表示被跟踪的子进程，USER区域地址由addr给出，data为需写入的数据
ptrace(PTRACE_CONT, pid, 0, signal)	继续执行。pid表示被跟踪的子进程，signal为0则忽略引起调试进程中止的信号，若不为0则继续处理信号signal
ptrace(PTRACE_SYS, pid, 0, signal)	继续执行。pid表示被跟踪的子进程，signal为0则忽略引起调试进程终止的信号，若不为0则继续处理信号signal。与PTRACE_CONT不同的是进行系统调用跟踪。在被跟踪进程继续运行直到调用系统调用开始或结束时，被跟踪进程被终止，并通知父进程
ptrace(PTRACE_KILL,pid)	杀掉子进程，使它退出。pid表示被跟踪的子进程
ptrace(PTRACE_KILL, pid, 0, signle)	设置单步执行标志，单步执行一条指令。pid表示被跟踪的子进程。signal为0则忽略引起调试进程中止的信号，若不为0则继续处理信号signal。当被跟踪进程单步执行完一个指令后，被跟踪进程被终止，并通知父进程
ptrace(PTRACE_ATTACH,pid)	跟踪指定pid 进程。pid表示被跟踪进程。被跟踪进程将成为当前进程的子进程，并进入终止状态
ptrace(PTRACE_DETACH,pid)	结束跟踪。pid表示被跟踪的子进程。结束跟踪后被跟踪进程将继续执行
ptrace(PTRACE_GETREGS, pid, 0, data)	读取寄存器值，pid表示被跟踪的子进程，data为用户变量地址用于返回读到的数据。此功能将读取所有17个基本寄存器的值
ptrace(PTRACE_SETREGS, pid, 0, data)	设置寄存器值，pid表示被跟踪的子进程，data为用户数据地址。此功能将设置所有17个基本寄存器的值
ptrace(PTRACE_GETFPREGS, pid, 0, data)	读取浮点寄存器值，pid表示被跟踪的子进程，data为用户变量地址用于返回读到的数据。此功能将读取所有浮点协处理器387的所有寄存器的值
ptrace(PTRACE_SETREGS, pid, 0, data)	设置浮点寄存器值，pid表示被跟踪的子进程，data为用户数据地址。此功能将设置所有浮点协处理器387的所有寄存器的值

8.1.2　Hook的种类

我们所讨论的Hook，也就是平时我们所说的函数挂钩、函数注入、函数劫持等操作。针对Android操作系统，根据API Hook对应的API不一样我们可以分为使用Android SDK开发环境的Java API Hook与使用Android NDK开发环境的Native API Hook。而对于Android中so库文件的函数Hook，根据ELF文件的特性能分为Got表Hook、Sym表Hook以及inline Hook等。当然，根据Hook方式的应用范围我们在Android这样一个特殊的环境中还能分别出全局Hook与单个应用程序Hook。本节，我们就具体地说说这些Hook的原理以及这些Hook方式给我们使用Hook带来的便利性。

TIPS

　对于Hook程序的运行环境不同，还可以分为用户级API Hook与内核级API Hook。用户级API Hook主要是针对在操作系统上为用户所提供的API函数方法进行重定向修改。而内核级API Hook则是针对Android内核Linux系统提供的内核驱动模式造成的函数重定向，多数是应用在Rootkit中。

8.1.2.1　Java层API Hook

通过对Android平台的虚拟机注入与Java反射的方式，来改变Android虚拟机调用函数的方式（ClassLoader），从而达到Java函数重定向的目的。这里我们将此类操作称为Java API Hook。因为是根据Java中的发射机制来重定向函数的，那么很多Java中反射出现的问题也会在此出现，如无法反射调用关键字为native的方法函数（JNI实现的函数），基本类型的静态常量无法反射修改等。

8.1.2.2　Native层So库Hook

主要是针对使用NDK开发出来的so库文件的函数重定向，其中也包括对Android操作系统底层的Linux函数重定向，如使用so库文件（ELF格式文件）中的全局偏移表GOT表或符号表SYM表进行修改从而达到的函数重定向，我们有可以对其称为GOT Hook和SYM Hook。针对其中的inline函数（内联函数）的Hook称为inline Hook。

8.1.2.3　全局Hook

针对Hook的不同进程来说又可以分为全局Hook与单个应用程序进程Hook，我们知道在Android系统中，应用程序进程都是由Zygote进程孵化出来的，而Zygote进程是由Init进程启动的。Zygote进程在启动时会创建一个Dalvik虚拟机实例，每当它孵化一个新的应用程序进程时，都会将这个Dalvik虚拟机实例复制到新的应用程序进程里面去，从而使每一个应用程序进程都有一个独立的Dalvik虚拟机实例。所以如果选择对Zygote进程Hook，则能够达到针对系统上所有的应用程序进程Hook，即一个全局Hook。对比效果如图8-3所示。

图8-3　Hook前和Hook后的对比

而对应的app_process正是zygote进程启动一个应用程序的入口，常见的Hook框架Xposed与Cydiasubstrate也是通过替换app_process来完成全局Hook的。

8.1.3　Hook的危害

API Hook技术是一种用于改变API执行结果的技术，能够将系统的API函数执行重定向。一个应用程序调用的函数方法被第三方 Hook 重定向后，其程序执行流程与执行结果是无法确认的，更别提程序的安全性了。而Hook技术的出现并不是为病毒和恶意程序服务的，Hook技术更多的是应用在安全管理软件上面。但是无论怎么说，已经被Hook后的应用程序，就毫无安全可言了。

8.2　常用的Hook工具

在日常工作学习中，我们希望使用Hook技术来完成某功能其实是相当烦琐的，但也并不是不可能的。我们这里没有手动地重新书写一个Hook工具，而是使用到了第三方提供的框架来做演示。Android的Hook技术虽然发展不久，但是也出现了很多的Hook框架工具。本节我们就具体介绍一下目前常用到的Hook框架。

8.2.1　Xposed框架

Xposed框架是一款可以在不修改APK的情况下影响程序运行（修改系统）的框架服务，通过替换/system/bin/app_process 程序控制 zygote 进程，使 app_process 在启动过程中加载XposedBridge.jar 这个jar包，从而完成对Zygote进程及其创建的Dalvik虚拟机的劫持。基于Xposed框架可以制作出许多功能强大的模块，且在功能不冲突的情况下同时运作。此外，Xposed框架中的每一个库还可以单独下载使用，如Per App Setting（为每个应用设置单独的dpi或修改权限）、Cydia、XPrivacy（防止隐私泄露）、BootManager（开启自启动程序管理应用），对原生Launcher替换图标等应用或功能均基于此框架。

官网地址：。

源码地址：。

Xposed框架是基于一个Android的本地服务应用XposedInstaller与一个提供API的jar文件来完成的。所以，安装使用Xposed框架我们需要完成以下几个步骤。

● 安装本地服务XposedInstaller

需要安装XposedInstall.apk本地服务应用，我们能够在其官网的framework栏目中找到，下载并安装。地址为：

。

安装好后进入XposedInstaller应用程序，会出现需要激活框架的界面，如图8-5所示。这里我们点击“安装/更新”就能完成框架的激活了。部分设备如果不支持直接写入的话，可以选择“安装方式”，修改为在Recovery模式下自动安装即可。

图8-4　Xposed框架Logo

图8-5　XposedInstall应用激活界面

因为安装时会需要Root权限，安装后会启动Xposed的app_process，所以安装过程中会存在设备多次重新启动。

TIPS

　由于国内的部分ROM对Xposed不兼容，如果安装Xposed不成功的话，强制使用Recovery写入可能会造成设备反复重启而无法正常启动。

● 下载使用API库

其 API 库XposedBridgeApi-<version>.jar（version 是 XposedAPI 的版本号，如我们这里是XposedBridgeApi-54.jar）文件，我们能够在Xposed的官方支持xda论坛找到，其地址为：

下载完毕后我们需要将 Xposed Library 复制到 lib目录（注意是 lib 目录，不是Android提供的 libs 目录），然后将这个 jar 包添加到 Build PATH 中，效果如图8-6所示。

图8-6　Android项目中的lib与libs目录截图

如果直接将jar包放置到了libs目录下，很可能会产生错误“IllegalAccessError: Class ref in pre-verified class resolved to unexpected implementation”。估计Xposed作者在其框架内部也引用了BridgeApi，这样操作可以避免重复引用。

8.2.2　CydiaSubstrate框架

如果使用过苹果手机的用户应该对Cydiasubstrate框架一点都不会陌生，因为Cydiasubstrate框架为苹果用户提供了越狱相关的服务框架。Cydiasubstrate原名MobileSubstrate（类库中都是以MS开头的），作者为大名鼎鼎的Jay Freeman（saurik）。当然Cydiasubstrate 也推出了Android版。Cydia Substrate是一个代码修改平台。它可以修改任何主进程的代码，不管是用Java还是C/C++（native代码）编写的。而Xposed只支持HOOK app_process中的 Java 函数，因此 Cydiasubstrate 是一款强大而实用的 HOOK工具。

图8-7　CydiaSubstrate框架Logo

官网地址：http://www.cydiasubstrate.com/

与使用Xposed框架类似，使用Cydiasubstrate框架之前我们需要配置它的使用环境，对于强大的Cydiasubstrate框架使用其实只需要配置两个地方。安装Cydiastrate框架Android本地服务，下载使用Cydiastrate提供的API。

● 安装Cydiastrate框架Android本地服务

一个就是在Android设备中安装Cydiasubstrate框架的本地服务应用substrate.apk，我们可以在其官网下载到。

官方下载地址为：。

当然，我们安装substrate后，需要“Link Substrate Files”（连接本地的Substrate服务文件），这一步是需要Root权限的，连接后还需要重启设备才能够生效。Substrate服务设置应用如图8-8所示。

图8-8　Substrate应用Link后界面

● 下载使用Cydiasubstrate库

Cydiasubstrate官方建议以在Android SDK Manager中添加它们插件地址的方式进行更新下载，如图8-9所示，在用户自定义网址中添加。

图8-9　在Android SDK Manager中添加Cydiasubstate地址

通过使用Android SDK Manager工具下载完Cydiasubstrate框架后，其存储于目录${ANDROID_ HOME}\sdk\extras\saurikit\cydia_substrate下。但是，由于Android SDK Manager在国内使用起来存在很多的限制，下载的时候也不是非常稳定，所以还是建议大家直接去官网下载开发库。

官方下载地址为：。

下载完成后，将得到的所有文件（很多的jar包与so库），都复制到Android项目下的libs文件夹中，就可以直接使用了。效果如图8-10所示。

图8-10　Android工程中的libs目录截图

其中的substrate.h头文件与lib文件夹下的so文件是提供在使用NDK进行原生Hook程序开发中的函数支持库。

TIPS

　CydiaSubstrate框架对于inline Hook的操作目前还存在一些bug，使用的时候可能会出现崩溃的现象，部分使用了国内定制的ROM的设备在使用CydiaSubstrate框架时会出现设备无法重新启动或无法Hook的现象。

8.2.3　ADBI/DDI框架

ADBI（全称为：Android Dynamic Binary Instrumentation Toolkit）即Android的动态二进制指令工具包，兼容Android中的ARM与Thmub指令，提供动态库注入与函数Hook（包括inline Hook）。当然，其也提供了Java层的类似功能，即DDI（Dynamic Dalvik Instrumentation Toolkit）框架。

ADBI/DDI框架与Xposed和CydiaSubstrate框架最大的区别是，它是一个命令行工具，使用起来更加的简单方便。我们可以在Github上找到其源码，地址为：

ADBI：。

DDI：

8.3　HookAndroid应用

前面我们介绍过Cydiasubstrate框架提供在Java层Hook的能力，其中主要是提供了三个比较重要的方法，MS.hookClassLoad、MS.hookMethod、MS.moveUnderClassLoader。三个方法的具体介绍如表8-2所示。

表8-2　CydiaSubstrate中常用到的Java Hook方法

方法名	说明
MS.hookClassLoad	拿到指定Class载入时的通知
MS.hookMethod	使用一个Java方法去替换另一个Java方法
MS.moveUnderClassLoader	使用不同的ClassLoder重载对象

几个方法的具体参数与返回值，我们可以看如下的方法具体定义。

* Hook一个指定的Class * * @paramname Class的包名+类名,如android.content.res.Resources * @paramhook 成功Hook一个Class后的回调 */ voidhookClassLoad(String name, MS.ClassLoadHook hook); /** * Hook一个指定的方法，并替换方法中的代码 *  * @param_class Hook的calss * @parammember Hook class的方法参数 * @paramhook 成功Hook方法后的回调 * @paramold Hook前方法，类似C中的方法指针 */ voidhookMethod(Class _class, Member member, MS.MethodHook hook, MS.MethodPointer old); /** * Hook一个指定的方法，并替换方法中的代码 *  * @param_class Hook的calss * @parammember Hook class的方法参数 * @paramalteration */ voidhookMethod(Class _class, Member member, MS.MethodAlteration alteration); /** * 使用一个ClassLoader重载一个对象 *  * @paramloader 使用的ClassLoader * @paramobject 待重载的对象 * @return重载后的对象 */ 
    
     TmoveUnderClassLoader(ClassLoader loader, T object);
    

8.3.1　尝试Hook系统API

说了这么多我们下面实战一下，如我们希望Hook Android系统中的Resources类，并将系统中的颜色都改为紫罗兰色。思路很简单，我们只需要拿到系统中Resources类的getColor方法，将其返回值做修改即可。

使用substrate来实现分为以下几步。

1．在AndroidManifest.xml文件中配置主入口

需要在AndroidManifest.xml中声明cydia.permission.SUBSTRATE权限，声明substrate的主入口。具体代码如下所示。

2．新创建主入口Main.Java类

上一步中已经声明了主入口为Main类，所以我们需要在对应的目录下新建一个Main类，且需要实现其initialize方法。具体实现如下：

publicclass {
     　　 /**　　  * substrate 初始化后的入口　　  */ staticvoidinitialize() {
     　　} }

3．Hook系统的Resources，Hook其getColor方法，修改为紫罗兰

使用MS.hookClassLoad方法Hook系统的Resources类，并使用MS.hookMethod方法hook其getColor方法，替换其方法。具体实现如下所示。

importJava.lang.reflect.Method; importcom.saurik.substrate.MS; publicclass {
     　　 /**　　  * substrate 初始化后的入口　　  */ staticvoidinitialize() {
     　　　　// hook 系统的 Resources类 　　　　MS.hookClassLoad("android.content.res.Resources", newMS.ClassLoadHook() {
     　　　　　　// 成功hook resources类 publicvoidclassLoaded(Class
     resources) {
     　　　　　　　　// 获取 Resources类中的 getColor方法 　　　　　　　　Method getColor; try{
     　　　　　　　　　　getColor = resources.getMethod("getColor", Integer.TYPE); 　　　　　　　　} catch(NoSuchMethodException e) {
     　　　　　　　　　　getColor = null; 　　　　　　　　} if(getColor != null) {
     　　　　　　　　　　// Hook前的原方法 finalMS.MethodPointer old = newMS.MethodPointer(); 　　　　　　　　　　// hook Resources类中的getColor方法 　　　　　　　　　　MS.hookMethod(resources, getColor, newMS.MethodHook() {
     publicObject invoked(Object resources, Object...args) throwsThrowable {
     intcolor = (Integer) old.invoke(resources, args); 　　　　　　　　　　　　　　// 将所有绿色修改成了紫罗兰色 returncolor & ~0x0000ff00 | 0x00ff0000; 　　　　　　　　　　　　} 　　　　　　　　　　}, old); 　　　　　　　　} 　　　　　　} 　　　　}); 　　} }

4．安装、重启、验证

因为我们的应用是没有Activity，只存在substrate的，所以安装后substrate就会自动地执行了。重启后，我们打开浏览器引用，发现颜色已经改变了，如图8-11所示。

阅读了本例之后，读者们是不是发现使用了CydiaSubstrate框架后我们Hook系统中的一些Java API并不是什么难事？上面的例子我们只是简单地修改了Resources中的getColor方法，并没有涉及到系统与应用的安全。但是，如果开发者直接Hook系统安全方面比较敏感的方法，如TelephonyManager 类中getDeviceId方法、短信相关的方法或一些关键的系统服务中的方法，那么后果是不堪想象的。

图8-11　Hook系统Resources的浏览器前后界面截图

8.3.2　Hook指定应用注入广告

从上面的例子我们可以看出来，使用Cydiasubstrate框架我们能够任意地Hook系统中的Java API，当然其中也用到了很多的反射机制，那么除了系统中给开发者提供的API以外，我们能否也Hook应用程序中的一些方法呢？答案是肯定的。下面我们就以一个实际的例子讲解一下如何Hook一个应用程序。

下面我们针对Android操作系统的浏览器应用，Hook其首页Activity的onCreate方法（其他方法不一定存在，但是onCreate方法一定会有），并在其中注入我们的广告。根据上面对Cydiasubstrate的介绍，我们有了一个简单的思路。

首先，我们根据某广告平台的规定，在我们的AndroidManifest.xml文件中填入一些广告相关的ID，并且在AndroidManifest.xml文件中填写一些使用Cydiasubstrate相关的配置与权限。当然，我们还会声明一个广告的Activity，并设置此Activity为背景透明的Activity，为什么设置为透明背景的Activity，原理如图8-12所示。

图8-12　注入广告Activity原理图

其AndroidManifest.xml文件的部分内容如下所示。

对于Cydiasubstrate的主入口Main类，依照之前的步骤新建一个包含有initialize方法的Main类。这个时候我们希望使用MS.hookClassLoad方式找到浏览器主页的Activity名称，这里我们在adb shell下使用dumpsys activity命令找到浏览器主页的Activity名称为com.android.browser.BrowserActivity，如图8-13所示。

图8-13　使用dumpsys activity查看当前activity名称

使用MS.hookClassLoad方法获取了BrowserActivity之后再hook其onCreate方法，在其中启动一个含有广告的Activity。Main类的代码如下所示。

publicclass {
      　　/**　　 * substrate 初始化后的入口　　 */ staticvoidinitialize() {
      　　　　//Hook 浏览器的主Activity，BrowserActivity 　　　　MS.hookClassLoad("com.android.browser.BrowserActivity", newMS. ClassLoadHook() {
     publicvoidclassLoaded(Class
     resources) {
      　　　　　　　　Log.e("test", "com.android.browser.BrowserActivity"); 　　　　　　　　// 获取BrowserActivity的onCreate方法 　　　　　　　　Method onCreate; try{
     　　　　　　　　　　onCreate = resources.getMethod("onCreate", Bundle.class); 　　　　　　　　} catch(NoSuchMethodException e) {
     　　　　　　　　　　onCreate = null; 　　　　　　　　}  if(onCreate != null) {
     finalMS.MethodPointer old = newMS.MethodPointer(); 　　　　　　　　　　// hook onCreate方法 　　　　　　　　　　MS.hookMethod(resources, onCreate, newMS.MethodHook() {
     publicObject invoked(Object object, Object...args) throwsThrowable {
     　　　　　　　　　　　　　　Log.e("test", "show ad"); // 执行Hook前的onCreate方法，保证浏览器正常启动 　　　　　　　　　　　　　　Object result =　old.invoke(object, args); // 没有Context 　　　　　　　　　　　　　　//执行一个shell启动我们的广告Activity 　　　　　　　　　　　　　　CMD.run("am start -a com.example.hook.AD");  returnresult; 　　　　　　　　　　　　} 　　　　　　　　　　}, old); 　　　　　　　　} 　　　　　　} 　　　　}); 　　} }

对于启动的广告MainActivity，在其中会弹出一个插屏广告，当然也可以是其他形式的广告或者浮层，内容比较简单这里不做演示了。对整个项目进行编译，运行。这个时候我们重新启动Android自带的浏览器的时候发现，浏览器会弹出一个广告弹框，如图8-14所示。

从上面的图片我们可以看出来了，之前我们设置插屏广告MainActivity为无标题透明（Theme.Translucent.NoTitleBar）就是为了使弹出来的广告与浏览器融为一体，让用户感觉是浏览器弹出的广告。这也是恶意广告程序为了防止自身被卸载掉的一些通用隐藏手段。

这里演示的注入广告是通过Hook指定的Activity中的onCreate方法来启动一个广告Activity的。当然，这里我们演示的Activity只是简单地弹出了一个广告。如果启动的Activity带有恶意性，如将Activity做成与原Activity一模一样的钓鱼Activity，那么对于移动设备用户来说是极具欺骗性的。

图8-14　Hook浏览器弹出广告

8.3.3　App登录劫持

看了上面的两个Hook例子，很多读者应该都能够了解了Hook所带来的巨大危害性，特别是针对一些有目的性的Hook。例如我们常见的登录劫持，就是使用到了Hook技术来完成的。那么这个登录劫持是如何完成的呢？下面我们就具体来看看，一个我们在开发中常见到的登录例子。首先我们看看一个常见的登录界面是什么样子的，图8-15所示是一个常见的登录页面。

图8-15　一个登录界面demo

其对应的登录流程代码如下所示。

// 登录按钮的onClick事件 mLoginButton.setOnClickListener(newOnClickListener() {
      　　@Override 　　publicvoidonClick(View v) {
     　　// 获取用户名 　　　　String username = mUserEditText.getText() + ""; //获取密码 　　　　String password = mPasswordEditText.getText() + "";  if(isCorrectInfo(username, password)) {
     　　　　　　Toast.makeText(MainActivity.this, "登录成功！", Toast.LENGTH_LONG).show(); 　　　　} else{
     　　　　　　Toast.makeText(MainActivity.this, "登录失败！", Toast.LENGTH_LONG).show(); 　　　　} 　　} });

我们会发现，登录界面上面的用户信息都存储在EditText控件上，然后通过用户手动点击“登录”按钮才会将上面的信息发送至服务器端去验证账号与密码是否正确。这样就很简单了，黑客们只需要找到开发者在使用EditText控件的getText方法后进行网络验证的方法，Hook该方法，就能劫持到用户的账户与密码了。具体流程如图8-16所示。

图8-16　App登录劫持流程

TIPS

　当然，我们也可以仿照上一个例子，做一个一模一样的Activity，再劫持原Activity优先弹出来，达到欺骗用户获取密码的目的。

明白了原理下面我们就实际地操作一次，这里我们选择使用Xposed框架来操作。使用Xposed进行Hook操作主要就是使用到了Xposed中的两个比较重要的方法，handleLoadPackage获取包加载时的回调并拿到其对应的classLoader，findAndHookMethod对指定类的方法进行Hook。它们的详细定义如下所示。

/**　　* 包加载时的回调　　 */ 　　publicvoidhandleLoadPackage(finalLoadPackageParam lpparam)  　　/**　　 * Xposed提供的Hook方法　　 * 　　 * @paramclassName 待Hook的Class　　 * @paramclassLoader classLoader　　 * @parammethodName 待Hook的Method　　 * @paramparameterTypesAndCallback hook回调　　 * @return 　　 */ Unhook findAndHookMethod(String className, ClassLoader classLoader, String methodName, Object... parameterTypesAndCallback)

当然，我们使用Xposed进行Hook也分为如下几个步骤。

1．在AndroidManifest.xml文件中配置插件名称与Api版本号

2．新创建一个入口类继承并实现IXposedHookLoadPackage接口

如下操作，我们新建了一个com.example.loginhook.Main的类，并实现IXposedHookLoadPackage接口中的handleLoadPackage方法，将非com.example.login包名的应用过滤掉，即我们只操作包名为com.example.login的应用，如下所示。

publicclass implementsIXposedHookLoadPackage {
      　　/**　　 * 包加载时的回调　　 */ publicvoidhandleLoadPackage(finalLoadPackageParam lpparam) throwsThrowable {
     　　　　// 将包名不是 com.example.login 的应用剔除掉 if(!lpparam.packageName.equals("com.example.login")) return; 　　　　XposedBridge.log("Loaded app: " + lpparam.packageName); 　　} }

3．声明主入口路径

需要在assets文件夹中新建一个xposed_init文件，并在其中声明主入口类。如这里我们的主入口类为com.example.loginhook.Main，查看其内容截图如图8-17所示。

图8-17　xposed_init内容截图

4．使用findAndHookMethod方法Hook劫持登录信息

这是最重要的一步，我们之前所分析的都需要到这一步进行操作。如我们之前所分析的登录程序，我们需要劫持就是需要Hook其com.example.login.MainActivity中的isCorrectInfo方法。我们使用Xposed提供的findAndHookMethod直接进行MethodHook操作（与Cydia很类似）。在其Hook回调中使用XposedBridge.log方法，将登录的账号密码信息打印至Xposed的日志中。具体操作如下所示。

importstaticde.robv.android.xposed.XposedHelpers.findAndHookMethod; publicclass implementsIXposedHookLoadPackage {
      　　/**　　 * 包加载时的回调　　 */ publicvoidhandleLoadPackage(finalLoadPackageParam lpparam) throwsThrowable {
      　　　　// 将包名不是 com.example.login 的应用剔除掉 if(!lpparam.packageName.equals("com.example.login")) return; 　　　　XposedBridge.log("Loaded app: " + lpparam.packageName);  　　　　// Hook MainActivity中的isCorrectInfo(String,String)方法 findAndHookMethod("com.example.login.MainActivity", lpparam.classLoader, "isCorrectInfo", String.class, 　　　　　　　　String.class, newXC_MethodHook() {
      　　　　　　　　　　@Override protectedvoidbeforeHookedMethod(MethodHookParam param) throwsThrowable {
     　　　　　　　　　　　　XposedBridge.log("开始劫持了~"); 　　　　　　　　　　　　XposedBridge.log("参数1 = " + param.args[0]); 　　　　　　　　　　　　XposedBridge.log("参数2 = " + param.args[1]); 　　　　　　　　　　}  　　　　　　　　　　@Override protectedvoidafterHookedMethod(MethodHookParam param) throwsThrowable {
     　　　　　　　　　　　　XposedBridge.log("劫持结束了~"); 　　　　　　　　　　　　XposedBridge.log("参数1 = " + param.args[0]); 　　　　　　　　　　　　XposedBridge.log("参数2 = " + param.args[1]); 　　　　　　　　　　} 　　　　　　　　}); 　　} }

5．在XposedInstaller中启动我们自定义的模块

编译后安装在Android设备上的模块应用程序不会立即生效，我们需要在XpasedInstaller模块选项中勾选待启用的模块才能让其正常地生效，如图8-18所示。

6．重启验证

重启Android设备，进入XposedInstaller查看日志模块，因为我们之前使用的是XposedBridge.log方法打印log，所以log都会显示在此处。如图8-19所示，我们发现我们需要劫持的账号密码都显示在此处。

图8-18　Xposed框架加载模块界面

图8-19　XPosed框架日志界面

TIPS

　这里我们是通过逆向分析该登录页面的登录判断调用函数来完成Hook与劫持工作的。有些读者应该想出来了，我们能不能直接对系统中提供给我们的控件EditText（输入框控件）中的getText()方法进行Hook呢？这样我们就能够对系统中所有的输入进行监控劫持了。这里留给大家一个思考，感兴趣的读者可以尝试一下。

8.4　Hook原生应用程序

之前我们演示过了如何在Java层Hook系统的API方法，但是我们都知道很多安全级别较高的操作我们都不会在Java层来完成，而且Java层很多的API都是通过JNI的方式在Native层完成的，所以对Java层的API方法Hook意义不是很大。本节我们就具体来说说在Android中如何使用CydiaSubstrate框架完成Native层的Hook操作。

8.4.1　CydiaSubstrate框架针对Native层Hook的支持

对于CydiaSubstrate框架来说，其给我们提供了类似在Java中的API方法，如在Native层的MSJavaHookClassLoad函数（类似Java中的hookClassLoad方法）、MSJavaHookMethod函数（类似Java中的hookMethod）。作者的意图就是为了让我们能够在Native层使用JNI完成Java函数的Hook。其中两个函数的具体定义如下：

/*** 通过JNI Hook Java中的ClassLoad * * @jni jni指针 * @name 待Hook的类,字符串形式 * @callback Hook后的回调 * @data 自定义参数数据 */ voidMSJavaHookClassLoad(JNIEnv *jni, constchar*name, void(*callback)(JNIEnv *, jclass, void*), void*data);  /** * 通过JNI Hook Java中的指定方法 * * @jni jni指针 * @_class jclass * @methodId 待Hook方法ID * @hook Hook后待替换的函数 * @old Hook前原函数的指针 */ voidMSJavaHookMethod(JNIEnv *jni, jclass _class, jmethodID methodId, void*hook, void**old);

上述的两个函数确实比较有用，但是却不是我们最想要的结果。在Native层Hook我们还是希望针对原生函数进行Hook操作。其实针对Native层的Hook原理，我们在本章的开头已经给各位读者介绍了。CydiaSubstrate只是针对其做了一个良好的封装操作，让我们更方便地使用。下面是CydiaSubstrate框架提供的Hook函数方法。

* 根据具体的地址路径加载动态库 * 类似于dlopen * * @return 动态库ImageRef */ MSImageRef MSGetImageByName(constchar*file);  /** * 根据指定库找到其中函数的偏移量 * 类似于dlsym * * @image 指定的动态库 * @name 指定函数的名称 * @return 指定函数的指针(兼容ARM/Thumb)找不到返回NULL */ void*MSFindSymbol(MSImageRef image, constchar*name);  /** * Hook Native层中的指定函数 * * @symbol 待Hook函数指针 * @hook Hook后待替换的函数指针 * @old Hook前函数指针 */ voidMSHookFunction(void*symbol, void*hook, void**old);

看到上面的函数说明估计读者们都跃跃欲试了，而且相信很多读者已经能够猜出如何使用CydiaSubstrate框架了。下面我们还是详细地说明一下，除了了解其提供的API函数之外，使用CydiaSubstrate框架还需要注意的一些注意事项。

• 基于CydiaSubstrate框架的动态库必须以“.cy.so”（系统默认是“.so”）作为后缀。
• 在AndroidManifest.xml文件中需要声明cydia.permission.SUBSTRATE权限。
• 需要在Native C/CPP方法前添加Config配置。

MSConfig(MSFilterExecutable, "/system/bin/app_process")

好了介绍完毕，下面我们具体地操作一次。

8.4.2　通过JNI改变系统颜色

与之前的尝试Hook系统API小节一样，如我们希望完成Hook Android系统中的Resources类，并将系统中的颜色都改为紫罗兰色。思路也是一样的，我们只需要拿到系统中Resources类的getColor方法，将其返回值做修改即可。那么我们使用原生方法实现，需要完成以下几个步骤。

1．在AndroidManifest.xml中声明权限与安装方式

因为是系统组件代码，我们需要设置其安装方式是internalOnly与hasCode=“false”，这样能够方便CydiaSubstrate框架获取我们的逻辑。当然还需要声明SUBSTRATE权限，具体的操作如下AndroidManifest.xml内容所示。

2．新创建项目的cpp文件，导入所需的库

这里我们新创建一个原生代码文件HookNative.cy.cpp（后缀必须为.cy.cpp，编译后则会出现.cy.so文件），并将CydiaSubstrate的库文件libsubstrate.so、libsubstrate-dvm.so、substrate.h一起复制到jni目录下（这里需要根据不同平台选择，我们这里选择的是ARM平台的库），jni目录如图8-20所示。

图8-20　项目中JNI目录截图

当然，我们还需要编写Makefile文件Android.mk，指定Substrate库参与编译，并引入一些必要的库。内容如下所示。

LOCAL_PATH := $(call my-dir)  # substrate-dvm 库 include $(CLEAR_VARS) LOCAL_MODULE:= substrate-dvmLOCAL_SRC_FILES := libsubstrate-dvm.soinclude $(PREBUILT_SHARED_LIBRARY)  # substrate 库 include $(CLEAR_VARS) LOCAL_MODULE:= substrateLOCAL_SRC_FILES := libsubstrate.soinclude $(PREBUILT_SHARED_LIBRARY)  include $(CLEAR_VARS)  LOCAL_MODULE　　:= HookNative.cyLOCAL_SRC_FILES := HookNative.cy.cpp  LOCAL_LDLIBS+= -L$(SYSROOT)/usr/lib -llogLOCAL_LDLIBS+= -L$(LOCAL_PATH) -lsubstrate-dvm -lsubstrateinclude $(BUILD_SHARED_LIBRARY)

3．载入配置文件与CydiaSubstrate入口

在HookNative.cy.cpp代码文件中，使用CydiaSubstrate框架的API，还需要在其中声明一些东西，如MSConfig配置app_process的路径，声明MSInitialize作为一个CydiaSubstrate插件的入口。我们还会应用一些开发中必要的头文件与LOG声明，如这里我们的HookNative.cy.cpp内容为：

#include
    
      #include
     
        #defineLOG_TAG "native_hook" #defineLOGI(...)　__android_log_print(ANDROID_LOG_INFO, LOG_TAG, __VA_ARGS__)  // 载入配置文件 MSConfig(MSFilterExecutable, "/system/bin/app_process")  // Cydia初始化入口 MSInitialize {
     }
     
    

4．Hook并替换其方法

其修改方法与上一节的Hook Java中的方法类似，我们只需要修改相关的函数完成Hook即可。如这里我们使用MSJavaHookClassLoad方法Hook系统的Resources类，并使用MSJavaHookMethod方法Hook其getColor方法，替换其方法。具体实现如下所示。

#include
    
      #include
     
        #defineLOG_TAG "native_hook"  #defineLOGI(...)　__android_log_print(ANDROID_LOG_INFO, LOG_TAG, __VA_ARGS__)  // 载入配置文件 MSConfig(MSFilterExecutable, "/system/bin/app_process")  // getColor方法Hook前原函数指针 staticjint (*_Resources$getColor)(JNIEnv *jni, jobject _this, ...);  // getColor方法Hook后被替换的函数 staticjint $Resources$getColor(JNIEnv *jni, jobject _this, jint rid) {
     　　jint color = _Resources$getColor(jni, _this, rid); returncolor & ~0x0000ff00 | 0x00ff0000; }  // Hook住Resources class的回调 staticvoidOnResources(JNIEnv *jni, jclass resources, void*data) {
     　　// hook其对应的getColor方法 　　jmethodID method = jni->GetMethodID(resources, "getColor", "(I)I"); if(method != NULL) 　　　　MSJavaHookMethod(jni, resources, method, &$Resources$getColor, &_Resources$getColor); }  // Cydia初始化入口 MSInitialize {
     　　// Hook Java中的Resources 　　MSJavaHookClassLoad(NULL, "android/content/res/Resources", &OnResources); }
     
    

5．编译、安装、重启验证

同样，因为CydiaSubstrate是Hook Zygote进程，而且我们Hook的又是系统的Resources方法，所以我们希望验证都需要重启一下设备。我们可以选择CydiaSubstrate中的软重启，这里我们对系统的设置页面Hook前后都做了一个截图，对比截图如图8-21所示。

图8-21　Hook前后系统设置界面截图对比

本例中我们继续之前Java中Hook的思想，完成了在原生代码中使用JNI针对Java中的API进行Hook操作。因为，CydiaSubstrate框架中的hookClassLoad方法、hookMethod方法底层实现也是如此，所以我们使用起来很类似。

8.4.3　Hook后替换指定应用中的原生方法

讨论了太久的Java层面的API Hook工作，也举了很多例子，本节中我们就看看如何使用CydiaSubstrate框架完成原生函数的Hook。

例如，现在我们有一个应用程序（包名为：com.example. testndklib），其主要功能就是按下界面上的“test”按钮后，通过JNI调用Native的test函数，在系统的Log中输入一个当前我有多少钱的整数值。界面如图8-22所示。

图8-22　testndklib应用界面

使用JNI调用的test函数，写在NDK库testNDKlib中，会调用一个名叫getMoney的函数，显示我当前有多少钱。当然，这里我们直接硬编码了，返回值为100的整数。中间，我们还将 getMoney 函数的地址通过 Log 打印出来。testNDKlib.cpp内容如下所示。

#include
    
      #include
     
       #include
      
        extern"C" {
     #define　LOGI(...)　__android_log_print(ANDROID_LOG_INFO, "cydia_native", __VA_ARGS__)  /** * 测试函数getMoney，返回一个整数 */ intgetMoney(void) {
     　　// 打印方法函数地址 　　LOGI(" getMoney() function address in : %p\n", &getMoney); 　　return100; }  // 一个JNI的test函数 jstring Java_com_example_testndklib_MainActivity_test(JNIEnv* env, 　　　　jobject thiz) {
     　　LOGI(" I have %d money.\n", getMoney()); 　　return0; } }
      
     
    

运行一下程序，单击“test”按钮，拿到了系统输出的 Log，与我们输出的预期一样。笔者将DDMS上输出的Log截图，如图8-23所示。

图8-23　test函数执行后产生的Log

现在我们希望Hook此so文件，找到其中的getMoney函数，替换它让它给我们返回整数值999999（类似一个游戏修改金币的外挂）。针对之前我们讨论的Hook的原理，我们需要做如下几步操作。

（1）加载原生库，libtestNDKlib.so。

（2）找到对应的函数符号地址，MSFindSymbol。

（3）替换函数，MSHookFunction。

这里我们在完成1、2步骤的时候，我们同时也用dlopen与dlsym方式实现给大家演示一下。之前的环境配置逻辑以及权限声明逻辑与上一个例子类似，这里我们不做赘述，直接看一下cpp文件中的内容，具体如下：

#include
    
      #include
     
       #include
      
         #defineLOG_TAG "cydia_native"  #defineLOGI(...)　__android_log_print(ANDROID_LOG_INFO, LOG_TAG, __VA_ARGS__)  // 初始化CydiaSubstrate MSConfig(MSFilterExecutable, "/system/bin/app_process")  // 原函数指针 int(*original_getMoney)(void);  /** * 替换后的函数 */ intreplaced_getMoney(void) {
      　　LOGI(" replaced_getMoney() function address in : %p\n", &replaced_getMoney); 　　return999999; }  /** * * 找到指定链接库中的函数地址 * * @libraryname 链接库地址 * @symbolname 函数名 * @return 对应的函数地址 */ void* lookup_symbol(char* libraryname, char* symbolname) {
     　　// dlopen打开指定库，获得句柄 　　void*imagehandle = dlopen(libraryname, RTLD_GLOBAL | RTLD_NOW); 　　if(imagehandle != NULL) {
     　　　　// 获得具体函数 　　　　void* sym = dlsym(imagehandle, symbolname); 　　　　if(sym != NULL) {
     　　　　　　returnsym; 　　　　} else{
     　　　　　　LOGI("(lookup_symbol) dlsym didn't work"); 　　　　　　returnNULL; 　　　　} 　　} else{
     　　　　LOGI("(lookup_symbol) dlerror: %s", dlerror()); 　　　　returnNULL; 　　} }  //初始化 MSInitialize {
      　　// 获得libtestNDKlib.so动态库中getMoney函数的地址 　　MSImageRef image; 　　image = MSGetImageByName( 　　　　　　"/data/data/com.example.testndklib/lib/libtestNDKlib.so"); 　　void* getAgeSym = MSFindSymbol(image, "getMoney");  　　// MSImageRef与 MSFindSymbol 也可以写为如下所示找到getMoney函数的地址 　　// 　　// void * getAgeSym = lookup_symbol( 　　//　　　　  "/data/data/com.example.testndklib/lib/libtestNDKlib.so", 　　//　　　　  "getMoney");  　　// 将getMoney函数替换为 replaced_getMoney函数 　　MSHookFunction(getAgeSym, (void*) &replaced_getMoney, 　　　　　　(void**) &original_getMoney);  }
      
     
    

编译后安装到已经安装了CydiaSubstrate框架的系统中，重启Android设备。如果在整个系统编译与配置没有什么错误的情况下，我们发现CydiaSubstrate框架会打出Log说Loding什么什么 so 文件了。这里我们看见，LodinglibnativeHook.cy.so 说明我们之前开发的 Hook 其中的getMoney方法已经生效了，如图8-24所示。

图8-24　CydiaSubstrate框架加载日志

这个时候我们继续运行程序，进入我们刚才的test应用程序。单击“test”按钮，获取调用JNI中的test函数打印我有多少钱。我们能够在DDMS中清楚地看到，getMoney函数已经被一个名为“replace_getMoney”的函数替换了，其地址也已经被替换了。我们也看到使用替换后的值输出为“I have 999999 money”，如图8-25所示。

图8-25　函数替换后打印的Log

8.4.4　使用Hook进行广告拦截

对于Android操作系统我们知道，Java层都是建立在原生C/C++语言上的，特别是针对一些系统级别的API函数。上面我们演示了如何对用户自定义函数进行Hook，下面我们演示一下如何对Native层的系统API进行Hook。

如这里我们希望对系统中的网络请求API进行Hook，然后过滤掉一些广告相关的请求，完成广告拦截功能，其具体的流程如图8-26所示。

这里我们查看Android操作系统的POSIX定义的源码Poxis.Java文件，发现其针对网络请求函数的定义是在native完成的，如图8-27所示。

图8-26　广告拦截流程图

图8-27　Posix.Java文件部分内容截图

对于此类的问题，我们就不得不在native完成Hook与函数替换工作了。所以我们还是使用CydiaSubstrate框架，对系统的API函数connect进行Hook与替换。如下代码所示，我们使用MSHookFunction对native层中的connect函数进行Hook替换至newConnect函数。

#defineLOG_TAG "cydia_native" #defineLOGI(...)　__android_log_print(ANDROID_LOG_INFO, LOG_TAG, __VA_ARGS__)  // 初始化CydiaSubstrate MSConfig(MSFilterExecutable, "/system/bin/app_process")  // 原connect函数指针 int*(*oldConnect)(int,  constsockaddr *, socklen_t); int*newConnect(intsocket, constsockaddr *address, socklen_t length) {
      　　charip[128] = {
     0 }; 　　intport = -1; 　　if(address->sa_family == AF_INET) {
     　　　　sockaddr_in *address_in = (sockaddr_in*) address; 　　　　// 获取 ip 　　　　inet_ntop(AF_INET, (void*) (structsockaddr*) &address_in->sin_addr, ip, 　　　　　　　　128); 　　　　// 获取端口 　　　　port = ntohs(address_in->sin_port);  　　　　// 过滤掉172.22.156.129的请求 　　　　if(strcmp(ip, "172.22.156.129") == 0) {
      　　　　　　LOGI("发现广告请求"); 　　　　　　structsockaddr_in my_addr; 　　　　　　intmy_len = sizeof(structsockaddr_in); 　　　　　　bzero(&my_addr, sizeof(my_addr)); 　　　　　　my_addr.sin_family = AF_INET; 　　　　　　my_addr.sin_port = htons(80); 　　　　　　my_addr.sin_addr.s_addr = inet_addr("127.0.0.1");  　　　　　　returnoldConnect(socket, (constsockaddr*) &my_addr, 　　　　　　　　　　sizeof(my_addr)); 　　　　} 　　　　returnoldConnect(socket, address, length);  　　} }  //初始化 MSInitialize{
     　　MSHookFunction((void*) &connect, (void*) &newConnect, 　　　　　　(void**) &oldConnect); }

这里我们只是简单地将IP为172.22.156.129的请求重定向到本地127.0.0.1，即让类似的广告请求拿不到数据。此类方式的广告过滤属于比较原始暴力类型的过滤方法，但却也简单有效。熟悉connect的读者应该会发现，如果已经能够替换掉connect函数，其实我们能做到的事情远远比拦截一个广告请求大得多，比如跳转至钓鱼网站，收集私密发送数据等。

8.5　Hook检测/修复

Hook的目的是为了对目标进程函数的替换和注入，Hook的危害是巨大的，Hook后的应用程序毫无安全可言。其实，自从PC时代起，Hook与反Hook一直就是一个旷日持久的战争。那么对于刚发展不久的Android操作系统安全方向而言，Hook的检测与修复无疑是给Android安全研究人员带来了巨大的挑战。本节我们就具体地看看，就Android操作系统而言，如何检测一个进程是否被Hook了，如何修复被Hook的进程消除其安全隐患。

8.5.1　Hook检测

上面演示了很多的Hook例子，Hook后的应用程序注入与劫持危害是不可估量的。所以，如何识别应用程序被Hook了，如何去除Hook程序也成为了难题。我们先从Hook的原理上来分析，Hook就是在一个目标进程中通过改变函数方法的指向地址，加入一段自定义的代码块。那么，加入一些非本进程的代码逻辑，进程会不会产生一些改变？带着疑问我们直接使用本章之前在浏览器中注入广告的例子查看一下。

1．Java层Hook检测

首先我们使用ps命令查看一下浏览器应用（包名为：com.android.browser）的进程pid，在adb shell模式下输入ps | busybox grep com.android.browser（busybox是一个扩展的命令工具），如图8-28所示。

图8-28　查看浏览器的进程pid

我们这里看见浏览器应用对应的进程pid为5425。

熟悉Android操作系统的朋友应该清楚，Android操作系统继承了Linux操作系统的优点，有一个虚拟文件系统也就是我们常访问的/proc目录，通过它可以使用一种新的方法在Android内核空间和用户空间之间进行通信，即我们能够看到当前进程的一些状态信息。而其中的maps文件又能查看进程的虚拟地址空间是如何使用的。

现在思路已经很清晰了，我们使用命令：

cat /proc/5425/maps | busybox grep /data/dalvik-cache/data@app

查看地址空间中的对应的dex文件有哪些是非系统应用提供的（浏览器是系统应用），即过滤出/data@app（系统应用是/system@app）中的，如图8-29所示。

图8-29　查看5425进程的虚拟地址空间

对应地输出了Dalvik虚拟机载入的非系统应用的dex文件，如图8-30所示。

图8-30　5425进程被加载的用户空间中的dex文件

在图 8-30 中我们清楚地看到，该进程确实被附加了很多非系统的 dex 文件，如 hookad-1. apk@classes.dex、loginhook-2.apk@classes.dex、substrate-1.apk@classes.dex等。如果没有上面的Hook演示，这里我们很难确定这些被附加的代码逻辑是做什么的，当然肯定也不是做什么好事。所以，我们得出结论，此应用已经被Hook，存在安全隐患。

2．native层Hook检测

上面演示了如何检测Java层应用是否被Hook了，对于native层的Hook检测其实原理也是一样的。这里我们对之前的演示的Hook后替换指定应用中的原函数例子做检测（包名为：com.example.testndklib），我们使用ps | busybox grep com.example.testndklib，如图8-31所示。

图8-31　查看com.example.testndklib包进程的详细信息

得到其对应的进程pid为15097，我们直接查看15097进程中的虚拟地址空间加载了哪些第三方的库文件，即过滤处/data/data目录中的，具体命令如图8-32所示。

图8-32　查看15097进程的虚拟地址空间

得到的输出结果如图8-33所示，发现其中多了很多的/com.saurik.substrate下面的动态库，说明该进程也已经被其注入了。所以我们判断com.example.testndklib应用程序已经被Hook，存在不安全的隐患。

图8-33　testndklib包下载入的第三方so库文件

同样的方式，我们能够查看到Zygote进程的运行情况，发现也是被注入了CydiaSubstrate框架的很多so库文件，如图8-34所示。

作为应用程序对自身的检测，也只需要读取对应的进程的虚拟地址空间目录/proc/pid/maps文件，判断当前进程空间中载入的代码库文件是否存在于自己白名单中的，即可判断自身程序是否被Hook。但是，对于zygote进程来说如果没有Root权限，我们是无法访问其maps文件的，那么也就无法判断Hook与否了。

图8-34　zygote进程的虚拟地址空间显示载入的so库文件

8.5.2　Hook修复

如何判断一个进程是否被其他第三方函数库Hook，我们已经知道了。为了让我们的应用程序能够在一个安全可靠的环境中运行，那么我们就必须将这些不速之客从应用程序的进程中剥离出去。

如上面我们演示的testndklib应用程序，我们在adb shell命令模式下查看其进程pid为30210，并根据进程pid查看其对应的进程虚拟地址空间。具体命令如图8-35所示。

图8-35　使用ps | busybox grep查看testndklib的pid

从系统返回的具体结果中我们发现，已经被很多的第三方 Hook 库所加载，这里都是以/com.saurik.substrate开头的substrate框架的动态库，如图8-36所示。

图8-36　testndklib中的虚拟地址空间加载的so库

当然，我们希望除了自身包名（com.example.testndklib）下的其他动态链接全都给删除关闭，且关闭后的应用程序还能够正常地运行。因为所有的第三方库都是通过dlopen后注入的方式附加到应用程序进程中的，这里我们很容易想到我们直接使用 dlclose 将其中的第三方函数挨个卸载关闭即可。

这样一个程序思路就来了，首先扫描/proc/<pid>/maps目录下的所有so库文件，并将自身的动态库文件排除，对于非自身的动态链接库我们全都卸载关闭。对于Java我们无法使用dlclose，所以这里我们还是采用了JNI的方式来完成，具体的操作函数如下所示。

　 /**　　 * 根据包名与进程pid，删除非包名下的动态库　　 * @parampid 进程pid　　 * @parampkg 包名　　 * @return 　　 */ publicList
    
     removeHooks(intpid, String pkg) {
     　　　　List
     
       hookLibFile = newArrayList<>(); 　　　　// 找到对应进程的虚拟地址空间文件 　　　　File file = newFile("/proc/" + pid + "/maps"); if(!file.exists()) {
     returnhookLibFile; 　　　　}  try{
     　　　　　　BufferedReader bufferedReader = newBufferedReader(newInputStreamReader (newFileInputStream(file))); 　　　　　　String lineString = null; while((lineString = bufferedReader.readLine()) != null) {
     　　　　　　　　String tempString = lineString.trim(); 　　　　　　　　// 被hook注入的so动态库 if(tempString.contains("/data/data") && !tempString.contains("/data/data/" + pkg)) {
     intindex = tempString.indexOf("/data/data"); 　　　　　　　　　　String soPath = tempString.substring(index); 　　　　　　　　　　hookLibFile.add(soPath); 　　　　　　　　　　// 调用native方法删除so动态库 　　　　　　　　　　removeHookSo(soPath); 　　　　　　　　} 　　　　　　} 　　　　　　bufferedReader.close(); 　　　　} catch(FileNotFoundException e) {
     　　　　　　e.printStackTrace(); 　　　　} catch(IOException e) {
     　　　　　　e.printStackTrace(); 　　　　} returnhookLibFile; 　　}  　　/**　　 *　卸载加载的so库　　 * @paramsoPath so库地址路径　　 */ publicnativevoidremoveHookSo(String soPath);  //　JNI中的removeHookSo卸载一个so的加载 voidJava_com_example_testndklib_MainActivity_removeHookSo(JNIEnv* env, 　　　　jobject thiz, jstring path) {
     　　constchar* chars = env->GetStringUTFChars(path, 0); 　　void* handle = dlopen(chars, RTLD_NOW); 　　intcount = 4; 　　inti = 0; 　　for(i = 0; i < count; i++) {
     　　　　 if(NULL != handle) {
     　　　　　　 dlclose(handle); 　　　　 } 　　} }
     
    

在需要卸载的应用程序中调用removeHooks(Process.myPid(), getPackageName())就能够轻松地完成上述的功能。那么是否所有的动态库都被卸载移除了？我们重新查看该应用程序的虚拟地址空间，得到结果如图8-37所示。

图8-37　dlclose后的testndklib虚拟地址空间中的so库

比较后大家都会发现，虽然卸载掉了大部分的so动态链接库，但是还是残余了少许没有被卸载干净，如我们这里剩余的libAndroidBootstrap0.so库还是依然在加载中。对于dlclose函数读者们应该都清楚，dlclose用于关闭指定句柄的动态链接库 ，只有当此动态链接库的使用计数为0时，才会真正被系统卸载。也就是说如果我们手动卸载动态链接库之前，系统已经保持对其的应用的话，我们是无法卸载的。

Hook框架的动态库什么时候加载如何加载我们都不能够得知，所以对非本包的动态链接库卸载也需要实时监测去卸载。且就算卸载也不能够完全地保证系统就没有对相关函数的引用，达到卸载干净的目的。所以，我们得出结论，对于Hook后的应用程序修复在目前来说是一项暂无解决方案的工作。

8.5.3　Hook检测小结

说到如何识别一个应用程序是否被Hook、修复Hook，我们会发现因为Android操作系统上沙箱（Sandbox）机制的存在，不管我们采用何种方案手段都没有办法完全避免程序被Hook。这个时候我们就需要将我们的目光转到如何防止应用程序被Hook，预防于未然才是主要的解决方案。