12306 Android客户端的libcheckcode.so解密及修复
源：http://blog.csdn.net/justfwd/article/details/45219895
这篇文章纯粹属于安全分析研究，请勿用于非法用途。如有侵犯到厂家，请告知作者删除
12306Android客户端每个请求包都会带个baseDTO.check_code（如下图）作为数据包安全及完整性校验码，这个校验码由libcheckcode.so生成
如果需要模拟购买火车票的过程，就要调用这个libcheckcode.so，不过这个SO使用dlopen无法加载。其ELF头，如下图所示，红框内表示ProgramHeader，里面的内容不符合elf格式规范
那它是如何加载起来的呢，猜测是借助了其它SO做了解密，下图列出lib/armeabi里的SO
分析后确定解密的工作是由libDexHelper.so来做的。 libDexHelper.so是最先加载的so,application调用的时候就加载了这个SO
libDexHelper.so自身做了加壳，这个壳不用花心思去脱，等它加载起来后，整个SO DUMP出来，将内存文件对齐修正一下就可以用IDA分析了
libDexHelper.so带有JNI_OnLoad，它会调用一个JNI_ALIYUN_ONLOAD函数
从函数名字上看，这个安全方案应该是由阿里云来做的
JNI_ALIYUN_ONLOAD内会做如下HOOK动作
也就是HOOK了dlopen,dlsym,_read,_open,mmap2五个函数,当加载libcheckcode.so的时候，会调用这五个函数，调用流程如下：
先调用dlopen,这里网上借个dlopen的调用流程图
这里的load_library会先调用_open打开文件，然后调用_read,再然后调用mmap2，将文件映射到内存
mmap2的hook过滤函数，当发现是libcheckcode.so文件时，会进行解密。
实际的解密代码，F5后，发下图所示：
是不是比较乱，它把跳转和循环改成了while switch方式，让人看得很纠结，所有长一点的函数都是这个样子。
等mmap2全部调用完了，把libcheckcode.so的内存DUMP出来，header如下图所示
已经变得正常了，这个文件直接IDA分析是没有结果的，需要将header里的文件偏移改成内存偏移，因为mmap已经将文件内容按内存对齐方式来存放了。
做一下对齐的修复，这个SO就可以用dlopen正常调用了。那么是不是大功告成了呢，我们写个12306的demo来调用这个so.
按MobileTicket逆向出来的代码描一个下面的类：
发现调用会CRASH，CRASH的偏移地址是1438a4,用IDA看下这段代码，这个地址就是checkcode的首地址
为什么会这样?回想一下，dlopen完了，还会调用初始化函数init_proc，IDA看下导出函数，确实存在一个叫.init_proc的函数
可以确定这里的init_proc就是壳代码，它还会继续对so进行解密，解密完了，这里才会有代码。
但是解密完了，这里运行仍然会出错。
什么原因呢？还有一个dlsym的HOOK函数没看
这个代码看得还是挺纠结的，就从它的return值往前推吧，基本可以确定它会返回wrapHook返回的内存地址。那就HOOK wrapHook，看它返回什么内容。
把wrapHook返回的内存块DUMP出来，用IDA分析
图上已经对这段代码做了标注。分析过程比较啰嗦，这里直接讲下结果吧。
dlsym的HOOK函数 功能：
如果要获取的函数名是Java_com_MobileTicket_CheckCodeUtil_checkcode，就调用wrapHook函数，返回wrapHook的返回值做为这个函数的地址。
wrapHook返回的代码段对Java_com_MobileTicket_CheckCodeUtil_checkcode函数重新做了一下包装，先调用so_prefix_wrap对Java_com_MobileTicket_CheckCodeUtil_checkcode函数进行解密，然后调用真实函数，调用完了再用so_postfix_wrap加密回去。
这里还有个细节要注意一下，这里的真实函数地址0x7bad6865是865结尾的，而我们的Java_com_MobileTicket_CheckCodeUtil_checkcode导出函数是以8a4结尾的，除了表示指令集不一样以外，同时指向的地址也是不一样的。
整理一下这个libcheckcode.so的加密方式，解密出来需要经过三个过程，先是mmap2解密，然后init_proc脱壳解密，最后调用checkcode函数的时候，还要运行时解密。
也就是说壳代码运行完后，checkcode还是处于加密状态，要使得libcheckcode.so能正常运行，init_proc之后还需要一次执行机会
怎么提供这个执行机会呢，想到两个办法，一个是patch init_proc函数，使其执行完后再执行一段解密代码，还有一个办法是增加init_array
上图是dlopen里的一个代码片断，可以看到，init_func执行完后，还会再执行init_array指向的函数阵列。
patch代码不太好玩，这里选择增加init_array的办法
从下图可以看到，这个SO本身存在一个大小4的init_array,可以放一个函数地址
但是指向的地址是0
只要在164dd8放一个地址就可以了。
不过还有个问题，init_array指向的函数地址阵列是需要重定向的，还需要在重定向表里，把这个地址给加上
查看重定向表，发现重定向表的后面已经填上了其它结构的数据，并无空间来扩展。
那就只有整体搬家了。
这是dynamicsection解析到的重定位表的偏移0x1dc4和大小0x130
将这里的0x1dc4改成其它偏移，就可以对它进行搬家了,大小可根据需要扩大
要搬到哪里去呢，armelf文件的结构比较紧凑，难以在原有文件上找到空间，只有另外扩充空间了
从上图可以看到，第2个programtable只是用来指示dynamic section，第1个program table占据文件的后半部分，只要把扩充的内容放到文件末尾，然后相应增加FileSize和MemSize两个就可以
扩充完了，把重定位表搬过去，并增加四字节大小
重定位表搬完了，init_array里的函数地址指向哪里呢。这个函数用来对checkcode函数进行解密。
要怎么去解密呢，逆向算法成本比较高，就直接把so_prefix_wrap运行后解出来的内存直接copy到原位置好了。把要拷贝的源和拷贝函数都放到第1节扩充的空间里去。
用C语言写个拷贝内存的代码，编译后，把那段拷贝函数，填到init_array函数指向的地址，再做一些必要的修改，让它可以正常运行。
最后一步把第1节的Flag加上可执行属性，改成跟第0节一样，都为RWX就行了。
至此，libcheckcode.so可以单独运行，不再需要借助libDexHelper.so的解密。
