And here's the sample save game decrypted, read from game memory during run-time: https://pastebin.com/X4h5cpXX(keep in mind that THIS IS how it should look immediately after decryption; the game does base64 encode before encryption)

So this is what my script looks like so far to get the key and IV, but as i said, the final file doesn't match up:

What's strange is that the actual encrypted data size is 440 bytes (without the first and last byte and the IV), but the properly decrypted file size ends up being 432 bytes. All the QuickBMS algorithms i've tried return 440 bytes.

It doesn't seem to do anything out of the ordinary, and i triple-checked the Key and IV used, they're the same as the ones in game memory during run-time.When i use the "des_ede_cfb64" OpenSSL algorithm in QuickBMS (or the "tomcrypt des3 cfb" one), at least the FIRST byte of the result is correct. The rest, however...

Wikipedia tells me that 3des can work with 16 byte keys, where key1 = first 8 bytes, key2 = last 8 bytes, and key3 = key1. That's how 3des-112 works, as opposed to 3des-168 which uses the full 24 bytes.

I made a test file via hijacking the game's encrypt function:

Code:

Ou1YIRIIK0QAqhgUCoyDwP3zoTn65+XcCqN9ASO28fU2cQXDOc/utK7viZZPkNAi7Ag=

De-Base64'd and taking the key salt and IV out of it, it should decrypt into this:

Code:

QuickBMS TripleDES encryption test!

It's easier to check immediate success with this. As i noticed before, The first byte decrypts correctly ('Q'), the rest ends up garbage. I wonder why, the triple DES implementation is standard .NET.

That's interesting because by using the "3des-112" encryption the result starts with 0x8c which is, indeed, used for PKCS but also in that case all the rest is garbage.Since the same happens also with your last test it doesn't seem a coincidence.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum