逆向某平臺分析過程指導
抓包報文分析
1、charles抓包分析報文
登錄和注冊發送驗證碼都帶有?個sign字段。
其他參數都為固定參數 ?如請求圖中的：
只有這個sign每次都是變化的，那我們就開始分析這個sign。
操作步驟
① 先查apk是否加固 查詢發現沒加固。
② 直接上jdax打開apk，能正常反編譯。
③ 發現網絡框架使?的okhttp。
代碼分析
因為使?的okhttp框架那么自然直接搜索OKhttpClient 在哪被初始化 jadx直接搜索到。
看名字猜測應該是網絡核心父類，接著按x找到相關引用類找到：
看名字就猜到了http相關的?具類，接著繼續找關鍵字sign，因為網絡相關的類都在framework包下的 helper??錄中所有隨便翻翻找到?個。
打開?看找到app相關的native?法都在這類中定義按x找到相關引用的類中 有?個。
看方法名就猜到了應該是計算sign的?法，打開看果然是：
計算?法為:
① 調用buildSignRequestParams(str,map)方法將請求參數賦值給hashMap，并將hashMap中的值按照 key進?排序，重新賦值給map。
② 遍歷排序后的hashmap的取出value進?拼接傳遞給buildSignValue()?法，調?native?法?frida Hook這兩個?法調?也證明了這兩點:
③ 接下來開始分析native方法 getServerApi() 找到使用的so 包為libNativeHelper.so。
扔到ida看導出函數發現是jni動態注冊沒找到getServerApi()這個?法，接下來使?unidbg進行分析 call_jni_onload 后找到偏移地址0x12795。
在ida中G 跳轉到偏移地址。
查看sub_4DF0函數F5?成偽代碼。
閱讀代碼修改原有的字段名稱。祭出大殺器unidbg Hookz。
多次調用方法發現入參為?串固定字符串值,先暫定它為加密因子吧！hook偽代碼中的strcat(參數1,參數2)。
參數1為之前調?java 層 native方法中請求參數排序后的value 字符串，參數2位固定的加密因子將兩個字 符串拼接后?成新的待加密串。
接著分析 sub_4538(&v20)函數。
這個4個常量 在結合sign的?度為32 很明顯的可以猜到使?的MD5加密，具體在往下看。 分析sub_4564()函數：
hook函數sub45F4函數 得到的入參為 md5標識和待加密串，接著點進去查看這個函數具體實現：
最終hook這兩個函數都沒發現?成具體的sign值 加密串也沒有最終被修改 于是隨?拿之前得到的加密串去做個MD5發現直接就跟sign?樣 所以?概得出這個sign算法就是標準的 MD5。
