Starcraft Keys

[rabbit]

Well, we know Warcraft II and StarCraft use the same system, or at least SC uses one derived from WC2, as we find that the reversed StarCraft has a case changing call...which makes not sense with a set of digits.  I have some theories, but I want to do more research before I actually post anything.

[MyndFyre]

Well, we know Warcraft II and StarCraft use the same system, or at least SC uses one derived from WC2, as we find that the reversed StarCraft has a case changing call...which makes not sense with a set of digits.  I have some theories, but I want to do more research before I actually post anything.

How do you know this?  Starcraft came out well before Warcraft II: Battle.net Edition and Diablo II, both of which use 16-character alphanumeric keys as opposed to Starcraft's 13-digit numeric-only key.

[rabbit]

From what I've learned of assembly, and the code segments for decoding keys I've been shown (I still can't actually FIND them...), I've noticed both start off with a case change.

[edit]
Unless I'm mistaken, which I may very well be.  I tend to suck at assembly.

[l2k-Shadow]

I am working on encoding function for w2/d2 keys. So far they are well following the system for sc keys but i am stuck on the 'shuffling' part of it and can't seem to get it working. Thing is when you 'shuffle' the d2 key, it outputs less values then before the algorithm, that's what's fux0ring me up.
Here's the decode:

Code Select Expand


Private Sub DecodeD2Key(ByVal CDKey As String, ByRef Product As Long, ByRef PublicValue As Long, ByRef PrivateValue As Long)
Dim i&, r&, n&, n2&, v&, V2&, C&, c1&, c2&, keyvalue&
Dim CodeValues$, tKey$(15), tStr$
    CDKey = UCase$(CDKey)
    CodeValues = "246789BCDEFGHJKMNPRTVWXZ"
    r = 1
    'Fill Array
    For i = 0 To 15
        tKey(i) = Mid$(CDKey, i + 1, 1)
    Next i
    For i = 0 To 15 Step 2
        c1 = InStr(CodeValues, tKey(i)) - 1
        n = c1 * 3
        c2 = InStr(CodeValues, tKey(i + 1)) - 1
        n = c2 + n * 8
        If n >= &H100 Then
            n = n - &H100
            keyvalue = keyvalue Or r
        End If
        n2 = n
        n2 = n2 \ 16
        tKey(i) = Hex$(n2)
        tKey(i + 1) = Hex$(n)
        r = r * 2
    Next i
    'Shuffling
    For i = 15 To 0 Step -1
        C = Asc(tKey(i))
        If i > 8 Then
            n = i - 9
        Else
            n = &HF - (8 - i)
        End If
        n = n And &HF
        c2 = Asc(tKey(n))
        tKey(i) = Chr$(c2)
        tKey(n) = Chr$(C)
    Next i
    'Final Values
    V2 = &H13AC9741
    For i = 15 To 0 Step -1
        C = Asc(UCase$(tKey(i)))
        If C <= 55 Then
            tKey(i) = Chr$((((V2 And &HFF) And 7) Xor C))
            V2 = V2 \ 8
        ElseIf C < 65 Then
            tKey(i) = Chr$(((i And 1) Xor C))
        End If
    Next i
    tStr = Join(tKey, vbNullString)
    Product = CLng("&H" & Left$(tStr, 2))
    PublicValue = CLng("&H" & Mid$(tStr, 3, 6))
    PrivateValue = CLng("&H" & Mid$(tStr, 9))
End Sub

I got the encoding fine for the final values but I need a poke in the right direction as to how to 'unshuffle'. Any ideas plz?

[ThePro]

I think you waste your time at all.

If an original Starcraft CD has been created, the CD-Key which will land on the CD-Cover will be registred to bnet. Thats what I think, how Blizzard handle that, so it's impossible to calculate a working battle.net cd-key.

[Arta]

Well, that's already been demonstrated not to be the case.

[Yegg]

I think you waste your time at all.

If an original Starcraft CD has been created, the CD-Key which will land on the CD-Cover will be registred to bnet. Thats what I think, how Blizzard handle that, so it's impossible to calculate a working battle.net cd-key.

Are you suggesting that a 13-digit variable (being the Starcraft key in this case) does not exist until it is put on a CD case and shipped from its warehouse?

[tA-Kane]

I think you waste your time at all.

If an original Starcraft CD has been created, the CD-Key which will land on the CD-Cover will be registred to bnet. Thats what I think, how Blizzard handle that, so it's impossible to calculate a working battle.net cd-key.

Are you suggesting that a 13-digit variable (being the Starcraft key in this case) does not exist until it is put on a CD case and shipped from its warehouse?

That's what I have believed for a very long while. though, it may be entirely false. Blizzard could have only the algorithm to verify that keys are valid instead of a database of which keys have been generated and distributed by them. It would be interesting to create a database of keys which are valid for install, but whose public values are known to not contain a matching valid private value which allows it onto Battle.net. Then, re-check the database every few months to see if any of them have changed from invalid to valid (even if being valid, theyv'e already been muted or jailed or whatever).

[Adron]

[EDIT]:
Removed post contents and PM'ed to arta
(Could be classed as harmfull infomation)

Hmmm? Sounds like something interesting?

[Topaz]

That's very possible, Kane; But if they do use an algorithm, then it's easy to generate working keys. After all, more than a million copies of Starcraft have been sold.

[Arta]

I have replied

Sorry, it's been a busy week. Feel free to repost my comments if you want.

[Kp]

Maybe, it was mainly a observation to go with the data-base idea
Arta hasnt replyed -- so im asumeing its nothing important, or an observation of somthing that was already known.

On the data-base subject:
If there was nothing more than a algorithm to generate valids cdkeys, it would mean blizzard possibly activated millions of valid cdkeys when they created the algorithm for SC keys, before they had even released a single copy of the game.
And if there was just a algorithm, there would have to be some kind of data base to keep record of banned, muted and inuse keys.
A 'CDKey' data base could do all of this, with out over confusing things and becoming messy.
But lets say theres nothing more than a algorithm, how would blizzard beable to check if the cdkey is banned, void or inuse?

There's no reason they'd need to turn on all valid keys when they first ship.  Suppose they have some function f such that f(public) = private.  The server uses this function to check whether a key could possibly be valid.  The server then has a second listing of what potentially valid keys are actually valid.  For instance, they might say that only keys which have a public value in [2000,2000000) are valid, even though f can compute (and therefore be used to check) the validity of all keys, regardless of their public value.  This listing of keys can be maintained much more cheaply than a full database, since it is just a set of ranges, not an enumeration of every key in the range.

Such a scheme would also encourage the use of sequential public values for CDs stamped at the same time, since you then create only one range on the server.  This in turn leads to several ways that they could keep the listing of banned/jailed/muted keys cheaply.  For instance, a balanced binary tree where the key's public value is the key to the node and the action (jail, mute, ban) is the value of the node.  If a key's value is not found in the tree, the default action is 'none': user has done nothing prohibited, so allow a full logon.  This is just what I've come up with offhand.  Blizzard had days, weeks, or maybe even months to pick out how they wanted to implement cdkey storage, and they still have the flexibility to change the underlying data structures since they never share the database or associated checking code.

Also - why're you posting public messages telling Arta when you've replied to him?  He can see it in the forum header, and the rest of us gain nothing from knowing which of you is waiting on the other to reply next.

[Arta]

A calculation would be faster than a database for determining the correctness of the private. A binary tree would be a nice way to hold a list of banned/muted/inuse keys in memory.

[tA-Kane]

Maybe, it was mainly a observation to go with the data-base idea
Arta hasnt replyed -- so im asumeing its nothing important, or an observation of somthing that was already known.

On the data-base subject:
If there was nothing more than a algorithm to generate valids cdkeys, it would mean blizzard possibly activated millions of valid cdkeys when they created the algorithm for SC keys, before they had even released a single copy of the game.
And if there was just a algorithm, there would have to be some kind of data base to keep record of banned, muted and inuse keys.
A 'CDKey' data base could do all of this, with out over confusing things and becoming messy.
But lets say theres nothing more than a algorithm, how would blizzard beable to check if the cdkey is banned, void or inuse?

There's no reason they'd need to turn on all valid keys when they first ship. Suppose they have some function f such that f(public) = private. The server uses this function to check whether a key could possibly be valid. The server then has a second listing of what potentially valid keys are actually valid. For instance, they might say that only keys which have a public value in [2000,2000000) are valid, even though f can compute (and therefore be used to check) the validity of all keys, regardless of their public value. This listing of keys can be maintained much more cheaply than a full database, since it is just a set of ranges, not an enumeration of every key in the range.

Such a scheme would also encourage the use of sequential public values for CDs stamped at the same time, since you then create only one range on the server. This in turn leads to several ways that they could keep the listing of banned/jailed/muted keys cheaply. For instance, a balanced binary tree where the key's public value is the key to the node and the action (jail, mute, ban) is the value of the node. If a key's value is not found in the tree, the default action is 'none': user has done nothing prohibited, so allow a full logon. This is just what I've come up with offhand. Blizzard had days, weeks, or maybe even months to pick out how they wanted to implement cdkey storage, and they still have the flexibility to change the underlying data structures since they never share the database or associated checking code.

Using a balanced AVL tree (see: here) for that is a pretty neat concept, but why not just use something a little easier to sync with other servers on the same gateway? Eg, SQL?

And yes, Ringo... a binary tree will work better & faster in C++ (actually, I'd venture a guess that anything would work better & faster in C++ than in VB).

[Kp]

Using a balanced AVL tree (see: here) for that is a pretty neat concept, but why not just use something a little easier to sync with other servers on the same gateway? Eg, SQL?

And yes, Ringo... a binary tree will work better & faster in C++ (actually, I'd venture a guess that anything would work better & faster in C++ than in VB).

SQL sounds like a perfectly workable solution as well, though keeping it in a local data structure could give better search performance (assuming a good data structure is used in both cases, so SQL has the necessary overhead of querying the remote server).  Automatic synchronization would be a definite plus for having it centralized, but they can reduce network load and code complexity by keeping it local.  It's all about trade-offs.

*wunders how smart blizzard were in 97* 

For the purpose of keeping the list of disallowed keys, it doesn't matter how smart they were when they implemented it.  As I noted above, they don't grant outside access to it, so they're theoretically free to change the internal structure whenever they want.