简介:
调试手机是Android 6.0的32位的手机。样本是自己写的一个demo小程序。加固时间为今年的12月中旬左右。
Java层分析
壳的入口是 MyWrapperProxyApplication,继承了父类 WrapperProxyApplication,并且实现了父类中的方法 initProxyApplication。
我们找到父类WrapperProxyApplication,首先找到最先执行的 attachBaseContext 方法。
可以看到首先获得了 basContext,这个 baseContext 变量会在后面 so 层中获取,进行 attach 新的 DelegateApplication。然后是给 shellApp 赋值,在调用 initProxyApplication,就是上面图中 MyWrapperProxyApplication 中实现的 initProxyApplication,可以看到
是为了获取 libshell-super.2019 的 so 文件路径进行 System.load 加载。到这里,我们Java层的分析就差不多了,下面进入SO层分析。
2.SO层分析
2.1 总叙
一般的话是先分析.init_array节区,再分析JNI_OnLoad。在这里我们先分析.init_array节区里的函数,如图所示:
从中我们可以看到有很多函数,那么我们就要考虑这些函数都做了什么事了。
同时我们可以看一下字符串有没有被处理,如果被处理的话,那么此部分极可能是做一些初始化工作和解密一些东西。
字符串窗口如图所示:
可以看出有一部分字符串是解密状态的,在这里我们可以用一下 elf-dump-fix 工具来dump出字符串被解密的so,然后分析。
此工具来自
接下来我们开始分析JNI_OnLoad,按F5查看函数的伪代码,把函数参数改为JavaVM *,在这里我们可以看一下它的Graph窗口,如下图:
从中可以看出,函数被混淆的比较厉害。分支较多,在这里因为混淆难度不是很高,即混淆是比较死的,不是很灵活,那么是什么意思呢,
它的路径只有一条,所以直接IDA动态调试就可以的,咱们这里就不展开讲如何处理混淆了。直接开始重点函数分析。
首先是 sub_1CA8C 函数,在这个函数里面对壳运行环境数据的初始化和获取,以及最重要的是找到被抽取的 Dex 文件压缩后的数据,
并释放到内存中。
还有一个是sub_CC9C 函数,它做了很多事情,完成了对系统函数的 hook,如mmap、fopen等,加载了Dex文件,并进行了对 ProxyApplication
到 DelegateApplication 的替换。
2.2 sub_1CA8C函数
下面开始说sub_1CA8C函数,
那么如何定位到sub_1CA8C函数呢,我这里说一下。
咱们在这里定位v44变量,即JavaVM *,如图:
在这里可以看到,sub_1CA8C函数传进去了JavaVM *,那么此函数就需要分析一下了。
我们点进去之后可以看到此函数做了很多事,如下图:
在这里,初始化了一些环境信息,比如系统SDK版本、虚拟机类型、壳的一些信息等等,并且把他们都存放到此函数的第三个函数里,
那么它的类型应该是一个结构体。当然它的类型可以在IDA中不做修改。
可以对比一下它的原so,即字符串未解密时,如图:
可以看到,字符串都是被加密了,信息获取不到。那么我们从内存中把so给dump下来,对我们的静态分析提供了很大的帮助。
当然,也仅仅是静态分析,动态调试时,这些字符串都解密了。
接下里,我们接着看这个函数,
随后,打开了o0oooOO0ooOo.dat文件,
需要一提的是*(v5 + 151)存的是虚拟机的类型,即 1==dalvik 2==art。
后面就会根据这个走对应的分支,如下图:
此图为dalivik分支
此为art分支
在sub_1BF80中就会找到被抽取加密的dex文件,并对它进行解密,即下面这个文件,
在此函数中有一下三个关键点,如图:
打开文件,然后映射,sub_1BF20函数解密。
IDA动态调试视角如下:
到此为止,sub_1CA8C函数的分析到此结束。
2.3 sub_CC9C函数
下面进行sub_CC9C函数的分析。
咱们先看此函数的第一个重点,如图:
同样是先判断虚拟机类型,咱们直接看art的。
紧接着判断sdk版本,我这里走的是sub_AD24分支。接着看这个函数干了什么事。
此函数里面同样会调用sub_5110函数,此函数完成了非常重要的工作,调用 Java 层的的 installDexes 方法装载 Dex 文件。
最后进行hook了几个方法,即mmap、open等,同样我们会发现导出函数窗口里有mmap函数。如下图:
Hook mmap函数的目的就是在系统调用ClassLoader加载dex文件的时候,在mmap函数里返回映射后已经解密的被抽取的dex文件地址。
如下图窗口:
到这里sub_AD24函数分析完了,咱们接着分析sub_CC9C函数。
接下来,到了重要的分支,如下图:
根据*(v3+152)的值判断走哪个分支,执行的逻辑区别并不是很大,都是要把抽取的函数指令给还原到原始dex中。
但是sub_17FFC中没有混淆,逻辑比较清晰,而sub_10B8C中存在混淆,当然混淆程度也不是很高。
在sub_10B8C函数中,会解压被加密的函数指令数据,然后进行填充到dex中。
sub_288F4函数为解压函数,需要解压两部分数据,即indexdata和bytecode。
sub_FB64函数实现指令填充,如图:
v4即为dex起始地址,当此函数执行完之后,从此地址处可以dump出完整的dex文件。
接下来就是完成 ProxyApplication 到 DelegateApplication 的替换过程。如下图:
紧接着调用WrapperProxyApplication类中的onCreate方法,如图:
onCreate方法中调用了一个动态注册的方法,如图:
我们在SO中找到其地址,在这里直接来到.data节区,找到其函数地址,如下图:
函数sub_472C,如下图所示:
那么它完成了API层所有的Application引用替换和ContentProviders替换。
最后回到用户的Application。
到此为止,对于此壳的分析全部完成了。
3.混淆处理
在此so中出现了大量的混淆,可以这样说,但凡是比较重要的函数都被混淆了。那么我们该怎样去处理呢,即如何提高逆向分析的效率?
我们可以采用这两种方式,IDA调试记录指令和模拟执行记录指令,其目的都是记录指令,然后用脚本进行patch修复。
在这里分享一些大佬反arm混淆的帖子:
细说arm反类ollvm混淆-基本思想
记使用Trace还原ollvm混淆的函数
Unicorn反混淆:恢复被OLLVM保护的程序(一)
ARM64 OLLVM反混淆
4.闲谈
相信大家应该注意到本文没有提到反调试,是的,在分析过程中我并没有碰到反调试。或许会有断点陷阱、时间反调试等,但我并没有走到
那里。当然还有必备的签名校验。那么我觉得最大的难点就在于混淆,其他的还好。
通过分析,收获良多。希望看完此贴的伙伴们也能有所收获!!
[CTF入门培训]顶尖高校博士及硕士团队亲授《30小时教你玩转CTF》,视频+靶场+题目!助力进入CTF世界
最后于 2020-12-23 17:20
被[軍]编辑
,原因: