待分析應用zxxy拖到Android killer中反編譯:

可以看到是加了樂固殼的。檢視lib目錄下的so檔案為libshella-2.8.so，字尾為a表示基於ARM平臺，x代表x86平臺，這裡的版本是2.8.0版本的樂固殼。要分析如何脫殼，那麼這個libshella-2.8.so就是分析的重點了。拖到IDA中靜態分析，一開始就無法解析並且出現警告提示，這裡老師上課講過了，是對elf檔案中的section header table做了混淆處理，因為我們在實際裝載過程中並不需要連結檢視中的section資訊，所以只需要找到section header table將其全部置為0，就可正常打開了。這裡檢視section header table的檔案偏移以及大小可以在虛擬機器Linux上使用readelf -a libshella-2.8.so來檢視，然後使用010Editor來編輯。另外一種方法就是使用xAnSo-master 這個工具進行修復，這是Github上面提供的，搜一下就能找到。==
處理之後IDA靜態分析如下：

這裡就能檢視到一些匯入函數了，在exports匯出函式中可以看到JNI_Onload函式，點選去看發現數據都是經過加密處理的，直接make code（快捷鍵c）並不能將資料轉化為程式碼。那麼猜想JNI_Onload函式肯定是在init_array或者init中進行了處理。接下來進行動態除錯so檔案進行分析，除錯的步驟這裡就不多說了，請參考上一篇文章。

點選執行，在上圖中載入libshella-2.8.so時停下來，接下來我們先定位到init_array的位置：

可以看到init_array的偏移地址為0x3e84，在動態分析IDA中ctrl+s檢視libshella-2.8.so載入到記憶體中的基地址：

那麼其地址為基地址+偏移地址，0x7631FE84，

這裡對應函式地址0x7631C944, 跳轉到該地址檢視。

// write access to const memory has been detected, the output may be wrong!
int sub_944()
{
  unsigned int v0; // [email protected]
  unsigned int v1; // [email protected]
  unsigned int v2; // [email protected]
  char v3; // [email protected]
 

  int v4; // [email protected]
  int j; // [sp+34h] [bp-18h]@13
  char v7; // [sp+38h] [bp-14h]@13
  char v8; // [sp+39h] [bp-13h]@13
  char v9; // [sp+3Ah] [bp-12h]@13
  char v10; // [sp+3Bh] [bp-11h]@13
  unsigned int v11; // [sp+3Ch] [bp-10h]@4
  int v12; // [sp+40h] [bp-Ch]@4
  int i; // [sp+44h] [bp-8h]@1

  for ( i = (unsigned int)sub_944 & 0xFFFFF000; *(_DWORD *)i != 1179403647; i -= 4096 )
    ;
  v12 = *(_DWORD *)(i + 28) + i;
  v11 = 0;
  while ( *(_WORD *)(i + 44) > v11 )
  {
    if ( *(_DWORD *)v12 != 1 || *(_DWORD *)(v12 + 24) != 5 )
    {
      if ( *(_DWORD *)v12 == 1 && *(_DWORD *)(v12 + 24) == 6 )
      {
        v1 = *(_DWORD *)(v12 + 8) & 0xFFFFF000;
        v2 = (*(_DWORD *)(v12 + 8) + *(_DWORD *)(v12 + 16) + 4095) & 0xFFFFF000;
        break;
      }
    }
    else
    {
      v0 = (*(_DWORD *)(v12 + 8) + *(_DWORD *)(v12 + 16) + 4095) & 0xFFFFF000;
    }
    ++v11;
    v12 += 32;
  }
  v10 = 43;
  v9 = -103;
  v8 = 32;
  v7 = 21;
  mprotect(i, 0, 3);
  for ( j = 0; j <= 0; ++j )
  {
    v3 = *(_BYTE *)(i + j);
    *(_BYTE *)(i + j) ^= (unsigned __int8)(((v9 - v8) ^ j) + v7) ^ v10;
    *(_BYTE *)(i + j) += v8 & v7 ^ v9;
    v10 += (v9 + v8 - v7) & v3 & j;
    v9 += (j + v10) ^ v3;
    v8 ^= (v3 - v10) ^ j;
    v7 += j - (v3 + v10);
  }
  mprotect(i, 0, 5);
  v4 = sub_7E8(i, 0);
  dword_4008 = i;
  return sub_898(v4);
}

這裡就是init_array對應的函式，通過檢視相應的函式可以看到前面實際上是進行了一些位元組變換，然後呼叫了mprotect，sub_B6F083DC和sub_B6F0F630三個函式。sub_B6F083DC函式就是做了 cacheflush和syscall操作。猜想這裡就是對JNI_Onload程式碼區的資料進行解密還原，這裡不是關注的重點。我們直接執行單步進入到sub_898函式內部，當前版本中並沒有反除錯程式碼。

更改名稱之後的兩個函式向日志中列印tag為txtag的日誌資訊，然後留意一下第一個函式，點進去看到有“LD_PRELOAD”關鍵字，猜想這裡應該是跟環境變數共享庫的設定有關，無需過分關注，直接單步跳過去。檢視最後一個函式呼叫，unk_7631E74C：

其實這個地址7631E74C剛好就是靜態分析對應的JNI_Onload地址，也就是說此時加密資料已經被還原了，能夠被我們IDA識別出來。
具體的流程就不用管了，我們知道肯定會去執行JNI_Onloadh函式，就在上圖這個函式中下斷點，然後執行到這個地方：

這裡想說一個很有效的除錯技巧，在除錯時可以結合反彙編出來的函式形式，通過檢視引數以及返回值來判斷函式的大致功能（檢視暫存器值，arm中r0-r4傳遞引數）。
通過檢視引數我們看到這段程式碼呼叫了dlopen和dlsym兩個函式。dlopen開啟一個動態連結庫，dlsym根據動態連結庫操作控制代碼(handle)與符號(symbol)，返回符號對應的地址（這裡的符號為JNI_Onload）。使用這個函式不但可以獲取函式地址，也可以獲取變數地址。
那麼也就是說最終v7才是真正希望執行的JNI_Onload函式地址，也就是對應如下arm程式碼中的BLX R3；中的R3暫存器中的地址：

檢視對應的C程式碼：

signed int __fastcall sub_7632DADC(int a1)
{
  signed int v1; // [email protected]
  int v2; // [email protected]
  int v4; // [sp+4h] [bp-14h]@1

  v1 = 0;
  v2 = a1;
  v4 = 0;
  if ( ((int (__cdecl *)(int, int *))unk_7632DA50)(a1, &v4) )
  {
    if ( ((int (__fastcall *)(_DWORD, _DWORD, signed int))unk_7632DA50)(v2, &v4, 65540) )
    {
      if ( ((int (__fastcall *)(int, int *, signed int))unk_7632DA50)(v2, &v4, 65538) )
      {
        if ( ((int (__fastcall *)(int, int *, signed int))unk_7632DA50)(v2, &v4, 65537) )
          return v1;
        v1 = 65537;
      }
      else
      {
        v1 = 65538;
      }
    }
    else
    {
      v1 = 65540;
    }
  }
  else
  {
    v1 = 65542;
  }
  if ( v4 )
  {
    ((void (*)(void))unk_7632E270)();
    ((void (*)(void))unk_7632DAA0)();
  }
  return v1;
}

依次點選其中的函式檢視程式碼，最後一個函式程式碼如下所示：

看到了registerNatives，那麼這裡肯定就是手動註冊native方法了，跟到上面的函式中：

那麼這裡我們重點關注RegisterNatives函式的引數，其函式原型為：
jint RegisterNatives(jclass clazz, const JNINativeMethod* methods,jint nMethods)
第二個引數是一個結構體:
typedef struct {
const char* name;
const char* signature;
void* fnPtr;
} JNINativeMethod;

也就是說，我們跟蹤到這個引數的時候就可以知道其註冊的native方法載入到記憶體後的函式地址，即對應結構體的第三個引數。從而可以獲取到在Java程式碼中呼叫了哪些原生函式進行脫殼操作。這裡結構體指標對應著第三個引數v6，因為第一個引數還傳入了env。
單步執行到這裡：

這裡我們看到第一個註冊方法的地址為7628CB55，那麼實際的地址應該為7628CB56，跳轉到該地址，檢視反彙編程式碼：

通過一些列印資訊提示可以猜測這裡肯定是與脫殼載入相關的函式程式碼。

這裡根據不同的虛擬機器指令版本執行不同的Load操作，那麼這裡的標出來的函式就應該是脫殼並載入的關鍵程式碼了。
接下來如何dump dex直接參考後面給出來的連結。
脫殼結果：

這裡還是比較坑的，除錯過程中即使是在真機上也會報出各種異常，不過還好最後一次除錯成功了。