[已发表，转载勘误]Android upx脱壳

已发在https://www.anquanke.com/post/id/197643
不过有部分内容发布之后无法编辑，勘误后如下。

Android upx脱壳

写在前面

因为我不是pc平台过来的，而是直接从Android入门的，所以upx壳其实一开始并不了解，后来接触到，但是可以直接动态调试或者做个内存快照，对我来说加没加upx其实对我逆向分析影响不大。另一方面upx壳因为开源且其实有很多脱壳的教程，所以一直觉得有些过时、保护力度不足，似乎不值得花太多时间再去深入。但是有些公司的面试官不这么觉得，似乎对于他来说，你说会写vmp但是不了解upx脱壳修复很可笑，所以趁着假期把这个坑补上。

基于快速解决问题的原则，搜了一些upx脱壳的文章，大概可以分为两类。
1：是基于你熟悉upx源码的情况下，梳理出逻辑和数据结构，dump修复等。
2：是基于经验、特征，直接定位特征代码，断点、dump修复等。

对于1是我想要的，但是大概看了下upx源码似乎还挺大，Android加upx壳问题很多且并没有修复，加上没想过修复upx壳的bug(我的强迫症比较严重，如果看完源码我很难能停下不去修复bug)，所以最后放弃了这条路。

对于2，找到的一些文章很多是pc平台的，Android的还是较少的，且似乎有些藏着掖着的嫌疑，当然也许是个人的主观判断，我也不想再搜或者去推敲不明确的地方，不如直接自己来吧，看能不能黑盒推理出来。

分析

找了个第三方app内加了upx壳的so，没有clone upx对自己的so加壳。
首先看一下这个加了upx壳的so的数据结构，第一个可读可执行的段包含了代码段，干脆就叫代码段吧。

代码段大小为136728=0x21618，加载到内存是4096/一页对齐，那么占用内存大小为0x22000。而接下来的数据段在内存中偏移是0x3dee8，那么起始页应该是0x3d000，0x3d000-0x22000=0x1b000，数据段和代码段隔了27页，太不正常了，一般编译出来的so相隔1页，所以应该是upx改的，但是这个数据段的偏移是编译时确定的，upx肯定不可能反汇编所有代码修改偏移，所以这个数据段的偏移是没有问题的，而且p_offset=0x21ee8，和p_vaddr也是相差一页的。所以可以推理出应该是改了代码段的大小，原来的代码段大小肯定不是0x21618，应该是在0x3b000-0x3d000之间(考虑到一般正常so会设置一页的间隔，那么可以缩小范围到0x3b000-0x3c000之间)。

为什么数据段的偏移是不能改的

如果对elf不是特别熟悉的话，这里我以一个正常的so为例来看下为什么说这个数据段的偏移是不能改的，

代码中从是偏移为3f004的地址取数据，这是经过ida优化的，实际指令含义不是这样，我们去掉优化(当然这样也还没完全去掉优化，你可以自己再解析指令，0x3a8c0是存储在指令后面的，现在是条LDR伪指令)。