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 author=XeoN link=board=17;threadid=1987;start=0#msg15476 date=1058791335]
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?
[/quote]
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 author=Adron link=board=17;threadid=1987;start=0#msg15491 date=1058796487]
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]

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 author=Grok link=board=17;threadid=1987;start=0#msg15495 date=1058798292]
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]

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 author=Adron link=board=17;threadid=1987;start=0#msg15498 date=1058799831]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]

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 author=Camel link=board=17;threadid=1987;start=0#msg15527 date=1058816591]
[quote author=Adron link=board=17;threadid=1987;start=0#msg15498 date=1058799831]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]

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.
[/quote]
I think you should reconsider how you think CD-key validation works serverside, because you are, frankly, wrong.

[quote author=Skywing link=board=17;threadid=1987;start=0#msg15530 date=1058818129]
[quote author=Camel link=board=17;threadid=1987;start=0#msg15527 date=1058816591]
[quote author=Adron link=board=17;threadid=1987;start=0#msg15498 date=1058799831]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]

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.
[/quote]
I think you should reconsider how you think CD-key validation works serverside, because you are, frankly, wrong.
[/quote]

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 author=Camel link=board=17;threadid=1987;start=0#msg15538 date=1058823902]
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?
[/quote]
Sure:
[quote author=Camel link=board=17;threadid=1987;start=0#msg15527 date=1058816591]
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.
[/quote]

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 author=Skywing link=board=17;threadid=1987;start=0#msg15585 date=1058854203][quote author=Camel link=board=17;threadid=1987;start=0#msg15527 date=1058816591]
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.
[/quote]

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.
[/quote]

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 author=Camel link=board=17;threadid=1987;start=15#msg15592 date=1058859320]
[quote author=Skywing link=board=17;threadid=1987;start=0#msg15585 date=1058854203][quote author=Camel link=board=17;threadid=1987;start=0#msg15527 date=1058816591]
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.
[/quote]

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.
[/quote]

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]
Under certain circumstances, yes. You are completely missing how it works here.

[quote author=Camel link=board=17;threadid=1987;start=0#msg15527 date=1058816591]
[quote author=Adron link=board=17;threadid=1987;start=0#msg15498 date=1058799831]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]

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]

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.

[quote]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.[/quote]

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 author=DarkMinion link=board=17;threadid=1987;start=15#msg15612 date=1058883504]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]

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?

[quote author=Grok link=board=17;threadid=1987;start=0#msg15495 date=1058798292]
Visual Basics
[/quote]
-1.

[quote author=laurion link=board=17;threadid=1987;start=15#msg15906 date=1059059287]
[quote author=Grok link=board=17;threadid=1987;start=0#msg15495 date=1058798292]
Visual Basics
[/quote]
-1.
[/quote]

Nothing gets past you!!
+1