starcraft2 network traffic

[Zoo]

I don't know what combo you are talking about but anyways.
Anyone know where to find a good, modern loader for SC/D2? Something that will let me inject DLLs. I've been using Ron's but its.. lacking (AE: I can't load more then one) and I'd like to know what the current populous uses.

I hope this suits your purposes:
http://bhfiles.com/files/Diablo%20II/1.12a/D3Loader%20by%20Gnarmock.rar

[aton]

The server stores the Identifier (I) and salt (s), it does NOT store the password. It stores a password verifier (v) which is generated using the password. So it's safe.
The username is actually sent to you by the server. I would assume this is done to allow you to change your email address in the future.
You send the e-mail and your random (A), and it returns the associated Identifier (I) and salt (s) as well as it's random (B)
So, in order to 'sniff' the protocol, you need 2 things.
a - a random number generated by the client which is never sent over the wire.
N - The unique modulus for use in SRP, this is in Password.dll somewhere.
g - The generator used in SRP, this is also in Password.dll somewhere

yea i read the documentation, it says the server stores the password, but you are probably right, they store a hash(v), not the password.
you say "you send the email and your random(A)" ... which means A hits the wire. The server returns I, s and B, so they hit the wire too.
now all thats missing is N and g, which are fixed values/functions and can be found in password.dll.

is this right?

[Hdx]

The server stores the Identifier (I) and salt (s), it does NOT store the password. It stores a password verifier (v) which is generated using the password. So it's safe.
The username is actually sent to you by the server. I would assume this is done to allow you to change your email address in the future.
You send the e-mail and your random (A), and it returns the associated Identifier (I) and salt (s) as well as it's random (B)
So, in order to 'sniff' the protocol, you need 2 things.
a - a random number generated by the client which is never sent over the wire.
N - The unique modulus for use in SRP, this is in Password.dll somewhere.
g - The generator used in SRP, this is also in Password.dll somewhere

yea i read the documentation, it says the server stores the password, but you are probably right, they store a hash(v), not the password.
you say "you send the email and your random(A)" ... which means A hits the wire. The server returns I, s and B, so they hit the wire too.
now all thats missing is N and g, which are fixed values/functions and can be found in password.dll.

is this right?

Nope, main reason being:
a != A
b != B
Hopefully this diagram will help you understand.
K requires S
S requires private info (a, or b)

Code Select Expand

      a = random()                              |
      A = g^a % N                              -->
      Email                                    -->
                                                |     v = Password Verifier from DB
                                                |     b = random()
                                               <--    s = Salt from DB
                                               <--    I = Identfies from DB
                                               <--    B = (v + g^b) % N
                                                |
      p = <raw password>                        |
      x = H(s | H(I | ":" | p))                 |
      u = H(A, B)                               |   u = H(A, B)
      S = (B - g^x) ^ (a + u * x) % N           |   S = (A * v^u) ^ b % N
      K = SHA_Interleave(S)                     |   K = SHA_Interleave(S)
                                                |
M1 = H(H(N) XOR H(g) | H(I) | s | A | B | K)   -->
                                               <--  M2 = H(A | M1 | K)[edit]NVM: Remembered how u was calculated, fixed diagram.
Also, added in M1/M2 verification.
M1/M2 are used to verify to both parties that they each have the same K value. If you look carefully, you will see that both sides use all shared variables to calculate M1/M2 (N, g, I, s, A, B are all shared).
N and g are known before hand (its in Password.dll)
Client sends A
Server sends I, s, B
K is never transmitted over he wire. But it is calculated by both sides using different formulas!

If this is still confusing look at it this way, we have the following variables:

Code Select Expand


Total:  NgaAvbsIBpxuSK
Client: NgaA  sIBpxuSK
Server: Ng AvbsIB  uSK
As you can see, there are gaps. And those gaps are what makes SRP the fortress that it is.


Hopefully, you better understand SRP now.



As for what is stored in the DB:

Code Select Expand

I = Identifier, in legacy clients, it was your username converted to uppercase (UCase(Username))
    But in SC2 it is a 32 byte 'random' number (I say random because iono how it's derived)
    Seine this is not known by the user, the server has to specify it. So the Server must ALSO save the EMail

s = salt = A random 32-byte number generated when you create your account or change your password.
           And never changes for the life of the password.

v = Password Verifier = Generated using the bellow formula, once again this is generated when you
    create your account, or change your password. And lives for the life of the password.

        x = SHA(<salt> | SHA(<username> | ":" | <raw password>))
        v = g^x % N


After all thats said and done, both sides generate RC4 keys to encrypt the rest of the communication.
IIRC: It's just like Warden:

Code Select Expand

InKey = RC4Init(Left(K, Len(K) >> 2))
OutKey = RC4Init(Mid(K, Len(K) >> 2 + 1))

[MyndFyre]

Have you looked into SHA-256 for I?  As you noted, I is used in the calculation of x, which is required both as part of the verifier and on the client.  But if it's 32 seemingly random bits, a SHA-256 hash is pretty unlikely to have many collisions, so it sounds like a pretty good candidate.

[Hdx]

Have you looked into SHA-256 for I?  As you noted, I is used in the calculation of x, which is required both as part of the verifier and on the client.  But if it's 32 seemingly random bits, a SHA-256 hash is pretty unlikely to have many collisions, so it sounds like a pretty good candidate.

Good idea, but I just ran my E-Mail through a SHA-256 hash (all logical variations), and none matched. Though I don't have a binary implementation handy so I couldn't try I = H(s, U) or anything like that.

But, from a pure login point of view the generation of I does not matter as SC2 simply blindly copies/uses it.

If anyone really wanted they could have it the user's 'Account Number' and send \x01\x00\x00... for the 1s't account, \x02\x00\x00\x00.. etc...
Like I said, SC2 does a blind copy, convert to UCased hex string, and use in standard SRP.

[Varlock]

Has anyone looked into the game protocol rather than bnet? Is it encrypted? UDP or TCP? Peer-to-peer or client/server or both like Warcraft III? I'm not in the beta so I don't have any idea how it works and if any of these questions have obvious answers.

I'd be curious to look at a dump of a game if it wasn't encrypted.

[Draugur]

Has anyone looked into the game protocol rather than bnet? Is it encrypted? UDP or TCP? Peer-to-peer or client/server or both like Warcraft III? I'm not in the beta so I don't have any idea how it works and if any of these questions have obvious answers.

I'd be curious to look at a dump of a game if it wasn't encrypted.

Yes it is encrypted.
TCP.
Client to Server.

[Varlock]

Thanks for the info.