源码分析 脱壳神器ZjDroid工作原理

0. 神器ZjDroid

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

1. 源码分析ZjDroid原理(

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

然后我们直接进入到这个类查看即可:

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

发现这开始拦截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层的代码公开,但是通过这里传递的参数可以了解到

命令用法: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}

3、总结

好了,到这里我们就讲解完了基于Xposed框架的脱壳神器ZjDroid的实现原理以及具体用法。而这里也感受到了Xposed框架的强大之处,当然这也只是一部分,后面还可以利用这个框架编写游戏外挂等操作。

4、源码

null

附件列表

时间: 2024-11-03 15:38:50

源码分析 脱壳神器ZjDroid工作原理的相关文章

zookeeper源码分析(一) 工作原理

来自:http://www.codedump.info/?p=207 阅读zookeeper代码一段时间(注:是很长一段时间,断断续续得有半年了吧?)之后,我要开始将一些积累下来的东西写下来了,鉴于我的java是这个过程中现学的,难免有说的不对的地方,所以如果有的话,请指教. 阅读时参考的版本是3.3.3. 简单的说一下zookeeper工作的过程,如果对这个过程还不太清楚,或者说对它如何使用等不太清楚的,可以参考一下其他的文章,比如这篇,这一系列的文章将不讲解它如何使用(实际上我也没有在具体项

Guava 源码分析之Cache的实现原理

Guava 源码分析之Cache的实现原理 前言 Google 出的 Guava 是 Java 核心增强的库,应用非常广泛. 我平时用的也挺频繁,这次就借助日常使用的 Cache 组件来看看 Google 大牛们是如何设计的. 缓存 本次主要讨论缓存.缓存在日常开发中举足轻重,如果你的应用对某类数据有着较高的读取频次,并且改动较小时那就非常适合利用缓存来提高性能. 缓存之所以可以提高性能是因为它的读取效率很高,就像是 CPU 的 L1.L2.L3 缓存一样,级别越高相应的读取速度也会越快. 但也

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

一.前言 在前文中我们介绍了如何使用Xposed框架修改地理位置信息来进行自身的隐藏功能,本文将继续介绍Xposed框架的另外一个功能就是实现应用的简单脱壳,其实说是Xposed的作用其实也不是,主要是模块编写的好就可以了,主要是利用Xposed的牛逼Hook技术实现的,下面就先来介绍一下这个脱壳模块工具ZjDroid的原理,因为他是开源的,所以咋们直接分析源码即可,源码的下载地址:https://github.com/halfkiss/ZjDroid 不过可惜的时候他只公开了Java层的代码,

Spring IOC 容器源码分析 - 余下的初始化工作

1. 简介 本篇文章是"Spring IOC 容器源码分析"系列文章的最后一篇文章,本篇文章所分析的对象是 initializeBean 方法,该方法用于对已完成属性填充的 bean 做最后的初始化工作.相较于之前几篇文章所分析的源码,initializeBean 的源码相对比较简单,大家可以愉快的阅读.好了,其他的不多说了,我们直入主题吧. 2. 源码分析 本章我们来分析一下 initializeBean 方法的源码.在完成分析后,还是像往常一样,把方法的执行流程列出来.好了,看源码

Tomcat7.0源码分析——启动与停止服务原理

前言 熟悉Tomcat的工程师们,肯定都知道Tomcat是如何启动与停止的.对于startup.sh.startup.bat.shutdown.sh.shutdown.bat等脚本或者批处理命令,大家一定知道改如何使用它,但是它们究竟是如何实现的,尤其是shutdown.sh脚本(或者shutdown.bat)究竟是如何和Tomcat进程通信的呢?本文将通过对Tomcat7.0的源码阅读,深入剖析这一过程. 由于在生产环境中,Tomcat一般部署在Linux系统下,所以本文将以startup.s

Mybatis源码分析之Cache二级缓存原理 (五)

一:Cache类的介绍 讲解缓存之前我们需要先了解一下Cache接口以及实现MyBatis定义了一个org.apache.ibatis.cache.Cache接口作为其Cache提供者的SPI(ServiceProvider Interface) ,所有的MyBatis内部的Cache缓存,都应该实现这一接口 Cache的实现类中,Cache有不同的功能,每个功能独立,互不影响,则对于不同的Cache功能,这里使用了装饰者模式实现. 看下cache的实现类,如下图: 1.FIFOCache:先进

源码分析 Sentinel 之 Dubbo 适配原理

在Alibaba Sentinel 限流与熔断初探(技巧篇) 的示例中我选择了 sentinel-demo-apache-dubbo 作为突破点,故本文就从该项目入手,看看 Sentinel 是如何对 Dubbo 做的适配,让项目使用方无感知,只需要引入对应的依即可. sentinel-apache-dubbo-adapter 比较简单,展开如下: 上面的代码应该比较简单,在正式进入源码研究之前,我先抛出如下二个问题: 1.限流.熔断相关的功能是在 Dubbo 的客户端实现还是服务端实现?为什么

同步锁源码分析(一)AbstractQueuedSynchronizer原理

文章转载自 AbstractQueuedSynchronizer的介绍和原理分析 建议去看一下原文的评论,会有不少收获. 简介 AbstractQueuedSynchronizer 提供了一个基于FIFO队列,可以用于构建锁或者其他相关同步装置的基础框架.该同步器(以下简称同步器)利用了一个int来表示状态,期望它能够成为实现大部分同步需求的基础.使用的方法是继承,子类通过继承同步器并需要实现它的方法来管理其状态,管理的方式就是通过类似acquire和release的方式来操纵状态.然而多线程环

skynet源码学习 - logger服务的工作原理

当skynet启动的时候,会根据配置文件制定的日志文件来创建一个logger context,具体过程就是找到logger.so动态链接文件,而后调用其logger_create函数(参数是配置的日志文件),而后构建这个服务对应的context(重要的是里面注册了该服务的回调函数_logger())和消息队列,最后执行logger_init函数,把logger的消息队列放入global queue.关键代码如下: <span style="white-space:pre">