Android平台开发测试过程中，Hook技术是每个开发人员都常用的技术。可以用于绕过系统限制、修改别人发布的代码、动态化、调用隐藏API、插件化、组件化、自动化测试、沙箱等等。
Hook如果要跨进程修改，则需先提权注入目标进程中。
本文主要盘点已经有Android进程权限后去如何hook修改运行时环境。例如：修改自己的进程。Hook相关技术名词很多，如：Xposed、inline hook、GOT、Native hook等等，但是这些hook技术的适用范围和优缺点，想必很多人还不能解释的清楚。
本文盘点这些技术的适用范围、优缺点、及基本原理。为方便阅读，先给出结论如下表，后面再一一展开。
Android进程结构
要了解hook技术，首先得了解Android进程的基本结构，进程中不同区域得用不同的hook技术去解决。
构成如上图，
Android本质是Linux系统，Android进程本质就是一个Linux进程。 进程由外层到里拆解：- 首先，最外层是一个linux进程，动态链接了一堆动态链接库so，其中有名如：libc标准C函数库、webkit、openGL等。
- Linux进程中主要运行的是ART/Davlik虚拟机，虚拟机包含Classloader、对象管理（内存管理）、线程调度等。虚拟机为JAVA提供运行时环境。
- 如果应用还包含navtive代码，native代码会和虚拟机一起在Linux进程中运行，两者是平行的关系
- 虚拟机中，包含JAVA FrameWork和应用JAVA代码两部分。
- Android进程和其他进程交换数据，依赖于linux内核提供进程通信接口（驱动），如：Binder通信、Socket通信等等
hook就是去修改Android进程中的这些组件，达到某预期目的的过程。
Android进程Hook：
反射/动态代理
如图中A点，作用于Java层。反射/动态代理是虚拟机提供的标准编程接口，可靠性较高。反射API可以帮助我们们访问到private属性并修改，动态代理可以直接从Interface中动态的构造出代理对象，并去监控这个对象。
常见的用法是，用动态代理构造出一个代理对象，然后用反射API去替换进程中的对象，从而达到hook的目的。如：对Java Framework API的修改常用这种方法，修改ActivityThread、修当前进程的系统调用等。
缺点：只在java层，只能通过替换对象达到目的，适用范围较小 优点：稳定性好，调用反射和动态代理并不存在适配问题，技术门槛低JNI Hook
如图中B点，java代码和native之间的调用是通过JNI接口调用的，所有JNI接口的函数指针都会被保存在虚拟机的一张表中。所以，java和native之间调用可以通过修改函数指针达到。
优点：稳定性高 缺点：只能hook Java和Native之间的native接口函数ClassLoader
如图中C点，java代码的执行都是靠虚拟机的类加载器ClassLoader去加载，ClassLoader默认的双亲委派机制保证了ClassLoader总是从父类优先去加载java class。所以一类hook方案就是通过修改ClassLoader加载java class的Path路径达到目的。常见的应用场景有一些热修复技术。
优点：稳定性高 缺点：需要提前编译好修改后的class去替换，灵活性降低了Xposed相关
如图中D点，这类hook技术的原理都是去修改ART/Dalvik虚拟机，虚拟机为java提供运行时环境，所有的java method都保存在虚拟机一张Map维护，每个Java Method都有个是否是JNI函数的标志位，如果是JNI函数则去查找对应的native函数。所以，一个hook方案是通过把要hook的函数修改为JNI函数，然后实现一个对应的native函数从而达到hook。
大量的一些自动化测试、动态调试都采用这个方法
优点：java层所有的class都可以修改，Activity等都可以注入。灵活性极高。 缺点：ART/Dalvik每次Android系统发布大版本都会被大改，导致每个Android版本都要去适配配。稳定性变差。前面hook技术都是去修改虚拟机中的java层，如果一个应用还包含Native code话，则得使用不同hook技术
GOT动态链接库hook
如图中E点，Android进程（linux进程）加载动态链接库的时候，都是通过dlopen()函数去把SO读入到当前进程中的一个内存区域中。当调用so代码时，直接跳转到so的内存区域去执行。so对外提供的函数表及函数地址也都在这块内存中。所以，一个hook方法是，修改这块函数地址，从而达到hook的目的。
例如native层的IO重定向，就可以通过这个技术hook libc的open read write等函数实现。
有大量的GOT注入库可以使用
优点：所有so的入口函数都可以被hook，稳定性高 缺点：替换后的函数签名要保持一致，只能hook so入口，无法hook so内部代码逻辑，且so的调用出现内联调用时（不查表直接跳函数地址）无法hook。Inline hook
如图中F点，因为GOT技术的局限性，有些场景需要hook so内部函数。这就要用到inline hook技术。基本原理是在目标函数执行区域中插入Jump指令，使得cpu跳转到我们的hook函数（shellcode）中。如果我们的hook函数和原目标函数的签名不一致，还需额外保存寄存器信息，跳转回原函数时恢复寄存器信息。inline hook原理虽简单，但是实现起来需要处理的细节很多，因为是直接去改so，所以和指令平台强相关，armv7，armv8，arm64，x86, Thumb指令集都需要去针对性的实现。github中有大量的开源hook框架可参考使用，但稳定性值得考究。
Android进程通信hook
Android进程和其他进程交换数据主要依赖于linux内核提供的进程通信接口。如：socket、Binder等等。所以，还存在一类hook这些通信接口的技术方案。
Binder进程通信hook
Binder进程通信结构如图，是一种典型的Proxy代理接口。Client端通过Proxy向服务端Imp发送消息。Proxy和Imp实现同样的Interface。所以Binder通信都是可以利用动态代理技术去替换Proxy或Imp来达到监控Binder通信的目的。常见的如：hook AMS、WMS、IMS等服务。沙箱技术如VirtualApp、一些自动化监测技术常常用到。且稳定性较高
Socket通信hook
Socket通信提供几个hook思路：
- 只hook Java层的调用，用Xposed类方案hook socket相关class就可做到
- 如果socket是client端，或者支持重新建立连接，某些场景可以构造自己的socket去conect，从而达到hook的目的
- native层则要用户GOT hook
IO重定向
思路：
- 简单的hook可以通过反射等手段修改Path达到
- java层可以用xposed，但因xposed的缘故，稳定性欠佳
- 通用的方案是用GOT hook Libc达到重定向，java层和native都可以解决
Hook技术使用心得
hook方案的选择是一门学问，几个心得原则是：
- 从简，能用简单方案解决的用简单方案 ，切勿轻易增加复杂度。否则稳定性和后期的维护都可能得不偿失。
- 并不是越底层的方案越好 ，越底层的hook技术可能反而引入局限性。例如：Xposed修改所有的Activity很简单，但是只修改某个Activity就变得复杂，因为为了定位出这个特殊Activiy会引入一堆复杂度。
以上内容来自工作中的总结，如有描述的不对地方还请指正探讨。每种技术的实现细节，网上有大量资料，需深入的同学可自行搜索。