登錄抓包逆向分析學習筆記

04-14

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

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

一、抓包&反編譯

1、首先在登錄時，抓包，看到相應的登錄信息：

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

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

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

3.通過反編譯後的java代碼，順著pawd向下尋找，於是找到「sign」的代碼：

4.通過查看，可以得出sign是通過KeyGenerator的getsign方法操作後獲取，於是進入「KeyGenerator」方法，可以查看到這裡調用了動態鏈接庫(System.loadLibrary "XX_key")：

二、so靜態分析

拿出神器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 原創轉載請註明來自看雪社區