360加固分析（二）

上一次調試各種手抖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; // r2

  if ( 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，會跳轉到失敗處理，修改爲0

手抖F9跳過case40，Debugger: thread 406 has exited (code 0)！