CD-Key Validation

[XeoN]

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?

[Tazo]

just check ur cd-key decoding function ^^;

[XeoN]

My bot is a CSB, there is no decoding function.

[Eternal]

Then you'll need to add one...

[______]

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?

[XeoN]

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.

[Adron]

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.

[Grok]

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.

[Adron]

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

[Camel]

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

[Skywing]

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.

I think you should reconsider how you think CD-key validation works serverside, because you are, frankly, wrong.

[Camel]

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.

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?

[DarkMinion]

The words cannot be found to express your stupidity.  Can't we ban Camel once and for all?

[Skywing]

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:

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.

[Adron]

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.