This new version brings some options to guide the XOR-key detection algorithm.

The beacon’s AES and HMAC key are contained in writable process memory: my tool cs-extract-key.py can detect these keys. But the beacon can be configured to encode these keys while it is sleeping. This feature is called a sleep mask, and uses a 13-byte long XOR key. The complete writable memory section that contains the beacon process data, like encryption keys, is encoded with this 13-byte long XOR key.

Since writable process memory sections contain a lot of consecutive NULL bytes (0x00), the 13-byte long XOR-key will be present in the encoded process memory (XORing 0x00 with a key gives the key).

My tool will try to detect this XOR-key, but searching for 13-byte long random byte sequences that appear often. It does this by considering all possible 13-byte long sequences as a potential key, and counting how many times each potential key appears. Then it throws away all keys that don’t appear often (less than 100 times) and all keys that do not appear random (for example, keys with more than 3 0x00 bytes).

The most prevalent of these remaining keys, is considered as the most likely XOR key.

The new options that have been added to version 0.0.3, allow to guide this key finding algorithm.

Option –keysize is the XOR key size: the default value is 13.

Option –numberofkeystotry specifies how many keys that are considered to be potential XOR keys. The default value is 10: this means that the 10 most prevalent keys are selected and displayed.

Option –keystotry specifies which keys to try, out of the 10 keys selected. By default, only the first key (most prevalent key) is tried: value 0. But you can provide several keys, as a comma separated list of indices.

A potential XOR-key is selected as a decoding key, if the decoded memory section contains string b’sha256\x00′.

Finally, option -r can be used to let the tool analyze a raw set of data (e.g., the provided file is not parsed as a minidump file, but just taken as raw data).