admin管理员组

文章数量:1586258

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

*安卓逆向交流学习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，这个方法进行了控制流混淆，流程对于我来说是非常复杂的。

本文标签： 脱壳

版权声明：本文标题：【安卓逆向】360加固-脱壳修复 内容由热心网友自发贡献，该文观点仅代表作者本人， 转载请联系作者并注明出处：https://m.elefans.com/xitong/1727976685a1140734.html， 本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，一经查实，本站将立刻删除。