2013 Hash file research con't'd

[RolandHazoto]

I was just working on the hash file and profile files. The hash seems to be randomly generated, I can't find any pattern. But I can see some consistency in the profile file.
I always have trouble describing these because my hexeditor (HxD) seems to display things differently from other but here goes:

Hash:
Unknown
Profile:
line 750 offset 2-4: 96 97 95
line 770 offset 2-3: ?? 8e (I forgot to write it down )

2nd file:
Hash:
23 bc 94 e5
Profile:
line 750 offset 2-4: 97 95 96
line 770 offset 3: 8f

3rd file:
Hash:
67 09 40 86
Profile:
line 750 offset 2-4: 96 95 97
line 770 offset 5-6: A5 9E (in 2nd file was 9F A5)

So there is some semblance of a pattern involved it's just not worked out.
Explaining HxD:
I struggle to put this into words but each "line" is a value of 10. Line 00000000 is the first line and line 00000010 is the 2nd. Then each line has the 00 - 0F. (14 bytes) Iused to know how to write these out properly but I'm a bit rusty so please bear with me.

[RolandHazoto]

I need to take a break for now but I will be adding more comparisons shortly.
Hopefully with enough comparisons the algorithim used will reveal itself.

[RiiakShiNal]

For me offsets 751-773 is part of a deck configuration. Offset 748-74B is the uid of what appears to be the second deck save in the file (assuming the one at offset 658 is a temporary). Though if the one at offset 658 is an actual deck save and not a temporary then it would be the third of a total of 19 deck saves. Of course all of this is educated guess work based on offset values and observed patterns.

As far as I can tell the hash takes into account the entire profile (all bytes in the 4,292 byte file) though I could be wrong.

[RolandHazoto]

I forgot to mention each file I checked was saving the exact same thing.
I would backup the 2 files, open the game, open deck editor, remove a card to a deck, add the card back into the deck, save and quit.
This way EVERY change listed is saving the exact same thing and all the changes should be results of the hash file only.
I figure, we crack the hash, maybe we'll get some breathing room.

[RiiakShiNal]

In that case you might get better results by only changing a single byte in each profile. Offset 51C is the player portrait and it results in completely different hashes (as would be expected from any decent hash).

File 1:
Offset 51C: 01
Hash: 86 23 B1 D7

File 2:
Offset 51C: 02
Hash: 1F 34 D7 AA

Of course without the rest of the profile this in and of itself doesn't tell anyone much. I could give generated checksums for each file (from Checksum-8 to Whirlpool 512-bit), but none of them even seem to come close to the hash generated by the game (so unless requested I'm going to save myself some typing and not include them).

[RolandHazoto]

My comparisons seem to implicate that the hash is not affected by file size, as the file should have been the same size every single time.
I think the game generates the values in the profile randomly and then creates the hash off of that. (or perhaps the other way around)
If we can find the number differences between the 2 it will give us something to work off of.
It might be worth mentioning, for the hell of it I set my hash file to read only, had the game save, closed it and re-opened. It acted as though I had never played before.
Anyway, I need to get away from this computer screen and get ready to call it a night. I'll post some more comparisons tomorrow. Also I just had an idea I wanna try tomorrow: profile read-only, see if hash file changes. If hash doesn't change then it is generated from the profile. If it does change, then all changes would be generated by the exe and it would be a matter of determining encryption methods.

[RiiakShiNal]

I think the game generates the values in the profile randomly and then creates the hash off of that. (or perhaps the other way around)
If we can find the number differences between the 2 it will give us something to work off of.

I haven't seen anything randomly generated in the profile (other than the cracks randomly generating player UIDs). In my above example the only differences between the two profiles was at offset 51C. The purpose of a hash is to check data integrity, by comparing two hashes you can be reasonably sure that the data was not tampered with and has not been corrupted (if they match) or if they don't match you can assume the data has either been tampered with or corrupted and should therefore be discarded.

The profile and the hash are probably generated as a set then passed to the crack dll which then just dutifully saves them both. In such a case setting either of them to read-only making a change in game exiting and reloading will give the same result the game will act as if you've never played before (wiped profile). The test to see if it generates the same hash would be to make a copy of the current profile, open the game, change the portrait, exit, open the game, change the portrait back, then exit and compare the two sets of files, if they are both completely matched then the hash is most definitely generated from the profile (as two matching profiles generate the same hash). Though we still do not know what the hashing algorithm is or if there is other outside constant information that is hashed in or not (such as the player's UID as reported by steam/crack or some secret salt that has been added). A "salted hash" can use a standard hashing algorithm, but if an outside party does not know the "salt" then the outside party can't regenerate any valid hashes (which is pretty secure and this is likely what DotP 2013 does). So ultimately we would have to figure out what both the algorithm and the salt is to be able to regenerate hashes for profile editing.

[RolandHazoto]

I know a way to check for an outside influence. Try loading someone else's hash and profile.

[RiiakShiNal]

I know a way to check for an outside influence. Try loading someone else's hash and profile.

I'm not talking about data from outside the game, the executable itself could be what is adding the "salt" (in which case your method would say there is no outside influence even if salt from the executable is being applied). For example a possible "salt" could be adding "MtG:DotP2013" to the beginning or the end of the file before hashing it. There are four ways to "salt" a hash:
1 - Place salt at the beginning of the data.
2 - Place salt at the end of the data.
3 - Place salt at both the beginning and end of the data.
4 - Transform the hash with the salt in some fashion (often either by Xor or a second hashing).

You can fairly easily make a program that can guarantee that it can find any "salt" to get a specific hash using any of the known hash algorithms. The problem is the program can't guarantee that it will find the "salt" within your lifetime due to the virtually infinite possible combinations (at a total of four bytes of salt you are already talking about more than 8 billion possible combinations).

The fastest and most sure method of figuring out the hashing algorithm is to disassemble the executable and locate the hashing algorithm and any "salt" from there.

[RolandHazoto]

Though we still do not know what the hashing algorithm is or if there is other outside constant information that is hashed in or not (such as the player's UID as reported by steam/crack or some secret salt that has been added).

^ That would be answered by loading someone else's files. That's what I was referring to.

[RiiakShiNal]

Though we still do not know what the hashing algorithm is or if there is other outside constant information that is hashed in or not (such as the player's UID as reported by steam/crack or some secret salt that has been added).

^ That would be answered by loading someone else's files. That's what I was referring to.

Actually, it wouldn't, though I can definitively tell you that it is not hashing in the player UID.

The reason it won't tell you if other outside information is hashed in or not is that any "secret salt" that is stored in the executable is "constant outside information" that is not stored in either the profile or the hash, but moving a player's save from one person's machine to another won't be able to tell if that information is used or not because on both machines the "constant outside information" is still present inside the executable (this information does not change from installation to installation).

The reason I can definitively tell you that it does not hash in the player UID is because I created multiple new profiles (each has a different uid and different name), but the files created by the game are virtually identical (though some profiles have the byte at offset 478 equal to 0x06 while others have that same byte equal to 0x04) and profiles that are newly created with the byte at offset 478 equal to 0x06 have a hash of "A8 DA 8F 6F" while those created with that byte set to 0x04 have a hash of "2A DE 9E A3". The player name/UID never factored in so it is not included in the hashed information.

There still could be a "secret salt" which is hashed in by the executable which we have no way of knowing other than:
1 - Brute force - trying every possible combination of every possible salt value for every possible length.
2 - Disassemble the executable to find and examine the hashing algorithm.

Number of Possibilities based on Salt length (only counts possibilities for that particular length of salt):

• 1 byte = 768 possibilities
• 2 bytes = 262,144 possibilities
• 3 bytes = 83,886,080 possibilities
• 4 bytes = 25,769,803,776 possibilities
• 5 bytes = 7,696,581,394,432 possibilities
• 6 bytes = 2,251,799,813,685,248 possibilities
• 7 bytes = 648,518,346,341,351,424 possibilities
• 8 bytes = 184,467,440,737,095,516,160 possibilities

Bottom line: We can not reasonably figure out the hashing algorithm/salt within our lifetimes without disassembling the executable.

Side note: The Theta version creates the player UID based (at least partially) on player name. On my machine creating a profile with one name generates a specific uid then deleting the swarm directory and re-creating that profile generates that same specific uid. You can, however, force a specific uid by setting it in the "vuid" file which can allow you to play someone else's save game with your name.

Edit: I realized my math was wrong for the possibilities, my numbers for most of them needed to be larger due to the number of possibilities when splitting the salt between the beginning and the end of the data (they have now been corrected).

Edit 2: For those curious the equation used to calculate possibilities is this:
2^(#Bytes * 8 ) * (3 + (#Bytes - 1)) = Number of possibilities

• 2^(#Bytes * 8 ) = Number of possible values for salt
• 3 = 3 ways to use salt (beginning, end, transforming hash [I only considered xoring for sake of simplicity, including other transformations of the hash will further increase number of possibilities.])
• (#Bytes - 1) = Number of ways to split bytes of salt between beginning and end of data.

Edit 3: Of course there is also the possibility that only part of the profile is hashed, in which case that also adds more possibilities to test, though those possibilities are easier to test because we know the values in the profile and don't have to guess at them.

[RolandHazoto]

LOL alright gotcha. Guess my approach was no good then. Well, learning experiences and all that jazz...

[RiiakShiNal]

LOL alright gotcha. Guess my approach was no good then. Well, learning experiences and all that jazz...

Yeah, well there is still the chance someone will get lucky and happen upon the method, but it's unlikely once you run the numbers. They almost definitely would not have figured out the algorithm from the method you were using.

Our best chance is if there is no salt, the hash is purely based on what is in the profile, and it uses a standard hashing algorithm. All of which is possible, it just depends on how lazy the developers of DotP were with creating the save protection.

Edit: Well, after sifting through about 5.5 GB of hashes (of a single 4,292 byte profile) I can say with pretty good certainty that it is not a naked CRC-32, MD5, RIPEMD-160, SHA-1, SHA-256, SHA-384, or SHA-512 of (or contiguous portion of) the profile file by itself. If it is one of those hashes then there must be some salt from somewhere.

Edit 2: I can now also say with certainty that it is not the 1's or 2's complement of a naked CRC-32, MD5, RIPEMD-160, SHA-1, SHA-256, SHA-384, or SHA-512 of the profile or contiguous portion of the profile (with and without the 1000 byte spacer). I have now sifted through more than 100 GB of hashes with no real results.

[noone]

I found the hashing algorithm in the game exe (with latest theta version)
It loads the profile, checks its size (0x10C4 hardcoded)
Then :

Code: Select all

hash = 0x811C9DC5
for (i = 0 to 0x10C4)
   hash = hash * 0x1000193
   hash = hash xor profileBytes[i]


Loads the hash.file and compares that computed hash and stored hash are equal

[RiiakShiNal]

I found the hashing algorithm in the game exe (with latest theta version)
It loads the profile, checks its size (0x10C4 hardcoded)
Then :

Code: Select all

hash = 0x811C9DC5
for (i = 0 to 0x10C4)
   hash = hash * 0x1000193
   hash = hash xor profileBytes[i]


Loads the hash.file and compares that computed hash and stored hash are equal

I confirm that this hashing algorithm produces the correct hash (tested on 3 different profiles).

Now, I can start playing around with the file itself and see if I can control which decks are saved.