Starcraft Keys

[LordNevar]

It's been confirmed that it is a strict BNLS issue, and the change works in any manner of manipulating the last number of the assigned key.

[QwertyMonster]

Thanks ringo

[LordNevar]

I have been doing alot of research on this with a massive list of working keys for battle.net, and I'm talking 10's of thousands of working keys. I have noticed something in there construction so far. This is just an observation not a confirmation of truth. This was done using the list provided by Joe, and Ringo, and also my personal lists, and some lists from other people. I did not test all these key's, nor want to spend the time too. So we'll take in affect that say 75% of them work.

Ex: 0000600003862 <~~~ Joe's First Key [Verified]

Now if I am correct this is how the basic structure of them is composed.
This table will be listed by first to last digit of the respective key.

1.)The first number cannot be higher than (4), as far as I know. I do not have any key's that start with a 5. They range from 0-4.

2.)The second number can be as high as (9).

3.)Third number can go as high as (6).

4.)Forth number can be as high as (9).

5.)Fifth number can be as high as (9).

6.)Sixth number can be as high as (9).

7.)Seventh number can be as high as (5).

8.)Eighth number can be as high as (9).

9.)Ninth number can be as high as (9).

10.)Tenth number can be as high as (7).

11.)Eleventh number can be as high as (9).

12.)Twelth number can be as high as (9).

13.)Thirteenth can be any number you want it to be from 0-9 as long as the key is correct, cause regardless if you change the last number of any starcraft/battle.net cdkey you can log on with it. Unless of course your using BNLS witch will give you an invalid key.

Note: If you change the last digit of any working stacraft/battle.net cdkey, if the key works or is muted or voided or inuse it will give you the same response for any number you assign to it.

This is just what I have so far, I have not gotten into the barebones of it. If anyone can supply a key that disproves any of my statements above, please contact me so I can make adjustments to this.

So far only creating keys in this sequence, I have managed to make 3 working key's out of 65 attempts at it, so I am obviously either very lucky or on the right track.

[Arta]

You guys should figure out how the decode routine works if you want to do this properly.

[Blaze]

Pffft, everyone already knows that starcraft keys are really poorly encrypted love messages between Yoni and Skywing.

[Mesiah / haiseM]

Pffft, everyone already knows that starcraft keys are really poorly encrypted love messages between Yoni and Skywing.

For one, I didn't know cdkeys were encrypted at all....

For another, why would they use cdkeys as a means of sharing love? Isn't that why they made the Botnet?

Anyways, on a more productive side of things, Arta is correct. To decipher and interperet the decoding technique will play a key role in analyzing how these keys are truely put together. However the server validates them, we will never know. But what we can do, is take a look at the key ideas, and use them to help analyze the decoding methods while reversing.

I, personally, do not know what file would be decompiled to look for such data, But I have seen many examples of code to emulate this routine.

To emulate such a complex matter, we can verify that we know how to "spoof" this routine. But this does not mean that we have "cracked" it full-proof.

Any information on what should/could be reversed to help aid in this matter would be great. I'm not the greatest with asm, but with all this useful data, and active users on this topic, I think we are not too farfetched from our answer. So lets keep this going guys...

Imagine, releasing our bots, without the need of a personal cdkey purchased from a store...

Imagine, the ease of usage for our users, and users to come... This could be a good thing, as long as we keep it away from those vile fools who abuse such information. Keep up the good work.

[Kp]

Imagine, releasing our bots, without the need of a personal cdkey purchased from a store...

Imagine, the ease of usage for our users, and users to come... This could be a good thing, as long as we keep it away from those vile fools who abuse such information. Keep up the good work.

Do you really think that the information would be long withheld from abusers if it goes into a publicly released client?  Also, remember what Blizzard did when bots emulating Diablo (a cdkey-free product) became too troublesome: confined all Diablo clients to a fairly useless subset of channels.  Do you doubt that they'll do the same to Starcraft if it becomes possible for any average user to make up a working cdkey?  As soon as keys can be generated, their anti-piracy measures and anti-abuser measures are rendered totally useless.  Anyone can download an illegal copy of Starcraft, synthesize a key, and log on to play on battle.net.  (Yes, people can do this already with third-party servers, but Blizzard seems to be much less interested in this - perhaps because there's no easy way for them to stop it.)  I could go on about the other dangers associated with a publicly available algorithm for key generation, but I think you'll get the point.

[UserLoser.]

Pattern matching probably won't get you really far.  Do what Arta said first

[shadypalm88]

The last digit in a StarCraft CD key is a check digit:  A value computed from the other 12 digits is equal to this value in valid keys.

C(++) code that does this:

Code Select Expand

int accum, i;
// Verification
accum = 3;
for (i = 0; i < (keyLen - 1); i++) {
    accum += ((cdkey[i] - '0') ^ (accum * 2));
}

if ((accum % 10) != (cdkey[12] - '0'))
    return 0;

So, seed the verification value with 3.  For each of the digits in the key, except for the last one, add that digit's numeric value XOR the current verification value x 2 to the current verification value.  The value modulo 10 (so that the check digit can be only one digit) should equal the last digit in the key.  If not, the key is invalid.

I guess you could just generate the first 12 digits and then calculate the check digit, but that's not very helpful.

Shuffling happens next during the decode and is fairly self-explanatory; here's a small program that takes a key, shuffles it, and then returns to the original key:

Code Select Expand


// file: keyshuffle.c
#include <string.h>
#include <stdio.h>

int main (int argc, char const* argv[])
{
char* cdkey;
int pos, i;
char temp;

if (argc < 2) {
fprintf(stderr, "usage: %s {cd-key}\n", argv[0]);
return 1;
}
cdkey = (char*) argv[1];
printf("Original   = \"%s\"\n", cdkey);

// Shuffling
pos = 0x0B;
for (i = 0xC2; i >= 7; i -= 0x11) {
temp = cdkey[pos];
cdkey[pos] = cdkey[i % 0x0C];
cdkey[i % 0x0C] = temp;
pos--;
}

printf("Shuffled   = \"%s\"\n", cdkey);

// Unshuffling
pos = 0;
for (i = 7; i <= 0xC2; i += 0x11) {
temp = cdkey[i % 0x0C];
cdkey[i % 0x0C] = cdkey[pos];
cdkey[pos] = temp;
pos++;
}

printf("Unshuffled = \"%s\"\n", cdkey);
return 0;
}The last step in the process follows; I can't think atm how you would take the known product value, public value (value1), and private value (value2) and reverse this step (and then unshuffle it) to produce an actual key.  Maybe someone less mathematically ignorant than I am can shed light on this.

Code Select Expand

// Final Value
for (i = (keyLen - 2); i >= 0; i--) {
temp = toupper(cdkey[i]);
cdkey[i] = temp;
if (temp <= '7') {
cdkey[i] ^= (char) (hashKey & 7);
hashKey >>= 3;
} else if (temp < 'A') {
cdkey[i] ^= ((char) i & 1);
}
}

// Final Calculations
sscanf(cdkey, "%2ld%7ld%3ld", &product, &value1, &value2);

[Joe[x86]]

I haven't studied the method used here, but as far as I know once the key is decoded to its three values, its basically like a hashing method. You're going to have to bruteforce to get the original key back.

[Arta]

If I remember rightly, the encode procedure is the same for encoding and decoding - it's an XOR cipher.

[shadypalm88]

If I remember rightly, the encode procedure is the same for encoding and decoding - it's an XOR cipher.

Good call.

encodekey.c

$  gcc -Wall -o sckey encodekey.c
$ ./sckey 2379322577914
Product       = 0x00000001
Public Value  = 0x0025FF9B
Private Value = 0x0000018C
$ ./sckey 0x0025FF9B 0x0000018C
CD-Key = 2379322577914

[MyndFyre]

I believe you shouldn't use Len(key) - 1.  That would be valid if you were using 0-based arrays, but since you're using i = 1 to ..., you'll probably want to go to Len(key).

[l2k-Shadow]

Ringo:
Code in my next post.

@ MyndFyre: Actually his way is correct because you only calculate the first 12 digits and not the 13th one which is the digit you are trying to end up with. His mistake was elsewhere though as you see..

[l2k-Shadow]

Sorry about that I kinda skimmed through it and didn't notice what I did... anyway this works:

Code Select Expand


Public Function VerifyKey(CdKey As String) As Boolean
' Function ported to VB6 from C++ by l2k-Shadow
    Dim Value As Long, i As Integer
    Value = 3
    For i = 1 To 12
        Value = Value + (Mid$(CdKey, i, 1) Xor (Value * 2))
    Next i
    If (Value Mod 10) = Right$(CdKey, 1) Then VerifyKey = True
End Function