I would like to add a feature to my bot that tells the user if the CD-Key is valid or invalid for install. That way, the user could avoid IP Banning.
How would I go about doing this? I saw DarkMinion post something about this but it was in C++. Would it be possible for someone to convert this to Visual Basic 6?
just check ur cd-key decoding function ^^;
My bot is a CSB, there is no decoding function.
Then you'll need to add one...
Quote from: XeoN on July 21, 2003, 07:42 AM
I would like to add a feature to my bot that tells the user if the CD-Key is valid or invalid for install. That way, the user could avoid IP Banning.
How would I go about doing this? I saw DarkMinion post something about this but it was in C++. Would it be possible for someone to convert this to Visual Basic 6?
Avoid IP banning, How do you do that?
Easy, you connect without using an invalid CD-Key. Surly you know Battle.net IP bans you when you connect with an invalid CD-Key.
You can't do that. A cd key that is invalid for installing cannot be sent to battle.net at all - the invalidity doesn't transfer.
Quote from: Adron on July 21, 2003, 09:08 AM
You can't do that. A cd key that is invalid for installing cannot be sent to battle.net at all - the invalidity doesn't transfer.
What are you talking about? Visual Basics makes everything easy. If something doesn't work in C+, switch to VB6 and insert "ON ERROR RESUME NEXT" everywhere you have a problem.
Quote from: Grok on July 21, 2003, 09:38 AM
What are you talking about? Visual Basics makes everything easy. If something doesn't work in C+, switch to VB6 and insert "ON ERROR RESUME NEXT" everywhere you have a problem.
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 :P
Quote from: Adron on July 21, 2003, 10:03 AMYou 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 :P
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
Quote from: Camel on July 21, 2003, 02:43 PM
Quote from: Adron on July 21, 2003, 10:03 AMYou 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 :P
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 you should reconsider how you think CD-key validation works serverside, because you are, frankly, wrong.
Quote from: Skywing on July 21, 2003, 03:08 PM
Quote from: Camel on July 21, 2003, 02:43 PM
Quote from: Adron on July 21, 2003, 10:03 AMYou 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 :P
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 you should reconsider how you think CD-key validation works serverside, because you are, frankly, wrong.
The server looks at the ProductID and Value1 the client sends, and looks at between one and some other small number of Value2s that it has matching that ProductID and Value1. It then hashes all of the matching Value2s with the appropriate salt (ClientSeed, ServerSeed, ProductID, Value1, 0). The result of the hashes are compared to the hash the client sent. If any of them match, the server knows that the client's Value2 matches Value1 and ProductID, and therefore is a valid battle.net cd key.
Care to explain how wrong I am, oh mighty one?
The words cannot be found to express your stupidity. Can't we ban Camel once and for all?
Quote from: Camel on July 21, 2003, 04:45 PM
The server looks at the ProductID and Value1 the client sends, and looks at between one and some other small number of Value2s that it has matching that ProductID and Value1. It then hashes all of the matching Value2s with the appropriate salt (ClientSeed, ServerSeed, ProductID, Value1, 0). The result of the hashes are compared to the hash the client sent. If any of them match, the server knows that the client's Value2 matches Value1 and ProductID, and therefore is a valid battle.net cd key.
Care to explain how wrong I am, oh mighty one?
Sure:
Quote from: Camel on July 21, 2003, 02:43 PM
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.
You should also note the difference between a cd key invalid to the installer and a cd key invalid to battle.net. Plenty of cd keys are valid for playing single player but invalid for battle.net use.
Quote from: Skywing on July 22, 2003, 01:10 AMQuote from: Camel on July 21, 2003, 02:43 PM
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.
Quote from: Camel on July 22, 2003, 02:35 AM
Quote from: Skywing on July 22, 2003, 01:10 AMQuote from: Camel on July 21, 2003, 02:43 PM
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.
Quote from: Camel on July 21, 2003, 02:43 PM
Quote from: Adron on July 21, 2003, 10:03 AMYou 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 :P
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.
QuoteLook 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...
Quote from: DarkMinion on July 22, 2003, 09:18 AMYou'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..."
*sigh*
It's like trying to break down a steel door with a nerf bat.
Are you going to explain, or just be pretentious?
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?
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.
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?