在逆向過程中經(jīng)常會遇到各種加密，如果在java層還好說，大部分都是在so層，而且自定義的算法較多，加殼，混淆，這時候我們就可以嘗試調(diào)用它們app的so文件，其中常見的手段就是簽名驗證，首先打開jadx-gui分析出java層加密調(diào)用so層方法

順著找上去發(fā)現(xiàn)調(diào)用so文件

直接找到加載so文件的地方

將so文件copy到我們demo中開啟一個http服務(wù)，直接調(diào)用下encyptString方法

發(fā)現(xiàn)并沒有返回真正的加密結(jié)果,一定so層做邏輯效驗了，我們找到這個so文件，使用ida打開，找到導(dǎo)出的函數(shù)

發(fā)現(xiàn)采用的方式是動態(tài)注冊(靜態(tài)注冊是以java_包名_類名_方法名開頭的，否則就是動態(tài)注冊）動態(tài)注冊會加載JNI_OnLoad 函數(shù)，我們進(jìn)入這個函數(shù)

可視效果太差了，我們導(dǎo)入jni.h頭文件（百度搜下載即可，簡單的說就是java和c的翻譯官）,右鍵選擇JNIEnv

發(fā)現(xiàn)代碼瞬間清晰了很多

找到RegisterNative第3個參數(shù)0ff_7004就是我們導(dǎo)出的函數(shù)地址，我們進(jìn)入這個函數(shù)，找到j(luò)ava層導(dǎo)出的函數(shù)地址sub_3DC4,因為so采用的是Thumb指令，所以要+1

跟進(jìn)去，查看下思維導(dǎo)圖

可以看代碼執(zhí)行的邏輯很簡單無非就是一個判斷，我們F5轉(zhuǎn)換成偽C代碼

發(fā)現(xiàn)ERROR_9304好眼熟啊

這正是我們demo返回的錯誤信息，由此可得出,if里面肯定就是正常邏輯了，else里面就是返回錯誤的邏輯，我們繼續(xù)跟進(jìn)sub_15C0

可以看到通過反射拿到當(dāng)前app的簽名和正確的簽名做比較，如果不確實是否有簽名驗證，就直接打開字符串窗口Shift+F12，搜索"signatures"，如果有就毋庸置疑了，我們并不關(guān)心他是怎樣的邏輯，我們關(guān)心的只是他的返回值，直接找到返回值v4

可以看出如果v4等于0的時候那么肯定就是錯誤的邏輯，我們只需要讓v4變量的初始化值為1或者直接修改返回值為1,這里我們采用第二種方式，回到匯編處

CMP R0,#0? 這句話就是比較R0寄存器（sub_15C0的返回值）的值如果為0則跳轉(zhuǎn)到BEQ對應(yīng)的函數(shù)地址，我們直接將R0寄存器值改為1，其匯編就是CMP R0,#1，找到對應(yīng)的16進(jìn)制3DD8

使用010編輯器打開當(dāng)前so文件，Ctrl+G跳轉(zhuǎn)到該函數(shù)地址處，將00直接改成01，之后保存修改

再次打開so文件查看修改后的結(jié)果。

將修改后的so文件放到demo中請求，得到結(jié)果如下：

成功獲取到結(jié)果

文章僅供學(xué)習(xí)交流，禁止一切商務(wù)用途。