https://bbs.pediy.com/thread-224559.htm

最近在學習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代碼分析的學習筆記。

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

轉載于:https://www.cnblogs.com/davidwang456/articles/8944205.html

總結

以上是生活随笔為你收集整理的登录抓包逆向分析学习笔记的全部內容，希望文章能夠幫你解決所遇到的問題。

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