翻译:興趣使然的小胃
预估稿费:140RMB
投稿方式:发送邮件至linwei#360.cn,或登陆网页版在线投稿
一、前言
在分析Android恶意软件的过程中,我们经常会碰到某些APK样本对主逻辑代码进行了隐藏或加密处理,只有在某些时刻才会将真正的代码释放到内存中,因此我们需要找到正确的时机才能提取这些代码。本文中,我将举例说明,当一个DEX文件中的某些关键方法被NOP指令抹去后,我们如何去修复这个文件,并且在程序执行时动态解压其代码。
请注意,以下的分析基于Android 4.4.2_r1版本(KOT49H)。
二、具体操作
首先,我们使用某些反编译工具打开一个classes.dex文件,如下所示:
图1. DEX文件的反编译结果
在图1中,我们可以看到每个函数的代码全部被抹去了。接下来,我们先使用010 Editor来解析这个Dex文件,如图2所示。
图2. 010 Editor无法解析此Dex文件
看来010 Editor无法解析classes.dex文件,原因可能在于Dex文件中的某些字段已经被修改过。这些字段可能包含某些偏移量信息,用来标识文件内部的偏移量。如果偏移量的值超过了DEX文件的大小,会导致文件解析错误。
该Dex文件的大小为0x2B2DD8。
我写了一个C++程序来解析Dex文件,检查其中不正常的字段,部分输出结果如图3所示。
图3. 使用C++程序解析Dex文件的输出结果
我们可以看到DexCode结构中,“debugInfoOff”字段的值不正常,超过了文件本身的0x2b2dd8大小。此例中,这些不正常的debugInfoOff字段取值范围在0x3ffff30到0x4000000之间。
图4. DexCode结构体的定义
为使010 Editor能正确解析这个Dex文件,我修复了文件debugInfoOff字段的值。我以MainActivity类中的“OnCreate”方法为例,演示修复过后的Dex文件在010 Editor中的解析结果。
图5. 修复过后的Dex文件在010 Editor中的解析结果
接下来我将debugInfoOff的值修改为0。insns_size字段代表了代码中指令的长度,每一条指令包括2个字节,因此代码的长度为0x76。“OnCreate”方法的具体代码以“0E 00”字节码开始,其余部分全部为NOP指令。“0E 00”字节码代表的是void返回类型。
现在的问题是,如何获取该方法的真正字节码?图5中,某些关键方法已经被NOP指令抹去了。程序准备调用某个方法前,会先对该方法中的字节码进行解密,调用完毕后程序会使用原始的NOP字节码重新替换填充。
在Dalvik虚拟机中,方法在调用时其字节码必须是正确的。换句话说,如果某个方法不处于调用状态,那么它的字节码可能是错误的。这个样本充分利用了这一点,实现了对方法的动态解密调用。
随后,我研究如何在方法调用前对其进行动态解密。通过某些逆向工程及分析工作,我发现该程序可以hook dalvik虚拟机中的dvmResolveClass方法。当某个类中的方法被调用时,整个类必须完成加载过程,dvmResolveClass方法正是在类的加载过程被调用。
下图是IDA Pro中dvmResolveClass方法的ARM指令:
图6. IDA Pro中dvmResolveClass方法的ARM指令
接下来,我继续使用IDA Pro进行动态调试,分析hook后的dvmResolveClass方法。
图7. hook后的dvmResolveClass方法
当执行arm指令时,程序跳转到了sub_75485310子函数,图8显示了sub_75485310的执行流程。
图8. sub_75485310的执行流程
图8中,ARM指令“BLX R3”用来调用真正的dvmResolveClass方法。之后程序执行位于0x75938000地址的指令。运行到0x75938014地址时,程序会跳转到0x414E468A地址,调用实际的dvmResolveClass方法,如图9所示。
图9. 从0x75938000地址开始程序的执行流程
图10. 返回到实际的dvmResolveClass方法
现在程序成功hook了dvmResolveClass方法,此时此刻,关键方法的正确字节码也已经加载到内存中,具体保存在Method结构的insns指针中。Method结构体的定义如图11所示。
图11. Method结构体的定义
接下来,我们可以修改dvmResolveClass方法的源代码,提取真正的字节码。
部分关键代码如下图所示。
图12. 在dvmResolveClass方法中添加关键代码以获取实际字节码
现在我们可以将真正的字节码保存为本地文件。
图13. 保存为本地文件中的真正字节码
最后,结合图13与图3的输出结果,我研发了一个python脚本,用来修改原始的classes.dex文件,修改后的文件如下图所示。
图14. dex文件修改前后的对比
图15. 使用dex反编译工具处理修改后的dex文件
对比图1和图15的结果,我们可以看到原来那些经过特殊处理的指令已经恢复正常。
三、总结
Android系统是个开源系统,通过阅读AOSP(Android Open Source Project,Android开源项目)的源代码,我们可以深入分析理解dalvik虚拟机的具体实现。读者也可以自行修改dalvik虚拟机的源代码,开发工具来修复其他经过混淆加固的DEX文件。
发表评论
您还未登录,请先登录。
登录