looks encrypted to me, perhaps same as d2?
yes it's encrypted.
it's suspected to be the value of A in srp.
Quote from: brew on March 19, 2010, 01:57 PM
yes it's encrypted.
it's suspected to be the value of A in srp.
K*
No you moron, it's encrypted with K (http://www.ietf.org/rfc/rfc2945.txt). Just like WoW is.
http://s2dev.onlythechosen.com/forum/
Quote from: Hdx on March 19, 2010, 04:21 PM
No you moron
Woah, fuck off dude.
Yeah, I stood corrected. So what?
Thanks for turning more than half this thread into prime Thrash Can material.
so can it be decrypted only by watching network packets?
Quote from: aton on March 20, 2010, 11:41 AM
so can it be decrypted only by watching network packets?
No. K is never sent over the network. I suggest that you, for now, hook Password!389613B0h. There are 16 bytes of CCh padding at the end of that function, so you could write a jmp to your own interception code over the ret.
is it a pre-shared key?
Quote from: brew on March 20, 2010, 12:57 AM
Quote from: Hdx on March 19, 2010, 04:21 PM
No you moron
Woah, fuck off dude.
Yeah, I stood corrected. So what?
Thanks for turning more than half this thread into prime Thrash Can material.
All of my replies are on topic and informative. You're the one who somewhat correct info(which I corrected) and then gave ludicrous info.
Anyways, no aton, k is not pre-shared it is calculated during SRP.
If you read the specs I linked earlier (http://www.ietf.org/rfc/rfc2945.txt) you will understand things more.
as i understood it, the server stores then (pre-shared) username and password and a salt and when the client establishes the connection, it sends the salt. now if i knew the username and password and could sniff the salt, couldnt i create the shared session key which would let me decrypt the traffic?
(i am not very good with crypto stuff)
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
A bit of poking around in the dlls should be easy to find it.
Take a read of the specs I linked. It will help you identify most of the start of the protocol.
Quote from: Hdx on March 20, 2010, 02:53 PM
You're the one who somewhat correct info(which I corrected) and then gave ludicrous info.
You didn't have to break the combo!
This proves it. You have 0 sense of humour.
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.
Quote from: Hdx on March 20, 2010, 09:41 PM
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
QuoteThe 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?
Quote from: aton on March 22, 2010, 06:03 AM
QuoteThe 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)
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:
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:
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 % NAfter all thats said and done, both sides generate RC4 keys to encrypt the rest of the communication.
IIRC: It's just like Warden:
InKey = RC4Init(Left(K, Len(K) >> 2))
OutKey = RC4Init(Mid(K, Len(K) >> 2 + 1))
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.
Quote from: MyndFyre on March 22, 2010, 02:40 PMHave 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.
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.
Quote from: Varlock on March 26, 2010, 03:37 PM
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.
Thanks for the info.