Xposed的实现解析

Xposed简介

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以实现的全局注入。

Android的启动过程

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

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

应用孵化器 - Zygote

Zygote介绍

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

USER     PID   PPID  VSIZE  RSS     WCHAN    PC         NAME
root      155   1     509740 41876 ffffffff b75761e0 S zygote
drm       156   1     18508  4064  ffffffff b7599ff6 S /system/bin/drmserver
media     157   1     69296  15656 ffffffff b755bff6 S /system/bin/mediaserver
install   158   1     6580   1228  c04d1048 b7507bb6 S /system/bin/installd
keystore  159   1     10172  2088  c03f4a25 b7561ff6 S /system/bin/keystore
root      160   1     1096   4     c044881c 080ddd03 S /system/xbin/su
system    187   1     81040  3860  ffffffff b75b0ff6 S /system/bin/surfaceflinger
root      343   2     0      0     c01cfbd5 00000000 S flush-8:16
root      414   62    6732   1412  c02f4452 b74c6bb6 S /system/bin/sh
root      418   62    6688   1464  c01c0a90 b752e1e0 S logcat
system    424   155   629276 46384 ffffffff b7575ff6 S system_server
u0_a44    506   155   564252 75032 ffffffff b75779eb S com.android.systemui
u0_a0     551   155   525484 25696 ffffffff b75779eb S android.process.acore
wifi      565   1     10776  2912  c01c0a90 b741d1e0 S /system/bin/wpa_supplicant
system    566   155   526468 21732 ffffffff b75779eb S com.android.settings
u0_a22    606   155   521276 24932 ffffffff b75779eb S com.android.inputmethod.latin
radio     623   155   539356 28428 ffffffff b75779eb S com.android.phone
u0_a23    637   155   557680 45252 ffffffff b75779eb S com.android.launcher
u0_a29    673   155   520300 20324 ffffffff b75779eb S com.android.music
u0_a16    693   155   521532 25876 ffffffff b75779eb S android.process.media
u0_a49    719   155   517580 18600 ffffffff b75779eb S com.android.smspush
u0_a15    806   155   521632 19920 ffffffff b75779eb S com.android.dialer
bluetooth 821   155   522828 22284 ffffffff b75779eb S com.android.bluetooth
dhcp      845   1     6656   1452  c01c0a90 b74e6ab6 S /system/bin/dhcpcd
u0_a6     916   155   527828 22036 ffffffff b75779eb S com.android.calendar
u0_a7     943   155   519636 23176 ffffffff b75779eb S com.android.providers.calendar
u0_a12    967   155   521156 21960 ffffffff b75779eb S com.android.deskclock
u0_a17    1019  155   528300 24912 ffffffff b75779eb S com.android.email
u0_a18    1078  155   524976 20436 ffffffff b75779eb S com.android.exchange
u0_a28    1168  155   530852 23100 ffffffff b75779eb S com.android.mms
u0_a32    1215  155   517576 19140 ffffffff b75779eb S com.android.onetimeinitializer
u0_a47    1251  155   517732 19072 ffffffff b75779eb S com.android.voicedialer

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

Zygote的启动

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

service zygote /system/bin/app_process -Xzygote /system/bin --zygote --start-system-server

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

Hook Zygote

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

    isXposedLoaded = xposed::initialize(zygote, startSystemServer, className, argc, argv);
    if (zygote) {
        runtime.start(isXposedLoaded ? XPOSED_CLASS_DOTS_ZYGOTE : "com.android.internal.os.ZygoteInit",
                startSystemServer ? "start-system-server" : "");
    } else if (className) {
        // Remainder of args get passed to startup class main()
        runtime.mClassName = className;
        runtime.mArgC = argc - i;
        runtime.mArgV = argv + i;
        runtime.start(isXposedLoaded ? XPOSED_CLASS_DOTS_TOOLS : "com.android.internal.os.RuntimeInit",
                application ? "application" : "tool");
    }

可以看到，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()

protected static void main(String[] args) {
    ...
        if (isZygote) {
            XposedInit.hookResources();
            XposedInit.initForZygote();
        }
    ...
}

initForZygote中又Hook了handleBindApplication

static void initForZygote() throws Throwable {
    ...
    findAndHookMethod(ActivityThread.class, "handleBindApplication", "android.app.ActivityThread.AppBindData", new XC_MethodHook() {
        @Override
        protected void beforeHookedMethod(MethodHookParam param) throws Throwable {
            ActivityThread activityThread = (ActivityThread) param.thisObject;
            ApplicationInfo appInfo = (ApplicationInfo) getObjectField(param.args[0], "appInfo");
            String reportedPackageName = appInfo.packageName.equals("android") ? "system" : appInfo.packageName;
            SELinuxHelper.initForProcess(reportedPackageName);
            ComponentName instrumentationName = (ComponentName) getObjectField(param.args[0], "instrumentationName");
            if (instrumentationName != null) {
                Log.w(TAG, "Instrumentation detected, disabling framework for " + reportedPackageName);
                XposedBridge.disableHooks = true;
                return;
            }
            CompatibilityInfo compatInfo = (CompatibilityInfo) getObjectField(param.args[0], "compatInfo");
            if (appInfo.sourceDir == null)
                return;

            setObjectField(activityThread, "mBoundApplication", param.args[0]);
            loadedPackagesInProcess.add(reportedPackageName);
            LoadedApk loadedApk = activityThread.getPackageInfoNoCheck(appInfo, compatInfo);
            XResources.setPackageNameForResDir(appInfo.packageName, loadedApk.getResDir());

            XC_LoadPackage.LoadPackageParam lpparam = new XC_LoadPackage.LoadPackageParam(XposedBridge.sLoadedPackageCallbacks);
            lpparam.packageName = reportedPackageName;
            lpparam.processName = (String) getObjectField(param.args[0], "processName");
            lpparam.classLoader = loadedApk.getClassLoader();
            lpparam.appInfo = appInfo;
            lpparam.isFirstApplication = true;
            XC_LoadPackage.callAll(lpparam);

            if (reportedPackageName.equals(INSTALLER_PACKAGE_NAME))
                hookXposedInstaller(lpparam.classLoader);
        }
    });
    ...
}

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

如何实现Hook

findAndHookMethod

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

public static XC_MethodHook.Unhook findAndHookMethod(Class<?> clazz, String methodName, Object... parameterTypesAndCallback) {
    if (parameterTypesAndCallback.length == 0 || !(parameterTypesAndCallback[parameterTypesAndCallback.length-1] instanceof XC_MethodHook))
        throw new IllegalArgumentException("no callback defined");

    XC_MethodHook callback = (XC_MethodHook) parameterTypesAndCallback[parameterTypesAndCallback.length-1];
    Method m = findMethodExact(clazz, methodName, getParameterClasses(clazz.getClassLoader(), parameterTypesAndCallback));

    return XposedBridge.hookMethod(m, callback);
}

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

public static XC_MethodHook.Unhook hookMethod(Member hookMethod, XC_MethodHook callback) {
    ...
    if (newMethod) {
        Class<?> declaringClass = hookMethod.getDeclaringClass();
        int slot;
        Class<?>[] parameterTypes;
        Class<?> returnType;
        if (runtime == RUNTIME_ART) {
            slot = 0;
            parameterTypes = null;
            returnType = null;
        } else if (hookMethod instanceof Method) {
            slot = getIntField(hookMethod, "slot");
            parameterTypes = ((Method) hookMethod).getParameterTypes();
            returnType = ((Method) hookMethod).getReturnType();
        } else {
            slot = getIntField(hookMethod, "slot");
            parameterTypes = ((Constructor<?>) hookMethod).getParameterTypes();
            returnType = null;
        }

        AdditionalHookInfo additionalInfo = new AdditionalHookInfo(callbacks, parameterTypes, returnType);
        hookMethodNative(hookMethod, declaringClass, slot, additionalInfo);
    }
    ...
}

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

static int methodToSlot(const Method* meth)
{
    ClassObject* clazz = meth->clazz;
    int slot;

    if (dvmIsDirectMethod(meth)) {
        slot = meth - clazz->directMethods;
        slot = -(slot+1);
    } else {
        slot = meth - clazz->virtualMethods;
    }

    return slot;
}

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

偷梁换柱

hookMethodNative对应C函数XposedBridge_hookMethodNative

void XposedBridge_hookMethodNative(JNIEnv* env, jclass clazz, jobject reflectedMethodIndirect,
            jobject declaredClassIndirect, jint slot, jobject additionalInfoIndirect) {
    // Usage errors?
    if (declaredClassIndirect == NULL || reflectedMethodIndirect == NULL) {
        dvmThrowIllegalArgumentException("method and declaredClass must not be null");
        return;
    }

    // Find the internal representation of the method
    ClassObject* declaredClass = (ClassObject*) dvmDecodeIndirectRef(dvmThreadSelf(), declaredClassIndirect);
    Method* method = dvmSlotToMethod(declaredClass, slot);
    if (method == NULL) {
        dvmThrowNoSuchMethodError("Could not get internal representation for method");
        return;
    }

    if (isMethodHooked(method)) {
        // already hooked
        return;
    }

    // Save a copy of the original method and other hook info
    XposedHookInfo* hookInfo = (XposedHookInfo*) calloc(1, sizeof(XposedHookInfo));
    memcpy(hookInfo, method, sizeof(hookInfo->originalMethodStruct));
    hookInfo->reflectedMethod = dvmDecodeIndirectRef(dvmThreadSelf(), env->NewGlobalRef(reflectedMethodIndirect));
    hookInfo->additionalInfo = dvmDecodeIndirectRef(dvmThreadSelf(), env->NewGlobalRef(additionalInfoIndirect));

    // Replace method with our own code
    SET_METHOD_FLAG(method, ACC_NATIVE);
    method->nativeFunc = &hookedMethodCallback;
    method->insns = (const u2*) hookInfo;
    method->registersSize = method->insSize;
    method->outsSize = 0;

    if (PTR_gDvmJit != NULL) {
        // reset JIT cache
        char currentValue = *((char*)PTR_gDvmJit + MEMBER_OFFSET_VAR(DvmJitGlobals,codeCacheFull));
        if (currentValue == 0 || currentValue == 1) {
            MEMBER_VAL(PTR_gDvmJit, DvmJitGlobals, codeCacheFull) = true;
        } else {
            ALOGE("Unexpected current value for codeCacheFull: %d", currentValue);
        }
    }
}

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

void hookedMethodCallback(const u4* args, JValue* pResult, const Method* method, ::Thread* self) {
    ...
    dvmCallMethod(self, (Method*) methodXposedBridgeHandleHookedMethod, NULL, &result,
        originalReflected, (int) original, additionalInfo, thisObject, argsArray);
    ...
}

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

private static Object handleHookedMethod(Member method, int originalMethodId, Object additionalInfoObj,
            Object thisObject, Object[] args) throws Throwable {
        ...
        int beforeIdx = 0;
        do {
            try {
                ((XC_MethodHook) callbacksSnapshot[beforeIdx]).beforeHookedMethod(param);
            } catch (Throwable t) {
                XposedBridge.log(t);

                // reset result (ignoring what the unexpectedly exiting callback did)
                param.setResult(null);
                param.returnEarly = false;
                continue;
            }

            if (param.returnEarly) {
                // skip remaining "before" callbacks and corresponding "after" callbacks
                beforeIdx++;
                break;
            }
        } while (++beforeIdx < callbacksLength);

        // call original method if not requested otherwise
        if (!param.returnEarly) {
            try {
                param.setResult(invokeOriginalMethodNative(method, originalMethodId,
                        additionalInfo.parameterTypes, additionalInfo.returnType, param.thisObject, param.args));
            } catch (InvocationTargetException e) {
                param.setThrowable(e.getCause());
            }
        }

        // call "after method" callbacks
        int afterIdx = beforeIdx - 1;
        do {
            Object lastResult =  param.getResult();
            Throwable lastThrowable = param.getThrowable();

            try {
                ((XC_MethodHook) callbacksSnapshot[afterIdx]).afterHookedMethod(param);
            } catch (Throwable t) {
                XposedBridge.log(t);

                // reset to last result (ignoring what the unexpectedly exiting callback did)
                if (lastThrowable == null)
                    param.setResult(lastResult);
                else
                    param.setThrowable(lastThrowable);
            }
        } while (--afterIdx >= 0);
    ...
}

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

还原执行

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

void XposedBridge_invokeOriginalMethodNative(const u4* args, JValue* pResult,
            const Method* method, ::Thread* self) {
    Method* meth = (Method*) args[1];
    if (meth == NULL) {
        meth = dvmGetMethodFromReflectObj((Object*) args[0]);
        if (isMethodHooked(meth)) {
            meth = (Method*) meth->insns;
        }
    }
    ArrayObject* params = (ArrayObject*) args[2];
    ClassObject* returnType = (ClassObject*) args[3];
    Object* thisObject = (Object*) args[4]; // null for static methods
    ArrayObject* argList = (ArrayObject*) args[5];

    // invoke the method
    pResult->l = dvmInvokeMethod(thisObject, meth, argList, params, returnType, true);
    return;
}

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

改造更新免重启的Xposed

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

Xposed原加载机制

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

protected static void main(String[] args) {
    ...
        if (isZygote) {
            XposedInit.hookResources();
            XposedInit.initForZygote();
        }

        XposedInit.loadModules();
    ...
}

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

处理办法

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

private static void loadModule(String apk, ClassLoader topClassLoader) {
        ...
                        if (moduleInstance instanceof IXposedHookZygoteInit) {
                            IXposedHookZygoteInit.StartupParam param = new IXposedHookZygoteInit.StartupParam();
                            param.modulePath = apk;
                            param.startsSystemServer = startsSystemServer;
                            ((IXposedHookZygoteInit) moduleInstance).initZygote(param);
                        }
                        if (moduleInstance instanceof IXposedHookLoadPackage)
                            XposedBridge.hookLoadPackage(new IXposedHookLoadPackage.Wrapper((IXposedHookLoadPackage) moduleInstance));
                        if (moduleInstance instanceof IXposedHookInitPackageResources)
                            XposedBridge.hookInitPackageResources(new IXposedHookInitPackageResources.Wrapper((IXposedHookInitPackageResources) moduleInstance));
                    } else {
                        if (moduleInstance instanceof IXposedHookCmdInit) {
                            IXposedHookCmdInit.StartupParam param = new IXposedHookCmdInit.StartupParam();
                            param.modulePath = apk;
                            param.startClassName = startClassName;
                            ((IXposedHookCmdInit) moduleInstance).initCmdApp(param);
        ...
    }

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

if (XposedBridge.isZygote) {
        if (moduleInstance instanceof IXposedHookZygoteInit) {
            IXposedHookZygoteInit.StartupParam param = new IXposedHookZygoteInit.StartupParam();
            param.modulePath = apk;
            param.startsSystemServer = startsSystemServer;
            ((IXposedHookZygoteInit) moduleInstance).initZygote(param);
        }

        if (moduleInstance instanceof IXposedHookLoadPackage)
            if(isLoadHookLoadPackage)
            {
                XposedBridge.hookLoadPackage(new IXposedHookLoadPackage.Wrapper((IXposedHookLoadPackage) moduleInstance));
            }
        if (moduleInstance instanceof IXposedHookInitPackageResources)
            XposedBridge.hookInitPackageResources(new IXposedHookInitPackageResources.Wrapper((IXposedHookInitPackageResources) moduleInstance));
    } else {
        if (moduleInstance instanceof IXposedHookCmdInit) {
            IXposedHookCmdInit.StartupParam param = new IXposedHookCmdInit.StartupParam();
            param.modulePath = apk;
            param.startClassName = startClassName;
            ((IXposedHookCmdInit) moduleInstance).initCmdApp(param);
        }
    }

实际上就是简单的加了一个if而已，然后在main的地方改成

XposedInit.loadModules(false);

最后就是在hook handleBindApplication的地方加上XposedInit.loadModules(true);

findAndHookMethod(ActivityThread.class, "handleBindApplication", "android.app.ActivityThread.AppBindData", new XC_MethodHook() {
    @Override
    protected void beforeHookedMethod(MethodHookParam param) throws Throwable {
        XposedInit.loadModules(true);
...

嗯，炒鸡简单，改源码不超过2分钟。

编译

改源码两分钟，编译五小时..
rovo89还提供了另外一个项目:https://github.com/rovo89/XposedTools
因为Xposed编译需要依赖AOSP来进行编译，这个工具就是专门用来编译Xposed源码的，使用方法也很简单，填好build.conf然后一把梭就可以了，具体的可以查看百度。

需要注意的是，上叙的源码是新版的xposed，就是支持5.0+art的，而我使用的是4.4.4的源码，模拟器也是4.4，所以clone源码的时候要-b master来切换分支。然后修改的代码也大同小异，就是loadmodule多了个startClassName参数，可以通过getStartClassName()方法获取，就是这样：
XposedBridge.loadModules(getStartClassName(),true);
因为这个老工程是个Eclipse工程，XposedTool是依赖于Gradle，所以无法使用XposedTool编译。直接使用Android Studio - Build Apk最后把文件名改成XposedBridge.jar即可，
最后你可以选择直接修改Xposed Installer将其中的XposedBridge.jar替换再安装，或者在手机上安装好Xposed，然后将修改好的XposedBridge.jar替换/data/data/de.robv.android.xposed.installer/bin/XposedBridge.jar，重启，就可以愉快的调插件玩耍了。

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