去年四五月份的时候客户反馈过一个so加壳的问题，分析后发现是和某Android应用市场SDK的libYSDK.so冲突。当时该so解壳过程中会操作linker的soinfo结构的部分数据，壳作者把dlopen返回的handle强制转成soinfo结构体指针，这操作个必然有兼容性问题。后来该壳也做了升级，其最新版本有一些挺有趣的技术点，跟大家分享下。

Ida直接打开:

函数列表只有31个sub_**（__mprotect是笔者改名来的）, 再看下Section表 ：

很多内容被擦掉了，dynsym 和 dynstr在7.0+上linker需要，必须保留，其他保留项对分析没什么用，壳的作者也保留了，这里直接抹掉elf-header中的section表偏移和大小，让ida使用动态链接表解析：

再用IDA打开后函数列表变了：

但是往下看代码区（JNI_OnLoad），代码加密了：

继续往后边拖拽，符号表竟然都在第二个loadsegment:

init解密壳

先考虑第一个loadsegment代码加密的问题，一般在linker的init中执行解密逻辑，init对应的那部分code一定是明文状态，greadelf –d libYSDK.so:

该so编译时的名字是“legu”，后来重命名为“YSDK”的，没有找到init段，只有init_array，跳过去看下：

看来sub_838就是解密函数了，贴上它的伪代码： 

对0x1000~0x28cc区间解密算法很简单，不过还是偷懒直接动态调试从内存扣了，ida脚本如下：

然后再替换到原so的0x1000~0x28cc上，再用IDA打开，JNI_OnLoad可以直接静态分析了（还原后的内容见附件）：

IDA分析的第二个加载段中符号表是怎么回事呢？我们先看下010Editor打开该so后布局上的诡异之处：

很明显，文件末尾放着更多内容，这才是真正的业务逻辑相关的代码、数据，加载这些内容的代码就在JNI_OnLoad中,伪代码如下：

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！