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会引入一堆复杂度。
以上内容来自工作中的总结,如有描述的不对地方还请指正探讨。每种技术的实现细节,网上有大量资料,需深入的同学可自行搜索。
技术交流,欢迎加我微信:ezglumes ,拉你入技术交流群。
扫码关注公众号【音视频开发进阶】,一起学习多媒体音视频开发~~~
喜欢就点个「在看」吧 ▽