Auth Proof CRC Hash

[Damocles the Elder]

I was perusing the MaNGOS source and noticed that there are some unknown fields on the auth_challenge and auth_proof structs; From looking at other resources, I've found that there's a 16 byte CRC Salt sent from the server to the client and the client returns a 20 byte CRC hash back to the server. I'm assuming the hash is a sha1 hash since it's 20 bytes and pretty much everything else is sha1, but I've made zero progress on figuring out how exactly the CRC is generated. I realize none of the servers check this or anything, but it's relevant to my interests- If anyone could shed some light on this, I'd be much obliged.

[Clain]

uniX made an IDA script to pull the CRC hash out of the client... can't find it anymore though. Spurous has the crc check stuff implemented though; hasn't changed in a long time so it still probably works(you need to update the addresses though).

[Glusk]

First of all I am sorry for bumping up an old thread, but since there is still no concrete answer to the original question, it just seemed wrong to open another.

I thought I would start with some of my findings on the topic and then perhaps someone else can fill in the missing pieces of the puzzle.

Here is what I have found so far via google:

• crc_hash = SHA-1(A, HMAC(some_game_files))
• the key (or seed) to HMAC is sent to the client by the server one packet earlier
• some_game_files is something that different sources refer to differently;
  
  • for SpuriousEmu these are WoW.bin, DivxDecoder.bin and Unicows.bin **
  • boogiebot packs various (and also nowhere specified and thus unknown) files into hash.bin
  • Trinity-Encore says these are WoW.exe and Unicows.dll, although they do not implement this check at all

My problem with that is that it does not work for me. I am connecting to my own auth server with the 3.3.5(12340) enUS client and the value computed at the server is different from what my client is sending me. I have tried all the different combinations of the files used by my sources but nothing has wroked. It is either that I am reading the files in a wrong way (see the Spurious note at the bottom) or the whole procedure is erroneous - after all the code written for this check is not actually used anywhere by any of the projects above.

Normally I try to contact the code writers when in doubt, but I have been unsuccessful so far as the above 3 projects are mostly retired and the actual coders made sure to leave no e-mails behind (not in the code itself and not anywhere on the repositories). If anyone knows anyone who has worked on any of those projects, some contact info would be much appreciated.

Here is a code snippet of my implementation in Java - perhaps a beginner's mistake was made by me as the procedure is trivial:

//---------------------------------------------------------------------
// This will ofc. not compile and is just meant to better illustrate my 
// procedure and perhaps expose any errors on my side.
try {
	Mac hmac = Mac.getInstance("HmacSHA1");
	
	// Use a fixed HMAC key (which is also sent to the cleint), for debugging:
	SecretKeySpec key = new SecretKeySpec(
		new byte[]{45, -9, 78, 33, 45, 78, -12, 102, 45, -34, 91, 105, 125, -34, -90, 46}, "HmacSHA1");
	hmac.init(key);
	
	String path = "<path_to_WorldOfWarcraft/>"
	BufferedInputStream bis = new BufferedInputStream(new FileInputStream(path+"Wow.exe"));
	byte[] temp = new byte[10000000];
	int len = bis.read(temp, 0, temp.length);
	hmac.update(temp, 0, len);
	System.out.println(len);
	
	
	bis = new BufferedInputStream(new FileInputStream(path+"DivxDecoder.dll"));
	len = bis.read(temp, 0, temp.length);
	hmac.update(temp, 0, len);
	System.out.println(len);
	
	
	bis = new BufferedInputStream(new FileInputStream(path+"unicows.dll"));
	len = bis.read(temp, 0, temp.length);
	hmac.update(temp, 0, len);
	System.out.println(len);
	
	byte[] fileHMAC = hmac.doFinal();
	
	// H(A, fileHMAC)
	MessageDigest md = MessageDigest.getInstance("SHA-1");
	md.update(this.srpA); //srp A field of Auth Logon Proof sent by the client 
	md.update(fileHMAC);
	byte[] rez = md.digest();
	
	// Output results
	System.out.println("My result:");
	System.out.println(java.util.Arrays.toString(rez));
	System.out.println("WoW.exe result:");
	System.out.println(java.util.Arrays.toString(this.crcHash));
}
catch (Exception e) {
	System.out.println("Error!");
	e.printStackTrace();
}
//---------------------------------------------------------------------

I think that is enough material for not only avoiding a wall of text, but also proving that I have done my homework and am not asking for "spoon feed".

---

->If anyone is having trouble finding code snippets of crc_hash generation of the 3 (basically 2) projects I was referencing, these can also be added to this post, although I think my summary should suffice.

->Random link (archived on Wayback Machine) that I have found while googling - I just felt like linking it here to have all references at one place + it contains a packet structure of the auth proof (C -> S).

->**Note from Spurious implementation:

WoW.exe and DivxDecoder.dll are loaded from pieces of data, while Unicows.dll is normal full file loading.
This is supposed to be a hint as to how one goes by, producing the *.bin file counterparts. I have no idea what is meant by "loaded from pieces of data" - which pieces?!

[TOM_RUS]

Wow.exe and DivxDecoder.dll hashed using some parts of the file (the function that does that is somewhat complicated, so it's easier to just dump it's output) and unicows.dll hashed as is.

data.zip ? RGhost ? file sharing data it hashes in one file dumped from 3.3.5.12340 client.
Dump log: http://paste2.org/AG79LV0K

[Glusk]

Wow.exe and DivxDecoder.dll hashed using some parts of the file (the function that does that is somewhat complicated, so it's easier to just dump it's output) and unicows.dll hashed as is.

data.zip ? RGhost ? file sharing data it hashes in one file dumped from 3.3.5.12340 client.

There seems to be something wrong, because I am still unable to match the client's crc_hash. Perhaps my files are different from yours or currupt?
My files:

• Wow.exe [CRC32: 0xB8D98B75]
• DivxDecoder.dll [CRC32: 0x392A474E]
• unicows.dll [CRC32: 0x69C12840]

The above chechsums are computed by the CRC32B on-line generator

[TOM_RUS]

There seems to be something wrong, because I am still unable to match the client's crc_hash. Perhaps my files are different from yours or currupt?
My files:

• Wow.exe [CRC32: 0xB8D98B75]
• DivxDecoder.dll [CRC32: 0x392A474E]
• unicows.dll [CRC32: 0x69C12840]

The above chechsums are computed by the CRC32B on-line generator

Your files are exactly same.

        public void Test()
        {
            byte[] key = new byte[] { 0x00, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88, 0x99, 0xAA, 0xBB, 0xCC, 0xDD, 0xEE, 0xFF };

            HMACSHA1 hsha1 = new HMACSHA1(key);

            byte[] A = ToArray("669AC246E58F17DD297D261F9F06DFF38B3DFB2E3541A5F2C7CC973E751B1776").Reverse().ToArray();

            SHA1Managed sha1 = new SHA1Managed();

            byte[] filesHash = hsha1.ComputeHash(File.ReadAllBytes("data.bin"));
            byte[] mycrc = sha1.ComputeHash(A.Concat(filesHash).ToArray());

            byte[] clientcrc = ToArray("35841EF1195CAD3D8E3AC3C16FE5692BBCEBF2F3").Reverse().ToArray();

            bool match = true;

            for (int i = 0; i < mycrc.Length; i++)
            {
                if (mycrc[i] != clientcrc[i])
                {
                    match = false;
                    break;
                }
            }

            if (match)
                MessageBox.Show("matches :)");
            else
                MessageBox.Show("nope :(");

            //[AuthChallenge] CRC Proof: 35841EF1195CAD3D8E3AC3C16FE5692BBCEBF2F3
            //[AuthChallenge] SRP A: 669AC246E58F17DD297D261F9F06DFF38B3DFB2E3541A5F2C7CC973E751B1776
        }

        private byte[] ToArray(string hex)
        {
            int NumberChars = hex.Length;
            byte[] bytes = new byte[NumberChars / 2];
            for (int i = 0; i < NumberChars; i += 2)
                bytes[i / 2] = Convert.ToByte(hex.Substring(i, 2), 16);
            return bytes;
        }

Works fine for me.

When running client in debugger with INT3 breakpoint set, client returns different hash.

[Glusk]

It works! I was updating my hash with SRP A in the wrong byte order (Little Endian instead of Big Endian).
@TOM_RUS Thanks alot for both the game files zip and this code sample which really helped. +REP

[nerexis]

Your posts really helped me, but please reupload data.zip file. Thanks

EDIT:
Is variable unk3[16]; in this packet, the crc hash sent to client?
http://arcemu.org/wiki/Server_Logon_Challenge

[Glusk]

Your posts really helped me, but please reupload data.zip file. Thanks

The file has been re-uploaded here!

EDIT:
Is variable unk3[16]; in this packet, the crc hash sent to client?
ArcEmu-Wiki has a problem

No.
Those are the HMAC seed bytes (aka key, secret key).
Note: the link is dead, here is the archived version

[shenhuyong]

The file has been re-uploaded here!



No.
Those are the HMAC seed bytes (aka key, secret key).
Note: the link is dead, here is the archived version

The link is dead, please reupload data.zip file again. Thanks a lot.
TrinityCore has implemented additional version check for modified clients after commit 250fcc8970842e3e8c6b48c15ed3b7c8ba240df1, so I'm trying to make it work for a custom wow.exe.

[stoneharry]

The link is dead, please reupload data.zip file again. Thanks a lot.
TrinityCore has implemented additional version check for modified clients after commit 250fcc8970842e3e8c6b48c15ed3b7c8ba240df1, so I'm trying to make it work for a custom wow.exe.

You can also disable that extra verification in config.