Salsa in Petya: defects caused by algorithm Modification

Salsa in Petya: defects caused by algorithm Modification

Previously, the harbo analysis system introduced the trojan Petya about modifying MBR for disk encryption extortion. Recently, Leo Stone provides a complete brute-force code and decryption tool for cracking Petya keys, and points out that the author of Petya uses the variant Salsa20 Algorithm for key verification. By checking the source code provided by Petya and combining the description of the Salsa algorithm, you can restore the modifications made to the algorithm by Petya and the specific logic of the process.

Salsa20
Salsa20 is a group encryption algorithm invented by Daniel J. Bernstein. It can encrypt data of up to 2 ^ 70 bytes, in which the Group length is 2 ^ 6 = 64 bytes. This algorithm is a symmetric encryption algorithm, and the encryption and decryption operations are equivalent. That is, the restored plaintext can be obtained by encrypting the plaintext twice with the same key.
Salsa Input
Salsa requires the following input data:
Key: Key, 16 or 32 bytes;
IV: initial vector, 8 bytes;
Round: calculates the number of rounds. The value is 8, 12, or 20;
Message: plaintext, no more than 2 ^ 70 bytes.
The output Ciphertext of Salsa is the encrypted data such as Message.
The official website cited a Python Demo. The usage is as follows:

Key Parameter
The Key is transformed from the Key that Petya uses for disk encryption. After the user enters the key, Petya uses this key to calculate the Salsa class and compares the result with the 512-byte reserved data stored in the 55-sector disk, if the results are consistent, the key is valid.
The Salsa Key must be at least 16 bytes, but the valid Key in Petya must be 8 bytes. This key has three conversion forms:
1. Original key: an 8-bit key. To facilitate user input, the characters must be selected from numbers and uppercase/lowercase letters. The cracked source code defines 54 valid characters;

2. Terminal key: the Key entered by the user. It consists of 16 characters and is formed by adding the letter "x" after each character of the original key;

3. Salsa Key: The Key used for the Salsa algorithm to extend the original Key into 16 bytes. The extension method is to extend each byte B of the original key to 2 bytes. The low part is the sum of ASCII (122) corresponding to B and the character "z", and the high part is B * 2. (The data in the Salsa algorithm is in the small order, the same below .)

In addition, it is worth noting that the original Salsa algorithm requires 8 DWORD groups of 32-byte keys. When the Input Key parameter is only 16 bytes, the Key is copied to 32 bytes. However, in the Petya variant algorithm, 16-byte keys are directly divided into eight groups of words for calculation.
IV Parameters
Initial vector. This vector is stored in the 8-byte starting from the 33 offset of 54 sector on the disk by Petya. It is called Nonce In the cracking source code. Although 8 bytes are stored, Petya only uses four bytes in total: 0, 1, 4, and 5, that is, the low WORD bit of two DWORD.

Parameter Extension
The structure in the cracking source code is a good description of the data structure during the operation of the Salsa algorithm:

Compared with the original algorithm, the biggest difference between the Petya variant algorithm is that each field is changed to 2 bytes. The Key and Nounce (IV) have been discussed, while Const and Counter extend the input parameters.
Const is a constant data, which is defined as follows in the Salsa algorithm:

Its meaning can be seen by translating it into corresponding ASCII characters:

When using Petya, it only takes its low WORD bit for computation.

Counter is a Counter with an initial value of 0. It is used to record the current group and participate in calculation. In the original algorithm, Counter is a 64-bit integer value. It can encrypt up to 2 ^ 64 groups and multiply them by the 64-byte length of each group, A total of 2 ^ 70 bytes of data can be encrypted. Similarly, in Petya variants, the maximum number of groups is also limited, which is 2 ^ 32, but in fact, Petya only uses eight groups.
Calculation wheel count
Leo Stone believes that Petya only performs 10 rounds of computation, and the calculation amount is half of the original algorithm. This is actually a misunderstanding. In the implementation of the officially quoted Salsa20, the standard cycle times are only 10:

This is because two rounds of computation are actually performed in each loop. in the official documentation, it is called the row computation wheel and the column computation wheel (rowround, columnround ), therefore, the 10 cycles have reached the Salsa20 calculation wheel.


Output Data
After the calculation is complete, the Salsa algorithm Concatenates the results of each group and obtains the data of the same length as the plain text, and performs an exclusive or operation with the plain text to obtain the output ciphertext. This is why the encryption and decryption operations of Salsa are equivalent: the plaintext data can be obtained after the calculation result is exclusive or operation with the ciphertext.
In the decryption source code, we can see that after the reserved result of 55 sectors of the disk is read, the bitwise operation is different from that of 0 × 37 or the operation is performed:

The true meaning of this step is that Petya uses the Salsa variant algorithm and specified parameters to encrypt the 512-byte plaintext of each bit, which is 0 × 37, then, the ciphertext is written to the disk sector.
Interestingly, although Petya used a 2-byte WORD as the basic data length in the previous step, however, the Group length is reserved as 64 bytes. This means that in the aforementioned petya_matrix struct, each field must be extended from 2 bytes to 4 bytes, and its high-level WORD will be filled with 0, and in the next XOR operation, the plaintext features are exposed:

Petya simplifies the Salsa20 algorithm a lot, including switching DWORD to WORD in multiple places. One of the most important changes is to limit the key space to a range of 54 ^ 8, and the plaintext and ciphertext are both known, this provides favorable conditions for brute-force cracking of keys.