这篇文章纯粹属于安全分析研究，请勿用于非法用途。如有侵犯到厂家，请告知作者删除
老早写的，现在已经2.3版本了，把这个放出来，这个方法要比之前的简单很多。
12306的so加载顺序是先libDexHelper.so后libcheckcode.so
一、修复libDexHelper.so
我们先把libDexHelper.so dump出来，并修复，修复后的IDA分析结果如下图:
libDexHelper.so修复好后，备用，后面需要用到这个so来辅助分析。
二、修复libcheckcode.so
先dump出libcheckcode.so
之前在_mmap2函数上dump出原始libcheckcode.so方式2.2版本已经无效了,
那么这次我们就直接等功能已经跑起来后，直接把libcheckcode.so内存dump出来
把这个dump用修复工具修复
三个关键的函数checkcoode,decheckcode,JNI_Onload，如下图所示
IDA分析结果都是arm指令集，但是JNI_OnLoad后面接着的函数却是thumb指令集，很显然，这里其实被故意改了函数的偏移。那么偏移了多少呢?
对dlsym进行HOOK，输出如下:
JNI_OnLoad的地址是0x525a3d11-0x52585000=0x1ED11
跟IDA分析出的0x1ED50相差了0x3F
把0x1ed10指向的地址分析为函数，如下图所示，已经是正常的函数了:
checkcode和decheckcode两个函数则不行,因为这两个函数是处于加密状态
checkcode和decheckcode两个函数是动态加解密的，该函数运行前被解密，运行完后又加密回去。
那么解密点，就要找到这个动态加解密的位置。
把590c3000-100__Java_com_MobileTicket_CheckCodeUtil_checkcode.dmp文件用IDA打开(指定为arm指令集)
libDexHelper.so的基址是0x51a25000，则可以计算出解密函数地址是0x51a4c305-0x51a25000=0x27305，加密函数是0x51a4c2ed-0x51a25000=0x272ed
解密函数:
在这里的解密函数上进行hook,等其解密完后，把libcheckcode.so dump出来即可。
因为这里有两个函数decheckcode和checkcode，所以需要dump两次。
可以在解密函数里通过输入长度的大小不同来分别dump
将直接dlopen完dump出的libcheckcode.so和解密函数执行完dump出来的进行二进制比较，可以看到有一部分是不一样的，不一样的地方，就是被解密的函数。
那么剩下的工作就是把这两个解密后的函数二进制，写个覆盖到dlopen完的dump上，即可。这个工作可以用脚本来实现。
剩下需要修复的工作是:
1.把JNI_OnLoad、checkcode、decheckcode三个函数地址减去0x3f
2.修复so,使其可以正常运行
3.把init_proc函数去掉，不让其再进行解密
(创建了一个Android逆向分析群，欢迎有兴趣的同学加入，群号码:376745720)
- 顶
- 0
- 踩
