1. 從“菜雞”到入門為什么逆向工程繞不開編碼與加密剛接觸逆向工程的朋友常常會(huì)卡在一個(gè)看似基礎(chǔ)實(shí)則至關(guān)重要的環(huán)節(jié)面對程序里一堆“亂碼”或者經(jīng)過變換的數(shù)據(jù)完全無從下手。你興致勃勃地打開調(diào)試器跟到一個(gè)關(guān)鍵函數(shù)發(fā)現(xiàn)它傳進(jìn)去的是一串“5L2g5aW977yM5oiR5Lus5LiA5Liq5a2X56ym5Liy”傳出來的卻是“你好這是一段中文”。或者你攔截到一個(gè)網(wǎng)絡(luò)包里面的關(guān)鍵參數(shù)是一長串毫無規(guī)律的十六進(jìn)制字符經(jīng)過某個(gè)算法處理后才變成可讀的明文。沒錯(cuò)這就是編碼和加密算法在“作祟”。對于逆向分析來說它們就像是鎖住寶藏的第一道也是最常見的一道門。不理解這些算法你的逆向之路就永遠(yuǎn)在門口打轉(zhuǎn)。我剛開始學(xué)逆向的時(shí)候也吃過不少虧。曾經(jīng)為了分析一個(gè)軟件的注冊機(jī)制對著一段經(jīng)過Base64編碼后又用自定義XOR處理的數(shù)據(jù)折騰了一整天最后才發(fā)現(xiàn)如果我先認(rèn)出Base64的特征五分鐘就能搞定。所以今天我就把自己在逆向過程中對常見編碼和加密算法的識別、分析與逆向經(jīng)驗(yàn)總結(jié)下來。這不僅僅是CTF比賽中的常客更是商業(yè)軟件、移動(dòng)應(yīng)用、網(wǎng)絡(luò)協(xié)議分析中每天都會(huì)遇到的“老朋友”。我們會(huì)重點(diǎn)聊聊Base64、SM4這些高頻出現(xiàn)的算法以及如何從二進(jìn)制代碼或腳本中快速識別它們并找到破解或繞過的思路。無論你是分析一個(gè)安卓APK的so庫還是解密一段網(wǎng)頁的JavaScript這些知識都是你的必備工具箱。2. 逆向思維下的編碼算法不只是“轉(zhuǎn)碼”那么簡單在正向開發(fā)中編碼Encoding主要用于數(shù)據(jù)表示、傳輸或存儲比如把二進(jìn)制數(shù)據(jù)變成可打印的文本。但在逆向工程師眼里編碼算法常常被用作一種輕量級的“混淆”或“偽裝”手段。識別它們是還原數(shù)據(jù)真實(shí)面貌的第一步。2.1 Base64逆向分析中的“老熟人”與它的變種們Base64恐怕是逆向中最最常見的編碼了。它的核心特征非常明顯字符集通常由A-Z, a-z, 0-9, , /以及填充符組成輸出字符串的長度通常是4的倍數(shù)。如何在逆向中快速識別Base64靜態(tài)字符串掃描在IDA Pro、Ghidra等反編譯工具中直接搜索上述字符集構(gòu)成的字符串。如果發(fā)現(xiàn)一段較長的、僅由這些字符組成的字符串大概率是Base64編碼的數(shù)據(jù)。動(dòng)態(tài)行為觀察在調(diào)試時(shí)如果發(fā)現(xiàn)程序調(diào)用了諸如base64_encode、base64_decode或類似命名的函數(shù)或者數(shù)據(jù)流經(jīng)過一個(gè)函數(shù)后從二進(jìn)制/十六進(jìn)制變成了可打印的ASCII字符串或反之就要高度懷疑。特征碼識別標(biāo)準(zhǔn)的Base64編碼/解碼函數(shù)有其固定的操作流程如按6位分組、查表替換。在一些簡單的程序中可能會(huì)直接內(nèi)聯(lián)實(shí)現(xiàn)。你可以通過識別其常量表比如一個(gè)包含64個(gè)字符的數(shù)組來定位。逆向?qū)崙?zhàn)中的Base64“花活”單純的Base64解碼很簡單但實(shí)際軟件中不會(huì)這么直接。多層嵌套編碼這是CTF和某些軟件中常用的技巧。比如一段數(shù)據(jù)先被Base64編碼結(jié)果再被Base64編碼一次甚至多次。在逆向時(shí)你需要觀察數(shù)據(jù)解碼后的結(jié)果是否仍然是Base64特征字符串。我常用的方法是寫個(gè)小腳本循環(huán)嘗試解碼直到結(jié)果不再符合Base64字符集為止。import base64 data “5L2g5aW977yM5oiR5Lus5LiA5Liq5a2X56ym5Liy” # 示例數(shù)據(jù) while True: try: # 嘗試解碼并檢查是否為ascii可打印或utf-8 decoded base64.b64decode(data) # 嘗試轉(zhuǎn)換為字符串如果失敗則可能仍是二進(jìn)制或另一層base64 try: text decoded.decode(‘utf-8’) print(f“解碼成功: {text}”) # 可以進(jìn)一步檢查text是否還是base64字符串特征 if all(c in ‘ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789/’ for c in text): print(“解碼后結(jié)果仍具有Base64特征可能為多層嵌套?！? data text # 繼續(xù)循環(huán) else: break except UnicodeDecodeError: print(“解碼結(jié)果為二進(jìn)制數(shù)據(jù):”, decoded.hex()) break except Exception as e: print(“解碼失敗:”, e) break自定義碼表這是增強(qiáng)隱蔽性的常用手段。程序不使用標(biāo)準(zhǔn)的ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789/碼表而是將其打亂。例如某些游戲或軟件使用自定義的64個(gè)字符作為碼表。逆向時(shí)關(guān)鍵就是找到這個(gè)碼表。你需要在反匯編代碼中尋找一個(gè)長度為64的常量字符數(shù)組它就是解密的鑰匙。結(jié)合其他簡單變換Base64編碼后可能再進(jìn)行一次簡單的XOR異或或加減操作。這需要你在動(dòng)態(tài)調(diào)試中觀察Base64解碼函數(shù)輸出后數(shù)據(jù)是否立即被另一個(gè)小函數(shù)處理。注意Base64只是一種編碼不是加密它沒有密鑰其“安全性”完全依賴于算法的隱蔽性如自定義碼表。一旦識別出來還原就是分分鐘的事。不要被它的外表唬住。2.2 十六進(jìn)制Hex與URL編碼網(wǎng)絡(luò)數(shù)據(jù)抓包的好伙伴這兩種編碼在逆向網(wǎng)絡(luò)協(xié)議、分析HTTP/HTTPS請求響應(yīng)時(shí)極為常見。十六進(jìn)制編碼將每個(gè)字節(jié)轉(zhuǎn)換為兩個(gè)字符的0-9, a-f表示。例如字節(jié)0xAB變成字符串”AB”或”ab”。在逆向中如果你看到字符串長度是偶數(shù)且字符僅在0-9a-fA-F范圍內(nèi)那很可能就是Hex編碼。Python的binascii.hexlify()和unhexlify()是處理它的利器。URL編碼Percent-Encoding為了在URL中安全傳輸特殊字符將其轉(zhuǎn)換為%后跟兩個(gè)十六進(jìn)制數(shù)字的形式如空格變成%20中文常用UTF-8編碼后再進(jìn)行此操作如“中”可能變成%E4%B8%AD。在逆向爬蟲或分析API時(shí)經(jīng)常需要解碼URL參數(shù)。識別特征就是包含大量的%符號。逆向技巧很多網(wǎng)絡(luò)庫如libcurl或語言內(nèi)置庫如Java的URLEncoder會(huì)直接調(diào)用相關(guān)函數(shù)。在反編譯代碼中搜索%字符串處理邏輯或定位hex、urlencode、percent等關(guān)鍵字可以幫助你快速找到相關(guān)代碼段。2.3 Unicode與字符串編碼解決亂碼問題的鑰匙在逆向跨平臺或國際化軟件時(shí)字符串編碼問題會(huì)讓你頭疼。程序內(nèi)部可能使用UTF-8、UTF-16LE、UTF-16BE或GBK等。識別特征UTF-8英文字符單字節(jié)中文字符通常為3字節(jié)。在內(nèi)存中ASCII部分正常中文部分每個(gè)字節(jié)都大于0x80。UTF-16LE在x86 Windows環(huán)境下非常常見。每個(gè)字符占2字節(jié)或4字節(jié)。英文字符ASCII會(huì)在內(nèi)存中呈現(xiàn)為類似a\x00b\x00c\x00的形式ASCII碼后跟一個(gè)零字節(jié)。在IDA中你可能會(huì)看到字符串被識別為aWideString。GBK中文Windows傳統(tǒng)編碼。一個(gè)中文占2字節(jié)。逆向中的應(yīng)用當(dāng)你從內(nèi)存或文件中dump出一段字符串?dāng)?shù)據(jù)顯示為亂碼時(shí)第一反應(yīng)就是嘗試不同的編碼解碼。在Python中你可以簡單地嘗試data b’\xd6\xd0\xce\xc4’ # 示例字節(jié)數(shù)據(jù) encodings [‘gbk’, ‘utf-8’, ‘utf-16-le’, ‘utf-16-be’] for enc in encodings: try: print(f“{enc}: {data.decode(enc)}”) except UnicodeDecodeError: pass在靜態(tài)分析中注意觀察程序調(diào)用的字符串處理API如Windows的MultiByteToWideChar/WideCharToMultiByte或Linux下的iconv相關(guān)函數(shù)它們指明了編碼轉(zhuǎn)換的發(fā)生點(diǎn)。3. 對稱加密算法逆向找到那個(gè)“唯一的鑰匙”對稱加密算法在軟件保護(hù)、通信加密、本地?cái)?shù)據(jù)存儲中應(yīng)用極廣。逆向的目標(biāo)往往不是破解算法本身現(xiàn)代加密算法在數(shù)學(xué)上是安全的而是找到那個(gè)被隱藏或硬編碼在程序中的密鑰Key或者理解其使用模式如ECB、CBC從而能夠模擬加密解密過程。3.1 國密SM4算法識別與分析SM4是我國商用密碼標(biāo)準(zhǔn)中的分組加密算法在金融、政務(wù)及一些國內(nèi)軟件中越來越常見。它和AES類似是分組密碼分組長度128位密鑰長度128位。如何在二進(jìn)制代碼中識別SM4查找常量表SM4算法內(nèi)部使用一個(gè)固定的S盒Substitution Box和FK、CK常量。這是最可靠的指紋。SM4的S盒是一個(gè)256字節(jié)的固定表。如果你在反匯編代碼的數(shù)據(jù)段.data或.rdata中發(fā)現(xiàn)一個(gè)256字節(jié)的、內(nèi)容固定的數(shù)組可以將其與標(biāo)準(zhǔn)SM4 S盒進(jìn)行比對。標(biāo)準(zhǔn)SM4 S盒的前幾個(gè)字節(jié)是{0xd6, 0x90, 0xe9, 0xfe, 0xcc, 0xe1, 0x3d, 0xb7, …}。函數(shù)特征SM4的輪函數(shù)操作涉及S盒查表、循環(huán)移位和異或。在反編譯代碼中你可能會(huì)看到大量的查表操作byte ptr [table_base index]、32位整數(shù)的循環(huán)左移rol指令或((x n) | (x (32-n)))的代碼模式以及異或xor操作。字符串與導(dǎo)入表如果程序使用了開源密碼庫如GMSSLBouncyCastle的國密Provider可能會(huì)在字符串或?qū)牒瘮?shù)中留下SM4、GMSSL、BC等痕跡。對于Java程序可以查找SM4Engine、SM4Cipher等類名。SM4工作模式ECB vs CBC識別出算法后確定其工作模式同樣關(guān)鍵它直接影響到逆向和攻擊的難度。ECB模式最簡單的模式相同的明文塊加密后得到相同的密文塊。在代碼中它通常表現(xiàn)為直接對每個(gè)128位分組調(diào)用加密函數(shù)沒有額外的初始化向量IV處理。安全性較低在逆向中如果你能獲得一段已知明文及其對應(yīng)的密文可能有助于分析或驗(yàn)證密鑰。CBC模式更常用的模式每個(gè)明文塊先與前一個(gè)密文塊異或后再加密。需要一個(gè)初始化向量IV。在代碼中你會(huì)看到在加密/解密循環(huán)開始前有一個(gè)IV被加載或生成并且在處理每個(gè)分組時(shí)有一個(gè)與上一分組密文或解密中間結(jié)果進(jìn)行異或的操作。逆向時(shí)必須同時(shí)找到Key和IV才能正確解密。逆向?qū)崙?zhàn)心得 對于像SM4、AES這類標(biāo)準(zhǔn)強(qiáng)加密算法直接通過逆向分析從算法中推導(dǎo)出密鑰幾乎不可能除非實(shí)現(xiàn)有嚴(yán)重漏洞。我們的主要思路是密鑰硬編碼在程序的字符串、常量數(shù)組或資源文件中搜索可能的密鑰。密鑰可能是16字節(jié)128位的十六進(jìn)制字符串或可打印字符。使用findcrypt-yara等IDA插件可以幫助識別常見算法的常量。密鑰派生密鑰可能不是直接存儲而是通過一個(gè)密碼Password和鹽值Salt經(jīng)過KDF密鑰派生函數(shù)如PBKDF2計(jì)算得出。你需要找到生成密鑰的那個(gè)函數(shù)并嘗試輸入已知的測試密碼觀察生成的密鑰是否與加密所用的一致。內(nèi)存dump在程序運(yùn)行時(shí)密鑰必然會(huì)被加載到內(nèi)存中。如果加密/解密操作發(fā)生在你的調(diào)試會(huì)話期間你可以在調(diào)用加密函數(shù)如SM4_Encrypt時(shí)通過調(diào)試器查看傳入的密鑰參數(shù)或者在該函數(shù)入口處設(shè)置斷點(diǎn)從寄存器或棧中提取密鑰。白盒密碼在一些高保護(hù)場景中可能會(huì)使用白盒密碼技術(shù)將密鑰與算法混淆在一起。逆向這種實(shí)現(xiàn)極其復(fù)雜通常需要深厚的密碼學(xué)和程序分析功底。遇到這種情況可能需要考慮其他攻擊面如協(xié)議層、輸入驗(yàn)證等。3.2 其他常見對稱加密算法特征速查除了SM4逆向中還常遇到AES識別方法與SM4類似查找其S盒256字節(jié)和輪常量Rcon數(shù)組。AES的S盒是公開的前幾個(gè)字節(jié)為{0x63, 0x7c, 0x77, 0x7b, 0xf2, 0x6b, 0x6f, 0xc5, …}。同樣需要注意ECB、CBC等模式。DES/3DESDES的S盒是8個(gè)4x16的查找表共512位。3DES是DES的三次應(yīng)用。在較老的金融系統(tǒng)或遺留軟件中常見。RC4流密碼。特征包括一個(gè)256字節(jié)的S盒初始化過程for i in range(256): S[i]i和偽隨機(jī)子密碼生成算法。代碼中通常有兩個(gè)索引變量i和j在循環(huán)更新。TEA/XTEA非常簡單的小型分組密碼核心操作是循環(huán)、加法、異或和移位通常直接以內(nèi)聯(lián)代碼實(shí)現(xiàn)沒有明顯的S盒。其魔數(shù)常數(shù)0x9e3779b9黃金比例的倒數(shù)是一個(gè)關(guān)鍵識別特征。4. 非對稱加密與哈希算法逆向中的驗(yàn)證與簽名在逆向中非對稱加密如RSA和哈希算法如SM3、MD5、SHA系列通常不用于直接加密大量數(shù)據(jù)而是用于簽名驗(yàn)證、密鑰交換或完整性校驗(yàn)。4.1 哈希算法識別與對抗哈希算法將任意長度數(shù)據(jù)映射為固定長度的摘要。在軟件中常用于驗(yàn)證文件完整性、密碼存儲加鹽哈希或生成挑戰(zhàn)碼。識別特征常量每種哈希算法都有固定的初始化向量IV。例如MD5的IV是0x67452301, 0xefcdab89, 0x98badcfe, 0x10325476。SHA-1、SHA-256也都有各自的IV常量。在數(shù)據(jù)段找到這些常量基本就能確定算法。函數(shù)名/字符串動(dòng)態(tài)鏈接庫可能導(dǎo)出MD5_Init、SHA256_Update等函數(shù)。字符串中也可能出現(xiàn)算法名。輸出長度MD5輸出128位16字節(jié)SHA-1輸出160位20字節(jié)SHA-256輸出256位32字節(jié)SM3輸出256位32字節(jié)。如果你看到程序在比較一個(gè)固定長度的二進(jìn)制串可以猜測其算法。逆向場景與應(yīng)對注冊碼/許可證驗(yàn)證軟件可能用哈希算法計(jì)算機(jī)器特征如硬盤序列號、MAC地址生成一個(gè)“機(jī)器碼”然后要求用戶輸入對應(yīng)的“注冊碼”。這個(gè)注冊碼可能是機(jī)器碼經(jīng)過某種變換如與一個(gè)固定密鑰拼接后再哈?；蚴褂梅菍ΨQ算法簽名的結(jié)果。你需要找到生成機(jī)器碼和驗(yàn)證注冊碼的代碼邏輯。API請求簽名很多網(wǎng)絡(luò)應(yīng)用如akamai盾、hcaptcha的后端交互或一些APP的API會(huì)對請求參數(shù)進(jìn)行哈希通常用HMAC或簽名防止篡改。逆向的目標(biāo)是找到生成簽名的密鑰和算法以便能自己構(gòu)造合法請求。這通常需要分析JavaScriptWeb逆向或移動(dòng)端的Native代碼Android/iOS逆向。密碼驗(yàn)證服務(wù)器不存儲明文密碼存儲的是加鹽哈希值。客戶端登錄時(shí)對用戶輸入的密碼進(jìn)行同樣的哈希運(yùn)算后發(fā)送。在逆向客戶端時(shí)你需要找到哈希函數(shù)和鹽值這可能用于制作離線密碼破解工具或進(jìn)行撞庫測試需在法律允許范圍內(nèi)。實(shí)操心得對于哈希由于其單向性逆向的目標(biāo)幾乎從不可能是“解密”哈希值而是識別算法、找到鹽值、并能夠復(fù)現(xiàn)計(jì)算過程。例如如果你發(fā)現(xiàn)一個(gè)游戲客戶端將用戶密碼與一個(gè)硬編碼的字符串拼接后做MD5那么你就可以用同樣的方式生成任意賬號的密碼哈?？赡苡糜诒镜啬M登錄測試。4.2 非對稱加密以RSA為例在逆向中的角色RSA算法在逆向中常見于軟件激活、許可證驗(yàn)證、通信密鑰交換等場景。識別點(diǎn)大數(shù)運(yùn)算代碼中會(huì)出現(xiàn)非常大的整數(shù)幾十上百字節(jié)以及模冪運(yùn)算a^b mod n?？赡軙?huì)調(diào)用大數(shù)庫如OpenSSL的BN函數(shù)。密鑰數(shù)據(jù)在程序數(shù)據(jù)段可能會(huì)發(fā)現(xiàn)PEM格式的證書字符串以—–BEGIN PUBLIC KEY—–開頭或者直接存儲著模數(shù)n和公鑰指數(shù)e通常為65537的二進(jìn)制大整數(shù)。功能上下文代碼在驗(yàn)證一個(gè)簽名使用公鑰解密一段數(shù)據(jù)與計(jì)算出的哈希值對比或者用公鑰加密一小段數(shù)據(jù)如會(huì)話密鑰。逆向策略 對于RSA私鑰通常不會(huì)出現(xiàn)在客戶端。因此逆向的目標(biāo)通常是提取或繞過公鑰驗(yàn)證如果你只是想讓程序認(rèn)為簽名有效可以嘗試修改驗(yàn)證函數(shù)的跳轉(zhuǎn)指令Patch或者找到一個(gè)有效的簽名并硬編碼到程序中。分析密鑰交換過程在通信協(xié)議中客戶端可能用服務(wù)器的公鑰加密一個(gè)隨機(jī)生成的對稱密鑰。你需要理解這個(gè)流程以便在中間人攻擊或模擬客戶端時(shí)能夠生成合法的加密數(shù)據(jù)。尋找弱密鑰或舊版本漏洞極少數(shù)情況下程序可能使用強(qiáng)度不足的RSA密鑰如512位或者使用的隨機(jī)數(shù)生成器有缺陷。但這需要專業(yè)的密碼學(xué)分析工具和知識。5. 實(shí)戰(zhàn)逆向流程與工具鏈配合理論說了這么多我們來看一個(gè)綜合性的簡化實(shí)戰(zhàn)流程假設(shè)我們要分析一個(gè)Android Native So庫中的加密函數(shù)。5.1 靜態(tài)分析定位入口使用IDA Pro/Ghidra加載So文件首先進(jìn)行反編譯等待自動(dòng)分析完成。字符串搜索在字符串窗口中搜索base64、encrypt、decrypt、AES、SM4、MD5、SHA等關(guān)鍵詞。注意中英文。查找密碼學(xué)常量使用FindCrypt等插件或手動(dòng)在數(shù)據(jù)段瀏覽尋找大的、看起來隨機(jī)的常量數(shù)組可能是S盒、IV、魔數(shù)。交叉引用分析找到上述字符串或常量的引用位置跳轉(zhuǎn)到相關(guān)函數(shù)。這很可能就是加密/解密/編碼/哈希的入口函數(shù)。5.2 動(dòng)態(tài)調(diào)試驗(yàn)證猜想靜態(tài)分析只能給出可能的位置動(dòng)態(tài)調(diào)試才能看清具體的數(shù)據(jù)流和參數(shù)。使用Frida進(jìn)行Hook這是移動(dòng)端逆向的神器。你可以寫一個(gè)Frida腳本Hook你懷疑的加密函數(shù)。// 示例Hook一個(gè)名為 native_encrypt 的JNI函數(shù) Java.perform(function() { var targetClass Java.use(“com.example.app.CryptoHelper”); // 假設(shè)有一個(gè)native方法叫 encryptData targetClass.encryptData.overload(‘[B’, ‘[B’).implementation function(input, key) { console.log(“[] encryptData called!”); console.log(“Input (hex):”, bytesToHex(input)); console.log(“Key (hex):”, bytesToHex(key)); var result this.encryptData(input, key); // 調(diào)用原函數(shù) console.log(“Result (hex):”, bytesToHex(result)); return result; }; function bytesToHex(bytes) { /* 轉(zhuǎn)換函數(shù) */ } });通過Hook你可以直接看到函數(shù)傳入的明文、密鑰和輸出的密文從而100%確認(rèn)該函數(shù)的功能。使用IDA Pro遠(yuǎn)程調(diào)試對于更底層的Native代碼邏輯分析可以將IDA連接到手機(jī)上的調(diào)試服務(wù)器如android_server在關(guān)鍵函數(shù)地址下斷點(diǎn)單步跟蹤寄存器、內(nèi)存和棧的變化觀察算法每一步的執(zhí)行細(xì)節(jié)。這對于分析自定義或混淆過的算法尤其有用。5.3 算法還原與模擬一旦通過動(dòng)態(tài)調(diào)試確認(rèn)了算法、密鑰、IV和模式下一步就是用自己的代碼復(fù)現(xiàn)這個(gè)過程。提取關(guān)鍵參數(shù)從內(nèi)存或代碼中提取出密鑰、IV、S盒如果是自定義的、工作模式。選擇對應(yīng)庫在Python中可以使用pycryptodome或cryptography庫來實(shí)現(xiàn)標(biāo)準(zhǔn)算法AES, SM4等。對于自定義編碼或簡單變換自己實(shí)現(xiàn)即可。編寫模擬代碼from Crypto.Cipher import AES from Crypto.Util.Padding import pad, unpad import base64 # 假設(shè)從逆向中獲取到的信息 key b’your_16_byte_key!!!’ # 16字節(jié)密鑰 iv b’initial_vector_16b’ # 16字節(jié)IV (CBC模式需要) cipher_text_hex “加密后的十六進(jìn)制字符串” cipher AES.new(key, AES.MODE_CBC, iv) cipher_text_bytes bytes.fromhex(cipher_text_hex) plain_text_padded cipher.decrypt(cipher_text_bytes) plain_text unpad(plain_text_padded, AES.block_size) # 去除填充 print(“Decrypted:”, plain_text.decode())驗(yàn)證用你的模擬代碼去解密一段已知的密文看是否能得到正確的明文。或者用你的代碼加密一段數(shù)據(jù)看是否與目標(biāo)程序產(chǎn)生的結(jié)果一致。6. 常見問題與排查技巧實(shí)錄在實(shí)際逆向過程中你會(huì)遇到各種奇怪的問題。這里記錄一些我踩過的坑和解決思路。問題1明明找到了加密函數(shù)Hook時(shí)卻捕獲不到調(diào)用可能原因1函數(shù)名混淆。So庫中的函數(shù)名可能被混淆成a、b、c或無意義字符串。此時(shí)靜態(tài)分析找到的函數(shù)地址可能不準(zhǔn)或者Hook腳本使用的函數(shù)簽名不對。解決使用函數(shù)地址進(jìn)行Hook而不是函數(shù)名。在IDA中查看函數(shù)的起始地址在Frida中使用Module.findExportByName(null, offset)或絕對地址進(jìn)行Hook。可能原因2調(diào)用時(shí)機(jī)過早。加密函數(shù)可能在APP啟動(dòng)或某個(gè)初始化階段就被調(diào)用你的Frida腳本附著上去時(shí)已經(jīng)晚了。解決使用frida -U -f com.package.name –no-pause在APP啟動(dòng)早期就注入腳本或者修改APP的啟動(dòng)方式確保腳本最先加載。可能原因3多線程調(diào)用。函數(shù)可能在非主線程調(diào)用導(dǎo)致Frida默認(rèn)的Java.perform上下文不對。解決確保Hook代碼在Java.perform內(nèi)并且考慮使用setImmediate或檢查線程。問題2解密出來的數(shù)據(jù)開頭或結(jié)尾有亂碼可能原因1填充問題。分組加密需要填充。常見的填充方式有PKCS#7、ZeroPadding等。如果解密時(shí)使用的填充方式與加密時(shí)不一致就會(huì)導(dǎo)致最后一塊數(shù)據(jù)錯(cuò)誤。解決嘗試不同的填充方式。觀察解密后數(shù)據(jù)的最后幾個(gè)字節(jié)它們可能就是填充值。例如PKCS#7填充的字節(jié)值就是填充的長度。可能原因2編碼問題。解密出的數(shù)據(jù)可能是二進(jìn)制數(shù)據(jù)你直接當(dāng)成UTF-8解碼就會(huì)亂碼。解決先不要解碼打印十六進(jìn)制形式hex()查看。它可能是圖片數(shù)據(jù)、序列化對象如Protobuf或其他結(jié)構(gòu)化二進(jìn)制數(shù)據(jù)。可能原因3IV錯(cuò)誤。CBC模式需要正確的IV。如果IV獲取錯(cuò)誤第一個(gè)解密塊會(huì)是亂碼但后續(xù)塊可能正確錯(cuò)誤傳播。解決仔細(xì)檢查動(dòng)態(tài)調(diào)試中傳入的IV值。問題3算法似乎是標(biāo)準(zhǔn)的但用自己的庫實(shí)現(xiàn)結(jié)果總是不對可能原因1工作模式或參數(shù)細(xì)節(jié)。除了ECB、CBC還有CFB、OFB、CTR等模式。確認(rèn)模式是否正確。另外一些實(shí)現(xiàn)可能使用“CBC with no padding”而你的庫默認(rèn)使用了填充?？赡茉?密鑰或IV處理。程序可能對原始的密鑰字符串進(jìn)行了預(yù)處理比如先做一次MD5哈希取前16字節(jié)作為AES密鑰。解決在調(diào)試器中在加密函數(shù)入口處不僅打印傳入的“密鑰”參數(shù)還要打印實(shí)際參與加密運(yùn)算的密鑰數(shù)據(jù)即函數(shù)內(nèi)部處理后的結(jié)果進(jìn)行對比。可能原因3字節(jié)序問題。特別是在處理多字節(jié)整數(shù)如AES的輪密鑰或從文件中讀取密鑰時(shí)大端序和小端序可能會(huì)搞錯(cuò)。問題4遇到未知的、看起來像自定義的加密/編碼怎么辦第一步動(dòng)態(tài)跟蹤。這是最有效的方法。在調(diào)試器中單步跟蹤記錄下輸入數(shù)據(jù)經(jīng)過每一個(gè)操作異或、加減、移位、查表后的變化。用紙筆或文本編輯器記下每一步的中間狀態(tài)。第二步尋找規(guī)律。觀察這些操作是否可逆異或、加減同一個(gè)數(shù)是可逆的查表如果有反向表也是可逆的。嘗試用窮舉小數(shù)據(jù)如單個(gè)字節(jié)0x00, 0x01, 0xFF輸入觀察輸出來推斷查表的內(nèi)容或運(yùn)算的性質(zhì)。第三步嘗試模擬。根據(jù)記錄的步驟用高級語言Python復(fù)現(xiàn)這個(gè)過程。先從最簡單的部分開始逐步增加復(fù)雜度并與調(diào)試結(jié)果對比。第四步利用符號執(zhí)行或污點(diǎn)分析高級技巧。對于復(fù)雜的混淆可以使用如Angr、Triton等框架進(jìn)行自動(dòng)化分析但這需要較高的學(xué)習(xí)成本。逆向編碼和加密算法就像是在解一個(gè)設(shè)計(jì)者留下的謎題。它考驗(yàn)的不僅是你的技術(shù)知識更是耐心、觀察力和邏輯推理能力。從最基礎(chǔ)的Base64識別開始逐步深入到復(fù)雜的自定義算法這個(gè)過程本身就是極大的樂趣和成就感來源。記住沒有無法分析的程序只有還沒找到的突破口。每次成功還原一個(gè)算法你的工具箱里就多了一件利器下次再遇到類似的保護(hù)就能更快地直擊要害。