某錢包轉賬付款算法分析篇
抓包
具體如何抓包就不在陳述，抓包我們會發現qpayunifiedconfig.cgi、qpay_balance.cgi等接口，但它的POST以及返回的數據都是十六進制的數據，毫無疑問是經過了加密，接下來就是分析如何找到它加密部分。（具體它的每個參數含義就暫時不講解）
定位
把整個apk拖入jadx-gui后，初始化檢索之后可以直接通過網址進行定位。
!str.contains("qpay_ydt.cgi") && !str.contains("qpay_balance.cgi") && !str.contains("qpay_fpay_regbind.cgi")
看到此處，它判斷的這3個URL接口名稱，恰是支付的，估計是它排除掉不是它的接口。
這里直接對它進行HOOK，我使用的是frida（雷電4模擬器環境），我們對這個signEncdata函數進行分析它具體的傳參，根據代碼過程大概判斷出，str是URL，剩余2個，拭目以待。
var EncryptRequest = Java.use("com.tenpay.sdk.basebl.EncryptRequest"); EncryptRequest['signEncdata'].implementation = function(str,str2,map){ console.log('[signEncdata] --> str:'+str) console.log('[signEncdata] --> str2:'+str2) console.log(map) var ret = this.signEncdata(str,str2,map) console.log("[signEncdata] ret -- >" +ret) return ret }
…………
結果就是，該HOOK代碼并沒有觸發，也就是并沒有執行到此處，但是我們發現當前class處幾乎每個函數都是加密相關，我對他們進行了逐一HOOK，最終發現encypt函數有了反應。
如下面圖所示：
但是代碼沒有能正常解析出來，具體它的參數打印出來的是：
[encypt] --> qquin:276265453[encypt] --> url:https://myun.tenpay.com/cgi-bin/qwallet_misc/qpay_unified_config.cgi?ver=2.0&chv=3[encypt] --> keyIndex:8[encypt] --> postdata:skey=v0aaf855a20617de1e4cf7b447711a49&uin=276265453&skey_type=0[encypt] --> pskey:D2bVXKh4GsqkNgFevM37b3Qf8h6yNyC4F4-e937-w58_ -------- [encypt] --> qquin:276265453[encypt] --> url:https://myun.tenpay.com/cgi-bin/clientv1.0/qpay_balance.cgi?ver=2.0&chv=3[encypt] --> keyIndex:8[encypt] --> postdata:token_id=5M6477be1c9445ba1621c6319e403075&p=31363335363339383237F0D6C4CEE093903BFD05D6303A581B97E8442ABD7934E8CCC9D71AAF6B60BD5186B12729677B20A25232EDECB539B81775F69AD79B48AF90B0D96BD8AB1D18E3EEAC513F451010C782F3919935171EA650F937A4C733865ECE77E9B4352D6BE6360D50605106FD9581221F92A809A42FC8617884EEAD942F721C71A3A32B9A642F94676A49F7C74E45B0D7B62802809FDEE2EE68×tamp=1635639827&is_reentry=0&skey=v0aaf855a20617de1e4cf7b447711a49[encypt] --> pskey:D2bVXKh4GsqkNgFevM37b3Qf8h6yNyC4F4-e937-w58_
參數名我是根據查找調用它的上一層代碼進行翻譯出來的，如圖片箭頭所示：
這些數據最長的就是postdata，也就是它發出去的數據的明文。
這個函數觸發了2次，第一次估計是在支付之前獲取某些信息，而第二次則是提交支付密碼（參數p，也是加密后的）以及token_id（支付訂單號）進行完成支付。
而skey估計則是cookie之類的關鍵token。
枯燥無味的分析
找到了它的關鍵代碼，就需要對它進行算法的還原，具體它postdata數據是如何構造的，它的每個參數含義就暫時不往回追溯，根據當前的encypt函數，繼續往下閱讀，但因為代碼是無法正常翻譯成java，只能通過閱讀class的原生指令。
我們直接拉到最后，前面基本上都是構造它的數據以及獲取更多的其它設備信息，因為我們看到了如 getNetworkType、getDeviceInfo、getMsgNo等關鍵字，估計是在進一步獲取更多信息。
L_0x01b4: com.tenpay.ndk.DesEncUtil r0 = com.tenpay.sdk.basebl.EncryptRequest.des // Catch:{ all -> 0x01cc } java.lang.String r2 = r8.toString() // Catch:{ all -> 0x01cc } postdata2 = keyIndex r0.encryptDes(postdata2, r2) // Catch:{ all -> 0x01cc }
這里我直接拉倒最后（部分參數名被我改了一下），r2 就是它最終構造完的信息，postdata2其實是keyIndex（忘記改回名字），那么就可以繼續跳轉到 r0.encryptDes 里面下個hook查看它傳進去的r2了。
var DesEncUtil = Java.use("com.tenpay.ndk.DesEncUtil"); DesEncUtil['encryptDes'].overload('int', 'java.lang.String').implementation = function(key,data){ var ret = this.encryptDes(key,data) console.log("[encryptDes] data --> "+data) console.log("[encryptDes] key --> "+key) console.log("[encryptDes] ret --> "+ret) return ret }
以下HOOK出來的打印數據：
[encryptDes] data --> pskey=D2bVXKh4GsqkNgFevM37b3Qf8h6yNyC4F4-e937-w58_&skey=v0aaf855a20617de1e4cf7b447711a49&uin=276265453&skey_type=0&h_net_type=WIFI&h_model=android_mqq&h_edition=84&h_location=2F55FF2C8A2AA4435A87356EA9373F29%7C%7CMI%209%7C7.1.2%2Csdk25%7C3E2A52202DF351F3821979EE78BEB82C%7CD41D8CD98F00B204E9800998ECF8427E%7C1%7C&h_qq_guid=3E2A52202DF351F3821979EE78BEB82C&h_qq_appid=537100433&h_exten=[encryptDes] key --> 8[encryptDes] ret --> true ------ [encryptDes] data --> pskey=D2bVXKh4GsqkNgFevM37b3Qf8h6yNyC4F4-e937-w58_&token_id=5M460db95537d6b5adb2a100c1870f77&p=31363335363339383237F0D6C4CEE093903BFD05D6303A581B97E8442ABD7934E8CCC9D71AAF6B60BD5186B12729677B20A25232EDECB539B81775F69AD79B48AF90B0D96BD8AB1D18E3EEAC513F451010C782F3919935171EA650F937A4C733865ECE77E9B4352D6BE6360D50605106FD9581221F92A809A42FC8617884EEAD942F721C71A3A32B9A642F94676A49F7C74E45B0D7B62802809FDEE2EE68×tamp=1635639827&is_reentry=0&skey=v0aaf855a20617de1e4cf7b447711a49&h_net_type=WIFI&h_model=android_mqq&h_edition=84&h_location=2F55FF2C8A2AA4435A87356EA9373F29%7C%7CMI%209%7C7.1.2%2Csdk25%7C3E2A52202DF351F3821979EE78BEB82C%7CD41D8CD98F00B204E9800998ECF8427E%7C1%7C&h_qq_guid=3E2A52202DF351F3821979EE78BEB82C&h_qq_appid=537100433&h_exten=[encryptDes] key --> 8[encryptDes] ret --> true
我們看到，data數據其實就是上一個hook的數據拼接在一起，但是看到它后面多出了h_net_type和h_model等相關設備的狀態信息，也就證實了剛剛說的那些關鍵字所獲取出來的數據。而這個key = 8 是比較迷惑的，我們現在把跟到encryptDes函數里面查看它具體進行的部分（因為我們看到它返回的是bool型，而不是最終的加密結果）。
如上圖所示，跟進去我們發現了它真正的加密過程是在so層中完成。
通過看到SoLoad.loadSo(context);部分，我們需要找到它加載的so文件。
我們看到它加載的是cftutils_v1、qwssl兩個文件。
但奈何查找整個apk資源，并沒有發現2個so文件。
嘗試全局檢索他們的名字，也無結果。
運氣?
可以說是運氣，也可以說是技巧，通過XSearch工具，我按照搜索qwssl名字，搜出了一張后綴名jpg圖片格式的文件。
但是它并不能正常打開查看，通過十六進制查看發現，它竟然是一個APK格式。
把他轉換成zip格式打開，發現了新大陸：
進入lib發現了2個驚喜文件。
最后我們使用ida載入這2個so，并看到了具體實現過程：
而前面所說過的keyindex，其實就如箭頭所示，unk_26004是一個存放加密公鑰的常量，它應該是偏移了幾位進行讀取，以達到部分混淆作用把。
此處我沒有繼續往下分析了，因為基本上也差不多了明了了整個算法過程，只需要時間基本上都能完成了。（當然還有它那個密碼p沒去看）
