【移动应用开发技术】Android安全讲座第九层(二) 内存dump

【移动应用开发技术】Android安全讲座第九层(二)内存dump

近来android上越来越多的应用对自身的保护机制加强了重视，主要表现在几个方面。

1dex加壳

2so加壳

3dex藏在so中，在适当的时候释放。

这是技术上一个进步，并且还有一些专业的公司提供了整个安全的解决方法，比如防ptrace，或者加密dex文件等。但是不管如何，在技术层面，cpu要运行的指令还必须是cpu能够支持的，除非不考虑效率利用复杂的动态内存机制来保护代码，一般情况下，加载内存的so或者dex等文件还都是原生态的cpu可以执行的指令集。

因为有时候骇客要破解你精心涉及的算法是一件很麻烦的事情，他要求一条一条的看枯燥的汇编代码，不是达不到，而是效率特别低。所以这个时候内存dump却是骇客们经常采用的一种手段了。

linux下的内存dump离不开ptrace，所以有些安全方案直接防止别的进程对其ptrace，主要手段就是ptrace住自己。即便如此，依然有孜孜不倦的骇客成功绕开了防止ptrace的保护机制，关于这方面的事情，我以后有时间在专门写一篇文章分享。今天只讲如何内存dump，内存dump需要的ptrace目标进程。

为了方便我个人的使用，我编写了一个memdump工具，这是一个elf的可执行文件，在android系统下adbshell进去以后直接可以执行。首先说一下这个工具的用法。shell@android:/#memdump

usage:memdumppidstart_addrend_addrfilaname

255|shell@android:/#用法十分简单，将memdump通过adbpush拷贝到你的手机里面，我是放在了/system/bin下面了，这样我不用每次找路径，直接运行命令即可。然后后面需要有4个参数pid要dump目标进程的进程号

start_addr要dump目标进程数据的虚拟起始地址

end_addr要dump目标进程数据的虚拟结束地址

filenamedump出来的数据要保存的文件名称（要求有路径）ok介绍完了命令使用方法，下一步就具体操作一下如何使用的。如图一上图中我自己编写了一个包名为com.example.socketcomm的apk应用，里面加载了一个libsocketback.so的库，打开以后其进程号为11164，通过查看其maps信息，发现其可执行的代码段在56d34000-56d37000r-xp00000000103:04579426

/data/data/com.example.socketcomm/lib/libsocketback.so这三个物理页面上由于物理页面是以0x1000对其，我不知道这个so具体的大小，但是没有关系，先将其全部dump出来再做处理。如上图，memdump111640x56d340000x56d37000/sdcard/dump.so通过这个命令将libsocketback.so

dump到了/sdcard/dump.so然后退出adbcmdline以后，通过adbpull将/sdcard/dump.so拉到linuxhost机器上再使用readelf-hdump.so查看elf文件头部，果然是Type:

DYN(Sharedobjectfile)这个共享对象。仔细的同学会看到readelf:Error:Unabletoreadin0x370bytesofsectionheaders这条错误，产生的原因是linux在加载so的时候是按照程序视图的方式加载的，主要关心的是Startofprogramheaders:

52(bytesintofile)这个开始的头部信息，对于链接方式的视图的段名等数据并不敏感，所以直接从内存dump出来的数据，是没有.symstrtab

.symtab

.strtab这些段的，所以解析错误也很正常。一般常用的修补so的方法是拿到原来的so，这个你只要有这个应用就应该能拿到，然后根据elf文件头部，找到Startofsectionheaders:

12600(bytesintofile)段表在文件中的偏移地址，拼接一下文件即可，这个程序的编写需要对elf文件有一定的了解，回头我会根据自己的研究和学习补充一些elf格式相关的博文。从本质来看，基本上这个时候的