Valhalla Legends Archive

Quote from: Camel on October 23, 2009, 03:46 PM

Quote from: Strilanc on October 23, 2009, 01:29 PM
I believe the private is not related to the public key mathematically, it is just generated randomly. Blizzard stores all the information on cd keys it has generated, so when you connect to bnet they can lookup your private key given the public key.

That's extremely unlikely, considering there's a huge amount of evidence that the relationship is algorithmic. I don't recall all the details exactly, but there has been a great deal of work put in to studying the relationship, and someone was able to come up with code that generated a battle.net-acceptable SC key about 5% of the time. If it was truly random, they either used a really shitty random number generator, or all the moons were just perfectly aligned.

Really, the only way to know would be to ask someone who implemented it, but you'd have to be pretty crazy to believe that they're random.

I was speaking specifically about the warcraft 3 cd keys. I've never done anything with starcraft keys. They may have switched strategies, but I can't speak about it with any confidence. Obviously I agree if you can generate a valid wc3 key a twentieth of the time then the private key isn't random, since if it was random your success rate would be more like one out of a trillion trillions.

Quote from: Camel on October 23, 2009, 03:58 PM

Quote from: Strilanc on October 23, 2009, 01:36 PM
Because the battle.net check is significantly stronger.

This is sort of misleading; the installer just checks that the key is decodable, and is for the product - like buying a car on ebay based on the picture looking like a car instead of a motorcycle, but without starting it up to see if it runs. When you send the 3 DWORDs to Battle.net, it checks that the private key matches the other two values according to whatever algorithm they used to generate the CD keys in the first place.

Sort of going off on a tangent here, but the private value from the cd key is never sent in plain text; it's hashed (BS1) with 32 bits of salt from the client, and 32 more from the server, to protect the key from being sniffed off the wire. It's a pretty weak security measure, since it only takes a few hours in the worst case to brute the private key (it's only a 32-bit value) with a poor implementation of BS1 and a slow computer.

Right. I'm aware of all that. Actually, I once wrote something so you could "lend" your keys to someone. Because the login process doesn't reveal the private key, you can just answer the login challenges for them. The key is "returned" once they log off.

Quote from: Imperceptus on October 23, 2009, 01:32 PM
myst,
Then how do you equate that there are cdkey generators that generate valid codes to install the game but not to bet onto battle.net?

Because the battle.net check is significantly stronger. Also, if the private key is randomly generated, then there is no practical way to verify a generated key will work other than connecting to bnet and trying it.

Generating an installer cd key only requires starting with a correct product id, arbitrary public/private keys, and running the encoding process backwards.

Quote from: rabbit on October 23, 2009, 08:43 AMNot really.  There's a lot of it.

But basically, you don't need to disassemble anything these days.  There is code out there for checking CD-Keys in Python, Java, C, C++, C#, VB.Net, JavaScript, and PHP (at least).

You're also trying to tell Camel how the private, public, and product values work.  He's got significantly more experience with this stuff than you do.

Right, which is why I made a post asking for a link instead of starting a disassembler.

I was telling Camel how I believed the values work, so that the answer I got back would explain what I was missing. It worked.

Quote from: Imperceptus on October 23, 2009, 11:45 AM
Correct me if im wrong, but weren't the keys that work generated and stored, amongst those a % of them flagged to be accepted on bnet? 

Apparently the installer accepts any cd key with the correct product key. Bnet requires a correct product key as well as a correct public/private key pair. When you connect the public key is used to identify your cd key while the private key is used to authenticate it.

I believe the private is not related to the public key mathematically, it is just generated randomly. Blizzard stores all the information on cd keys it has generated, so when you connect to bnet they can lookup your private key given the public key.

Quote from: rabbit on October 22, 2009, 07:49 AMYou've got a lot to learn.

Could you be more specific?

Quote from: Camel on October 21, 2009, 01:46 PM
Look at the product id.

I see, so you're saying the product id *is* the checksum. I hadn't considered that part. I figured part of the private key was a checksum.

Thanks.

Quote from: Camel on October 21, 2009, 01:42 PM

Quote from: Strilanc on October 21, 2009, 01:26 PM
That is code for extracting the public/private/product values from a cd key. It is needed for bnet login, and is probably involved in verifying the key, but doesn't actually perform verification.

If you say so.

Would you care to point out the line where they verify the checksum?

Quote from: rabbit on October 21, 2009, 10:40 AM
Make one yourself?  It's hard to make a typo in a string that is 26 characters long and has no single proper spelling.

Making one myself would require disassembling the installer, and finding the code which verifies the key. That's a lot of work which may have already been done, which is why I'm posting the request.

Quote from: Camel on October 21, 2009, 11:39 AM
http://code.google.com/p/bnubot/source/browse/trunk/BNUBot/src/org/jbls/Hashing/War3Decode.java

That is code for extracting the public/private/product values from a cd key. It is needed for bnet login, and is probably involved in verifying the key, but doesn't actually perform verification.

I'm looking for source code to verify that a wc3 cd key will be accepted by the installer, in order to catch typos when people enter a key into my hosting bot.

Anyone have a link?

My current theory:
- The allocated id is for fast-access (eg. array storage). The counter id would require a tree or other non-constant-time structure.
- The counter id is for uniqueness. The allocated id could be reassigned between the time a player issues an order and the host receives the order.

No, the ids are unique to each instance of an object. Also, the type would presumably be part of the information the primary id points to.

Alright, now it looks like id2 is a strictly increasing index while id1 is an allocated index. Any ideas why they would use both?

I created a test map which created 5 peasants, waited 5 seconds, removed the peasants, waited 5 seconds, repeat.

I selected the peasants to get their IDs from the selection action data, and noted how the IDs change.

The primary id stayed between 900 and 1000, even after I let the map run for 20 minutes or so. The secondary id started less than 10 away from the primary id, but after 20 minutes it was in the tens of thousands. But during each create-5-peasants cycle it was not strictly increasing.

...

unless

...

Maybe it *was* strictly increasing, but it simply ordered the peasants by primary id and so it only looked like it was decreasing.

...

I need to test something.

When communicating in multiplayer, or saving to a replay, the objects (units, destructibles, items, etc) in a wc3 game are referred to by an id number. Duh. It seems to be allocated and freed, pretty simple. You can see it in any of the order or selection actions.

The mystery is that the id is always followed by a second value, which I'll just call id2 (since it seems to be unique per object). All objects created at game init have id = id2. id2 seems to increase with time and with the number of ids. Late in the game a typical id2 for new units is in the hundred thousands whereas the id stays relatively stable due to units dying and such. id2 also seems to increase as more ids are allocated. But, most confusing of all, it doesn't strictly increase. It goes up and down over the short term.

So, the question is: what is this value? What information is the primary id not specifying that this weird secondary one specifies? Why does it increase over the long term? Is it just there to screw with my mind?

So it doesn't include any checksums in the result? You just have to say "Yep, that check I definitely did sure did succeed!"?

That seems... pointless. It would make more sense to randomly send a check that should fail, which would make it hard to answer.

You explained what the memory check actually does (reads bytes from the file; or presumably from the file loaded in memory), but you didn't explain what the page check actually does.