最近在學習ARM彙編和逆向方面的基礎知識，抽空跟著“無名”大神的逆向資料分析視訊學習了一下，以下是本人在學習過程中的一些心得和筆記，還望各位大牛們指正。

PS：本人已對截圖做了相應的打碼處理，如有侵權或涉及敏感資訊，還望告知，我會第一'時間做出處理。謝謝！

一、抓包&反編譯

首先在登入時，抓包，看到相應的登入資訊：

通過POST資訊可以看到，除了時間戳、手機號碼、經過MD5處理的密碼以及deviceid外，有一個“sign”的認證資訊，故本次逆向分析就是針對“sign”的HASH方式進行分析。

拿出Android killer對該安裝包嘗試反編譯，順利反編譯，發現搜尋“sign”關鍵字後的搜尋結果太多，於是換了關鍵字“pawd”進行搜尋後，發現只有兩條結果：

根據名稱可以基本定位在下方LoginRegisterManager這個方法中。

3.通過反編譯後的java程式碼，順著pawd向下尋找，於是找到“sign”的程式碼：

4.通過檢視，可以得出sign是通過KeyGenerator的getsign方法操作後獲取，於是進入“KeyGenerator”方法，可以檢視到這裡呼叫了動態連結庫

(System.loadLibrary "XX_key")：

二、so靜態分析

1.拿出神器IDA，開啟apk包lib目錄下的libxx_key.so檔案，首先下意識的在Exports中搜尋關鍵字“Java”，檢視是否有相應方法呼叫，發現並沒有，於是需要通過JNI_Onload中去尋找相應方法，進入JNI_Onload後，F5檢視偽C程式碼，程式碼相對比較簡練，RegisterNatives此處為JNI環境註冊Native方法的通用做法：

2.點選gMethods進入檢視，這是一個典型的JNINativeMethod methods[]陣列，通常是3個引數：
引數1：Java層方法名
引數2：方法的簽名以及返回值為Java String型別 (Ljava/lang/String;)Ljava/lang/String;
引數3：為SO庫實現的方法名，這裡強制轉換成了函式指標，會指向SO中的方法（generateKeyByParams）

3.點選第三個引數，進入到generateKeyByParams方法內，同樣F5檢視偽C程式碼：

4.發現偽C程式碼居然將generateKeyByParams的方法只識別了1個傳參（上一張截圖中可以明顯看出該方法是有3個傳參的），通過上一張截圖可以得知，3個引數的含義：
引數1：Env指標
引數2：Java層類物件
引數3：使用者輸入的String

5._ZN7_JNIEnv17GetStringUTFCharsEP8_jstringPh ; _JNIEnv::GetStringUTFChars(_jstring ,uchar ) 表示將java傳入的string轉換為C的string格式

6.通過對generateKeyByParams方法的分析，發現它在前面做了一些初始化的工作：

大概有40位元組的記憶體空間初始化，然後呼叫了generate_key_by_value(v19, v4)這個方法

7.通過以上分析，我們可以初步斷定，HASH處理應該就在generate_key_by_value方法內了

三、動態除錯

手機開啟，adb shell執行android_server，執行APP，IDA遠端除錯連線，選中相應的APP程式

在module中通過查詢“libxx_key”，定位到libxx_key.so，然後查詢到“generate_key_by_value”，在其開始處下斷點，執行

然後在手機上隨便填寫一個手機號碼和12345678的密碼，登入，此時IDA會停留在我們的斷點處，根據前面所知，generate_key_by_value有兩個傳參，我們可以通過動態除錯的方式檢視R0，R1這兩個暫存器中的內容，也就是說v19和v4兩個引數了：

4.通過檢視可以發現R0即為我們提交時的POST封包的一些資料，而R1則為記憶體初始化的一段空間，此時為00

5.此時記下R1的地址（我的是BEFF34E4，每個人會有所不同），然後在generate_key_by_value方法的結束處下斷點，然後執行，IDA會停留在結束處的斷點，此時在HEX-View處，按G，輸入剛才記下的R1地址，檢視R1暫存器中的內容：

可以發現R1的內容已經為HASH後的資料，將該段資料複製出來與抓包的sign資料進行比對：

資料完全吻合，此時可以肯定，generate_key_by_value就是HASH方法關鍵所在。

四、演算法分析

1.為了分析HASH演算法，可以在IDA靜態分析中繼續檢視generate_key_by_value的偽C程式碼，通過檢視程式碼，可以發現是典型的SHA1雜湊值函式組合生成

其大致的流程為SHA1Init()-->SHAUpdate()-->SHA1Final()

而程式碼中共呼叫了4次SHAUpdate()：

SHAUpdate(a)，SHAUpdate(b)，相當於SHAUpdate(a+b)，於是我們可以通過程式碼看到這4次呼叫，第1次和最後1次，分別有&v15的一串字串“bi2ipxazqodmw9hoety0h1wwgjvkttng”，推斷大致的HASH流程為SHAUpdate（&v15+v6+v8+v10+v12+&v15)：

2.為了驗證是否正確，再次結合動態除錯，在第一處BL SHA1Update處進入到SHA1Update方法中，在開始處下斷

3.APP再次登入，IDA會停留到SHA1Update斷點處，檢視R1暫存器中的內容，發現“bi2ipxazqodmw9hoety0h1wwgjvkttng”字串：

4.再次執行，IDA會再次停留在下斷處，再次檢視R1暫存器中的內容，此時變為“deviceid”：

5.繼續執行，依次檢視R1暫存器中的內容，“mobile”、“pawd”、“timestamp”、“bi2ipxazqodmw9hoety0h1wwgjvkttng”及其相應資料：

6.然後在generate_key_by_valu方法的結束處下斷，F9執行，在HEX-View中按G，檢視之前記下的R1地址(BEFF34E4)，將已HASH後的資料複製出來

7.然後將動態除錯時獲取到的“bi2ipxazqodmw9hoety0h1wwgjvkttng”、“deviceid”等資料放在一起，保證無空格、無換行，然後通過網上SHA1雜湊後與抓包的資料比對，發現完全一致：

故之前推斷的HASH流程完全正確。

未完待續，後面會補充SHA1Update()偽C程式碼分析的學習筆記。

通過兩晚的學習，發現還是很有收穫的，更加激發了逆向的學習動力，雖然已近不惑，憑著對逆向的熱愛興趣，一直以來都以自學和瀏覽帖子為主，很少有勇氣發帖，希望通過看雪這個平臺多與志同道合的朋友們交流，共同進步。

本文由看雪論壇 bugchong 原創 轉載請註明來自看雪社群