## 2 The Proposed Methodology  
The proposed methodology, whose steps are depicted in Figure 1, starts by the analysis of the file containing the encrypted stolen information. This can be accomplished by simply opening it in a hexadecimal editor, in order to check if it is a text file or if there are patterns that could indicate the use of an encoding mechanism, such as Base64, Radix-64, or two-digit ASCII code. Whenever one gets a positive response for this verification, one should proceed with the data decoding. This step should be repetitively executed until one cannot identify an output containing encoded information. Additionally, one should verify whether compression is used or not and unpack the data if necessary. In order to test whether a classic (or weak) cryptographic algorithm is used, one can measure the level of redundancy of the data, by trying to compress it. One shall remember that the output of a strong encryption mechanism should look like something random, which implies that compression should result in a slightly bigger file, instead of a smaller one. The reasoning behind this is that compression is based on few elements being more frequent than others, which should not occur in a random stream, considering a sample of reasonable size, since each element tends to appear approximately the same number of times. Another simple technique to check this consists in making a histogram of the file contents and look for an uneven distribution of the byte values. There are several techniques that can be employed to perform the cryptanalysis of a classic algorithm. For simple substitution ciphers, one can employ frequency analysis [5], which is based on the following  
Figure 1: Methodology for retrieving information from malware encrypted output files. facts: (1) frequencies of plaintext symbols are preserved in the ciphertext; (2) each language has a characteristic frequency distribution of symbols. Considering these facts, the idea consists simply in substituting symbols in one alphabet for another according to similar frequencies. Transposition ciphers can also be broken using language statistics, but those related to the frequency of digrams and trigrams. In case of polyalphabetic mechanisms, one can employ [PERSON]'s method [5], which takes into consideration that a repeated sequence of symbols renders the same ciphertext when encrypted with the same key positions. This observation helps in finding the key length \(k\), which is enough to reduce the original problem to the cryptanalysis of \(k\) mono-alphabetic ciphers. Alternatively, the period of the polyalphabetic cipher can be found by using the index of coincidence [6], which measures the relative frequency of symbols in the ciphertext. Normally, it should not be possible to pinpoint the encryption algorithm that was used to generate a given ciphertext. However, one can at least try to infer some information related to the class of cipher used by inspecting the encrypted data. For instance, if one identifies that the messages have a fixed length of 2048 bits, it is reasonable to consider that an asymmetric cipher was used, especially the RSA cryptosystem [7], which commonly uses such a key size. On the other hand, if the size of messages varies and is multiple of 128 bits, one can suppose a 128-bit block cipher is being used. Finally, if one detects a variable message size that is not multiple of a common block size, a stream cipher might be a possible candidate. Note that it is important to know which algorithm we are facing, in order to correctly search the key and to be able to perform the decryption at the final step. The initial approach concerning key search in malware binary consists in looking for textual information contained in it. Clearly, it is a vulnerability to embed sensitive information, such as keys, in the source code, but even malware writers quite frequently do that [8]. If this test is unsuccessful, however, one can try [PERSON]'s algorithm [9], which considers the entropy of a securely generated key.