首先是下載了多個版本發(fā)現(xiàn)最早能用的版本就只有7.8
所以以下我們使用7.8版本的 * * 佳緣作為分析案例
我們的目的是分析抓包登陸信息，分析登錄的相關協(xié)議信息
找到頂部登陸activity，可以參考使用一下兩種方式
adb shell dumpsys activity activities | findstr "cmp="
adb shell dumpsys activity | findstr "mFoc"
拿到棧頂activity，jadx跟進代碼
看到a方法的參數(shù)入值就是一個接口返回的請求信息，也就是說調用loginActivity的a方法之前，極驗已經完成了認證，a方法回調是給我們調用正常的登陸邏輯的
這里面的兩個a，有參的明顯是ons=Success，無參的就是onFailed回調
（tips:下面這兩張圖會說明上面這里我為什么這么說）
這里的e.d不就是上文中的presenter調用的方法么，這里就對應起來了，所以之前的分析沒錯，這里就是極驗的回調
再往下就是分兩個方向去分析了：
① 極驗成功后的回調（正常的用戶登陸邏輯）
post : https://api.jiayuan.com/sign/signoninfo.php
(post參數(shù)挺多的，就不挨著列出來了)
② 極驗的三個請求的參數(shù)邏輯
第一個簡單極驗后的接口簡單點，我們先來跟第一個
回到之前那個presenter的位置
三個參數(shù)
對應一下請求參數(shù)便可知道：
gecode ===> 70abde****|jordan (第二個傳參)
gechallenge ===> 6851f25**** (第一個傳參)
gevalidate ===> 70abde**** (第三個傳參）
這里也寫得蠻清楚的，剛才分析的時候沒看到。。。
這里的d.a實際就是一個map的put操作，請求信息的拼接
可以hook一下看看調用，這里hook他的目的不只是查看參數(shù)，主要是為了清楚它的拼接順序，哪些東西先拼接，哪些東西后拼接
以上的這四張圖片就是說明了Presenter（發(fā)起自己的登錄請求）調用之前拼接的字符串全部會出現(xiàn)在第二張圖片，調用presenters.e.d.a之前，參數(shù)太多了這先不總結，后面需要哪個字段來這里查看就知道了
下面我們就來具體分析細節(jié)參數(shù)（這里從Fildder參數(shù)列表順序來?。?/p>
gecode：不用分析了，是上一個接口返回的參數(shù)
userinfotypes：
可以看出來它就是一個常量....(整的還挺花里胡哨)
[1,2,112,104,3,127,128,129,130,131,132,133,134,135,8,136,137,100,101,106,110,114,117,116,121,122,107,184,102,103,111,125,221,115,6,5,21,232,185,186,147,123,148,146,113,149,124,163,156,119,150,151,153,179,182,160,161,171,152,162,155,154,180,120,187,157,168,169,174,170,240,167,173,231,158,118,7,241,242,243,237,244,105,236,249,255,254,247,181,145,251,252,178,259,258,233,257,260,261,264,265,266,267,268,245,269,270,272,273,274,279,277,280,288,4,292]
簡單的參數(shù)偽造包的時候不變就是了，以下都是可以不變的
osv，token，carrier，geo_lat，channelID，bundle，connection_type，imei，logmod，reallogin，screenHeight，lang，orientation，channel，android_id
android_id可以簡單的看一下他是什么
還是這樣，需要改可以hook或者修改smali重打包，再或者是動態(tài)添加一些隨機數(shù)產生的smali代碼生成隨機android_id
clientID；固定值 "13"
clientVer: versionName
dd,screenWidth,password(SHA-1)
geo_accu
mac，os_type，clientid，deviceid，bd，geo_lon，make，brand
secucode：這個地方可能就是關鍵了，關鍵函數(shù)native話，針對這種問題，測試階段我們可以使用hook的函數(shù)主動調用去獲取返回值，或者是把他的so文件拖出來，構建一個項目去主動調用，目的都是一致的，達到函數(shù)的主動調用目的，后面在分析so，這里先看看參數(shù)
第一個參數(shù)是固定的5c28cc****，第二個參數(shù)就是手機號碼
這里是三個native函數(shù)的返回值
key和算法都不會變，其實看起來也就簡單了
這里大概就是這個意思：
對于a方法傳進來的兩個參數(shù)，第一個是一個固定的string（5c28cc****）前面說到了，第二個是一個電話號碼，a方法的返回值可以看成是對第一個參數(shù)進行des加密，加密密鑰為65,74,67........，加密完成后再調用native方法getNewCode加密，這里加密邏輯再so里，我稍后再去分析so，然后把返回的byte數(shù)組轉換為String（Integer.HexToString()）,完成加密的計算，得到得值也就是我們需要的secucode
isgeet，screen_dpi，ip，name，channelid，os_version，isJailbreak，ver，product，model，gevalidate（見上）
traceid 跟一下
也就是不同手機對應的一個常量（也就是可能服務器端用作驗證是不是同一個手機的參數(shù)，請求的時候看情況隨意偽造）
下面是so層的分析
先hook一下so加載，判斷得到加密函數(shù)存在于 libjyn.so
于是乎我們去到apk解壓目錄下查看又沒有這個so，發(fā)現(xiàn)沒有，所以這個應該是運行時動態(tài)加載出來的，但是文件目錄不變,所以直接去app目錄托出來
getKey() 這個代碼也啥子意思，簡單看一下就是了，寫的很簡單，返回的也就是常量而已
getAlgorithm() 同上
getNewCode() 就是一個md5
getSendMsgAuthStr()
到此基本上自主登陸請求接口就分析完了，但是還有一個大關極驗沒過，首先是極驗返回給了我們一個驗證字符串（token），我們拿到這個token才能進入下一步的登錄驗證，這也是這里為什么選了7.8版本，7.8版本不是每次登錄都會觸發(fā)極驗，最新版是每次都觸發(fā)，所以這里也就是簡單的分析了一下登錄的接口數(shù)據(jù)請求y
