Android中Xposed框架篇---基于Xposed的一款脱壳神器ZjDroid工具原理解析

一、前言

在前文中我们介绍了如何使用Xposed框架修改地理位置信息来进行自身的隐藏功能，本文将继续介绍Xposed框架的另外一个功能就是实现应用的简单脱壳，其实说是Xposed的作用其实也不是，主要是模块编写的好就可以了，主要是利用Xposed的牛逼Hook技术实现的，下面就先来介绍一下这个脱壳模块工具ZjDroid的原理，因为他是开源的，所以咋们直接分析源码即可，源码的下载地址：https://github.com/halfkiss/ZjDroid 不过可惜的时候他只公开了Java层的代码，而native层的代码并没有公开，但是分析源码之后会发现最重要的功能就在native层，不过也没关系，等分析到那里的时候我在给大家讲解底层的大致实现方案即可。

二、ZjDroid原理分析

下面就来详细的分析一下ZjDroid工具的源码吧，他是一个Eclipse工程导入很简单，基于之前的Xposed模块编写的经验，我们知道找到入口代码也很简单，在assets目录下有一个xposed_init文件中就记录了模块的入口类：

我们直接进入到这个类即可：

看到了，遵循统一规则，实现了IXposedHookLoadPackage接口，实现handleLoadPackage回调方法即可，下面继续分析入口方法ModuleContext：

这里开始拦截Application的onCreate方法了，而这个方法一般是每个应用程序的启动方法，在这里做拦截操作也是合情合理的，在看看拦截之后做了什么，也就是ApplicationOnCreateHook类的实现：

在这里开始了真正的拦截操作了，主要是添加了一个广播，也就是说设备中每个应用在启动的时候都回去注册这个广播，而如果后续发送一个这样对应Action的广播的话，每个应用程序都会收到。所以这里可以看到，核心工作就在这个广播的接受之后做了，接下来继续去看这个广播的定义：

果然在这里，可以看到了首先会通过发送广播的intent中携带一些数据过来，主要是两个数据：

一个是进程id：这个作用主要是为了过滤其他应用，只处理本应用的逻辑，因为这个广播发送之后所有的应用都能接收到，但是我们脱壳有时候肯定只是针对于某一个应用，那么只需要在这个应用的广播接收中做处理即可。

一个是命令字符串：这个是为了发送广播可以支持多种功能，后面分析也可以看到的确有很多功能的。

然后这里得到命令之后就开始构造一个命令执行器类，这里用到了设计模式中的命令模式。下面继续看看有哪几种命令执行器类：

在这个方法中就开始分析了这里支持的哪几种命令类，下面来一一分析一下：

第一个命令：dump_dexinfo

获取应用运行时内存中dex的信息：DumpDexInfoCommandHandler

进入方法在详细查看一下：

看到了，这里的实现逻辑还是比较简单的，全部通过反射机制获取每个应用的dex文件对应的DexFile类型对象，这里的工作和我们之前介绍了Android中插件化开发已经很熟悉了，通过应用的默认类加载PathClassLoader类得到DexPathList类，然后在得到具体的DexFile对象即可。这里要说的就是这个dex文件对应的cookie值，这个值非常重要，是后续命令操作的基本信息，他代表的含义就是底层中每个应用的dex文件对应的唯一id值，系统会维护一个map结构来保存这些数据的，系统然后通过这个cookie值来找到对应的dex文件信息的。

命令用法：am broadcast -a com.zjdroid.invoke --ei target [pid] --es cmd '{"action":"dump_dexinfo"}'

这里使用的是命令方式发送一个广播，通过--ei携带目标进程id是一个int类型，通过--es携带命令字符串

第二个命令：dump_dexfile

这个命令也是后续脱壳的重要命令，就是dump出应用内存中的dex文件：DumpDexFileCommandHandler

这里可以看到dump出应用的内存数据，首先得需要传入源应用的dex数据也就是apk文件，这个一般都是存放在/data/app/xxx.apk目录下的，然后就是这里自己构建了一个dump之后的dex文件路径，通过源码查看是在/data/data/xxx/files/dexdump.odex中。接下来继续查看dump的核心代码：

看到这里有一个核心的方法，但是可惜的是这个方法是native的，而这个工具并没有把native层的代码公开，但是通过这里传递的参数可以了解到，底层应该是采用了libdvm.so或者是libart.so库来得到具体的函数，然后通过dex对应的cookie值获取信息。

命令用法：am broadcast -a com.zjdroid.invoke --ei target [pid] --es cmd '{"action":"dump_dexfile","dexpath":"*****"}'

注意这里的dexpath参数是代表需要脱壳的dex文件，也就是应用程序文件。

第三个命令：backsmali

这个命令其实是和上面的命令差不多功能，只是这里的命令多了一层操作就是把dex文件转化成smali文件，所以这里不再详细说明了，咋们可以先得到dex文件，然后在通过工具得到smali文件也是可以的。

命令用法：am broadcast -a com.zjdroid.invoke --ei target pid --es cmd '{"action":"backsmali","dexpath":"*****"}'

注意这里的dexpath参数是代表需要脱壳的dex文件，也就是应用程序文件。而最终生成的smali文件夹是放在/data/data/xxx/smali下面的。

第四个命令：dump_mem

这个命令是用来dump出应用程序运行时内存中指定开始位置和长度的内存块数据的：DumpMemCommandHandler

可惜这个方法也是native层的，但是这个操作就比较简单了，我们知道每个应用运行时的内存地址都在 /proc/[pid]/maps 文件中：

那么查找内存地址，然后在使用memcpy进行内存数据拷贝也是非常简单的。

命令用法：am broadcast -a com.zjdroid.invoke --ei target [pid] --es cmd '{"action":"dump_mem","start":111,"length":23}'

注意这里的start和length都是十进制的，而不是十六进制的数据格式。

第五个命令：dump_heap

这个命令是可以dump出虚拟机的堆内存信息的，文件可以使用java heap工具进行分析，而对于这个命令我们想一下应该也知道实现逻辑应该是也是在native层的，而且这个代码逻辑应该和上面的那个命令差不多的，但是对于这个命令我还没有想到具体的思路，悲哀呀，如果有了解的同学就告知一下哈！

命令用法：am broadcast -a com.zjdroid.invoke --ei target [pid] --es cmd '{"action":"dump_heap"}'

第六个命令：dump_class

这个命令主要是用于dump出dex文件中的类信息，这个操作也是非常简单的，因为在DexFile对象中有一个隐藏的方法可以把dex文件中的所有类名获取到：getClassNameList

这里可以看到这个方法的传入参数为一个dex文件对应的cookie值。

命令用法：am broadcast -a com.zjdroid.invoke --ei target pid --es cmd '{"action":"dump_class","dexpath":"*****"}'

这里的dexpath是需要得到所有类信息的dex文件路径，也就是应用的apk文件路径。

第七个命令：invoke

这个命令是用于运行时动态调用Lua脚本，本人并没有看懂这个命令的作用，该功能可以通过Lua脚本动态调用java代码。使用场景：可以动态调用解密函数，完成解密。可以动态触发特定逻辑。代码就不进行分析了，因为我觉得这个命令应该不怎么会使用

命令用法：am broadcast -a com.zjdroid.invoke --ei target pid --es cmd '{"action":"invoke","filepath":"****"}'

这里的filepath是lua脚本文件的存放路径。

到这里就全部介绍完了ZjDroid的所有命令了，下面还有两个非常重要的打印日志的tag：

第一个：adb logcat -s zjdroid-shell-{package name}

这个tag可以查看上面每个命令执行的结果，便于查看命令执行的状态。

第二个：adb logcat -s zjdroid-apimonitor-{package name}

这个tag可以监听对应包名应用调用的哪些api信息，这个作用有点类似于运行时权限请求的作用。这个做起来就非常简单了，可以直接通过Xposed提供的方法进行系统的一些敏感api进行拦截然后添加监控代码即可。

三、命令总结

上面就从源码的角度完全分析完了ZjDroid工具的功能了，下面就来总结一下：

1、获取APK当前加载DEX文件信息
am broadcast -a com.zjdroid.invoke --ei target pid --es cmd '{"action":"dump_dexinfo"}'

2、获取指定DEX文件包含可加载类名
am broadcast -a com.zjdroid.invoke --ei target pid --es cmd '{"action":"dump_class","dexpath":"*****"}'

3、根据Dalvik相关内存指针动态反编译指定DEX，并以文件形式保存
am broadcast -a com.zjdroid.invoke --ei target pid --es cmd '{"action":"backsmali","dexpath":"*****"}'

4、Dump指定DEX内存中的数据并保存到文件（数据为odex格式，可在pc上反编译）
am broadcast -a com.zjdroid.invoke --ei target pid --es cmd '{"action":"dump_dexfile","dexpath":"*****"}'

5、Dump指定内存空间区域数据到文件
am broadcast -a com.zjdroid.invoke --ei target pid --es cmd '{"action":"dump_mem","start":1234567,"length":123}'

6、Dump Dalvik堆栈信息到文件，文件可以通过java heap分析工具分析处理
am broadcast -a com.zjdroid.invoke --ei target pid --es cmd '{"action":"dump_heap"}'

7、运行时动态调用Lua脚本
该功能可以通过Lua脚本动态调用java代码。使用场景：可以动态调用解密函数，完成解密。可以动态触发特定逻辑。
am broadcast -a com.zjdroid.invoke --ei target pid --es cmd '{"action":"invoke","filepath":"****"}'

8、相关命令执行结果查看
1》、命令执行结果
adb shell logcat -s zjdroid-shell-{package name}

2》、敏感API调用监控输出结果
adb shell logcat -s zjdroid-apimonitor-{package name} 

四、案例使用分析

下面咋们就要用一个案例来看看这个工具到底如何使用，有哪些功效，咋们就用一个应用做案例，就是捕鱼达人v1.0.1版本，具体的apk文件可以自行去网上搜索哈。我们安装游戏之后，然后顺便把上面的ZjDroid模块工具也安装上，然后进行重启生效。

我们最好是单独开一个CMD窗口用来查看打印结果，但是从上面的命令可以看到，我们应该需要这游戏的包名和进程id，那么这两个数据怎么获取呢？其实我在前面的文章已经介绍了很多次了，用一个命令即可：adb shell dumpsys activity top 但是这时候需要运行起来捕鱼达人游戏：

这里看到了，就非常简单的获取到了游戏的包名：org.cocos2d.fishingjoy3和进程id=25304，这两个数据非常重要可以这里先进行保管，进而后面可以使用。

下面首先来看一下这个应用用了哪些敏感的api数据，使用上面查看日志的命令即可：

adb shell logcat -s zjdroid-apimonitor-org.cocos2d.fishingjoy3

看到了，这里又网络请求信息，网络切换的广播等数据的，感觉还是蛮有用的这个工具。

下面在来看一下这个应用的dex文件信息，可以使用下面命令即可：

am broadcast -a com.zjdroid.invoke --ei target 25304 --es cmd '{action:dump_dexinfo}'

这里运行之后的结果：

这时候会发现，运行没有看到实际效果，原因是因为我们需要通过日志才能可以看到数据的，因为上面命令运行的结果都是需要通过这个日志才可以看到的：adb logcat -s zjdroid-shell-org.cocos2d.fishingjoy3

这里就可以看到了具体的信息了，看到了有一个filepath这个就是我们后续有些命令需要用到的dex路径，所以一定要记下来，后面的命令会使用到的。

接下来在看一个关于dump出游戏中所有的类名的命令：

am broadcast -a com.zjdroid.invoke --ei target 25304 --es cmd '{"action":"dump_class","dexpath":"/data/app/org.cocos2d.fishingjoy3-1.apk"}'

这里的路径就是上面获取到的apk路径，结果咋们还是需要通过上面的日志命令才可以看到：

看到了吧，这里就导出来了游戏包含的所有类名了。

最后在来一发，这个是最关键的，也是本文的重点也是这个工具最实用的一个功能，就是进行应用的脱壳处理了，而本文的游戏也是进行加固处理的，我们可以反编译看看这个游戏：

你会发现没几个类，而且有一个Application类，那么可以认定了这个游戏被加固了，本文不介绍是使用哪家的加固平台操作了，也不再使用IDA等工具去动态调试脱壳了，这里直接使用这个工具进行操作即可。咋们为了后续代码阅读方便可以直接获取他的smali代码，也就是使用这个命令：

am broadcast -a com.zjdroid.invoke --ei target 25304 --es cmd '{action:backsmali, "dexpath":"/data/app/org.cocos2d.fishingjoy3-1.apk"}'

这个命令的运行结果咋们通过日志查看：

而这个smali文件夹是存放在应用的 /data/data/org.cocos2d.fishingjoy3/smali 中的，咋们可以把他拷贝出来即可：

这里可以看到咋们就成功的脱壳了，生成了游戏的所有smali文件代码了。其实这个脱壳操作和我们之前介绍使用IDA工具进行脱壳原理都差不多，因为应用程序不管怎么加固，最终都会使用一个系统函数将dex文件加载到内存中，而加载之前肯定要进行解密操作，我们只要在加载之前解密之后进行拦截即可。

五、总结

好了，到这里我们就讲解完了基于Xposed框架的脱壳神器ZjDroid的实现原理以及具体用法。而这里也感受到了Xposed框架的强大之处，当然这也只是一部分，后面还可以利用这个框架编写游戏外挂等操作。所以好好膜拜这个框架，也好好拜读这个框架的源码吧，学不完的东东呢！写的好累好辛苦，记得给小编点赞呢！！

更多内容：点击这里

关注微信公众号，最新技术干货实时推送

扫一扫加小编微信
添加时注明：“编码美丽”否则不予通过！