靜態分析sscronet和metasec_ml走不通了,換個思路繼續搞! 1、直接打開從內存dump的so,報錯如下: 本以為只是簡單破壞了文件頭,於是用010editor比對內存dump的so和安裝包原始的so,看看哪些地方被破壞了,手動挨個恢復;結果發現 ...
做脫機協議,首先要找到關鍵的加密代碼,然而這些代碼一般都在so里面,因為逆向c c 的難度遠比java大多了 找到關鍵代碼后,一般情況下是逐行分析,然后自己寫代碼復現整個加密過程。但是,有些非標准的加密算法是由一個團隊實現的,整個過程非常復雜。逆向人員再去逐行分析和復現,有點 不划算 怎么才能直接調用so里面的這些關鍵代碼了 可以通過前面的介紹的frida hook,也可以通過今天介紹的這個so ...
2021-06-13 21:54 1 7545 推薦指數:
靜態分析sscronet和metasec_ml走不通了,換個思路繼續搞! 1、直接打開從內存dump的so,報錯如下: 本以為只是簡單破壞了文件頭,於是用010editor比對內存dump的so和安裝包原始的so,看看哪些地方被破壞了,手動挨個恢復;結果發現 ...
逆向時用frida hook java層相對比較簡單,找准hook點用objection就行!或則自己寫腳本hook java常見的加密/編碼也很簡單,核心原因就是類名、函數名稱得以保留,逆向人員能快速定位!java層常見的加密/編碼hook腳本這里有:https ...
上次找到了兩個關鍵的so:sscronet和metasec_ml,本想着用jni trace看看jni函數的加載順序、參數、地址等關鍵信息,結果大失所望:一個都沒有....... 仔細想想原因:要么是沒用到,要么是加密了! 繼續用ida打開mestasec_ml:發現導出函數 ...
之前逆向中,通過ida棧回溯找到了一些函數,但分析起來還是費勁,主要的痛點: 代碼量大:libmetasec_ml的text段從0x7c50開始,0x84170結束;粗略估計代碼超過13萬行(這還不包括init段的代碼); ; 嘗試着用CE在內存中找各種加密 ...
結構看原入口已經沒了)!java層靜態分析的路走不通了,繼續看so;lib目錄下有個libjiagu_ ...
對於逆向同學而言,用android killer打開、分析、修改源代碼、重新編譯apk是很方便的一件事,所以大部分人都是按照這個流程逆向搞APK的;對於大部分APK而言這么做也是ok的,但是對於少數APK,用android killer打開的時候就會報錯,比如前面提到的這款國民級app ...
稱在java層或so層查找加密的方法,這次body的字段都加密了,字段名稱都不知道,怎么找? 有同學 ...
1、上次自己構造了一個app來調用x音的關鍵so,結果在一條“LDR R0, [R4,#0xC] “語句卡住了:通過ida查看得知:R4就是第三個參數,這里被當成了地址使用(java層怪不得用long類型)!第三個參數我是用frida hook得到的,換了個環境地址肯定也變了,所以這里直接 ...