【安卓逆向】360加固-脱壳修复

最新推荐文章于 2024-08-08 07:05:09 发布

置顶

YJJYXM

最新推荐文章于 2024-08-08 07:05:09 发布

阅读量2.2w

点赞数 17

分类专栏： Android逆向 360加固脱壳修复

本文链接：https://blog.csdn.net/YJJYXM/article/details/102366953

版权

本文详细记录了对360加固安卓应用进行逆向工程，包括如何在ART环境下从内存中DUMP原始classes.dex，分析混淆算法，以及如何绕过反调试并提取解释器SO。通过动态调试，作者揭示了解释执行过程，探讨了如何还原被加密的指令，提出了建立指令映射表以实现自动化脱壳的可能性。

摘要由CSDN通过智能技术生成

最近花了一些时间学习逆向脱壳，这方面一直投入的时间比较少。样本经过某加固宝进行加固，这里简单记录一下脱壳过程和思路，感谢某数字公司对安全加固的无私贡献，让我有机会小小的提高一下这方面的技能。

*安卓逆向交流学习qq：3251901516
vx:13140310004
DUMP classes.dex

打开APK包中的classes.dex看一下：
在这里插入图片描述
已经变成了壳代{过}{滤}理，没有一点原APK的代码。在assets中，有两个壳相关的SO：

尝试从内存中DUMP原classes.dex。

考虑到在Dalvik下，360可能会自己实现从内存中加载classes.dex的代码，不容易找到DUMP的点。而ART下，可操作空间就小多了，所以我是在ART下操作的。

具体的，我是在ClassLinker::DefineClass函数处得到dex_file的begin和size，然后DUMP出原来的classes.dex。我看到有人在dex2oat的地方DUMP，但我觉得如果360 HOOK execv，阻止dex2oat对原classes.dex作oat转换的话，会不会就脱不出来了呢？不过我对Android虚拟机不太了解，可能有更好的DUMP点。

成功DUMP出原classes.dex：
在这里插入图片描述
但是可以看到，有些方法（图中onCreate）的指令被抽走了，并且改为了native方法。同时，在static代码块中，有一行调用StubApp.interface11(16)。

可以猜测：当该class被加载时，static代码块会首先被执行，这样StubApp.interface11方法就会将onCreate注册到壳SO的某个native方法上。这样，当执行onCreate时，就会执行相应的native方法，该native方法会首先找到onCreate对应的指令，然后解密，最终解释执行。

interface11以及onCreate对应的native方法，以及解释器并没有实现在上图中的libjiagu.so中，而是实现在另一个运行时从内存中加载的SO中（暂且称其为解释器SO）。

DUMP解释器SO

APK运行后，会首先加载libjiagu.so，并执行其JNI_Onload方法。该方法最终会调用到__fun_a_18，这个方法进行了控制流混淆，流程对于我来说是非常复杂的。