每次尋找漏洞的時候，我都喜歡從抓包開始

噢噢，這裡有點尷尬~~請求和返回的資料都進行了加密處理，這波操作我挺喜歡的，證明人家公司的開發人員還是有點安全意識的，不過沒有關係，他有張良計,我有過牆梯，先反編譯一波看看，使用的工具是 jadx

很明顯，app用了360加固了，哎，在以前，有加固的應用我基本會放棄的，不過現在沒關係，脫殼唄

我用的脫殼原始碼在這裡 https://github.com/dstmath/frida-unpack

用了Firda進行脫殼，不會使用Frida的可以看這裡 https://blog.csdn.net/u014476720/article/details/83537843

脫了殼 拿到了dex檔案就可以分析了

根據上面抓包的情況，分析app包無非就是解決 t ，sign , n , options 這幾個值加密和解密

這裡我先從請求的資料開始入手，直接先搞到登入介面的

看了一下程式碼，很好很漂亮，檔名很清晰，沒有怎麼進行混淆處理

密碼的引數傳入了下面的方法進行拼接

格式：固定文字+密碼+固定文字  最後以這種格式進行了MD5加密

到這裡分析了登入攜帶的引數後，苦逼了

登入需要的引數都傳入了下面的a方法，他的網路請求框架是retrofit2，這種我不熟悉啊，之後不知道怎麼跑了

後來看了看工具類裡面還有個 EncryptDES ，好像都沒有看到在哪裡有用到，於是抱著試一試的心態進行了一番全域性搜尋

噢噢 這麼一搜索不得了，網路請求的資料結構全部都在此

響應返回引數

上面需要的相關引數用Xposed框架編寫個外掛就可以全部輸出知道了

編寫外掛的時候需要注意的幾個傳入型別： byte[].class ， int.class

因為是加固過的，所有直接hook是找不到路徑的，需要先hook 載入過原dex 的 ClassLoader ，再用hook到的ClassLoader進行其他hook

 final Class clazz1 = XposedHelpers.findClass("android.app.Application", lpparam.classLoader);
            XposedHelpers.findAndHookMethod(clazz1, "attach", Context.class, new XC_MethodHook() {

                @Override
                protected void afterHookedMethod(MethodHookParam param) throws Throwable {
                    super.afterHookedMethod(param);
                    Context context = (Context) param.args[0];
                    ClassLoader classLoader = context.getClassLoader();
}
 

總結：分析了上面的app之後，我覺得做ndk開發還真是有必要的，重要的引數都放進C程式碼裡面處理，即使那些演算法想用java層的也不要用的那麼明顯，可以用jni來處理， native通過反射調取java層的方法，雖然還是能夠破解，但是至少能夠增加多一點破解的難度吧