关注微信公众号:“编码美丽”技术干货实时推荐,欢迎访问我的github:点击进入

Android中免Root实现Hook的Dexposed框架实现原理解析以及如何实现应用的热修复

Android技术篇 jiangwei212 4962℃ 0评论

一、前言

今天我们来看一下阿里的一个开源框架Dexposed,关于这个框架网上已经有很多解析了,但是都是讲解原理,而且讲的不是很清楚,这里因为工作中的需要就研究了一下,所以这里就先讲解一下这个框架的原理,然后在通过一个例子来看看他如何使用,最后在用它来实现应用的热修复问题。

二、知识点准备

首先在讲解这个框架的时候,我们先来了解几个知识点:

1、关于之前的Xposed框架

我们在很早就知道了这个框架,本来想整理一下顺便说一下这个框架的,但是这个框架网上说的很多,而且也很详细,所以就不做太多的解析了,这里就大致说一下他的中心思想和核心原理。

通过进行设备root之后,替换/system/bin/app_process程序控制zygote进程,使得app_process在启动过程中会加载XposedBridge.jar这个jar包,从而完成对Zygote进程及其创建的Dalvik虚拟机的劫持。

那么这里就引出了一个问题,为什么要替换app_process程序呢?

关于app_process程序网上也有很多讲解了,他其实是一个程序,存放在system/bin目录下的,他的作用就是启动一个程序,比如我们熟知的zygote进程,还有所有app启动,app_process只要找到需要运行程序的main函数也就是入口函数,然后执行,他不仅能执行C/C++程序,也可以执行Java程序,其实在之前我们遇到过一个情况,就是想在Android中运行一个Java程序的jar,其实那个就是用的app_process命令启动的。运行的命令也很简单:

app_process [java-options] cmd-dir start-class-name [options]

我们可以查看他的源码app_main.cpp


从app_process的main函数(在app_main.cpp里面)可以看出,app_process有两种启动方式:一种是init.rc里面的这种方式,这种方式将会以zygote模式启动com.android.internal.os.ZygoteInit,并将进程名称改为zygote;另外一种是以非zygote模拟启动com.android.internal.os.RuntimeInit,并调用它的main方法,main的最后会执行finishInit,finishInit是一个native方法,这个方法会调用app_process的onStarted方法,在onStarted里面将会调用真正要执行的class:


在这里不想介绍的太多,因为后面会说到Android的一个应用的启动过程的时候,再详细解析。这里我们知道一个点就是Android中的所有程序都是通过app_process命令启动,而且app_process命令还可以启动任何Java程序,比如我们用到的am命令,这个命令Java源码和shell源码位于:Android源码目录\frameworks\base\cmds\

我们可以查看他的java源码内部实现:


指定有一个入口函数main

然后再看看他shell源码:


看到了这里首先设置CLASSPATH变量,就是am.jar的路径,然后开始执行命令,命令中需要指定具体的类名。

这里我们也学会了如何在Android中执行一个jar文件啦。

那么从上面我们分析了app_process命令的作用,那么我们就知道了为什么Xposed框架需要替换app_process命令了:

首先在Android系统中,应用程序进程都是由Zygote进程孵化出来的,而Zygote进程是由Init进程启动的。Zygote进程在启动时会创建一个Dalvik虚拟机实例,每当它孵化一个新的应用程序进程时,都会将这个Dalvik虚拟机实例复制到新的应用程序进程里面去,从而使得每一个应用程序进程都有一个独立的Dalvik虚拟机实例。这也是Xposed选择替换app_process的原因。
Zygote进程在启动的过程中,除了会创建一个Dalvik虚拟机实例之外,还会将Java运行时库加载到进程中来,以及注册一些Android核心类的JNI方法来前面创建的Dalvik虚拟机实例中去。注意,一个应用程序进程被Zygote进程孵化出来的时候,不仅会获得Zygote进程中的Dalvik虚拟机实例拷贝,还会与Zygote一起共享Java运行时库。这也就是可以将XposedBridge这个jar包加载到每一个Android应用程序中的原因。XposedBridge有一个私有的Native(JNI)方法hookMethodNative,这个方法也在app_process中使用。这个函数提供一个方法对象利用Java的Reflection机制来对内置方法覆写。

看到了吧,这就是Xposed框架选择app_proess作为入口的一个原因,因为这个入口有两个好处:

1》、一旦修改了,就可以修改了所有的app

2》、这里的时机是最早的,可以加载所有的东西

上面就简单的分析了一下Xposed框架的实现原理,这个是我们需要了解的第一个知识点。

2、修改非native方法为native方法

第二我们需要了解的知识点是,如何将Android中一个非native方法改成native的,并且可以将这个native方法指定成特定执行的函数。

关于这个知识点,我在之前的一篇文章:Android中通过进程注入技术修改系统返回的Mac地址

这篇文章就很详细的讲解了我们如何修改系统的获取Mac地址的方法,原理很简单:

将系统的获取Mac地址的方法getMacAddress改成native的,然后指定nativeFunc为dvmResolveNativeMethod这个函数,这个函数是dvm提供的。其中dvmResolveNativeMethod调用了dvmLookupInternalNativeMethod和lookupSharedLibMethod来查找jni中注册的native函数。 dalvik最后将执行得到的java native函数.

通过上面的代码片段,我们了解到要对一个java函数进行hook需要步骤有
[1] 把修改method的属性修改成native
[2] 修改method的registersSize、insSize、nativeFunc、computeJniArgInfo
[3] RegisterNatives注册目标method的native函数

然后我们将系统获取Mac地址的方法getMacAddress和我们自己的一个函数做一次注册:

{“android/net/wifi/WifiInfo”,”getMacAddress”,”()Ljava/lang/String;”,(void*)test}

那么这里的test函数就是我们自己想要做事的函数,可以返回任意值啦~~


这个知识点很重要,也是我们今天说的核心知识点

三、原理分析

分析完了上面的两个知识点,下面我们就来正式看看Dexposed框架的原理了,首先我们通过一张图来了解一下:


看到了吧,其实不是很复杂,主要分为Java层和Native层的,

第一、首先我们来分析一下Java层的DexposedBridge.java类

1、hookMethodNative方法:


这个方法是一个native