Starcraft Keys

[rabbit]

Hrm..is it just me, or are these values a little wanky?



[edit]
Reconstructing, by using the private and public values decoded, change that first key to 3940140577719, which is decodes correctly.

Reconstructing the second key, it becomes 2848162025364.

The third becomes 0598383798773.

The fourth becomes 3327490657450.

The reconstructed keys have the proper product codes.  Hrm.

[UserLoser]

What are you talking about

[rabbit]

I have a list of keys and some of them work on Battle.Net, but have weird product values (0x32, for example), and when I run their public and privates to generate the key, I got a different key.  It just seems odd..

[Lenny]

I would either check your decoding and encoding.  The first thing Battle.net does when they receive your decoded key is verify the correct product value...

[l2k-Shadow]

Not to mention those are not valid Battle.net keys.. probably why you're getting fucked values.

[dxoigmn]

I have a list of keys and some of them work on Battle.Net, but have weird product values (0x32, for example), and when I run their public and privates to generate the key, I got a different key.  It just seems odd..

Something is wrong with the way you're encoding the cdkey from the product/public/private values (either you're not supply the same values, or the actual algorithm has a bug).  If I wasn't so lazy, I could probably pinpoint exactly where the flaw in your code is by just the samples you posted. I'll leave that as an excercise for you.

Edit: Oh see, you're just using the public and private values and a static value of 1 for the product. Of course changing the product value will completely change the encoded cdkey. Someone should verify that those keys (with the weird product ids) do work on battle.net.

[UserLoser]

I have a list of keys and some of them work on Battle.Net, but have weird product values (0x32, for example), and when I run their public and privates to generate the key, I got a different key.  It just seems odd..

Something is wrong with the way you're encoding the cdkey from the product/public/private values (either you're not supply the same values, or the actual algorithm has a bug).  If I wasn't so lazy, I could probably pinpoint exactly where the flaw in your code is by just the samples you posted. I'll leave that as an excercise for you.

Edit: Oh see, you're just using the public and private values and a static value of 1 for the product. Of course changing the product value will completely change the encoded cdkey. Someone should verify that those keys (with the weird product ids) do work on battle.net.

They do work, yet don't.  You get the bad product code response back.

[rabbit]

Hm...I'll recheck that then, I swear they worked.

Anyway, I'm using the program posted earlier:

Code Select Expand

#include <string.h>
#include <stdio.h>
#include <stdlib.h>
#include <ctype.h>

void decode(char* cdkey);
void encode(char* public_s, char* private_s);

int main (int argc, char* argv[])
{
switch (argc) {
case 2:
decode(argv[1]);
break;
case 3:
encode(argv[1], argv[2]);
break;
default:
fprintf(stderr, "usage:\n\t%s {cd key}\n-or-\n\t%s {public value} "
"{private value}\n", argv[0], argv[0]);
return 1;
}

return 0;
}

void decode(char* cdkey)
{
int accum, pos, i;
char temp;
int hashKey = 0x13AC9741;
unsigned long value1, value2, product;
int keyLen = 13;

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

if ((accum % 10) != (cdkey[12] - '0')) {
printf("Error: Verification failed.\n");
return;
}

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

// 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);
printf("Product       = 0x%08lX (%08d)\n", product, product);
printf("Public Value  = 0x%08lX (%08d)\n", value1, value1);
printf("Private Value = 0x%08lX (%08d)\n", value2, value2);
}

void encode(char* public_s, char* private_s)
{
char cdkey[14] = "\0";
unsigned long public, private;
int pos, i;
char temp;
int keyLen = 13;
int hashKey = 0x13AC9741;
int accum;

public = strtoul(public_s, NULL, 0);
private = strtoul(private_s, NULL, 0);
sprintf(cdkey, "%02u%07lu%03lu", (unsigned) 1, public, private);

// 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);
}
}

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

// Calculate check digit
accum = 3;
for (i = 0; i < (keyLen - 1); i++) {
accum += ((tolower(cdkey[i]) - '0') ^ (accum * 2));
}
cdkey[12] = (char) (accum % 10) + '0';

printf("CD-Key = %s\n", cdkey);
}
by I-forget-who.

[Lenny]

This really depends on your definition of working key 

Bad product keys should be lower than invalid keys because they couldn't even pass the product check that the server first does (as already stated in my last message).  Battle.net doesn't ipban for these keys because it's not even a threat to their system.  With invalid keys, you still have at least 1 in a 1000 chance of getting a valid.

Mayhaps we can assume the actual cdkey check is fairly complex if they're willing to check the product code before they start anything at all...

[Kp]

This really depends on your definition of working key 

Bad product keys should be lower than invalid keys because they couldn't even pass the product check that the server first does (as already stated in my last message).  Battle.net doesn't ipban for these keys because it's not even a threat to their system.  With invalid keys, you still have at least 1 in a 1000 chance of getting a valid.

Mayhaps we can assume the actual cdkey check is fairly complex if they're willing to check the product code before they start anything at all...

Possibly, but I don't think that's a safe assumption.  It's a fairly common programming optimization that you check the easy stuff first, and checking that the product code is 1 (or maybe 2) is a very easy check.

[rabbit]

Pfft..yeah right, that takes like.... 8 whole cycles.  Fuck me if I'll do THAT!

But on a more serious note, I kept meaning to test those keys out again, but I realized I just didn't care that much.

[Trejo]

I Decoded 1000 Keys... All using the same Public Values.
The Public Value being: 3240285
The CDKey Range being: 3307x609x7x13 (x = Random... For randomizing Private Values.)
The Product Value being: 01
The Private Value being: Random

There are 499 Invalid, 500 Wrong Product and 1 Valid (Muted or Voided or Working)
Therefore, Your odds are now 1 in 500. After you remove all the keys with the product
of: 01 < *

Which raises the question: Where does the value 5460083 come from... I know its a
valid public value..... but what relationship does it have with the key.... its like a sister
key of the "Product Value"..... Help me out here?

Note: Delete the Wrong Product values and encode all the values to get the 1 in 500
Odds.

You know the 3 x's are based on the private value, right? Where did you get the other 10 digits from?

[Lenny]

And also there's 1000 possible keys associated with a specific product/public value pair.  So your chances are still 1/1000.....

[~Mike~]

Well after I decode my keys, i think i'm gettin an extra digit for my private value. i.e

2571472281941   1   2205677   5991

Where i thinks it is adding the 1 to end of private value from the 13th #. Any solutions?

[rabbit]

If it's always a 1, ignore it.