CD-Key Validation

[Camel]

I don't think checksum is an accurate description of the two DWORDS; the two numbers uniquely identify the key to battle.net, and can be reversed to produce a cd key relatively easily. Try doing that with a checksum.

I think that it should be immediately obvious to you and to anyone else why this statement is completely incorrect.

If not, maybe you should look up the concepts behind a checksum.  I think that's about as strong as a hint as I can give without giving the whole thing away.

So if I were to give you the checksum of any random file you could relatively easily return the file in full, eh? Now that's fucking impressive.

Look Skywing, I understand that it technicly qualifies as a checksum, but I was pointing out that it is not really used as a checksum, and here's why: A checksum is used to verify that a file or data is correct without having to send the entire thing. In the case of the cd key however, any cd key can be described by three DWORDS. It's simiply not possible to identify anything one could imagine by such a small ammount of data.

Perhaps it would be more accurate to call the cd key a text representation of the three DWORDS than the three DWORDS a checksum of the cd key. Note how I didn't say it's not a checksum, as it is.

[Skywing]

I don't think checksum is an accurate description of the two DWORDS; the two numbers uniquely identify the key to battle.net, and can be reversed to produce a cd key relatively easily. Try doing that with a checksum.

I think that it should be immediately obvious to you and to anyone else why this statement is completely incorrect.

If not, maybe you should look up the concepts behind a checksum.  I think that's about as strong as a hint as I can give without giving the whole thing away.

So if I were to give you the checksum of any random file you could relatively easily return the file in full, eh? Now that's fucking impressive.

Look Skywing, I understand that it technicly qualifies as a checksum, but I was pointing out that it is not really used as a checksum, and here's why: A checksum is used to verify that a file or data is correct without having to send the entire thing. In the case of the cd key however, any cd key can be described by three DWORDS. It's simiply not possible to identify anything one could imagine by such a small ammount of data.

Perhaps it would be more accurate to call the cd key a text representation of the three DWORDS than the three DWORDS a checksum of the cd key. Note how I didn't say it's not a checksum, as it is.

Under certain circumstances, yes.  You are completely missing how it works here.

[Adron]

You are slightly off because C++ defaults to "on error resume next" for 95% of the errors. The remaining ones (null pointers etc) I suppose would be easier to ignore in VB6, but then, it won't help you send a cdkey with an invalid checksum to b.net

I don't think checksum is an accurate description of the two DWORDS; the two numbers uniquely identify the key to battle.net, and can be reversed to produce a cd key relatively easily. Try doing that with a checksum.

[edit] make that 3 dwords; product id, value1, and value2

Note that I'm not calling all those dwords a checksum. And note #2 that the checksum I'm talking about is never sent to b.net. Think for a while and realize that if the checksum is never sent to b.net, then you won't be sending an invalid checksum to b.net either. Interestingly enough, there's more than one checksum involved, and Skywing is probably talking about the other checksum. Or possibly the third. Those aren't really checksums though, because a checksum doesn't have the properties that those two "checksums" have. One of them is better called hash, and the other one I'm uncertain about. If it was simply a checksum we would probably have lots of keys though.

[DarkMinion]

Look Skywing, I understand that it technicly qualifies as a checksum, but I was pointing out that it is not really used as a checksum, and here's why: A checksum is used to verify that a file or data is correct without having to send the entire thing. In the case of the cd key however, any cd key can be described by three DWORDS. It's simiply not possible to identify anything one could imagine by such a small ammount of data.

You're assuming that battle.net converts the checksums into an actual string cdkey and checks it that way...

How are you so entirely sure that's how it is done?

I'm with Sky here, you aren't understanding the basic concept here...

[Camel]

You're assuming that battle.net converts the checksums into an actual string cdkey and checks it that way...

How are you so entirely sure that's how it is done?

I'm with Sky here, you aren't understanding the basic concept here...

If I implied that, I am sorry. I would bet a lot of money that the battle.net servers store no solid record of the cd keys, and make no attempt to produce cd keys. I was merely pointing out on a side-note that it's not the classic checksum because it is possible to produce a cd key from the three values.

As I tried to explain, it would be much more feasable for battle.net to look at the ProductID and Value1 sent in plain text, and find the matching Value2. Everything is hashed for security -- let's set that aside. Pretend all three DWORDS are sent in plain text: The goal would be to send three DWORDS such that the (going out on a limb here for the sake of argument) table battle.net has which matches the ProductID and Value1 with the correct Value2 contains a row where all three values are the same as those sent by the client.

Here's why this makes sense:
Battle.net needs only to check if the client's Value2 is the same as the (for the sake of argument) Value2 in the one entry in its database of ProductID-Value1-Value2 where ProductID and Value1 are the same as sent by the client.

How it's done:
The hash sent is derrived from the following public values: ClientKey, ServerKey, ProductID, Value1, Zero, and the following private values: Value2

Both the server and the client definately have the exact same everything except Value2. If the hash send by the client matches the one the server produces with the correct cd key, there is an extremely high -- possibly certain -- chanse that the key is valid for battle.net.


Side note: It is possible that multiple valid cd keys could share the same ProductID and Value1. It is also possible that certain ProductID-Value1 combinations have no valid Value2. In the case of multiple Value2s, battle.net would need to perform multiple hashes and check for at least one which was vaild. I do, however, find this unlikely as I suspect that Value1 is an ID and Value2 is a password.


[edit] "...servers...makes no attempt..."

[DarkMinion]

*sigh*

It's like trying to break down a steel door with a nerf bat.

[Camel]

Are you going to explain, or just be pretentious?

[Adron]

The hypothesis accepted by most people so far is that value1 is a sequential id number and value2 is calculated from a function that takes value1/productid as inputs - value2 is a checksum or hash.

If you doubt that, consider the size of the lookup table that would be required to validate cd keys. Also, testing has indicated that productid/value1 uniquely identifies a cd key - there is exactly one valid value2 for a particular productid/value1 combination.

Now, can you tell me which the three checksums/hashes involved in parsing/validating and sending a cd key to b.net are?

[Camel]

I've never heard anybody say that Value2 is a checksum of ProductID and Value1. I suppose that could work, but my point that calling ProductID+Value1+Value2 a checksum of the raw cd key is misleading is still valid.

[Adron]

From what I've seen, you're the only one who has talked of product+value1+value2 as a checksum of the cd key. That's why everyone else has thought you made absolutely no sense?

[Tazo]

Visual Basics

-1.

[Grok]

Visual Basics

-1.

Nothing gets past you!!
+1