勒索軟件CTB-Locker核心原理的一些疑問和分析

解密的過程是在釋放到臨時目錄中的進程來完成的,相關代碼如下:

2. 加密文件的結構是什么？

原始文件經過ZLIB壓縮和AES加密后，寫在了一個臨時文件的x030開始的位置。最后再向臨時文件頭部寫入0×30長度的數(shù)據(jù)，其中前0×20是會話公鑰，接下來是的四個DWORD分別是標志“CTB1”,壓縮后的大小，壓縮前的的大小，標志(值為1). 會話公鑰是明文不加密的，但是針對“CTB1”及后面的長度為0×10數(shù)據(jù)進行加密。在對該段長度為0×10的數(shù)據(jù)解密后首先判斷開頭是否是“CTB1”接著判斷尾部是不是1，兩者同時匹配才會認為是CTB-Locker加密過的文件。

3. 為什么樣本在離線的時候仍然能夠解密5個文件?

在系統(tǒng)中文件被加密后，如果我們選擇對話框中的“NEXT”,CTB-Locker會讓我們搜索一些文件來測試能否解密.如下圖:

如果我們選擇解密文件，文件是可以解密成功的。這讓我們產生一個錯覺:密鑰是不是在本地保存了? 其實可以說是保存了但是只是保存了5個.保存的是AES的KEY并且是保存在開始提到的配置文件中。首先在為每一個文件產生AES KEY時都會將這個AES的KEY返回給調用者:

調用者會判斷當前保存的KEY是否超過了5個,如果超過了5個就不再保存了。代碼如下:

當你選擇解密5個文件時，CTB-Locker會遍歷所有的已加密文件嘗試著使用這5個KEY來解密文件偏移0×20處的數(shù)據(jù).如果和標志相匹配就說明KEY匹配上了。然后就把這5個可以解密的文件名字輸出到屏幕上。相關代碼如下:

因此離線解密5個文件并不足為奇，有種你保存所有的密鑰啊…

4. 要求受害者向服務器提交的public key和文件加密有關系嗎？

最開始我們猜測這個publickey是不是和文件加密有關系或者它會攜帶一些能夠幫助解密的信息。經過分析幾乎沒有。這個public key 是在所有文件被加密完成后產生的，它主要包含了配置文件中的一些數(shù)據(jù)以及所有加密文件的總的大小.某種程度上算是類似一個序列號的東西.