Android热修复之Xposed

2017-05-31  本文已影响116人  WuRichard

主流热修复技术方案

Java流派(除了Tinker)使用的dex插桩方案在Dalvik平台上存在性能损耗、而在ART平台由于地址偏移问题则会导致补丁包过大。

Native流派实现技术都是基于native hook技术实现热补丁,但痛点在于兼容性存在很大问题(贴出下表大家自己体会),由于是基于Native层实现的,所以调试以及异常排查的难度大大增加,也存在无法增加变量与类等限制,无法做到功能发布级别。
提到native hook技术就引出了今天的主角Xposed框架目前市面上基于native层实现的热修复框架都借鉴了Xposed框架中的设计思想,在这个框架下,我们可以加载很多插件App,这些插件App可以直接或间接操纵系统层面的东西,比如操纵一些本来只对系统厂商才开放的功能。 而且理论上该框架支持我们hook系统中的任意一个Java进程(当然,使用该框架有一个必要的前提:Root)。因此,与其去分析这些native流派的热修复框架,倒不如直接分析Xposed框架,学习作者设计该框架用到的思想,感受作者在Android、Java、linux上的高深造诣。

Runtime Android Version Support
Dalvik 2.2 Not Test
Dalvik 2.3 Yes
Dalvik 3.0 No
Dalvik 4.0-4.4 Yes
ART 5.0 Testing
ART 5.1 No
ART M No

Note:本文主角是Xposed,所以关于Java流派的实现方案暂不讨论。

什么是native hook

首先我们可以先看看Java层的hook技术,其实也就是Java中的动态代理,通过调用Proxy类的静态方法newProxyInstance去创建出一个代理类,然后在这个代理类里面执行原方法的前后加入自己的执行逻辑以达到hook效果(这种技术只对本应用有效,无法去hook其他的Java进程)。
Xposed框架使用的是inline hook方式,通过替换函数开始处的指令为跳转指令,使得原函数跳转到自己的函数,通常还会保留原函数的调用接口。

Xposed的hook流程

  1. 先找到目标函数在native层对应的Method对象;
  2. 修改这个Method为native方法,并设置nativeFunc为hookedMethodCallback函数;
  3. 保存原函数的一些信息到insns域。

下面是Xposed中native层以及Java层的时序图(部分函数调用省略)


Xposed jni调用时序图.png Xposed java层调用时序图.png
首先看图1中标红的addJarToClasspath部分,这个流程其实是将Xposed自己的XposedBridge.jar以及对应平台的so文件给加入到环境变量中,这一步的作用是什么呢?上面我们介绍的hook方法有提到一个局限:无法hook系统中其他的进程。
Andorid系统中第一个运行的Dalvik虚拟机程序叫zygote(卵),zygote进程在启动的时候会去加载Android一些共享的类和资源(也就是Framework层的代码),因为zygote进程用于孵化出其他Dalvik进程,所以当这些类和资源被装载后,新的Dalvik进程就不需要再去装载了。
回到刚刚说的addJarToClasspath部分,这里其实就相当于在zygote进程启动的时候多装载了一部分东西(XposedBridge.jar、so文件),讲到这里想必你已经懂了,这就相当于系统中的卵已经不干净了,被注入了奇怪的东西在里面,所以这个卵孵化出来的进程都已经不是原来纯粹的进程,既然这个孵化器都已经被我们控制了,那还有什么是我们不能做的呢?

hook处理分析

前面我们已经搞清楚了Xposed是如何做到hook系统中的其他进程的,接下来我们就要搞懂Xposed是怎么去对目标函数挂钩的,这部分主要涉及到findAndHookMethod、hookMethod以及XposedBridge_hookMethodNative三个方法。先看下面的流程图

Xposed hook流程.png
上一篇下一篇

猜你喜欢

热点阅读