SimpleModulus revisited
Recently, I was working on getting game client version 0.75 to work with OpenMU. One big obstacle was the SimpleModulus encryption which was somehow different in the earlier versions of MU Online. You can find an analysis of it here. According to a change log in a leaked 0.65 server source, SimpleModulus was introduced with Version 0.74. Unfortunately, the server source (0.65) didn't include the source code of SimpleModulus - just a header and a lib file. As I found out later, it wasn't correct for this client anyway.
My first attempts decrypting a captured packet using the newer SimpleModulus variant failed miserably. The provided dat-files (they contain the encryption keys) of the game client were too big to make sense for me, too. After a while, I realized they contain more keys than newer variants. The key files were also encrypted (simple XOR) and of course, the encryption key for the files was longer in earlier versions. To find the longer key, I searched in the old main.exe for the first values of the known key and found the others. I had luck that Webzen just shortened the key.
After a while I managed to decrypt the captured packet and refactored my code so that it's possible to support both variants.
To make a long story short, I summarize the difference to newer versions:
- The block size. In 0.75 it used a block size of 32 decrypted and 38 encrypted bytes, instead of 8 decrypted and 11 encrypted. One 16 bit value needs 18 bits in encrypted state (because the multiplication result is bigger), so you can basically calculate the encrypted block size as follows:
blockSizeencrypted = (blockSizedecrypted * 18 / 16) + 2
- More keys. Because blocks were bigger in earlier versions, they used more keys. Every 16 bit value is encrypted separately, so it uses 16 keys ( 32 decrypted bytes / 2 bytes).
- The missing counter. The old variant didn't use a counter in its header. The first byte in the first encrypted block was already the content. Webzen probably has added the counter in a later version to make replay attacks harder.
It's pretty interesting that Webzen actually decreased security in one aspect (key size/count) and increased it by a counter. I can just assume that they wanted to reduce the required network traffic and CPU utilization back at the time (~2002). Needless to say, this algorithm isn't secure, no matter which variant is used.