In part 1, I gave some examples to recover XOR keys from encoded executables if we knew some of the content of the unencoded file (known plaintext attack).
In this part, I give some examples to automate this process using my xor-kpa tool.
xor-kpa.py takes 2 files as input: the first file contains the plaintext, and the second file the encoded file. We are going to search for string This program cannot be run in DOS mode width:852px” />
xor-kpa displays some potential keys, in ascending order of extra characters.
Value Key is the recovered key, and Key (hex) is the hexadecimal representation of the key (in case the key would not be printable).
Keystream is the keystream, from which xor-kpa extracted the key by looking for repeating strings.
Extra is the difference between the length of the keystream and the length of the key. If this is just one character, the proposed key is very unlikely to be the encoding key. Output can be filtered by requiring a minimum value for extra by using option -e.
Divide is the number of times the key is present in the keystream.
And counts reports the number of times the same key was recovered at different positions in the encoded file.
So by using this known plaintext (This program cannot be run in DOS mode) with the encoded file, xor-kpa proposes a number of keys. In this example, the key with the highest number of extra characters is the actual encoding key (Password).
Another way to recover the key we saw yesterday, is looking for sequences of null bytes (0x00) which have been encoded. xor-kpa.py can do this too, by giving 000000000000… as plaintext. We could create a file containing null bytes, but it width:852px” />
The key was recovered, and the count is very high, so it width:852px” />
Please post a comment is you have ideas for other known plaintexts in executables.
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.