解密的过程是在释放到临时目录中的进程来完成的,相关代码如下:
2. 加密文件的结构是什么？
原始文件经过ZLIB压缩和AES加密后，写在了一个临时文件的x030开始的位置。最后再向临时文件头部写入0×30长度的数据，其中前0×20是会话公钥，接下来是的四个DWORD分别是标志“CTB1”,压缩后的大小，压缩前的的大小，标志(值为1). 会话公钥是明文不加密的，但是针对“CTB1”及后面的长度为0×10数据进行加密。在对该段长度为0×10的数据解密后首先判断开头是否是“CTB1”接着判断尾部是不是1，两者同时匹配才会认为是CTB-Locker加密过的文件。
3. 为什么样本在离线的时候仍然能够解密5个文件?
在系统中文件被加密后，如果我们选择对话框中的“NEXT”,CTB-Locker会让我们搜索一些文件来测试能否解密.如下图:
如果我们选择解密文件，文件是可以解密成功的。这让我们产生一个错觉:密钥是不是在本地保存了? 其实可以说是保存了但是只是保存了5个.保存的是AES的KEY并且是保存在开始提到的配置文件中。首先在为每一个文件产生AES KEY时都会将这个AES的KEY返回给调用者:
调用者会判断当前保存的KEY是否超过了5个,如果超过了5个就不再保存了。代码如下:
当你选择解密5个文件时，CTB-Locker会遍历所有的已加密文件尝试着使用这5个KEY来解密文件偏移0×20处的数据.如果和标志相匹配就说明KEY匹配上了。然后就把这5个可以解密的文件名字输出到屏幕上。相关代码如下:
因此离线解密5个文件并不足为奇，有种你保存所有的密钥啊…
4. 要求受害者向服务器提交的public key和文件加密有关系吗？
最开始我们猜测这个publickey是不是和文件加密有关系或者它会携带一些能够帮助解密的信息。经过分析几乎没有。这个public key 是在所有文件被加密完成后产生的，它主要包含了配置文件中的一些数据以及所有加密文件的总的大小.某种程度上算是类似一个序列号的东西.
