Would it be possible to take the function(s) used to encrypt & get the 3 values from a CDKey, and reverse them - What I mean by this, is the reversed function(s) takes the 3 key values, hashed cdkey data (5 dwords), server key, client key, and it results in the actual CDKey?

Must be possible, the server knows your CDKey - If they don't, what the hell, because a rep can tell you if the CDKey you're telling them is the CDKey you used to create your account

Edit: Forgot to include server key (iago :P)

I think it's possible if you know the server key, client key, product, and key hash to BF it..

[quote author=UserLoser. link=board=17;threadid=4517;start=0#msg37651 date=1072821503]Would it be possible to take the function(s) used to encrypt & get the 3 values from a CDKey, and reverse them - What I mean by this, is the reversed function(s) takes the 3 key values, hashed cdkey data (5 dwords), server key, client key, and it results in the actual CDKey?[/quote]

Probably so, but I don't see why it'd really be necessary to do that. If you have the product code, magic number, and secret number, then you can convince the server you have the key whether you know the text of the key or not. So, the rep might just feed the key you give him into a command-line key decoder and compare what it prints out with the saved magic in your user data. Neither the product code nor secret need be saved; a bad product code would've prevented logon, and a bad secret would've banned you. So, only the magic needs actually be checked.

[quote author=Kp link=board=17;threadid=4517;start=0#msg37654 date=1072823090]
Probably so, but I don't see why it'd really be necessary to do that. If you have the product code, magic number, and secret number, then you can convince the server you have the key whether you know the text of the key or not. So, the rep might just feed the key you give him into a command-line key decoder and compare what it prints out with the saved magic in your user data. Neither the product code nor secret need be saved; a bad product code would've prevented logon, and a bad secret would've banned you. So, only the magic needs actually be checked.
[/quote]

Makes sense...

Well then (because i'm curious), what about the functions used to hash a password when creating an account - those don't require any client/server keys/"magic" numbers/codes, just a password to encrypt to 5 DWORDs. Can anyone with great math skills please do me a favor and reverse the functions? ;)

Or, explain how a battle.net server gets the password (or whatever it saves) out of it?

A regular old battle.net server saves the hash you send it when you set the password. That's all it needs to verify your later logons using that password.

It's very possible to create a function that makes a CD key from it's values. I have written such a function. (How do you think Blizzard do it?) It's not possible to write a function to retrieve a password from a hash - at least not mathematically. A hash (In this case, broken SHA-1) is by it's very nature one-way. You could, of course, brute-force it.

FYI, brute-forcing a Starcraft CD key hash from a packet such as SID_AUTH_CHECK, assuming you have the tokens and public value, is trivial. It can be accomplished in well under a second. The tokens and public value are generally easily available, since they're transmitted plain - if you have the hash, you're likely to have the rest. A Diablo 2 or Warcraft 2 key would take a little longer, but it's still trivial.

The moral of the story: be careful who you give your packet captures to :)

[quote author=Adron link=board=17;threadid=4517;start=0#msg37664 date=1072826879]
A regular old battle.net server saves the hash you send it when you set the password. That's all it needs to verify your later logons using that password.[/quote]

To extend and clarify on this: when you create an account, you send the one-pass hashing of your password. The server saves this with your account data. When you attempt to log on, your client computes a one-pass hash of your password (which is the same exact data as what the server has stored), then hashes *that* with the cookies and sends the result + client cookie. The server loads up the one-pass hash from your account information, and computes the second-phase hash based on the saved first-phase and the cookies. If the second phase you sent matches the second phase it computed, it is very very likely you have the right password, so it lets you on.

Anyone care to explain this, except with the "NLS" - WAR3/W3XP