Rudimentary Warden information

[Barabajagal]

RSHA... and it has all the standard BNET hashing stuff (Passwords, CDKeys, and various SHA hashes)

[brew]

Yeah, Rob is using the same method to respond to the requests as Ringo right now. It's not by any means solved, though.

[Rob]

Yeah, Rob is using the same method to respond to the requests as Ringo right now. It's not by any means solved, though.

My method differs from Ringo's as it does not require the game to be loaded.  I patch required memory addresses within battle.snp and call the functions directly to handle warden in the same method that the game would.  This method has worked since first developing it, even when modules have changed.

[Barabajagal]

So you're letting Maiev handle everything for you... not quite a redistributable solution...

[Rob]

So you're letting Maiev handle everything for you... not quite a redistributable solution...

Redistribution was never my intention.

[Barabajagal]

Ya, I know. That's why it's always my stuff that ends up getting used.

[Rob]

Ya, I know. That's why it's always my stuff that ends up getting used.

Battle.net is a better place without a public warden implementation.  You should really rethink the implications of your release before doing it again.

[Mystical]

So I should make my DLL require the Hash Files like it used to? XD

what do you mean by that?

Don't you recall the first revision Andy wrote of his DLL needed a few extra DLL's to run?

I think one was like RSA.dll? It contained a few hashing functions, (I hardly remember so correct me if I'm wrong)


Edit: Meh. Andy replied ^^

Nah I didn't use the DLL then, anywho, the public implementation is bad to battle.net when it gets into the wrong hands like trick & his warbots or nes_sucks,

but for the few of us that like to login just starcraft on our bots, well.. Yeah kinda sucks, now my progress of work playing with Ringos new fun modules for game join/creation is at a uttor hault. :[

[Barabajagal]

Ok... I won't update my Warden DLL... It apparently caused too much trouble.

[Mystical]

well that sucks

[Ringo]

Yeah, Rob is using the same method to respond to the requests as Ringo right now. It's not by any means solved, though.

I'm not sure where you got that from.
The method Rob came up with was nothing like the method I came up with.

My method differs from Ringo's as it does not require the game to be loaded.

The orginal method I conjured up, didn't require the game be loaded, altho I orginaly needed to watch the traffic between the game and the server inorder to take the next step.
That said, ive only ran 8 bots, for 20mins uptime in a little test I did awhile back with the current warden, but haven't continued with it.
Altho the responces I send back are pretty much 100% safe, I don't really want to go into detail on what I do, because blizzard could patch/detect it in a nano-second, if they knew what to look for :p


Anyway, back to what I orginaly posted some days ago:
I probed somthing today and found out somthing else.
It seems the "second layer of encryption" infact replaces the first.
This is what I know for sure so far (keep in mind, I really haven't spent much time at all on this todate)
1) the value the server sends to the client in 0x05, is based on the orginal RC4 encryption.
- By that, I mean it could be based on another logon variable, the orginal seed of the rc4(1st dword of the cdkey hash) or somthing alike.
- it's also based on the current module as well.
2) the value the client sends back to the server in 0x04 seems to be dependent on the value in 0x05, or what went into generating the value seen in 0x05.
3) I still can't say for sure what those 2 value's really are or how to generate them.
- i'm wundering atm, if the server value is an MD5 of *somthing* and the client value is a SHA1 of *somthing* alike.
- they could just be 16 bytes both ways, but i'm not sure if the client value is a checksum+16 bytes, or just 20bytes.
4) After the 0x05/0x04 have pass'ed, the orginal rc4 encryption is pretty much useless.
- i'm guessing the orginal RC4 keys need to be updated *somehow* with the new value's in 0x05/0x04 or a new set of keys created -- that is, if the values in 0x05/0x04 seed an rc4 encryption and not somthing else.

I think it's safe to say, the client and server value, are pretty important.

I would really like to see/get my hands on the default module (raw) that the client's are currently running, that is, if it changed in the latest patch.
iago, how did you orginaly go about extracting it? :p

[PunK]

Tell me if I get this. I'm trying to make sense of this.

Warden now requires you to store another log on variable along with first 4 bytes of the cdkey hash. On top of that, the new value joints to with the old RC4 encryption to create the 0x04 value?

[Ringo]

Warden now requires you to store another log on variable along with first 4 bytes of the cdkey hash.

Maybe, but very unlikely -- I still can't rule out, 100% that another logon value comes into play, but I would make the assumption it doesn't. I figger, it's best not to put all the eggs into 1 basket just yet.

On top of that, the new value joints to with the old RC4 encryption to create the 0x04 value?

yeah, somthing along those lines. I really haven't probed this much at all, so I guess you could say i'm open minded for now.

let's say for example, you're seed (first dword of key hash) is always the same.
The value sent from the server in 0x05, will always be the same, and the value sent back from the client, will also be the same to.
Now, when the module changes, these value's will change.
The reassion these value's are not always the same for a given module, is because the seed changes each seassion.
So, it's safe to say, the value in 0x05 at least, is tied to the module and the seed, the SHA1 data stream, or the RC4 keys generated from them.
I can't say for sure if the responce value in 0x04, is tied into the value in 0x05, or if the client generates it's own value in the same manner the sevrer generate's it's 0x05 value, with out probeing deeper.
It take's a fair amount of time and hastle to test thses kind of things, so you need to be fairly motivated to do it.
I will post some logs in awhile from now, If i get around to it, showing what I mean.


[edit]:
Both seassions have the same seed:

Seassion1:

Code Select Expand


[07:46:51] WARDEN: Recv
00000000    00 A9 4A 90 B0 BC AD FD 19 DB 79 ED 51 69 69 FC       ..J.......y.Qii.
00000010    17 12 63 A2 D4 83 09 9B 28 A7 3F C9 1A 9B 3B 4C       ..c.....(.?...;L
00000020    E0 51 48 00 00                                        .QH..

[07:46:51] WARDEN: Sent
00000000    01                                                    .

[07:46:51] WARDEN: Recv
00000000    05 1D 58 E3 7E 07 13 84 41 53 02 22 AA 6D CD EE       ..X.~...AS.".m..
00000010    C2                                                    .

[07:46:51] WARDEN: Sent
00000000    04 3A A9 B5 C3 C0 7D 96 7B 71 04 C5 57 CE FC BA       .:....}.{q..W...
00000010    C1 AE A1 0C 54                                        ....T

[07:46:56] WARDEN: Recv
00000000    1E D1 8C 9B 20 3D F4 B1 40 43 76 91 17 AC F4 2E       .... =..@Cv.....
00000010    4D BD 1C D3 47 25 15 FF 9F B6 77 D6 A1 4A 92 52       M...G%....w..J.R
00000020    38 0E F3 D1 BD 1B 35 E6 16 21 39 93 18 5F 95 48       8.....5..!9.._.H
00000030    13 6E 85 CE 74 11 9A DB 7D 15 F9 DE EF C9 92 FD       .n..t...}.......
00000040    44 7C 52 8C 0A BE B3 CC 07 59 47 B8 8A 0C 53 29       D|R......YG...S)
00000050    8E C3 AB AB F5 84 89 11 EB 1C D5 60 D1 0A C5 2B       ...........`...+
00000060    3F F5 0F 7B 2C 91 A6 FE 4A 77 7E 81 FC 31 3B CF       ?..{,...Jw~..1;.
00000070    D2 7A B9 77 C2 1F EE CA 58 E0 AC 71 EE 17 F9 C0       .z.w....X..q....
00000080    45 B9 1B 4B 7E 49 F6 8F A4 E1 31 89 D7 21 11 F0       E..K~I....1..!..
00000090    6A 78 DF 96 14 BF 52 85 C8                            jx....R..

[07:46:56] WARDEN: Sent
00000000    D6 B1 26 26 7D 3D 9A 5E C6 32 8B 51                   ..&&}=.^.2.Q


Seassion2:

Code Select Expand


[08:39:31] WARDEN: Recv
00000000    00 A9 4A 90 B0 BC AD FD 19 DB 79 ED 51 69 69 FC       ..J.......y.Qii.
00000010    17 12 63 A2 D4 83 09 9B 28 A7 3F C9 1A 9B 3B 4C       ..c.....(.?...;L
00000020    E0 51 48 00 00                                        .QH..

[08:39:31] WARDEN: Sent
00000000    01                                                    .

[08:39:31] WARDEN: Recv
00000000    05 1D 58 E3 7E 07 13 84 41 53 02 22 AA 6D CD EE       ..X.~...AS.".m..
00000010    C2                                                    .

[08:39:31] WARDEN: Sent
00000000    04 3A A9 B5 C3 C0 7D 96 7B 71 04 C5 57 CE FC BA       .:....}.{q..W...
00000010    C1 AE A1 0C 54                                        ....T

[08:39:36] WARDEN: Recv
00000000    1E D1 8C 9B 20 3D F4 B1 40 43 76 91 17 AC F4 2E       .... =..@Cv.....
00000010    4D BD 1C D3 47 25 15 FF 9F B6 77 D6 A1 4A 92 52       M...G%....w..J.R
00000020    38 0E F3 D1 BD 1B 35 E6 16 21 39 93 18 5F 95 48       8.....5..!9.._.H
00000030    13 6E 85 CE 74 11 9A DB 7D 15 F9 DE EF C9 92 FD       .n..t...}.......
00000040    44 7C 52 8C 0A BE B3 CC 07 59 47 B8 8A 0C 53 29       D|R......YG...S)
00000050    8E C3 AB AB F5 84 89 11 EB 1C D5 60 D1 0A C5 2B       ...........`...+
00000060    3F F5 0F 7B 2C 91 A6 FE 4A 77 7E 81 FC 31 3B CF       ?..{,...Jw~..1;.
00000070    D2 7A B9 77 C2 1F EE CA 58 E0 AC 71 EE 17 F9 C0       .z.w....X..q....
00000080    45 B9 1B 4B 7E 49 F6 8F A4 E1 31 89 D7 21 11 F0       E..K~I....1..!..
00000090    6A 78 DF 96 14 BF 52 85 C8                            jx....R..

[08:39:36] WARDEN: Sent
00000000    D6 B1 26 26 7D 3D 9A 5E C6 32 8B 51                   ..&&}=.^.2.Q


I will post another log later, when the module finaly changes, and you should see that the values in 0x04/0x05 change.
The values would also change, if the seed changed, but in the above 2 examples, they were 2 differnt connections with the same seed (1st dword of cdkey hash).

I also checked somthing else why gathering these logs.
When I changed a byte in the 0x05 value, the client responded with a totaly differnt 0x04 value.
So it's safe to say, the value in 0x05 is invloved in generating the value in 0x04. But i'm sure, that's just the tip if the iceburg.
You should have probly noticed by now, that the request is pretty much static, and there is also only a handfull of requests and responces, like before. Hence why I said blizzard are as dumb as ever.
This is probly all just to verify the client really does have the given module, and changes the encryption key's to throw us all off the cent.
I can't see why, once we figger out how to generate the responce to 0x05 plus the new encryption keys, why we can't just hardcode the requests vs responces, like before.
Basicly, If Checksum(Request) = X then send Y -- should be as simple as that, thank's to blizzards wunderfull imagination.
Figgering out how to generate the responce to 0x05, should be pretty easy -- you could set up an array of buffers containing all the value's you know go into it, then brute force every combination possible untill you get a matching value to that seen in 0x04.
I'm pretty sure that the new encryption key's are generated after this process tho, so they would be abit harder to figger out that way.

[herzog_zwei]

I can't see why, once we figger out how to generate the responce to 0x05 plus the new encryption keys, why we can't just hardcode the requests vs responces, like before.
Basicly, If Checksum(Request) = X then send Y -- should be as simple as that, thank's to blizzards wunderfull imagination.
Figgering out how to generate the responce to 0x05, should be pretty easy -- you could set up an array of buffers containing all the value's you know go into it, then brute force every combination possible untill you get a matching value to that seen in 0x04.

It's only true in theory but not in practice.  0x05 is a challenge and 0x04 is the response to verify that the challenge was computed correctly.  It also changes other things, one of them being the pad.  The computation of 0x05 is different in each module so you're not going to have much luck brute forcing a 128 bit challenge (nor would you want to) when the modules change every few hours.  So module 1 might compute 0x05 as X^2+5 while module 2 computes it as sqrt(X+3)/2 (it's much more involved and complicated than that but you get the idea).  0x04 is SHA1(f(0x05)).  One other improvement to this version over earlier ones is it attempts to foil replaying of responses.  Other than those, the protocol remains the same as before.  Things like these are the reason why I've said not to worry about how to compute checksums, what hasher to use, what protocol to use, what encryption scheme to use, etc., because it is all dependent upon the module they give.  A generic warden responder won't work in the long run; the specific warden module's code has to run or be analyzed at some point to get the correct response (which for now can mostly be replayed).

[Barabajagal]

Can we... run the modules in a virtual environment or something? I've never understood why that wouldn't be possible for dealing with things like checkrevision and warden. Just emulate enough of the game's memory to pass as a running client?