記一次對某韓遊的反反調試
樣本:Y29tLndlbWFkZS5uaWdodGNyb3dz
前言聊點題外話,最近在找工作,一家公司說要搞NP,我果斷拒絕,還有一家公司給了一道面試題,內容是分析一款外掛( 針對他們家遊戲的 )和實現一個有效的外掛功能。當我興致勃勃下載好遊戲後,打開apk的lib目錄一看,發現libtprt.so、libtersafe2.so的特徵就知道67了。
眾所周知這是tx的MTP,我自認水平有限是搞不定的了,但還是硬著頭皮分析了一下,主要想分析他的CRC檢測,找到了幾處CRC邏輯,但都不是主要的邏輯,直到最後看到疑似vm虛擬機的東西,感覺他的核心檢測邏輯可能是在vm裡?看之後有沒有機會再分析看看吧。
小小分析完libtprt.so後,道心破碎,於是打算找個簡單點的來玩玩,正好前段時間一位大佬分享了一個樣本,就決定是你的。這是個UE5遊戲,主要看看他的檢測邏輯。
frida閃退分析frida注入後過1s左右會直接閃退,打印加載的so,看到只有一個libdxbase.so是APP本身的,顯然檢測邏輯在裡面。
將libdxbase.so拉入IDA,沒有報錯,即so大概率沒有加固。
然後習慣先 ...
2025吾愛解題領紅包活動(Android題解)
前言簡單寫一下Android部份的解題思路。
第三題:Android初級題明顯的xxtea特徵。
解密後直接得到flag
第四題:Android中級題目標是找到秘鑰。
Java層關鍵邏輯如下,調用了Check函數來檢查密鑰。
是個native函數。
嘗試直接hook RegisterNatives,發現Check果然是動態注冊的,在0xe8c54。
Check一開始是一些反調試邏輯。
先看anti1,它調用decrypt_str解密字符串,但奇怪的是解密出來的字符串不是以\x00結尾,導致opendir直接失敗,使得後面的反調試邏輯形同虛設?( 不知是故意的還是不小心的 )
anti2、do_something1也同理,皆因為decrypt_str的問題導致後續的邏輯失效。
繼續向下跟,看到它動態計算出一個函數地址,大概率就是加密函數,最後與密文進行對比。
一開始以為動態計算的那個函數地址是固定的,後來才發現有兩個不同的地址,會隨著上面anti1、anti2、do_something1、getenv等函數返回的結果而改變。
類似蜜罐的概念,當觸發anti邏輯後,不主 ...
2024騰訊遊戲安全大賽安卓決賽(復現)
前言很少接觸UE4逆向,借這個比賽的題目來學習下UE4逆向和vm虛擬機。
主要參考這兩篇文章來復現:
「[原创] 2024腾讯游戏安全大赛-安卓赛道决赛VM分析与还原」
「[原创] 腾讯游戏安全技术竞赛2024决赛 安卓方向解题报告」
Dump SDKUE4逆向的第一步基本都要先Dump SDK,否則根本無從下手。
UE4三件套按常規方法靜態定位三件套。
GName:0x4E2EC00
GWorld:0x4F5C0D0
GObject:0x4E533AC
嘗試用ue4dumper來dump sdk,但失敗了。失敗的原因很有可能是GWorld的結構被魔改了。
用frida驗證下GNmae字符串算法是否被魔改。
根據UE4.27源碼的FNmae::ToString()函數,可以得出32位程序的字符串算法如下。
123456789101112131415161718192021222324252627282930313233function getName32(GName, idx) { var ComparisonIndex = idx; var FNam ...
某盾so加固與修復
文章在看雪那邊被警告了,這邊也不留了^^
LIAPP手遊保護分析
packagename:bmV0LmdhbWVkdW8udGJk聲明:本文內容僅供學習交流之用
前言淺淺記錄一次對LIAPP的分析過程。
初見反調試直接打開APP會提示debuggable。
用frida注入後會提示ng1ok-64.so ( 一般的frida應該是frida-agent-64.so )
用frida hook dlopen,發現在閃退前只加載了libdyzzwwc.so,顯然anti frida的邏輯就在這個so中。
查看libdyzzwwc.so的.init_array,看上去有點奇怪。
手動按D幫助IDA重新解析,發現靜態分析.init_array只能看到有一個初始化函數,相關檢測邏輯大概就在這裡。
將sub_B8080重命名為init_array_func1。
進入init_array_func1,會發現有些函數調用IDA靜態分析時無法識別,像下圖這樣。
遇到這種情況時,只好動調看看了。
動調分析init_array注:一些函數是經過我重命名的,並非原本就是這樣。
在動調前要先弄清楚主要的目的:
嘗試找到檢測邏輯。
熟悉代碼( 相信代碼,代碼就 ...
so加載—relocate篇
https://xrefandroid.com/android-10.0.0_r47/xref/bionic/linker/linker.cpp
relocate分析只保留relocate中與arm64有關的部份,刪除了其他架構&tls相關的東西。
relocate做了以下事情:
調用soinfo_do_lookup獲取類型為ElfW(Sym)的s。
將s傳入resolve_symbol_address函數,它會返回對應符號的地址sym_addr。
最後會根據不同的重定向類型來進行重定向,主要分為3類R_GENERIC_JUMP_SLOT、R_GENERIC_GLOB_DAT、R_GENERIC_RELATIVE。
reloc指向待重定向的地址,根據不同的重定向類型,修改為不同的值。
1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677 ...
【N1CTF2024】ezapk
前言久違的看看安卓題,順便水一篇文章,有任何問題歡迎指出!
分析java層拉入jadx,很容易可以定位到關鍵邏輯,經典的加密對比。
加密函數enc在native層,而且加載了2個so。
嘗試分別將2個so都拉入ida,但都未發現enc,顯然是動態注冊的。
網上抄的一個frida腳本,用來hook動態注冊的native函數
12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849// com.n1ctf2024.ezapkfunction find_RegisterNatives(params) { let symbols = Module.enumerateSymbolsSync("libart.so"); let addrRegisterNatives = null; for (let i = 0; i < symbols.length; i++) { let symbol = s ...
淺談Cocos2djs逆向
前言簡單聊一下cocos2djs手遊的逆向,有任何相關想法歡迎和我討論^^
一些概念列出一些個人認為比較有用的概念:
Cocos遊戲的兩大開發工具分別是CocosCreator和CocosStudio,區別是前者是cocos2djs專用的開發工具,後者則是cocos2d-lua、cocos2d-cpp那些。
使用Cocos Creator 2開發的手遊,生成的關鍵so默認名稱是libcocos2djs.so
使用Cocos Creator 3開發的手遊,生成的關鍵so默認名稱是libcocos.so ( 入口函數非applicationDidFinishLaunching )
Cocos Creator在構建時可以選擇是否對.js腳本進行加密&壓縮,而加密算法固定是xxtea,還可以選擇是否使用Zip壓縮
libcocos2djs.so裡的AppDelegate::applicationDidFinishLaunching是入口函數,可以從這裡開始進行分析
Cocos2djs是Cocos2d-x的一個分支,因此https://github.com/cocos2d/co ...
自實現Linker加載so
前言前一陣子在研究so加固,發現其中涉及自實現的Linker加載so的技術,而我對此知之什少,因此只好先來學習下Linker的加載流程。
本文參考AOSP源碼和r0ysue大佬的文章( 不知為何文中給出的那個demo我一直跑不起來 )來實現一個簡單的自實現Linker Demo。
環境:Pixel1XL、AOSP - Oreo - 8.1.0_r81
Demo實現Linker在加載so時大致可以分成五步:
讀取so文件:讀取ehdr( Elf header )、phdr( Program header )等信息。
載入so:預留一片內存空間,隨後將相關信息加載進去,最後修正so。
預鏈接:主要處理.dynamic節的內容。
正式鏈接:處理重定位的信息。
調用.init、.init_array
Read利用open+mmap來將待加載的so文件映射到內存空間,存放在start_addr_中。然後調用Read函數來獲取ehdr、phdr等信息。
123456789101112int fd;struct stat sb;fd = open(path, O_RDONLY);fstat(fd ...
初窺ARM平坦化還原
前言上周在看DASCTF的題發現難得有一道安卓( 題目名:RealeazyRealeazy ),興致勃勃地打開IDA卻發現了這可悲的控制流平坦化,當場直接自閉…
之後分析了下發現這ollvm應該算是比較簡單的那類( 只有間接跳轉 + 最普通的平坦化,貌似沒有虛假分支/虛假塊 ),於是決定好好地學習下怎麼還原。
一開始是想按「使用unidbg还原标准ollvm的fla控制流程平坦化」一樣使用Unidbg來還原,後面發現分支的情況用Unidbg不太好處理。
最後還是決定用Unicorn的模擬執行來還原,具體思路&實現完全參考「[原创]ARM64 OLLVM反混淆」。
還原思路利用Unicorn來模擬執行,從而獲取程序的執行流程,主要有以下步驟:
識別&保存函數所有的真實塊,有兩種識別思路,要麼通過真實塊的特徵,要麼通過非真實塊的特徵,看哪種特徵比較明顯,對本例來說真實塊有個明顯的特徵就是mov pc, r0這樣的間接跳轉。
模擬執行並保存執行路徑,遇到分支時就手動修改寄存器的值來遍歷( 本例沒有虛假分支,不用考慮太多,直接2條分支都執行就可以 )。模擬執行過程中遇到bl ...