Understanding how hashing works

[Soul Taker]

How is the Server key used to hash password / cdkey

The server key is included in the digest to be hashed, which would also contain the password or CD-Key.  I think the server key is just a random value, determined by the server.

How Can starcraft/Diablo2 use NLS Revison 0x01?.. lost me there

They both contain support for NLS revision 1, but since the server does not tell them to use it as of right now, you probably will never see it happen.

What exactly is the FILETIME used for?

It is used to determine if the file already present on your hard drive is the same as the one the server is telling you to use.

I STill don't understand what Server Signature is.

The server signature is checked by WAR3/W3XP.  I don't know the forumla used to check it, but if the signature does not match the IP of the server that the client is connected to, the client will abort the connection.  I can only assume this is to prevent people from proxying War3 connections.

HTH

Edit: somehow deleted your question about the checksum.  It's used to make sure the client version matches what the server thinks it should be.

[BaDDBLooD]

And than you send all this in 0x51?

Would someone give me a Rough Explination of 0x51, what you have to send, how you do it.

[Soul Taker]

Check it out in http://www.valhallalegends.com/yoni/BNLSProtocolSpec.txt

[BaDDBLooD]

Code Select Expand



(DWORD) Client session key.*
(DWORD) Version.**
(DWORD) Checksum.**
(DWORD) Amount of CD-keys. This is typically 2 for Lord of Destruction, 1 otherwise.***
(BOOL) TRUE for spawn (Starcraft, Japan Starcraft and Warcraft 2 only), FALSE for normal.
(9 DWORDs) CD-key data.*
(Optional 9 DWORDs) CD-key data for second CD-key, if using Lord of Destruction.***
(String) Version check stat string.**
(String) CD-key owner name.




Ok so

Client Session Key, is Telling the server who you are, Right?
What the heck is Version

How do you Calculate Checksum.  Do you just Plug in all the Numbers for Hash COmmand along with S ( Which is from Storm.DLL ) And that's what you send??

What is the 9 DWORD'S of CDKey Data?
Version Check statstring?

[iago]

To quibble with semantics, SRP also uses SHA-1.  But not broken.  

The idea of SHA-1 (for the original login) is this:
The server makes a random key.  The client makes a random key.  The keys are exchanged.  The client hashes the password along with the 2 values, and the server hashes the password with the 2 values.  If they match, the password was right.  SHA-1 allows the password to be sent securely.  It's a "one way hash".  SRP is basically a more complicated version of this whole thing, which you can find out if you read that site.

That's all about the password hashing and verification.   The CDKey stuff is different, and we can discuss that more later, if you'd like

[BaDDBLooD]

Thank you iago, you explained it exactly how i needed it explained.  Thanks a bunch!

I Would greatly like to learn about the cdkey stuff

EDIT: We could talk on AIM

EDIT #2: It would probly be more Beneficial to talk on here though.

EDIT #3: About your above post.  Do you mean like Me sending them a Client Token, and them sending me a Server Token?

EDIT #4: Still need help with Version Etc..

[OnlyMeat]

Not very related, but if true could change a lot:
http://www.freedom-to-tinker.com/archives/000661.html

I Doubt that is true tbh sha-1//md5 are the most widely used on the internet, and they are also the most secure, well they were.

Of course better algorithms are out now but as noted they are just variations upon the same algorithms.

[iago]

Not very related, but if true could change a lot:
http://www.freedom-to-tinker.com/archives/000661.html

I Doubt that is true tbh sha-1//md5 are the most widely used on the internet, and they are also the most secure, well they were.

Of course better algorithms are out now but as noted they are just variations upon the same algorithms.

I have heard rumours that there are weaknesses, and I have also heard rumours that the last person who was going to go public with it disappeared.  Rumours are fun.

Badd -- contact me on IM.  If you learn anything, post the log here

[Soul Taker]

Not very related, but if true could change a lot:
http://www.freedom-to-tinker.com/archives/000661.html

I Doubt that is true tbh sha-1//md5 are the most widely used on the internet, and they are also the most secure, well they were.

Of course better algorithms are out now but as noted they are just variations upon the same algorithms.

SHA-0 has already been broken (http://www.mail-archive.com/cryptography%40metzdowd.com/msg02554.html), so it seems to me like SHA-1 shouldn't be far behind.

[Arta]

I didn't notice the second page before I typed all this  

ho hum!

> How is the Server key used to hash password / cdkey

It's included in the hash along with the data that you're hashing. It's a way of ensuring that the hash of your password/cdkey is different every time you send it. If there were no server key (which changes each time you log on) then the hash would be the same every time you logged on, which would make it much easier to brute-force your logon information from the hash. I'm ignoring the client key here, but it serves essentially the same purpose.

>How Can starcraft/Diablo2 use NLS Revison 0x01?.. lost me there

The games include code to log on using that method, as well as the normal method. IIRC, the NLS/SRP code in star/d2dv is quite outdated and would probably not work in its current state.

> What exactly is the FILETIME used for?

When you recieve the packet, you should check your local copy of the versioning dll, to see if it has the same filetime as is in the packet. If that time is different (read: newer) it means that a new version dll is available and the client should download it before proceeding with CheckRevision().

> What is the Checksum used for that comes from the hash command?

I think you're referring to the hash returned by CheckRevision here, although I'm not sure. If that's what you mean: That hash is used by battle.net to ensure that your game files have not been modified. The reason that Blizzard uses CheckRevision and not a standard hashing algorithm is that each version dll (ix86ver0, ver1, ver2, ...) is slightly different, and so produces a slightly different hash. This, presumeably, is to make the logon process harder to emulate.

> I STill don't understand what Server Signature is.

The server signature is used to ensure (in theory) that you are connecting to a Blizzard server. Some data about the server (Presumeably the IP address) is cryptographically hashed by Battle.net and sent to the client. The client then does the same and ensures that the signatures match. I'm not really sure about the details, but so far as I know, this is basically the same as digitally signing something. This is what (used to?) prevent Warcraft III from connecting to non-Blizzard servers without being cracked.

[ChR0NiC]

I definitely think this should be a candidate for the Battle.net Reference area of the forum

[BaDDBLooD]

Ok, After talking with iago on aim.  I Still have a few more questions.

1) What Exactly does Check Revision Do?

2) Why do you have to "Decode" The CDKey, how do you Decode it?  What is the Public CDKey Value? and Hashed CDKey Data that you send in 0x51?

[Eibro]

Ok, After talking with iago on aim.  I Still have a few more questions.

1) What Exactly does Check Revision Do?

2) Why do you have to "Decode" The CDKey, how do you Decode it?  What is the Public CDKey Value? and Hashed CDKey Data that you send in 0x51?

CheckRevison does many things. Firstly, it calculates a version value (DWORD) from the exe's version information resource. Second, it builds a string containing information about the exe (last write time/file size) and thirdly, it creates a hash value using information from all three files (war3.exe/storm.dll/game.dll). All three of these computed values must match those calculated by Blizzard.

Basically, it checks if the clients game files are up to date and/or not modified in any way. (For example, if you modify the exe so you don't have to insert a CD to play, CheckRevision will return incorrect values and you'll be disconnected apon sending its results.)

[Flame]

CheckRevision basically returns information from the hash files to be sent during 0x51, and they would be the 2nd and 3rd DWORDs.  The CheckRevision source is available at the Botdev Source Code Download page if you want to actually see how it works.

The decoded CdKey information is sent during 0x51 as: Product, CDKEY Value 1, and Hashed Key Data, which can be found in the below structure of 0x51 (courtesy of Bnetdocs ).

Code Select Expand


[0x51 Sent]
(DWORD)       Client Token
(DWORD)       Version
(DWORD)       Checksum
(DWORD)       Number of keys in this packet
(BOOLEAN)        Using Spawn
-- For Each Key:
(DWORD)       Key Length
(DWORD)       Product
(DWORD)       CDKEY Value 1
(DWORD)       Unknown (0)
(DWORD[5])       Hashed Key Data
-- Continued...
(STRING)       Exe Information
(STRING)       CD Key owner name


The actual hashing however, is usually done with a few functions, if you're able to find the bnetauth source, it contains the functions required for hashing, as well as the CheckRevision.  If you use BNLS though, you're not going to have to worry about the actual hashing functions.

[Arta]

2) Why do you have to "Decode" The CDKey, how do you Decode it?  What is the Public CDKey Value? and Hashed CDKey Data that you send in 0x51?

CD keys are encoded to make them easier to enter when you install the game. Also, probably, to obfuscate them. The key encoding is also what is checked by the installer - it only knows if the cd key is properly encoded, not if it is actually valid. This is why any number of silly values will get past the installer, but not onto battle.net. The actual values in the key - the public, private, and product values - are what are encoded. In a starcraft key, they occupy all the digits except the last one. The last digit is a check digit, and the value of that digit is what the installer verifies.

The public, private, and product  values are what Battle.net checks. Put simply, when you encode your CD key, you use lots of information that is known by Battle.net and you (product, public, client/server tokens) and one thing that only you know (your private value). When you send your hash to Battle.net, Battle.net runs some (unknown) algorithm on the public value of your key, which yields the private value. Battle.net then re-hashes all the data it already knew about, along with the private value it calculated, and compares the hashes. If they are different, that means that your private value is wrong, and your key is invalid. What prevents key generators from making working keys for Battle.net is the fact that we don't know this algorithm.