Checksum checks in World of Warcraft

[Itzamna]

Hello astute readers,

I am the owner of a private server (at version 3.1.3) and I have long wished for a way to customize spells (to undo the butchering of gameplay that Blizzard has done). However, whenever I modified Spell.dbc, World of Warcraft would throw error 83 (file corrupt) in my face. So, I inducted myself into assembly programming.

Using the renowned debugger OllyDBG, I studied Wow.exe and experimented for a whole week. I had figured it should be as easy as changing a few conditional jumps into unconditional ones, but whenever I tackled one check, another would be thrown in my face.

My question to you is this: has anyone succeeded in disabling the file checks in the client? If not, I am looking for someone to work with on this. I have built up some documentation on the functions inside Wow.exe.

Thanks in advance,

Itzamna

[Sonic Waffle]

WoWME fix? I believe it's bypassing the file checks. Although I am not certain that it does the same for DBCs, I know it does it for MPQs, so surely DBCs must have been noted before. Since half the game uses DBCs.

[Itzamna]

Thanks for your response, Dark Soul;

sadly, the WoWMe executable does not disrupt the DBC checks. However, as I said, I did learn a lot about the functions inside Wow.exe (talking about the 3.1.3 client):

The function at address 0x008ea5a0 appears to be the general MoPaQ function, called whenever the client needs access to a MoPaQ archive, it includes the ASCII strings patch-%s.MPQ, patch-%s-2.MPQ and locale-%s.MPQ.

The function at address 0x004044f0 checks whether an error code has been moved into the EAX register (CMP EAX,85100083) and jumps to a short segment of code if true, then clears the stack and returns. There are several functions that PUSH 85100083 onto the stack, perhaps one for every file?

The function at address 0x00658e10 is definitely the prime function for Spell.dbc. It has several CMP and conditional jump instructions and error messages in ASCII. I have fiddled around with this, but making these jumps unconditional results in the client going to locale-enGB.MPQ for all its DBC needs, thus throwing error 79 (0x85100079) due to a mismatch in the number of columns.

I'm still busy studying Wow.exe, but I sure could use the help from someone more adept than me at assembly programming.

[Cypher]

Why not just patch the DBCs in memory? That way you'd bypass all the file loading checks.

At any rate, I'm pretty sure that you're getting that error because you're corrupting the format/state of the DBC, not because you've modified it. Because I used to modify DBCs all the time and I only got that error message on patches when the DBC format changed and I needed to modify my edit...

It's been a long time though, so you may have to wait for someone like Schlumpf to come, because he knows a lot more about model editing and what-not than most.

[kynox]

I'm bored and feel like tackling this for you. Can you shoot me the offending DBC?

[Itzamna]

Wow, I didn't expect this many responses, thank you! If we can distribute executables that don't act like the Blizztapo, we will be doing the community a great service.

@ Cypher: I have tested your hypothesis, it doesn't appear that my DBC editing program, Smartworks' MyDBCEditor, corrupts the DBCs. I did this by comitting a change to Spell.dbc, then reverting that change. Inside common.MPQ and patch-X.mpq, there is a file called 'signaturefile' which contains a hash for most DBC files. I checked, it is not MD5, SHA1 or CRC32 - it may be a nested checksum, I don't know yet.

Would this Schlumpf fellow take kindly to a private message?

@ Kynox: Here are various facts:

World of Warcraft client version: 9947 (3.1.3)
Operating system: Gentoo GNU/Linux (I run Windows programs in WINE, actually not important to know)
Debugger / disassembler: OllyDBG, binary: click
DBC editor: MyDBCEditor by Smartworks, source code: click (he was kind enough to release it under the LGPL for me)
MPQ archiver: Ladik's MPQ Editor version 2.0.1.310, binary: click
Spell.dbc (modified): click (it is archived as .tar.gz)

- Server-side, everything's just peachy: Trinity Core (my server program) reads the modified Spell.dbc without a problem. I modified Inner Fire to last 3 minutes and not have charges, these changes take effect. However, the spell's tooltip and visual are resolved completely client-side. Thus, Inner Fire (all ranks) is our control spell.

- The function at address 0x658e10 handles Spell.dbc. When I convert all JEs and JNZs to JMPs, it no longer throws error 0x85100083 pertaining to Spell.dbc, but it complains about a corrupted Achievement.dbc, while I have not even touched it. In this scenario, I have replaced the Spell.dbc inside patch-enGB-2.MPQ.

- The functions at addresses 0x0053e050 and 0x0053e070 both call the function at 0x0053df80, which is the exception handler function.

If you need any more information, please ask. And thanks for your time!

[kynox]

I can't do any active debugging as you can't run older executables with newer files, but try patching 0x41FD70 to xor al, al; retn 4

It looks to be the function that compares two hashes and returns true/false depending on the equality of the hashes.

[Itzamna]

Hello Kynox and thanks for your response.

I have modified the lines at 0x0041fd70 and 0x0041fd71. It did have an effect: instead of giving error 0x85100083, it now throws a 0x85100079, complaining about Spell.dbc not having the right amount of columns. The Spell.dbc the game is reading comes from locale-enGB.MPQ, which has an insufficient number of columns. This is the same problem I ran into earlier, by modifying the function at 0x00658e10 - the game seems to want to open locale-enGB.MPQ and doesn't look anywhere else. Adding another Spell.dbc to locale-enGB.MPQ doesn't seem to work.

Could you, perhaps, debug your version of the client? I could use an offset comparison tool to apply your changes to my old 3.1.3 executable.

Thanks for your help!

[kynox]

When it has the wrong column number, its reading an incorrect version of the tool and will more than likely fail as the code will not match up to the database.

How is it reading an incorrect version of the database?

[Itzamna]

@ Kynox:

Because the only Spell.dbc that has 222 columns is in the archive locale-enGB.MPQ. A similar error occurred when I modifed another function, but that time it affected AreaPOI.dbc. It found 40-odd columns, while it needed 50-odd - so that's why I'm pretty certain the client falls back to the DBCs inside locale-enGB.MPQ.

This problem is boggling, it will take more figuring out - how much time would you like to spend on this?

[kynox]

@ Kynox:

Because the only Spell.dbc that has 222 columns is in the archive locale-enGB.MPQ. A similar error occurred when I modifed another function, but that time it affected AreaPOI.dbc. It found 40-odd columns, while it needed 50-odd - so that's why I'm pretty certain the client falls back to the DBCs inside locale-enGB.MPQ.

This problem is boggling, it will take more figuring out - how much time would you like to spend on this?

Not a lot, but if you can shoot me an updated version of Spell.dbc that would work in the latest version of WoW, i could debug the program flow and speed up progress.

[Itzamna]

Hello Kynox,

It's a bit much to install a separate client, so I'll give you MyDBCEditor and a DBC patch. Don't worry, it's not a hassle:

- Download MyDBCEditor and the DBC patch here (both are in the same archive)
- Extract Spell.dbc from patch-enGB.MPQ or patch-enGB-2.MPQ
- Open Spell.DBC with MyDBCEditor, then go to File -> Apply Patch and select Spell.patch and then go to File -> Save
- Open patch-enGB.MPQ or patch-enGB-2.MPQ from your World of Warcraft directory, delete Spell.dbc, then right-click and click on 'Add new file' (don't encrypt it). Then you can go to Operations -> Compact Archive to reduce the MPQ's size

Or, you can send me your patch-enGB-2.MPQ or patch-enGB.MPQ so I can modify your Spell.DBC, after which I send it back to you.

Thanks a lot for putting your mind to this problem!

If anyone else wants to have customized spells on his / her private server (or want to edit DBCs for more nefarious purposes... ), your help will be appreciated.

[schlumpf]

The "model editing" patch also gets you to edit DBCs. There is no additional check. Still, DBCs are checked for having the right number of columns. (and more? i think there was something else.. idk)

I really think - just like Josh - that you have ****ed "something" up. May you send me the original DBC and the one you have as output (lazy me, i could also scroll up, i guess)?

The order of the MPQs loaded is:
archiveNames.push_back( "common.MPQ" );
archiveNames.push_back( "common-2.MPQ" );
archiveNames.push_back( "expansion.MPQ" );
archiveNames.push_back( "lichking.MPQ" );
archiveNames.push_back( "patch.MPQ" );
archiveNames.push_back( "patch-{number}.MPQ" );
archiveNames.push_back( "patch-{character}.MPQ" );

// archiveNames.push_back( "{locale}\\backup-{locale}.MPQ" ); // These do not really contain any files we want.
archiveNames.push_back( "{locale}\\base-{locale}.MPQ" );
archiveNames.push_back( "{locale}\\locale-{locale}.MPQ" );
archiveNames.push_back( "{locale}\\speech-{locale}.MPQ" );
archiveNames.push_back( "{locale}\\expansion-locale-{locale}.MPQ" );
archiveNames.push_back( "{locale}\\expansion-speech-{locale}.MPQ" );
archiveNames.push_back( "{locale}\\lichking-locale-{locale}.MPQ" );
archiveNames.push_back( "{locale}\\lichking-speech-{locale}.MPQ" );
archiveNames.push_back( "{locale}\\patch-{locale}.MPQ" );
archiveNames.push_back( "{locale}\\patch-{locale}-{number}.MPQ" );
archiveNames.push_back( "{locale}\\patch-{locale}-{character}.MPQ" );

Therefore you should take the latest DBC from {locale}\patch-{locale}-2.MPQ (i guess).

(That code looks different in the client. They push a structure with additional flags like if the MPQ is loaded in a specific locale. Thats why its still capable of loading 1.* named MPQs if you do it right. It can also load development.MPQ (if the condition is filled.). But that list should be what's loaded on the average client.

[Itzamna]

Hello Schlumpf, thank you very much for your answer.

I have already tested the 'broken DBC' hypothesis, I told Cypher in an earlier post that this is not the case. By manually restoring Spell.dbc's fields to its official values, the game loads again.

Also, WoWMe.exe does not allow the loading of a customized Spell.dbc. When I have a custom Spell.dbc, placed in patch-enGB.MPQ or patch-enGB-2.MPQ, WoWMe.exe simply hangs. When just placing the custom Spell.dbc in patch-3.MPQ in the Data/ folder, it will still load the official DBCs.

Inside WoW.exe, there are checksum checks, this is certain. The file 'signaturefile', contained in common.MPQ and patch-2.MPQ, contains a list of files and checksums that belong to them. The checksums are not MD5, SHA-1, CRC32 or anything else I know, so it must be a nested checksum or they have their very own hash. I did manage to crack Wow.exe in such a way that it loads a custom signaturefile (!) but without knowledge of Blizzard's hash algorithm this is pretty much useless.

I think that the only possible way we are going to have a fully customized World of Warcraft experience, is to modify WoW.exe. In fact, private servers with custom items around the globe reported that after a certain patch (I'm researching which version it was) they could no longer modify Item.dbc to customize their items.

In a word - the only thing I can do right now is find out how Wow.exe works; it's a Tantalus torment if you just got into assembly programming.

Do you have any ideas, Schlumpf?

[kynox]

I just verified my theory by pulling out the Spell.dbc from the patch locale file, and the game loads it (from the original game files it has an incorrect number of columns).

What you want to do is patch the patch-locale-enGB.MPQ's Spell.dbc.