360脱壳分析.docxVIP

360 so脱壳分析 1 修复错误的elf文件 首先我们将原始的libqihoo.so拖到IDA分析，发现IDA报如下两个错误： 第一个错误说明是节区头部表格的表项大小错误，第二个错误是节区头部表格的大小或偏移值错误。了解ELF的同学都知道这几个信息都包含在ELF的header中。那么我们使用WinHex查看下此ELF的header即可： Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F 7F 45 4C 46 01 01 01 00 00 00 00 00 00 00 00 00 ELF 03 00e_type = 3,表示共享目标文件 28 00e_machine = 0x28，表 arm处理器 01 00 00 00 e_version=1,表示当前版本 00 00 00 00e_entry= 0,程序入口的虚拟地址，由于是动态库，所以入口地址为0 34 00 00 00e_phoff=0x34,程序头部表格的偏移量(按字节计算) ( 4 8C 11 02 00e_shoff=0x2118c，节区头部表格的偏移量 00 00 00 05e_flags=0x50000,保存与文件相关的，特定于处理器的标志。 34 00e_ehsize=0x34,ELF头部的大小 20 00e_phentsize=0x20，程序头部表格的表项大小 07 00e_phnum=7，程序头部表格的表项数目 6C 00★e_shentsize=0x6c，节区头部表格的表项大小，显然是错误的，应该改为0x28 ? 4 l 66 00★e_shnum=0x66，节区头部表格的表项数目，这里明显是错误的，正确结果见后面分析！ 78 00★e_shstrndx=0x78，节区头部表格中与节区名称字符串表相关的表项的索引，显然这也是错误的。 06 00 00 00 34 00 00 00 34 00 00 00 f x 4 4 34 00 00 00 E0 00 00 00 E0 00 00 00 04 00 00 00 4 ? ? 04 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 因为节区头部表的偏移值为0x2118c，所以根据ELF文件的结构，从该偏移值开始到文件结尾的数据为整个节区头部表。由于节区头部表项的大小固定为0x28，所以我们可以由:(0x214fb - 0x2118c + 1)/0x28 = 0x16 得出真正的节区头部表项数目为0x16。 下面再来看e_shstrndx字段，我们从ELF文件中可以明显地看出，字符串表节区为最后一个节区，所以它的索引值应当为0x15。至此，ELF修复完毕。 然后我们将修复完毕的ELF拖到 IDA中发现不会报错了~ 2 开始脱壳 IDA不报错，并不意味我们就可以开始痛快地分析了！我们在IDA中查看导出函数发现了JNI_Onload和verify函数： 但是双击这两个函数却发现代码是被加密过的 o(╯□╰)o： 由于JNI_Onload是Android APK在加载so的时候第一个执行的函数，而此函数又被加密了，那么解密函数就只能在so的入口地址init.array处了。 定位到init.array节，发现了关键信息： 在上图中可以很明显地看到，init.array会执行__gnu_armfinit_26函数！下面就开始分析这个函数吧。此函数也是加入了大量花指令，我已经将去除花指令后的代码放在了附件中，大家可以参照附件中的initArray.txt文档继续阅读。 大致流程就是： ①进行系统配置，为操作修改so文件做准备； ②根据so中特定位置的字符串，构造转换表； ③以此转换表为基础，解密so文件中的0x176d c到0x176dc+0x8aec的代码。 了解了解密逻辑，我们就可以自己编写解密程序了。鉴于so的解密与前一帖子中计算序列号的算法是一样的，所以我们只需要对前一帖子中的代码进行更改即可。详细代码见附件的unshell1.cpp。 满心欢喜地解密so，以为大功告成，结果~~~ 将解密后的so拖到IDA，通过EXPORT找到JNI_Onload： TMD还是密文！！！看来我们只脱了一层壳，还有其他壳等着我们啊~ 问题来了，我用的IDA6.1