D2GS Packet Research

[UserLoser.]

I'm curious as to how Starcraft utilizes the WardenClient, does anybody have any information about it?  I took a look at battle.snp, and there obviously is a WardenClient 'feature' in it.  It's called right after battle.snp creates KeepAliveThreadProc...I just can't think of any messages that could do this in Starcraft (and when it could do it)...

[Forged]

why do we need to know about d2 game packets? i mean who really wants to play that old crappy game anymore let alone waste time making bots and or hacks for it -.-

As you can see by the screen shot below 22,000 of the 38,000 total games going on at the moment are diablo 2.  So I guess majority of battle.net users that still game and don't just sit in chat care about the game...

[l2k-Shadow]

Additionally, the 0x6D ping packet sent to me by Arta (from shadow) seems to be wrong. The data my Diablo 2 sends is:

(DWORD) TC
(DWORD) Unknown - (not null)
(DWORD) NULL

Thats the new 0x6D format. I have found from packet logging that the first byte of the second DWORD contains a value, and the remaining 3 BYTES are null. So this is the format i use.

(BYTE)      0x6D     - ID
(DWORD) Random - Cookie
(DWORD) Random - First byte has a value, the rest are nulls.
(DWORD) Null        - Unknown

I believe you have to update the ping format, and send the new 0x66 warden packet to stay in the game.

That is quite odd, when I packet logged 0x6D last time, I always received a null value for the 2nd DWORD, they must have changed something since then I suppose. Also, this may sound nub, but the RC4 cipher which is apparently used to do some kind of encryption in the 0xAE - 0x66 relation is open source, so it'd be quite easy to break it if someone knows the encryption key... does anyone know if D2GS assigns the encryption key in the 0xAE packet or is it hardcoded inside the client?

[NetNX]

It wouldn't matter anyway since theres more then just the RC4 cipher thats going on there.. I'm sure the key is assigned in the first packet but there is much more involved ...

[hi.times]

I had another look at this 0x66 packet generation, and as far as i can tell this is the entry point procedure for sending 0x66 (does not include the code to generate the packet's data contents, thats somewhere before this in the call stack).

Note - ; DATA XREF: .rdata:6FB86114 ; only referenced through data (odd?)

Code Select Expand


.text:6FB02A30 sub_6FB02A30    proc near               ; DATA XREF: .rdata:6FB86114
.text:6FB02A30
.text:6FB02A30 arg_0           = dword ptr  4
.text:6FB02A30 arg_4           = dword ptr  8
.text:6FB02A30
.text:6FB02A30                 mov     eax, [esp+arg_0]
.text:6FB02A34                 mov     ecx, [esp+arg_4]
.text:6FB02A38                 push    eax
.text:6FB02A39                 call    loc_6FB235A0           ; This procedure constructs 0x66 packet, ESP+10h is packet start position, it then procedes to call the d2net send function(eventually).
.text:6FB02A3E                 retn    8


Now i ran into a problem doing a stack trace from this procedure, at first i thought i was doing something wrong, but it looks like the stack trace didn't work because this procedure isn't directly called by code.

Instead it looks as if a pointer to this procedure is stored as data and called through the data reference. If you use IDA's show xref's command on the procedure above, you will notice it's only called through these data references. I'm hoping maybe someone more skilled than me at debugging/asm could take a look at it and give their opinion.

It makes it extremely hard to trace the call stack when these data based procedure pointers are used. I also have a funny feeling that it's dynamically loading/executing code in some way, because of the way some of the offsets are changing.

Here is some code below to calculate the variable length of the 0xAE packet, which i'm sure we will need when we determine how to decode it's contents.

Code Select Expand


  // Added in 1.11
  // Assumes buf is a pointer to the data portion of the 0xAE packet
_asm
{
mov   ebx ,  buf ; copy buf pointer into ebx
mov   cx ,  WORD PTR [ebx+0] ; move first word into cx(counter)
movzx edx ,  cx ; move cx into 32bit register with zero extend
add   edx ,  2 ; increment length by 2
mov   eax  ,  edx ; return size in eax
}


[NetNX]

I had another look at this 0x66 packet generation, and as far as i can tell this is the entry point procedure for sending 0x66 (does not include the code to generate the packet's data contents, thats somewhere before this in the call stack).

Note - ; DATA XREF: .rdata:6FB86114 ; only referenced through data (odd?)

Code Select Expand


.text:6FB02A30 sub_6FB02A30    proc near               ; DATA XREF: .rdata:6FB86114
.text:6FB02A30
.text:6FB02A30 arg_0           = dword ptr  4
.text:6FB02A30 arg_4           = dword ptr  8
.text:6FB02A30
.text:6FB02A30                 mov     eax, [esp+arg_0]
.text:6FB02A34                 mov     ecx, [esp+arg_4]
.text:6FB02A38                 push    eax
.text:6FB02A39                 call    loc_6FB235A0           ; This procedure constructs 0x66 packet, ESP+10h is packet start position, it then procedes to call the d2net send function(eventually).
.text:6FB02A3E                 retn    8


Now i ran into a problem doing a stack trace from this procedure, at first i thought i was doing something wrong, but it looks like the stack trace didn't work because this procedure isn't directly called by code.

Instead it looks as if a pointer to this procedure is stored as data and called through the data reference. If you use IDA's show xref's command on the procedure above, you will notice it's only called through these data references. I'm hoping maybe someone more skilled than me at debugging/asm could take a look at it and give their opinion.

It makes it extremely hard to trace the call stack when these data based procedure pointers are used. I also have a funny feeling that it's dynamically loading/executing code in some way, because of the way some of the offsets are changing.

Here is some code below to calculate the variable length of the 0xAE packet, which i'm sure we will need when we determine how to decode it's contents.

Code Select Expand


  // Added in 1.11
  // Assumes buf is a pointer to the data portion of the 0xAE packet
_asm
{
mov   ebx ,  buf ; copy buf pointer into ebx
mov   cx ,  WORD PTR [ebx+0] ; move first word into cx(counter)
movzx edx ,  cx ; move cx into 32bit register with zero extend
add   edx ,  2 ; increment length by 2
mov   eax  ,  edx ; return size in eax
}


Damnit. Bnet is learning from their horrible mistakes but ive almost got 0x66 and 0xAE licked with a temporary solution!

[DarkMinion]

I'm working on updating DMBot to allow it to join D2 games....what exactly has changed with the accept sequence on BNETDocs?

I am currently unable to get on D2 to packet log it myself else I wouldn't ask

(lost my CDs)

[NetNX]

Aim me: Grim Reaper Ice
-or-
MSN: [email protected]

I'll send you the iso's

Although not much has changed the only real changes since 1.10 have been the increase in packet id's by one in the D2GS Protocol and the implementation of wardenclient.cpp to piss everyone off

[NetNX]

I finally got around warden although i need a recompression dll 9$ for it if anyone wants to take up the task of doing it

http://forum.valhallalegends.com/phpbbs/index.php?topic=12692.0 <- Replys go here

[dxoigmn]

I finally got around warden although i need a recompression dll 9$ for it if anyone wants to take up the task of doing it

http://forum.valhallalegends.com/phpbbs/index.php?topic=12692.0 <- Replys go here

What do you mean by recompression dll? I'd gladly help if you share your research, now that I have time to investigate warden.

[NetNX]

I finally got around warden although i need a recompression dll 9$ for it if anyone wants to take up the task of doing it

http://forum.valhallalegends.com/phpbbs/index.php?topic=12692.0 <- Replys go here

What do you mean by recompression dll? I'd gladly help if you share your research, now that I have time to investigate warden.

D2GS.dll decopresses incoming packets from the D2GS Server i need a program that will allow me to recompress them...

[Warrior]

...reverse the effects of the decompression code..duh.

[dxoigmn]

D2GS.dll decopresses incoming packets from the D2GS Server i need a program that will allow me to recompress them...

Is that necessary to bypasse/emulate warden? If so, explain please.

...reverse the effects of the decompression code..duh.

Thank you for your contribution.

[Hdx]

D2GS.dll decopresses incoming packets from the D2GS Server i need a program that will allow me to recompress them...

Thats un-needed.
All* Packets sent from the client to the server are un-compressed.
please explain why you want this.
~-~(HDX)~-~

[NetNX]

to stop packets being send from the server to d2 and change them? and/or create my own server