Starcraft Keys

[Lenny]

 
It doesn't matter?

F(public,product) = encoded...Wouldn't that be just as useful?

There more than a few ways to look for patterns.  There are 4 values, encoded, product, public and private.  Patterns found between any 3 of those 4 values would be very useful. 

The only reason the encoded isn't the best choice is because many of the patterns are only as a result of the 'encode' function.
We already have part of the actual algorithm (known as decode cdkey).  But that doesn't mean the encoded value is useless.

The pattern that Myst_DooM has found is not a result of decoding.  You can check this yourself...And it's a rather frequent pattern in valid cdkeys (however there are a few exceptions).

[dxoigmn]

It doesn't matter?

F(public,product) = encoded...Wouldn't that be just as useful?

There more than a few ways to look for patterns.  There are 4 values, encoded, product, public and private.  Patterns found between any 3 of those 4 values would be very useful. 

The only reason the encoded isn't the best choice is because many of the patterns are only as a result of the 'encode' function.
We already have part of the actual algorithm (known as decode cdkey).  But that doesn't mean the encoded value is useless.

The pattern that Myst_DooM has found is not a result of decoding.  You can check this yourself...And it's a rather frequent pattern in valid cdkeys (however there are a few exceptions).

No that is not useful.

If any of you actually took the time to see what the decoding process does, then you'd realize what I am saying. Notice that when the cdkey is shuffled, that digit doesn't really move (nor does the last digit because it is a check digit):

Code Select Expand


Regular:  0123456789ABC
Shuffled: 60293B1754A8C


The only reason that digit will change is in the xor stage. The pattern he found is a result of decoding. My advice, ignore any encoded form of the cdkey, and just look for relationships between private and public values of the same product.

[Lenny]

The only reason that digit will change is in the xor stage. The pattern he found is a result of decoding. My advice, ignore any encoded form of the cdkey, and just look for relationships between private and public values of the same product.

I'm not following.  You're agreeing that the xor will change the 11th digit of the encoded key (or decoded since as you already said, the shuffling actually shuffles it back to the same place). 

Also, you can verify this yourself via the encode function.  For a product/public value pair, you can generate 1000 possible keys (only 1 being valid).  But of those 1000, not all follow the pattern.  Now if it were a result of the decode, wouldn't all 1000 keys follow this pattern?

[Arta]

Patterns in 'encoded', or between the encoded and decoded forms, are completely irrelevant.

[Lenny]

Not if the pattern or trend is only apparent in valid keys and not a result of the actual decode.

Or are you still trying to find the definite algorithm for key generation (ie the F(public,product)=private)?  Because that's not feasable and would be exponentially more difficult if there were multiple algorithms involved (which is very possible).

[Arta]

Not if the pattern or trend is only apparent in valid keys and not a result of the actual decode.

I don't really know what you mean.

To look for patterns between the encoded/decoded forms is completely pointless. We understand how one produces an encoded key, and how one produces a decoded key. No additional information is present in either form. The decoded version contains the data that Battle.net processes; therefore, it is data that is closest to the algorithms of interest. To look for patterns that exist as a result of an algorithm we already understand is a complete waste of time.

Or are you still trying to find the definite algorithm for key generation (ie the F(public,product)=private)?

Of course. That's the only algorithm of interest here.

Because that's not feasable and would be exponentially more difficult if there were multiple algorithms involved (which is very possible).

It has been my assertion all along that this task is very difficult. It is not, however, impossible -- especially if Blizzard's algorithm is based on some other, existing, algorithm. Given Blizzard's history, this is plausible. Either way, a mathematically gifted person may well notice some pattern between public, product and private values that could yield a working theory on the relationship between these numbers.

Like I said, it's certainly difficult, but not impossible.

[Lenny]

It's simple process of elimination, nothing more.  You simply look for trends that ARE NOT a result of the decoding/encoding which is already known.  Any pattern which is found to be apparently only in valid keys while not in invalid keys (which were generated via encode or decoding) is valuable simply because you''re narrowing your set of possible keys.

Now ask yourself, is this a pattern generated by all keys which are encoded correctly?

Also, the problem with finding the actual algorithm are arbitrary functions which would prevent any 'mathematically gifted' person from simply finding the actual algorithm. 
Example:
if(key < 5)
  key = sqrt(43);
else if(sqrt(key) < e)
  key = ln(643);

There's no mathematical basis for such operations which could easily be in several parts of the algorithm.

I doubt blizzard would need any outside sources to implement this algorithm.  It's not difficult to create it (cracking it is a different story).  And if such a 'common' algorithm used existed, it would work in such which knowing what operations are done still makes it unfeasable to break (ie encryption).

[PaiD]

It has been my assertion all along that this task is very difficult. It is not, however, impossible -- especially if Blizzard's algorithm is based on some other, existing, algorithm. Given Blizzard's history, this is plausible. Either way, a mathematically gifted person may well notice some pattern between public, product and private values that could yield a working theory on the relationship between these numbers.

Someone get Yoni over here 

[Joe[x86]]

It has been my assertion all along that this task is very difficult. It is not, however, impossible -- especially if Blizzard's algorithm is based on some other, existing, algorithm. Given Blizzard's history, this is plausible. Either way, a mathematically gifted person may well notice some pattern between public, product and private values that could yield a working theory on the relationship between these numbers.

Someone get Yoni over here 

ROFL.

[Arta]

It's simple process of elimination, nothing more.  You simply look for trends that ARE NOT a result of the decoding/encoding which is already known.  Any pattern which is found to be apparently only in valid keys while not in invalid keys (which were generated via encode or decoding) is valuable simply because you''re narrowing your set of possible keys.

Any patterns you see in an encoded key are likely to have been produced by the encoding process. The observation of such patterns is thus not useful. The observation of patterns in keys' decoded form is all that is of interest. The encoded form contains no more information that the decoded form, and the relationship between the encoded and decoded forms is understood, so there is no benefit in further analysis on that front.

I understand why it's appealing -- compared to the other avenues of investigation, it's very easy -- but it is not worth pursuing.

Now ask yourself, is this a pattern generated by all keys which are encoded correctly?

Any trend in an encoded key that is produced by all valid keys would have an analagous trend in the decoded form. It's that trend that is worth investigating.

Also, the problem with finding the actual algorithm are arbitrary functions which would prevent any 'mathematically gifted' person from simply finding the actual algorithm. 
Example:
if(key < 5)
  key = sqrt(43);
else if(sqrt(key) < e)
  key = ln(643);

There's no mathematical basis for such operations which could easily be in several parts of the algorithm.

That's plausible, but not confirmed. I agree that this task is very difficult, and is perhaps impossible, and I have made that quite clear in my posts from the beginning of this thread. I spent quite some time studying CD keys a few years ago, and concluded that I was unlikely to find anything useful.

There are really only two ways that the algorithm could be discovered:

1: It's based on an existing known algorithm with recognisable behaviour;
2: It's very simple.

If it's very simple, then the analysis of a large enough set of keys by an appropriately skilled person could yield useful results. As I said before, if it is neither of these things, then the task is likely impossible.

I doubt blizzard would need any outside sources to implement this algorithm.

That's a matter of opinion

[UserLoser]

IMO, the best set of data known/we have to work with:

Cd-Key (Product-Public-Private)

1125310113636 (1-0000002-660)
1125400163437 (1-0000003-147)
1125370153335 (1-0000004-634)
3133400395019 (1-0000005-418)
1125650153437 (1-0000006-344)

[Lenny]

It's simple process of elimination, nothing more.  You simply look for trends that ARE NOT a result of the decoding/encoding which is already known.  Any pattern which is found to be apparently only in valid keys while not in invalid keys (which were generated via encode or decoding) is valuable simply because you''re narrowing your set of possible keys.

Any patterns you see in an encoded key are likely to have been produced by the encoding process. The observation of such patterns is thus not useful. The observation of patterns in keys' decoded form is all that is of interest. The encoded form contains no more information that the decoded form, and the relationship between the encoded and decoded forms is understood, so there is no benefit in further analysis on that front.

I understand why it's appealing -- compared to the other avenues of investigation, it's very easy -- but it is not worth pursuing.

Now ask yourself, is this a pattern generated by all keys which are encoded correctly?

Any trend in an encoded key that is produced by all valid keys would have an analagous trend in the decoded form. It's that trend that is worth investigating.

Also, the problem with finding the actual algorithm are arbitrary functions which would prevent any 'mathematically gifted' person from simply finding the actual algorithm. 
Example:
if(key < 5)
  key = sqrt(43);
else if(sqrt(key) < e)
  key = ln(643);

There's no mathematical basis for such operations which could easily be in several parts of the algorithm.

That's plausible, but not confirmed. I agree that this task is very difficult, and is perhaps impossible, and I have made that quite clear in my posts from the beginning of this thread. I spent quite some time studying CD keys a few years ago, and concluded that I was unlikely to find anything useful.

There are really only two ways that the algorithm could be discovered:

1: It's based on an existing known algorithm with recognisable behaviour;
2: It's very simple.

If it's very simple, then the analysis of a large enough set of keys by an appropriately skilled person could yield useful results. As I said before, if it is neither of these things, then the task is likely impossible.

I doubt blizzard would need any outside sources to implement this algorithm.

That's a matter of opinion

But you're on the assumption that decoding a key places it in a simpler form.  Decoding places the key in another 12 digit form.  The largest importance of decoding keys in this situation is the filtering of only those which produce a product value of 01 or 02.

As you already said, any patterns are LIKELY to be produced as a result of decoding/encoding, but not necessarily.  And this is why comparing patterns in either the decoded or encoded form is difficult.  And finding patterns in either form which are apparent in valid keys (but not a result of encoding/decoding) is useful.


The analgous trend may not be as easy to recognize in decoded form (or vis versa) because there is a xor operation done between the two forms.  Therefore, seeing one trend in the encoded form does not mean it will appear as simplisticly in the decoded form.

[dxoigmn]

IMO, the best set of data known/we have to work with:

Cd-Key (Product-Public-Private)

1125310113636 (1-0000002-660)
1125400163437 (1-0000003-147)
1125370153335 (1-0000004-634)
3133400395019 (1-0000005-418)
1125650153437 (1-0000006-344)

What I would like to see ie either (a) all private values that map to a single public value, or (b) all the public values that map to a single private value. The former seems easier, while the latter more difficult. The only way to do this is a brute force approach.

[Arta]

But you're on the assumption that decoding a key places it in a simpler form.

It does. Decoding produces the values that are used in the computation.

As you already said, any patterns are LIKELY to be produced as a result of decoding/encoding, but not necessarily.  And this is why comparing patterns in either the decoded or encoded form is difficult.  And finding patterns in either form which are apparent in valid keys (but not a result of encoding/decoding) is useful.

The analgous trend may not be as easy to recognize in decoded form (or vis versa) because there is a xor operation done between the two forms.  Therefore, seeing one trend in the encoded form does not mean it will appear as simplisticly in the decoded form.

Any pattern present in an encoded form would be the encoding of a pattern present in the decoded form. Looking for patterns in the encoded form serves only to increase the complexity of the problem: you are then required to make sure that your trend is meaningful, and not simply an artefact of encoding. What's the point in doing that when the trend will also be present in the decoded form? I see no reason why an encoded trend should be easier to spot than a decoded trend.

I'm not going to discuss this further as I've explained it numerous times and you are apparently unwilling to reconsider your position.

[Lenny]

But you're on the assumption that decoding a key places it in a simpler form.

It does. Decoding produces the values that are used in the computation.

As you already said, any patterns are LIKELY to be produced as a result of decoding/encoding, but not necessarily.  And this is why comparing patterns in either the decoded or encoded form is difficult.  And finding patterns in either form which are apparent in valid keys (but not a result of encoding/decoding) is useful.

The analgous trend may not be as easy to recognize in decoded form (or vis versa) because there is a xor operation done between the two forms.  Therefore, seeing one trend in the encoded form does not mean it will appear as simplisticly in the decoded form.

Any pattern present in an encoded form would be the encoding of a pattern present in the decoded form. Looking for patterns in the encoded form serves only to increase the complexity of the problem: you are then required to make sure that your trend is meaningful, and not simply an artefact of encoding. What's the point in doing that when the trend will also be present in the decoded form? I see no reason why an encoded trend should be easier to spot than a decoded trend.

I'm not going to discuss this further as I've explained it numerous times and you are apparently unwilling to reconsider your position.

Well you can't make the claim that it is a simplification with out actual knowledge of how the 'valid key' algorithm works.  The public value could be easily xor'ed back, and from that value, be used to find the private.  The last xor in the decode could even be xor obfuscation.

And yes, any pattern in the encode will be in the decode, but as I've said earlier it may not be as simple to see.  To see it by a visual comparison of numbers would require someone to be able to mentally 'xor' numbers as easily as most can mentally perform addition and subtraction.

I agree there's no reason for this argument to continue.  But as a note, Ringo is an example of proof of concept.  As far as I have seen, he has been generating cdkeys with the best success rate here.  And as he has already said, he has accomplished this by observing many of the trends in encoded keys.