From among thousands of different files in the GRUNTZ.REZ archive two are truly unique. These are GAME\ATTRIBUTEZ.TXT and STATEZ\CREDITZ\PALETTEZ\CHEATZ.TXT files. In total, there are four files with the *.TXT extension in the archive. In addition to the two mentioned above, there are also files GAME\VERSION\VERSION.TXT (not used by the game itself, containing only the string “1.00”) and STATEZ\CREDITZ\CREDITZ.TXT (end credits of the game with some funny gags at the end). But while these two files can be easily read with Notepad, ATTRIBUTEZ.TXT and CHEATZ.TXT files may pose a problem – if opened in a typical text editor random gibberish would appear with no clear indication of what the real purpose of these files really is. If someone wants to view them, you can download them right here:

Wait a minute, these are binary files! When I first saw these files some time ago, I felt a bit bitter about this fact, believing that I wouldn’t ever get to know the real contents of those files. Especially the CHEATZ.TXT file, whose name can make many people drool involuntarily. And what’s the deal with the PALLETEZ folder anyways, why is it in there?

In this post I’ll try to explain what ATTRIBUTEZ.TXT really is and what it is for. The next post will be reserved for the file CHEATZ.TXT.


Due to the fact that the ATTRIBUTEZ.TXT file is inherently a binary file, the HEX editor naturally comes in as a first weapon of choice to look for any byte patterns in the data. Even though the whole file looks as if it has been spewed out of the pseudorandom number generator, some patterns can be spotted. At the beginning of the file, a sequence of eight bytes is repeated a few times: 71 F2 D4 36 B7 5B D9 E3:

The fact that the data looks random to some extent may suggest that the file contains some preprocessed (mangled) data. Most of the times it’s caused by some compression or encryption algorithm. A repetitive sequence of bytes however may point more towards the encryption in the ECB (Electronic Codebook) mode. In this mode the same byte sequences are encrypted in the same way, which results in visible repetitive byte patterns in the encrypted message. But still, it leaves us with two essential questions: what encryption algorithm was used and what key is used for decryption?

Well, the algorithm used turns out to be the symmetric Blowfish encryption algorithm, and the key used is a string: “1212“. And unfortunately no, it wasn’t me who figured all of this out. I was late to the party myself and took up the subject when everything was pretty much disclosed. It all started with the user Friedslick6, who created a topic in the XeNTaX forum and asked for help in decrypting both files: ATTRIBUTEZ.TXT and CHEATZ.TXT. After almost a year of waiting with no response whatsoever, it was the user dniel888 who decided to share his own findings with the others. He revealed the name of the algorithm, the encryption key and a script to the program QuickBMS which decrypted the file. The key was extracted from the game executable itself by first disassembling it and then analyzing the assembly instructions. It sure isn’t easy but it’s doable (I successfully did it myself after a bit of struggling with the program named IDA. But it’s easy to accomplish when you actually know what to search for, isn’t it? 😛 ). Sadly the user dniel888 didn’t say anything about the CHEATZ.TXT file, but I will come back to it. Finally, Friedslick6 informed the GooRoo’s Gruntz Forum community in this thread about the discovery.

So we know how to decrypt the file. So not it’s time for a celebratory decryption! After using the Blowfish algorithm with the key “1212” the following text is revealed:

We now see that the repetitive block of eight bytes I mentioned at the very beginning of the article is actually eight asterisk characters (“********“) that make up the initial comment in the file.

If someone sees the contents of this file for the first time, let’s be honest – he can get hiccups out of excitement. The file contains hundreds of parameters that control virtually every aspect of the game. In essence, this is nothing more than a configuration file. Imagine what aspects of the game you could actually change! You can:

  • change the movement speed of any type of Grunt (which would certainly ruin over 75% of all existing levels)
  • change the color of teleporters (judging from the comments in the decrypted file, there are up to 7 different colors to choose from)
  • change the range of tools. Like, any tool, including those used purely as melee weapons! You could make a Sword Grunt be able to remotely smack a Grunt at the other end of a map, or make a Gauntletz Grunt destroy any rock in the vicinity. How crazy is that?
  • change all the aspects of any spell (like freezing time or the speed of conjured rolling balls)
  • change the probability distribution for producing any tool and toy by Grumley during a multiplayer match
  • … and many, many other things!

But perhaps the biggest surprise here is that the ATTRIBUTEZ.TXT file contains all of the cheat codes used in the game – something we would rather expect to be a part of the CHEATZ.TXT file. As you can see however they are not stored as a plain text – instead they are encoded in some way. It’s quite an important information if you think of it.

Cheat codes by definition should be kept secret. Since they are input as a plain string during gameplay, the game has to have some means of comparing those strings and deducing which cheat code it’s dealing with. Now, if the programmers explicitly used the strings like “MPVASFLAM” or “MPLAMBERT” during game development, those characters would also be visible in the executable itself. Searching for the cheat codes would then be as easy as opening the executable in plain Notepad, hitting Ctrl+F and searching for them. Therefore, the programmers were forced to store those strings in a more intricate way that would effectively obfuscate their locations. What we see in the ATTRIBUTEZ.TXT file is the result. These encoded strings are not a temporary way to store them in the file. In this form all cheat codes are stored in the game memory and used by the game. This subject deserves a separate article in which I’ll show how important implications it has.

Decoding the cheat codes is not that hard and may be considered a simple exercise. That’s because, unlike the ATTRIBUTEZ.TXT file, cheat codes are not encrypted but encoded. Encryption makes sense when you want to protect the contents of some data whose location is relatively well known from unauthorized people. Cheat codes are treated the other way around – we want them to be hidden (obfuscated) so that they’re hard to find. However when you finally locate them decoding process is often trivial.

There are several methods to hide easily distinguishable data. The simplest is probably bitwise XOR-ing each byte by some constant. In this case however the programmers took a more “arithmetic” approach and a fixed offset is simply added to each character (byte) of the string. A good example here is the code for getting a sword – “mparrrrrrr“. In the decrypted ATTRIBUTEZ.TXT file, this code corresponds to a byte sequence 8A 8D 7E 8F 8F 8F 8F 8F 8F 8F. If you inspect the ASCII codes of the cheat code in plain form you will see immediately how each value is simply increased by a fixed offset. Since the letter “m” corresponds to the ASCII value of 0x6D, the offset is 0x1D. But is it though … ? We could as well take a capital “M” as a reference point. Since the ASCII code of “M” is 0x4D the offset could as well be 0x3D. How do we verify which offset is correct? Luckily for us, out of all 70 cheat codes there is one containing a … digit. It’s the code for resurrection: “mpback2life”, whose encoded version is represented by a byte sequence: “8A 8D 7F 7E 80 88 6F 89 86 83 82“. If we assume the value 0x1D as an offset, the decoded code would turn out to be “mpbackRlife. Notice the character “R” instead of “2”. However if we use the offset equal to 0x3D we get the string “MPBACK2LIFE“, just as expected! So that means that the plain version of every cheat code is represented with capital letters. However if the code “MPBACK2LIFE” didn’t exist, it would get a little bit more complicated and some experimenting would be required.

If we decode all the cheat codes, the following file appears to us:

We’ve practically read the entire file at this point, but we may not rest just yet! Look at the very end of the file. The Blowfish algorithm is a block cipher which works on 8-byte blocks. However, if we take a closer look at the ATTRIBUTEZ.TXT file, its size turns out not to be a multiple of 8 bytes. At the end of the file there is one additional byte with the value 0x05.

If we inspect the last decrypted 8-byte block in the ATTRIBUTEZ.TXT file, we can see that the original text file was padded at the end with 0x0 bytes, so that its total size is a multiple of 8 bytes after all. This method is called a zero padding. This last byte in the encrypted ATTRIBUTEZ.TXT file is the amount of bytes from the last decrypted block which should be actually read. This extra byte is really important: if it’s not present in the file, the value 0x0 is assumed by default and the entire last block of the decrypted file is ignored!

And that’s pretty much it. Now with all the information from this article you can create tools which would easily and painlessly decrypt and encrypt the ATTRIBUTEZ.TXT file and allow for modifying all the game attributes. This way you could also modify cheat codes and … add new ones! But I’m getting ahead of myself – that surely is some material for the next article or two which I’m planning to do some day.

And the next article will be all about the CHEATZ.TXT file.

Cheers,
Tomalla