Rudimentary Warden information

[Ringo]

iirc, each request (once warden gets going) seeds the next, thats why it has a request order -- skipping a message would brake it.
Anyone wanna explain to me the update routine of that SHA1?
Im happy to help expand on this topic, if somone doesnt mind helping me with this simple little understanding issue im having with warden/lockdown version of SHA1 update cycle's.
I also have a few theorys to put to the test as well.

[l2k-Shadow]

ah ok. i'll try messing around with the seeds later. thx.

[iago]

Anyone wanna explain to me the update routine of that SHA1?

As far as I know, it's identical to the update() routine of standard SHA1.

[Rob]

Anyone wanna explain to me the update routine of that SHA1?

When I originally looked at lockdown, I used standard sha1 code and roughly modified the sha1_final routine.

http://www.onlythechosen.com/sha1_ld.zip if you want to take a look

[Ringo]

As far as I know, it's identical to the update() routine of standard SHA1.

When I originally looked at lockdown, I used standard sha1 code and roughly modified the sha1_final routine.

http://www.onlythechosen.com/sha1_ld.zip if you want to take a look

Thanks both of you for verifying that, im still confused about this 64bit int (and maybe the new padding)
I had another crack at it today, but with no luck.
I will create a new topic and post some code, sadly i still cant get it right. Im sort of beating around the bush a little.
Thanks

[Ringo]

Hmm, 0x02 is all figgerd out
I can now build and send responces with out issue all day long, but there is still a few things im unsure of (like a checksum and less importantly, a module unique 16bit integer)
SC currently only checks for 3(?) hacks, so its pretty easy.
Im going to PM iago before i post any more info

[l2k-Shadow]

Grats. but does your method work for all modules, or just the current one?

[Ringo]

all so far
from what i have seen so far, the module wont effect the responce (unless the checksum is unique to code in the module)
So far, it seems a few values in the request are differnt on a set module, none of which are important, but the checks remain the same.
Now waiting for another module update so i can compare the checksums.

[Barabajagal]

Okay, so is this all correct for the 4 types of SHA used?

Standard SHA (Used for Warcraft 3 CDKeys):
Completely Standard SHA-1.

Broken SHA (Used for Passwords, STAR/D2/W2BN CDKeys):
Endians are not reversed (In "Transform" or "Final")
Buffered to 0x40 bytes, all null.
First RoL is reversed

Lockdown SHA (Used for Lockdown Checkrevision):
Endians are not reveresed (As in Broken SHA)
Buffer is the same as Standard SHA except length*8 and 4 null bytes are in reversed order

Warden SHA (Used for decrypting SID_WARDEN (0x5E) packet):
Exactly the same as SHA except the final 5 DWORDS are individually reversed

[Ringo]

Well im going to bed -- wardens being a bitch and wont update the modules.
Then i noticed i had a log from a module before this one, and the checksum was the same for that request, so is safe to guess that the same checksum code exists in (or out side) the module and is possibly a checksum of the send data, how ever, could do with some infomation on that.
I have pm'ed iago with the current protocol spec, so its his call if he wants me to post it or not (dont wanna jump the gun)

Grats. but does your method work for all modules, or just the current one?

I had another quick think about this, and assuming the requests are process'ed in the warden module, they could implement a whole new/differnt warden protcol in a single module change.
All the current modules just check 3 address's and return sniplets of asm back to the server to be checked (probly map hacks and such that rewrite asm) so its just a case of getting them from starcraft.exe file data.
I did some tests setting the checksum to 0, and the server loves it long time -- altho its probly bannable, but theres only currently about 6 differnt possible checksums, so they could be hard coded.
Persionaly (i now notice) i have been sending my memory blobs back as null, and havent been banned for it yet, been doing that for months lol.
IM going to take a guess that the packet ID's (0x00, 0x01, 0x02) are infact protocol ID's.
0x00 being a version/module check, 0x01 being a FTP-type protocol, and 0x02(+?) being a w/e u wanna call it protocol (hack check or w/e), since 0x02 has a possible packet ID of 0x00 (just after 0x02), but havent seen any other packet id's for 0x02 if thats the case.

Okay, so is this all correct for the 4 types of SHA used?

Standard SHA (Used for Warcraft 3 CDKeys):
Completely Standard SHA-1.

Broken SHA (Used for Passwords, STAR/D2/W2BN CDKeys):
Endians are not reversed (In "Transform" or "Final")
Buffered to 0x40 bytes, all null.
First RoL is reversed

Lockdown SHA (Used for Lockdown Checkrevision):
Endians are not reveresed (As in Broken SHA)
Buffer is the same as Standard SHA except length*8 and 4 null bytes are in reversed order

Warden SHA (Used for decrypting SID_WARDEN (0x5E) packet):
Exactly the same as SHA except the final 5 DWORDS are individually reversed

Sounds about right (assuming w3 uses standard SHA1 -- thats news to me, but never done much with w3)
Apart from lockdown, which does not reverse the 64bit integer (lengh * 8 high/low word)

[Barabajagal]

I meant it does the length after the 0's instead of the 0's first...

[Ringo]

I meant it does the length after the 0's instead of the 0's first...

iirc, they all do (apart from broken SHA1), its part of standard SHA1 padding:
0x80, variable lengh null padding, 64bit int resulting in a padded buffer divisible by 64.
80 00 ........ 00 64bit int = pads orginal data to be divisible by 64

[Barabajagal]

Your own code says otherwise...

Code Select Expand

        If bRE Then
            S = S & A & String(4, 0) & StrReverse(MakeDWORD((Len(S) * 8)))
        Else
            S = S & A & MakeDWORD((Len(S) * 8)) & String(4, 0)
        End If

[Ringo]

Your own code says otherwise...

Code Select Expand

        If bRE Then
            S = S & A & String(4, 0) & StrReverse(MakeDWORD((Len(S) * 8)))
        Else
            S = S & A & MakeDWORD((Len(S) * 8)) & String(4, 0)
        End If

Yeah, that is the 8 byte (64bit int), i just managed it in 1 dword, rather than calculating it on a low/high word, since you would need over 200mb droped into SHA1 for the other word to come into play.




Heres some request/responce spec:

Requests are:

Code Select Expand


(BYTE) Packet ID
(BYTE) Event/Packet ID#2

For each check to preform (while pos < len):
    (WORD)  Module unique 16bit integer (calling this Command for now)
            this seems to change with a new module
    (DWORD) Process Adderss to read
    (BYTE)  Lengh to read
end
(BYTE) hmm not sure of this, changes with the module i think

So, for example:
02 00 30 00 F7 2F 4A 00 08 30 00 B0 7F 49 00 0E 30 00 3D C3 49 00 07 D9

02      Packet ID
00      Event/useage/packet ID#2

30 00         Command (module unique)
F7 2F 4A 00   Address
08            Lengh

30 00         Command (module unique)
B0 7F 49 00   Address
0E            Lengh

30 00         Command (module unique)
3D C3 49 00   Address
07            Lengh

D9        Command#2?  (module unique)


And for building/sending back the responce:

Code Select Expand



(BYTE)  0x02 - Packet ID
(WORD)  Lengh of message (discluding this header of 7 bytes -- ID/Len/Checksum)
(DWORD) Checksum of the send buffer

For each memory request:
    (BYTE)  0x00  Not sure what this is, seems constant
    (VOID)  Chunk of memory from requested address/lengh
end


Heres some out puts of my bot handling a few requests in a single connection:

Code Select Expand


[06:56:11] 0x02 Request: 1
    Command: 0x004E, Address: 0x00497FB0, Lengh: 14
    Command: 0x004E, Address: 0x004A2FF7, Lengh: 8
    Command: 0x004E, Address: 0x0049C33D, Lengh: 7
02 20 00 00 00 00 00 00 84 5E 0C 74 05 E8 F6 54
F9 FF 8B 76 04 85 00 A3 68 CC 59 00 E8 DF 23 00
83 00 00 00 8B 55 08

[06:56:26] 0x02 Request: 2
    Command: 0x004E, Address: 0x0049C33D, Lengh: 7
    Command: 0x004E, Address: 0x004A2FF7, Lengh: 8
    Command: 0x004E, Address: 0x00497FB0, Lengh: 14
02 20 00 00 00 00 00 00 83 00 00 00 8B 55 08 00
A3 68 CC 59 00 E8 DF 23 00 84 5E 0C 74 05 E8 F6
54 F9 FF 8B 76 04 85

[06:56:42] 0x02 Request: 3
    Command: 0x004E, Address: 0x0049C33D, Lengh: 7
    Command: 0x004E, Address: 0x00497FB0, Lengh: 14
    Command: 0x004E, Address: 0x004A2FF7, Lengh: 8
02 20 00 00 00 00 00 00 83 00 00 00 8B 55 08 00
84 5E 0C 74 05 E8 F6 54 F9 FF 8B 76 04 85 00 A3
68 CC 59 00 E8 DF 23

[06:56:57] 0x02 Request: 4
    Command: 0x004E, Address: 0x0049C33D, Lengh: 7
    Command: 0x004E, Address: 0x00497FB0, Lengh: 14
    Command: 0x004E, Address: 0x004A2FF7, Lengh: 8
02 20 00 00 00 00 00 00 83 00 00 00 8B 55 08 00
84 5E 0C 74 05 E8 F6 54 F9 FF 8B 76 04 85 00 A3
68 CC 59 00 E8 DF 23

[06:57:12] 0x02 Request: 5
    Command: 0x004E, Address: 0x004A2FF7, Lengh: 8
    Command: 0x004E, Address: 0x00497FB0, Lengh: 14
    Command: 0x004E, Address: 0x0049C33D, Lengh: 7
02 20 00 00 00 00 00 00 A3 68 CC 59 00 E8 DF 23
00 84 5E 0C 74 05 E8 F6 54 F9 FF 8B 76 04 85 00
83 00 00 00 8B 55 08

The current 3 blobs of memory sent back to the server's warden are:

Code Select Expand


83 00 00 00 8B 55 08
A3 68 CC 59 00 E8 DF 23
84 5E 0C 74 05 E8 F6 54 F9 FF 8B 76 04 85

Im currently setting the checksum (or w/e it is) to 0 and bnet doesnt seem to mind, but there is only currently 3 memory checks, so only about 6 possible checksums.
im also just grabbing those memory blocks from starcraft.exe:

Code Select Expand


R = R & Mid(wFile, lngAddr - &H400000 + 1, lngLen)

wFile being a string holding the file data from starcraft.exe for now. (only seems to be requesting code/asm sniplets)


If im correct then this format for 0x02 can change at any time, as im assuming the downloaded warden module parses/builds it.

[EDIT] After the header of S<>C 0x02's, the buffer can be anything, depending on the warden module at hand.
      The end byte of S>C 0x02, seems to be present on all wardens (SC/BW/D2 at least)

Does anyone fancy reverseing that checksum algorithm used in C>S 0x02?

[iago]

Good work on that! I'm glad to see that somebody picked up where I left off.

If somebody's interested, I'd appreciate it if what Ringo posted could be translated to English (err, I mean formalized ) and added to my wiki. I don't really have time to do it.

<edit> Also, from what I understand, Battle.net isn't currently banning people who send back invalid checksums in Starcraft. However, they occasionally do ban sweeps in other games, so I wouldn't be surprised if they queue it up and look for people who have been caught more than once.