首页
社区
课程
招聘
[分享]【安卓逆向】360加固-脱壳修复
发表于: 2020-1-6 10:25 28804

[分享]【安卓逆向】360加固-脱壳修复

2020-1-6 10:25
28804

360加固-脱壳修复

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

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,这个方法进行了控制流混淆,流程对于我来说是非常复杂的。

 

刚开始,我以为它用了o-llvm进行混淆编译。但仔细看一下汇编代码,应该不是。应该就是自己在源码中利用while-switch实现了“控制流平坦化”的混淆算法。

怎么破?我没有什么好办法,只有硬看,不断的调试,参考大神们的帖子。

由于我手机是自己编译的系统,对于某些反调试天然免疫,所以遇到的反调并不多。下面简述我是怎么过反调并DUMP出解释器SO的,因为这个混淆算法应该每个版本都有所变化,所以这个流程并不一定适用别的样本。

第一处反调,来自case 37:

 

继续执行:

 

来到这个位置,看到R3保存的是rtld_db_dlactivity符号的地址,我担心它是要作SIGTRAP信号反调,所以手动将R3的值修改为0。

继续执行。当第4次进入case 32时:

 

继续执行,来到下面的位置:

 

注意此时R1的值,要将600B0010修改为200B0010,否则会执行R4地址处的代码。

R4地址处的代码是什么?看一下:

就是终止进程的代码。

过了此处反调之后,继续执行,来到case 31:

 继续,来到如下位置,这里就是加载解释器SO的函数了。

 

注意,这里不是通过调用dlopen函数来加载解释器SO的,而是自己实现的类似于linker的加载代码。

其实linker的工作原理并不复杂,简单来说就是将目标SO文件的LOAD段映射内存,解析文件格式,做好符号重定位,再调用init/init_array方法等等。

继续执行,来到解密ELF Header的地方:

 

解密完毕:

 

根据R3的值,将ELF Header先DUMP出来。

 

继续执行,来到解密Program Header的地方:

解密完毕:

 

将Program Header也DUMP出来:

 继续执行,来到如下位置:

 

这个方法是要将解释器SO的LOAD段映射到内存,然后完成整个加载过程。

根据so_addr和so_size将整个SO DUMP出来,但这里DUMP出来的SO是没有ELF Header和ProgramHeader的,但这两个头前面已经DUMP出来了。最后三者拼在一起,就是完整的解释器SO了。

还原onCreate

有了解释器SO,就可以继续分析了,核心的内容都在这个SO里面。

由于我编译的系统,加了很多日志,所以在执行到前面的onCreate方法时,看到如下日志:

 

就像前面猜测的那样,当执行该onCreate方法时,先执行class的static代码块,调用interface11方法,该方法将onCreate注册到了一个地址为0x75c74e2d的native方法上。该native方法就实现在解释器SO中。用0x75c74e2d减去load_base,可知是解释器SO中的sub_10E2C方法。

 

跟踪并分析该方法。

继续动态调试,在解释器SO中偏移0xFAAE处下断点:

观察此时R1寄存器的值为0xBE027450,跳到该处内存,并得到0xBE027458处的值为0x75EA5418。

跳到0x75EA5418内存处。

观察0x75EA5418内存处的值,得到本次解释执行的方法是:com.xxx.xxxActivity->onCreate。

继续,在解释器SO中偏移0x35C80处下断点:

观察此时R7寄存器的值为0x75E96A10,在Hex View中,跳到0x75E96A10内存处:

观察此时0x75E96A18地址处存储的值为0x7699C61C,在Hex View中跳到0x7699C61C内存处:

在0x7699C61C内存处存储的就是DexCode结构,DexCode的结构定义如下:

由此可知“com.xxx.xxxActivity->onCreate”方法的insns指令数组大小是0x93*2=294个字节,指令数据流是:

这个指令数据流是经过加密的,解密key存储在0x75E96A2C地址处,值为0x3B。

继续调试的话,就是执行switch型的解释器了。这个解释器和Dalvik解释器类似。在android2.x版本中曾有2种形式的C实现的解释器,一种goto的,一种switch的。后来谷歌把switch型解释器去掉了,因为执行效率没有goto的好。再后来就有了ART,貌似把C语言实现的解释器都去掉了。再再后来到了7.0,goto和switch型的C解释器又都回来了。

简单来说,就是解释执行整个onCreate方法的指令数据流,每条指令在执行前会解密。那怎么将这些指令还原回原本的dalvik字节码指令,达到脱壳目的呢?可以根据每个case的实现,来得到当前执行的opcode对应dalvik字节码指令中的哪一条,然后对应还原。

比如,这里的0xAE,在解释执行时,跳转到case 174处执行。假设拿case 174处的代码对比分析Dalvik解释器,发现case 174执行的是invoke-static指令,那么这条指令就还原出来了。

这样有点麻烦。

有一个好点的办法就是:自己在onCreate方法中将所有的dalvik指令,一共200多条全部写出来。然后用360加固,动态调试,总结出每条dalvik指令对应的360解释器的case处理指令的偏移,最后得到一张指令映射表。这样,后续在脱壳的时候,就可以根据解释执行代码的偏移,还原出原来的指令。当然,360解释器也是在不断变化的,所以,这个表也是要跟着变化的。

那能写自动脱壳机吗?只要这张指令映射表是有效的,脱壳就可以自动化完成。

那如果指令映射表失效了,能通过代码自动生成新的指令映射表吗?仔细分析解释器,每个指令的处理逻辑没大变化的,也许可以。

扯远了,下图是某个onCreate方法还原前后:

由于时间和水平都有限,很多地方还没仔细分析,本篇笔记只是简单记录一下本次操作的大致过程和一些思路。最后,感谢倾听。



[招生]科锐逆向工程师培训(2024年11月15日实地,远程教学同时开班, 第51期)

最后于 2020-1-6 10:53 被遥远的她编辑 ,原因:
收藏
免费 0
支持
分享
最新回复 (2)
雪    币: 62
活跃值: (971)
能力值: ( LV4,RANK:50 )
在线值:
发帖
回帖
粉丝
2
关键字:我编译的系统
2020-1-6 10:48
0
雪    币: 26205
活跃值: (63302)
能力值: (RANK:135 )
在线值:
发帖
回帖
粉丝
3
直接抄袭 ? https://www.jianshu.com/p/d057b3fa3cbc

最后于 2020-1-6 13:25 被Editor编辑 ,原因:
2020-1-6 13:23
5
游客
登录 | 注册 方可回帖
返回
//