Xposed已经作为Android的Java层Hook大哥好多年了，不仅仅是安全研究者和逆向工程师手中的神器，还拥有着很多的插件开发者，在官方仓库收录的插件也已经超过了1000+个，而其服务的用户以各搞机论坛用户为主，也是不尽其数。
Xposed的代码是完全开源的，并且代码量也不算很大，对于安全研究者来说呢，我觉得研究一下Xposed的原理还是很有必要的。
Xposed的github地址：
https://github.com/rovo89/Xposed
https://github.com/rovo89/XposedBridge

本文使用Android4.4的源码进行分析

简单的讲，Xposed是通过替换修改过的app_process来注入Zygote以实现的全局注入。

想要知道Xposed是如何实现的全局注入，首先要分析一下Android系统的启动过程，就可以很方便的理解Xposed选择的注入点。
我画了张图，Android系统的启动大致如下：

从图中可以很方便的理解从BootLoader到显示系统界面的过程。

Zygote，中文是"受精卵"...实际上他就是一个孵化器，所有应用程序的进程都是由它fork出来的。

可以看到，这些包名格式的进程的PPID(父进程PID)都是155，即zygote进程。
Zygote启动之后会建立一个Socket Server，然后fork自身成为一个新的进程——system_server，并让它成为"前端代言人"，当system_server接收到打开进程的请求时，它就会通过Socket跟Zygote通讯，Zygote就再fork自身称为新的进程。

在init.rc中可以看到，Zygote是通过app_process启动的，

这时app_process的任务也很简单，就是把自己的进程名变成Zygote，然后反射调用Zygote的主方法，即com.android.internal.os.ZygoteInit的main()。之后Zygote做的事情就是在介绍中说过的了。

那么Xposed就是通过修改app_process的方式来实现注入Zygote的。
项目地址：https://github.com/rovo89/Xposed 即是修改app_process的源码，在app_main.cpp的main函数中可以看到

可以看到，Xposed首先尝试加载自己的库，如果成功的话，就将runtime.start的类名替换成自己的类：de.robv.android.xposed.XposedBridge，因为app_processs是采用反射main()的方法来调用加载方法，所以只要在这个类中定义一个main()方法，就可以为所欲为了，最后只需在末尾调用一下com.android.internal.os.ZygoteInit的main()让系统继续跑下去就可以实现对Zygote的Hook。

既然已经拿到了Zygote的所有权了，但是现在Application还没跑起来呢，如果这个时候就执行Hook模块，肯定是无法Hook到相关代码的。那么这时候就有必要提一下从Zygote接受到请求之后做了什么，我又简单的画了张图:

值得注意的是，因为fork之后的子进程是会继承父进程的状态继续往下跑，所以到handleChildProc的时候，此时已经是子进程在执行程序了，而ActivityThread也是在新进程中loop。
在Activity的loop中，可以接收的消息也包括了Appcalition的生命周期BIND_APPLICATION和EXIT_APPLICATION。处理BIND_APPLICATION的时候是直接调用了handleBindApplication方法，Xposed便是在Zygote中Hook了这个方法，在这里面执行用户的Hook模块，因为在这个时候，已经可以拿到应用的classLoader了，然后将此classLoader封装成一个LoadPackageParam再传给各个模块的handleLoadPackage即可。
在XposedBridge的main中可看到其调用了initForZygote()

initForZygote中又Hook了handleBindApplication

Xposed在Zygote进程中执行完这些之后，每次fork出来的都是handleBindApplication已经被Hook过的进程，所以当每个应用进程被打开的时候，都会最开始就先执行Xposed的模块插件，然后才开始执行本身的代码。这样就实现了注入到每个应用程序来进行Hook。

findAndHookMethod想必是大家写Xposed插件最常用及最熟悉的一个方法，我们就通过这个方法来分析Xposed是如何实现的Java Hook。

大家知道这个方法的参数是个可变长参数列表，然后它会取最后一个参数来作为callback，即hook时的注入的代码。然后通过反射的方法来得到原本的Method。最后将这两个传给hookMethod。

可以看到hookMethod实际上时调用了一个native函数hookMethodNative，其他参数都很好理解，但是取的这个slot是个什么东西？翻了一下百度，在Dalvik的源码中dalvik/vm/reflect.c:

原来这个slot就是此method在ClassObject的methods中的偏移，directMethods为负，virtualMethods为正。

hookMethodNative对应C函数XposedBridge_hookMethodNative

首先是通过slot获取到Method对象在内存中的Method结构体指针，然后将它设置为一个native方法，再将他的nativeFunc即执行时对应的函数地址设置为hookedMethodCallback的指针，将保存着原method信息的hookInfo暂时存放在本是dalvik字节码的insns，reflectedMethod是原method的java对象，additionalInfo是AdditionalHookInfo对象。
然后当调用到这个方法的时候，执行的就变成了hookedMethodCallback函数了。

主要就是又调了一个java方法methodXposedBridgeHandleHookedMethod，解释一下各个参数，originalReflected就是上面hookInfo的reflectedMethod，original是原method结构体指针，后面的不必解释了吧。

那么methodXposedBridgeHandleHookedMethod做的事情也很好理解，就是先把所有的beforeHookedMethod给调用一遍，然后再还原原来的method调用一遍，最后再把所有的afterHookMethod的给调用一遍，就完成了。

执行原来的方法调用的是native方法invokeOriginalMethodNative。

emm..就是通过拿到备份的method结构体，然后直接调用dvmInvokeMethod即可。

大家在写Xposed模块的时候是不是有一个很不爽的地方，就是每次改两行代码之后又得重启，非常的烦，那么清楚了注入的原理之后，发现这点好像不是必须的！只是rovo89可能是考虑到性能的问题，所以才采用这种方案。实际上，只要轻轻的改动两行代码，就可以实现免重启更新！

Xposed原本是在app_process的时候一次性将模块列表读取，Load之后将其hook类放到一个Set里面，在de.robv.android.xposed.XposedBridge的main()中可以看到

待到应用启动的时候再分别调用每个handleLoadPackage，之后就不再读取插件。因为这样，所以每次fork之后，插件已经被加载在内存中了，就算更新插件也不会被读取加载，所以必须得重启才能使得插件生效。

之前说到，Xposed通过HookhandleBindApplication来进入每个应用进程，那只要在这个时候再loadModules，那不就ojbk了吗？
在loadModule中，进行加载不仅有handleLoadPackage，还有hook资源及hook命令行程序的包，

但是我的需求就是只需要处理handleLoadPackage就可以了，所以给这个参数加个开关isLoadHookLoadPackage，我的代码如下

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课