Avaddon勒索解密工具原理解析
文章目錄
- Avaddon勒索
- 解密工具
- 解密工具原理
- 解密工具優(yōu)化
- 關于文件大小的疑惑
- Avaddon勒索加密流程補充
- 解密工具實現(xiàn)
- 相關資料
Avaddon勒索
該勒索病毒使用C++語言進行編寫，采用RSA-2048和AES-256加密算法對文件進行加密，加密庫使用的是Windows自帶的CryptAPI
被該勒索加密后的文件后綴為avdn
解密工具
國外安全研究人員發(fā)布了一款Avaddon勒索病毒解密工具，解密工具源代碼地址：
https://github.com/JavierYuste/AvaddonDecryptor
經(jīng)過測試，這個工具確實是可以解密被Avaddon勒索加密的文件，下面是 我輸出的解密時的日志
想要解密被加密的文件 需要具備下面幾個條件
然后調(diào)用下面這個命令
python3 main.py -f <encrypted_file> -o <original_file> -d <memory_dump> --folder <folder_to_decrypt>就可以解密機器上所有的被加密文件了（需要修改源碼中寫死的三個路徑 才能把解密腳本跑起來)
解密工具原理
目前我的需求是把這個解密能力集成的到公司的工具里，再來分析一下代碼
首先在dump文件中搜索所有可能的密鑰，然后返回一個偏移列表，再根據(jù)這個偏移列表，去拿到所有的key
輸出的日志顯示offset有90個，也就是說有90個AES的密鑰
然后利用搜索到的key去解密文件，每解密一次，都去和源文件進行比對，比對成功則說明密鑰正確
比對成功之后，開始解密整個系統(tǒng)的文件。
解密文件時，傳入被加密的文件路徑和解密后的文件路徑以及密鑰文件路徑，然后調(diào)用DecryptFile.exe對文件進行解密
需要特殊處理的是，如果文件大小大于0x100000個字節(jié)，那么解密完成之后需要將0x10000字節(jié)后的數(shù)據(jù)全部復制到解密后的文件。
也就是說這個勒索實際上只會加密前0x10000個字節(jié)，這個細節(jié)在目前已有的分析報告中并沒有提及。
解密完成之后，將文件截斷為原始文件大小
那么這里其實有一個問題，為什么可以根據(jù)內(nèi)置的特征碼搜索到AES密鑰？那個密鑰的特征碼是哪來的？
作者在代碼中給出了這樣一句注釋
# Dump the process with procdump.exe -ma <PID> # Pattern to search for (part of the key_data_s structure, in particular alg_id, flags and key_size): # 106600000100000020000000根據(jù)這個提示，找到了這個結(jié)構(gòu)體，原文出處：https://forums.codeguru.com/showthread.php?79163-Structure-of-HCRYPTKEY-Data
struct key_data_s {void *unknown; // XOR-eduint32_t alg;uint32_t flags;uint32_t key_size;void* key_bytes; };勒索采用的是AES256 ，那 alg = 0x00006610,keysize=0x00000020, flags= 0x1
則特征值對應：106600000100000020000000
這個結(jié)構(gòu)體來自于CryptApi，作者是逆向了cryptsp.dll和rsaenh.dll這兩個dll得到的這個數(shù)據(jù)結(jié)構(gòu)。
也就是說，這種在內(nèi)存中暴力搜索密鑰去解密被加密文件的方式，只適用于調(diào)用了CryptApi，并且隨機生成密鑰的情況。
那么有沒有可能將作者的源碼進行優(yōu)化呢？答案是有
解密工具優(yōu)化
在這之后，bd也針對該勒索發(fā)布了一款解密工具，根據(jù)提示，也是基于上面的代碼做了一個圖形化的工具而已。
工具只需要一個被加密文件和被加密前的源文件，不需要選擇進程，不需要dump文件，就能對整個文件夾進行解密，但是我這里測試是解密失敗的。分析一下這個工具有沒有什么可借鑒的地方
bd的做法是遍歷整個系統(tǒng)的進程
直接在內(nèi)存里匹配密鑰，
如果匹配完成，就直接讀取，然后調(diào)用解密程序。
關于文件大小的疑惑
根據(jù)網(wǎng)上的分析報告提示
最后附加的24個字節(jié)中前4個字節(jié)是原始文件大小，但這個大小似乎不太對。如果原始文件大小是0x01EB0B，那么
0x01EB0B-512-24=0x1E8F3但上圖被加密文件數(shù)據(jù)的大小是0x20000，這個文件大小這么來看的話是對不上的。直到我即將完成我的解密工具的時候，解密出來的文件在末尾總是會出現(xiàn)一堆0。
末尾的這一堆0，直接導致了解密后的文件和解密前的文件md5對比失敗，一開始我以為是程序邏輯上的bug，但是后來發(fā)現(xiàn)并不是。實際上
文件大小的計算方式如下：
加密后的文件大小(小于0x100000)=原始文件大小+填充0的字節(jié)數(shù)+512+24以下面某個文件為例：
- 原始文件大小為：0x2EE82
- 加密后的文件大小為:0x30218
- 填充0的字節(jié)數(shù)為4478
最后填充的0實際上是為了對齊到0x2000個字節(jié)，因為該樣本每次會加密0x2000個字節(jié)，如果不足2000那么在加密的過程可能會導致異常退出。
Avaddon勒索加密流程補充
解決了文件大小的問題，這里對Avaddon勒索的AES加密流程做一個補充。
對于文件大小小于0x10000的文件，首先會在文件末尾填充0，將大小補齊到0x2000，然后將樣本進行加密處理，每次加密0x2000個字節(jié)
對于文件大小大于0x10000的文件，直接加密前0x10000個字節(jié)，0x10000以后的部分不做加密處理。所以在末尾不需要填充0
解密工具實現(xiàn)
那么到這里，已經(jīng)填完了所有的坑，可以做一個相對來說最優(yōu)化的解決方案。整個解密流程如下：
BOOL Check(LPCTSTR lpszFile);首先判斷是否是該家族的加密文件，判斷條件有三個，兩個末尾24字節(jié)寫死的特征碼和文件大小的計算是否滿足條件
void GetValidPid();然后獲取有效進程的PID，遍歷整個進程，并且獲取進程映像文件的md5，將md5和注冊表啟動項中的映像文件做對比，如果對比成功，說明可能是潛在的勒索進程。
這個勒索是會將路徑寫到啟動項，可以通過這個方法來過濾掉絕大部分的進程，提高后面特征匹配的效率
接著遍歷所有的有效進程，搜索特征碼，獲取到所有可能的Key
BOOL GetUniqueKey(LPCTSTR szSourceFile, LPCTSTR szEncryptedFile);用所有可能的Key文件去解密被加密文件，如果解密出來的文件和源文件md5一致，那么視為密鑰獲取成功。
成功獲取密鑰的條件也可以用文件格式的魔數(shù)頭來做判斷，但是并不符合我的應用場景。
開始解密整個需要解密的目錄
記錄一下整個過程和一些踩過的坑，這個解密工具寫了快1100行代碼，花了6天左右的時間。工程這里就不發(fā)了。
相關資料
勒索分析：https://www.freebuf.com/articles/others-articles/249109.html
解密工具: https://github.com/JavierYuste/AvaddonDecryptor
勒索解密工具分析：https://mp.weixin.qq.com/s?__biz=MzA4ODEyODA3MQ==&mid=2247486514&idx=1&sn=6464b9066980a6c045a33ef58dd5b6b0&chksm=902fa31aa7582a0c88242eb816fb466cbb7f94fe33b3e8b14f1f769d6d493961eaf9721cc87d#rd
密工具分析：https://mp.weixin.qq.com/s?__biz=MzA4ODEyODA3MQ==&mid=2247486514&idx=1&sn=6464b9066980a6c045a33ef58dd5b6b0&chksm=902fa31aa7582a0c88242eb816fb466cbb7f94fe33b3e8b14f1f769d6d493961eaf9721cc87d#rd
總結(jié)
以上是生活随笔為你收集整理的Avaddon勒索解密工具原理解析的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： PC微信逆向：分析通用设置数组
- 下一篇： VMProtect SDK完全避坑指南