The Mystery of the Encrypted Gauss Payload
There are many remaining mysteries in the Gauss and Flame stories. For instance, how do people get infected with the malware? Or, what is the purpose of the uniquely named “Palida Narrow” font that Gauss installs?
Perhaps the most interesting mystery is Gauss’ encrypted warhead. Gauss contains a module named “Godel” that features an encrypted payload. The malware tries to decrypt this payload using several strings from the system and, upon success, executes it. Despite our best efforts, we were unable to break the encryption. So today we are presenting all the available information about the payload in the hope that someone can find a solution and unlock its secrets. We are asking anyone interested in cryptology and mathematics to join us in solving the mystery and extracting the hidden payload.
Infected USB sticks have two files that contain several encrypted sections. Named “System32.dat” and “System32.bin”, they are 32-bit and 64-bit versions of the same code. These files are loaded from infected drives using the well-known LNK exploit introduced by Stuxnet. Their primary goal is to extract a lot of information about the victim system and write it back to a file on the drive named “.thumbs.db”. Several known versions of the files contain three encrypted sections (one code section, two data sections).
The decryption key for these sections is generated dynamically and depends on the features of the victim system, preventing anyone except the designated target(s) from extracting the contents of the sections.
By the way, the 64-bit version of the module has some debug information left in it. The module contains debug assertion strings and names of the modules:
.\loader.cpp NULL != encSection Path NULL != pathVar && curPos < pathVarSize NULL != progFilesDirs && curPos < progFilesDirsSize NULL != isExpected NULL != key (NULL != result) && (NULL !=str1) && (NULL != str2) .\encryption_funcs.cpp
The mysterious encrypted data is stored in three sections:
The files also contain an encrypted resource “100” that seems to be the actual payload, given the relatively small size of the encrypted sections. It is most likely that the section “.exsdat” contains the code for decrypting the resource and executing its contents.