## 3 Case Studies
### Third Malware
#### 3.3.2 Analysis of the Encrypted File  
From Figure 12, one can easily see that the file is Base64 encoded. Trying to decode it gives us the result illustrated in Figure 13. At first sight, it seems the decoded file is very entropic, meaning a not so weak encryption algorithm was used. In order to confirm or reject the supposition, one can estimate the randomness of the file, by checking the compression rate that can be achieved. When running the decoded file through gzip, one actually gets an increase in its size, implying that classical cryptosystems can be discarded. The next step therefore requires one to discover if an asymmetric or symmetric encryption algorithm was used, and, in the latter case, if it is a stream or a block cipher. Public-key schemes are not likely to be employed, due to a bigger code size and because they are not suitable for large inputs. Stream ciphers, on the other hand, are generally not secure when different messages are protected under the same key, because one can simply xor two distinct encrypted texts to cancel the keystream and perform a statistical analysis on the result [5]. Of course this is not common knowledge and actually one can find this vulnerable use of cryptography on the wild. However, considering that one has far more implementations of block ciphers than stream ciphers, we should try the former first. In order to proceed, one needs to find the cipher block size so as to narrow the list of possible algorithms. One way to do that is to analyze the Base64 encoded file, determine the boundaries between messages, and then check their sizes. One should remember that Base64 encodes three octets into four Base64 characters. Therefore, when the input size is multiple of three, it is not possible to detect where a message ends. For example, \"new\", \"man\", and \"newman\" are encoded as \"bmV3\", \"bWFu\", and \"bmV3 bWFu\", respectively. Observe that, in the last case, it is not possible to affirm if the original text consists of a single word or not. Figure 12: Encrypted file #3 sample. One straight strategy that can be adopted to circumvent that problem consists in looking for messages whose size is not multiple of three. In this situation, the last input block can have one or two octets, resulting in the padding illustrated in Figure 14. Searching the file for the padding character (\"=\") will help us find message boundaries and consequently infer the cipher block size. One such desired occurrence can be seen in Figure 15.  
Observe that, in the example, the delimited message contains 56 Base64 characters, of which the last four comprise a padded input block of length one. Since each four Base64 characters correspond to three input octets, we conclude that the message size is 40 bytes: we need to subtract 4 from 56, due to the padding block, multiply the result, 52, by \(\
icefrac{{3}}{{4}}\), which gives us 39 octets, and finally add 1 back, which is related to the last block. Figure 14: Base64 padding process. Figure 13: Result of Base64 decoding the file #3. Most modern block ciphers, such as AES [11], employs a 128-bit or larger block size (192 or 256-bit). Legacy encryption algorithms, such as DES, on the other hand, use a 64-bit block size. Given 40 bytes is not multiple of 16 (128 bits), 24 (192 bits), neither 32 (256 bits), we can assume that the malware does not use any modern algorithm, and therefore we should focus our work on 64-bit block ciphers.