简介：

调试手机是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混淆的帖子：

4.闲谈

相信大家应该注意到本文没有提到反调试，是的，在分析过程中我并没有碰到反调试。或许会有断点陷阱、时间反调试等，但我并没有走到

那里。当然还有必备的签名校验。那么我觉得最大的难点就在于混淆，其他的还好。

通过分析，收获良多。希望看完此贴的伙伴们也能有所收获！！

最后于 2020-12-23 17:20

被[軍]编辑

，原因：

上传的附件：

lg.rar

(1.99MB，53次下载)