上一次調試各種手抖F9跳過了許多關鍵內容，這次繼續。

case31分支

case31分支中每一次設置的LR寄存器地址都不一樣，反調試驗證等手段大都在這里進行跳轉。

1：

驗證加載的so文件是不是libjiaguXXX.so

單步跟，一直到case32中進入函數sub_75CEA9FC里發現處理結果的分支：

R4跳轉為raise函數，向進程自己發送SIGKILL（9）信號來終止進程。但是我們這里加載的是正確的so文件，tst指令結果為0，跳過了這里。

2：

獲取時間戳，猜測是獲取執行時間差來判斷是不是被調試了，那就讓time()返回0就好了

3：重調用外圍函數_Z10__arm_a_21v
4、5：memcpy

6：解密字符串

sub_75CEBF2C，說明前面從so文件某處拷貝加密的字符串，在這里解密。


解密函數在后面還有多次用到：

BYTE * sub_75CEBF2C(BYTE *result, int a2) {int v2; // r2if ( a2 ){v2 = (int)&result[a2];do{*result = ~(*result ^ 0x5A);++result;}while ( result != (BYTE *)v2 );}return result; }

/system/bin/linker里有什么東西呢- -，在模塊里找到了它

上次沒搞懂，這次找到了這個rtld_db_dlactivity

rtld_db_dlactivity函數默認情況下為空函數，當有調試器時將被改為斷點指令。Android反調試對抗中，SIGTRAP信號反調試可通過判斷該函數的數值來判斷是否處于被調試狀態等，所以必要時需要將該函數對應的寄存器的值修改為0。

7:

解密字符串rtld_db_dlactivity

8：遍歷符號表獲取rtld_db_dlactivity地址

打開maps文件尋找/system/bin/linker模塊，找到rtld_db_dlactivity。
把DE 10修改為nop指令 C0 46或者00 00（0xDE10為thumb breakpoint）

9：讀取rtld_db_dlactivity

sub_75CE73E4函數讀取文件內容

此時該地址在上一步已經被手動修改為00

單步跟蹤，到case32 - sub_75CEA9FC，又是熟悉的分支，此時R4為__stack_chk_fail，不過我們驗證通過了。

10、11： _Z10__arm_a_20v函數TracerPid反調試

上一篇中有提到過，這里手動修改TracerPid為0
12：getpid，后續操作沒有跟出來。。

在這里判斷，R1&0x40000000!=0，會跳轉到R4，修改為0

case40，Debugger: thread 406 has exited (code 0)！

重開這次不修改上一步中的R1，r4為：

隨后再次進入case31:sub_75CEDCE4。

跳過了退出，再次進入case31，sub_75CEDD20：解密了一些函數名字符串

跟了不知道多少次BLX LR跳轉到了這里sub_75CE7C84：

通過uncompress函數解壓libz.so文件并解密找到對應的JNI_Onload函數，主要作用就是動態注冊那些被native的函數。
至此全部反調試都應該沒了，一直下斷點跟蹤調試。
…
在內存中找到最新的區段，dump出來。

總結

以上是生活随笔為你收集整理的360加固分析（二）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。