這篇文章純粹屬於安全分析研究，請勿用於非法用途。如有侵犯到廠家，請告知作者刪除
老早寫的，現在已經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
- 踩
