Author | Message | Time |
---|---|---|
UserLoser | i've been working on somewhat of a client, or gamebot for diablo ii. so far, it creates games, and other users can join it. but, i've ran into some problems, and i'm wondering if anyone is willing to share some public information on D2GS packets, besides having higher level access on BnetDocs. I have found some information at BlizzHackers.com, but the information there doesn't seem to be correct since the new patch for diablo ii. One of my problems is dropping due to timeout, I can't seem to find the correct keepalive? packet. however, i do believe it is d2gs packet 0x6c, also packet decompression I have had some help creating a DLL from this thread: https://davnit.net/bnet/vL/phpbbs/index.php?board=17;action=display;threadid=585 http://www.userloser.net/D2GSClient.dll But, i'm not sure how to use the dll in VB Exported by DLL: [code]unsigned char GamePacketSize(unsigned char *data, unsigned int *size, unsigned int *offset);[/code] What i have in VB, seems to be incorrect: [code] Public Declare Function GamePacketSize Lib "D2GSClient.dll" (ByRef Data As String, ByRef Size As Integer, ByRef Offset As Integer) As String[/code] And [code]GamePacketDecode(unsigned char *indata, unsigned int insize, unsigned char *outdata, unsigned int outmax, unsigned int *outsize);[/code] [code] Public Declare Function GamePacketDecode Lib "D2GSClient.dll" (ByRef inData As String, ByVal inSize As Integer, ByRef outData As String, ByVal outMax As Integer, ByRef outSize As Integer) As Integer[/code] Has the decompression code changed with the new patch? (Skywing?) Or, is that decompression code originally posted completely wrong, or wrong at all? | November 1, 2003, 1:56 AM |
Soul Taker | The code from this forum I tried a long time ago and it seems to cut off parts of the packet. For instance, I could not see an entire message typed by someone, or the starts of some packets. As for a keep-alive, I used packet 0x6a, but I haven't looked at in-game packets with the new patch so that may not work anymore. | November 1, 2003, 5:47 AM |
Skywing | [quote author=UserLoser link=board=17;threadid=3357;start=0#msg26750 date=1067651798] i've been working on somewhat of a client, or gamebot for diablo ii. so far, it creates games, and other users can join it. but, i've ran into some problems, and i'm wondering if anyone is willing to share some public information on D2GS packets, besides having higher level access on BnetDocs. I have found some information at BlizzHackers.com, but the information there doesn't seem to be correct since the new patch for diablo ii. One of my problems is dropping due to timeout, I can't seem to find the correct keepalive? packet. however, i do believe it is d2gs packet 0x6c, also packet decompression I have had some help creating a DLL from this thread: https://davnit.net/bnet/vL/phpbbs/index.php?board=17;action=display;threadid=585 http://www.userloser.net/D2GSClient.dll But, i'm not sure how to use the dll in VB Exported by DLL: [code]unsigned char GamePacketSize(unsigned char *data, unsigned int *size, unsigned int *offset);[/code] What i have in VB, seems to be incorrect: [code] Public Declare Function GamePacketSize Lib "D2GSClient.dll" (ByRef Data As String, ByRef Size As Integer, ByRef Offset As Integer) As String[/code] And [code]GamePacketDecode(unsigned char *indata, unsigned int insize, unsigned char *outdata, unsigned int outmax, unsigned int *outsize);[/code] [code] Public Declare Function GamePacketDecode Lib "D2GSClient.dll" (ByRef inData As String, ByVal inSize As Integer, ByRef outData As String, ByVal outMax As Integer, ByRef outSize As Integer) As Integer[/code] Has the decompression code changed with the new patch? (Skywing?) Or, is that decompression code originally posted completely wrong, or wrong at all? [/quote] I haven't checked if the in-game protocol has changed yet. Are you declaring the DLL export to be stdcall, either explicitly via the __stdcall keyword, or implicitly via the default calling convention compiler option? Visual Basic only officially supports calling stdcall exports. Old versions had an unsupported option for calling cdecl, but I'm fairly certain this has been removed now. | November 1, 2003, 6:40 PM |
UserLoser | Yes, the _stdcall is there Also, would you be able to verify what Brand.X posted here compared to your code, is correct? | November 1, 2003, 7:52 PM |
Soul Taker | I send a hardcoded, random (at the time of coding it, anyway) value in 0x6a and have stayed in games for ~30 minutes helping people mule. | November 2, 2003, 2:57 AM |
-MichaeL- | Could the values maybe be different for ladder and hardcore chars. maybe for regular also? | November 2, 2003, 3:01 AM |
Soul Taker | [code]p.InsertDWORD &H6738A20 p.InsertDWORD &H0 p.SendGamePacket &H6A[/code] I have that sent every time a 15 second timer fires. | November 2, 2003, 5:00 AM |
Paul | From what I can tell 0x6C is the Keepalive packet in 1.10 per the following piece of code, which is on a timer: [code] :6FAAD3D3 C64424046C mov [esp+04], 6C <----- Client update packet type / Keepalive :6FAAD3D8 FFD6 call esi :6FAAD3DA 89442405 mov dword ptr [esp+05], eax :6FAAD3DE E8FDC6FFFF call 6FAA9AE0 :6FAAD3E3 8D542404 lea edx, dword ptr [esp+04] :6FAAD3E7 6A09 push 00000009 <----- Packet length = 9 bytes :6FAAD3E9 52 push edx :6FAAD3EA D1E8 shr eax, 1 :6FAAD3EC 6A00 push 00000000 :6FAAD3EE 89442415 mov dword ptr [esp+15], eax :6FAAD3F2 E811EA0B00 Call 6FB6BE08 <----- Call a send() for auto-update! [/code] If 0x6C isn't the Keepalive I don't know what it is... Edit: I should probably mention that's from the 1.10 D2Client.dll! :) | November 2, 2003, 6:13 AM |
Skywing | [quote author=Paul link=board=17;threadid=3357;start=0#msg26973 date=1067753635] From what I can tell 0x6C is the Keepalive packet in 1.10 per the following piece of code, which is on a timer: [code] :6FAAD3D3 C64424046C mov [esp+04], 6C <----- Client update packet type / Keepalive :6FAAD3D8 FFD6 call esi :6FAAD3DA 89442405 mov dword ptr [esp+05], eax :6FAAD3DE E8FDC6FFFF call 6FAA9AE0 :6FAAD3E3 8D542404 lea edx, dword ptr [esp+04] :6FAAD3E7 6A09 push 00000009 <----- Packet length = 9 bytes :6FAAD3E9 52 push edx :6FAAD3EA D1E8 shr eax, 1 :6FAAD3EC 6A00 push 00000000 :6FAAD3EE 89442415 mov dword ptr [esp+15], eax :6FAAD3F2 E811EA0B00 Call 6FB6BE08 <----- Call a send() for auto-update! [/code] If 0x6C isn't the Keepalive I don't know what it is... Edit: I should probably mention that's from the 1.10 D2Client.dll! :) [/quote] That looks promising. BTW, do you know if they've made any changes to the huffman compression for 1.10? I haven't gotten around to researching gameserver changes yet. | November 2, 2003, 6:39 AM |
Paul | What does huffman compression have to do with anything? Edit: I should have read the thread more thoroughly instead of skimming and only noticing the words Keepalive and 0x6A... :P He's making a game bot! ::) | November 2, 2003, 6:58 AM |
Skywing | [quote author=Paul link=board=17;threadid=3357;start=0#msg26976 date=1067756298] What does huffman compression have to do with anything? Edit: I should have read the thread more thoroughly instead of skimming and only noticing the words Keepalive and 0x6A... :P He's making a game bot! ::) [/quote] IIRC, that's what previous versions (and probably this version?) used for the in-game compression. | November 2, 2003, 8:20 AM |
iago | [quote author=Skywing link=board=17;threadid=3357;start=0#msg26980 date=1067761256] [quote author=Paul link=board=17;threadid=3357;start=0#msg26976 date=1067756298] What does huffman compression have to do with anything? Edit: I should have read the thread more thoroughly instead of skimming and only noticing the words Keepalive and 0x6A... :P He's making a game bot! ::) [/quote] IIRC, that's what previous versions (and probably this version?) used for the in-game compression. [/quote] Yes, it is. I doubt it, since Huffman encoding is a greedy algorithm, and will always find the minimum length; doubt they could improve upon it without using a totally different compression message. But who knows what blizzard does sometimes? | November 2, 2003, 2:24 PM |
Skywing | [quote author=UserLoser. link=board=17;threadid=3357;start=15#msg27070 date=1067803644] Anyone mind explaining what a Huffman algorithm is, and how it is used in this case? [/quote] Google can help you learn about Huffman coding. | November 2, 2003, 8:23 PM |
iago | Simly, Huffman encoding is when you represent the more frequent characters as shorter (unique) binary sequences. If you want to see an example, written in java, it was an assignment that you can find here: http://www.valhallalegends.com/iago/Huffman.rar | November 2, 2003, 11:41 PM |
smoke | To answer the question about the status of huffman compression in 1.10. It appears to be the exact same huffman compression table. I haven't had any problems with my 1.09 and 1.10 beta huffman compression/decompression routines on the realms. I do have a question though... has anybody bothered to extract the new packet length tables for server and client packets? I did this in 1.10 beta, and can do it again... but it is a pain in the a$$. Thanks, smoke | November 9, 2003, 12:35 PM |
Skywing | [quote author=smoke link=board=17;threadid=3357;start=15#msg28271 date=1068381315] To answer the question about the status of huffman compression in 1.10. It appears to be the exact same huffman compression table. I haven't had any problems with my 1.09 and 1.10 beta huffman compression/decompression routines on the realms. I do have a question though... has anybody bothered to extract the new packet length tables for server and client packets? I did this in 1.10 beta, and can do it again... but it is a pain in the a$$. Thanks, smoke [/quote] That's on my list of things to do in order to revamp my in-game support for D2, but I haven't yet done a whole lot with it. I do, however, have a few leads on the subject. Feel free to mail me or somesuch if you want to work together on this. | November 9, 2003, 5:55 PM |
smoke | If you are interesting in where the tables are located. They are at address 6FC08148 and 6FC08418 in D2Net.dll. All entries with value of 0xFFFFFFFF have to be treated in special ways since they are of variable length. The first table appears to be server to client packet lengths and the second table is the opposite. -smoke | November 9, 2003, 11:26 PM |
smoke | I have the rest of the packet size calculations complete. The main one is server to client packet sizes... since many packets can be clumped in the compressed packets. If you are interested in these, please contanct me directly via AIM: smokehl or message me on this forum. -smoke | November 10, 2003, 8:16 AM |
Skywing | [quote author=smoke link=board=17;threadid=3357;start=15#msg28357 date=1068420365] If you are interesting in where the tables are located. They are at address 6FC08148 and 6FC08418 in D2Net.dll. All entries with value of 0xFFFFFFFF have to be treated in special ways since they are of variable length. The first table appears to be server to client packet lengths and the second table is the opposite. -smoke [/quote] Are you sure about them being in D2Net? I'm fairly certain that there's a version in D2Client... Consider the following research of mine: [code] 0000 0000 SCMD_HANDLER struc ; (sizeof=0xc) ; XREF: .data:6FB76274r 0000 SCmdLength dd ? ; base 16 0004 SCmdHandler1 dd ? ; offset (FFFFFFFF) 0008 SCmdHandler2 dd ? ; offset (FFFFFFFF) 000C SCMD_HANDLER ends 000C .text:6FAB50B0 D2GetSCmdLength proc near ; CODE XREF: sub_6FAA9AF0+397p ... .text:6FAB5109 cmp bl, 0AEh ; SCmd ID .text:6FAB510C mov [esp+64h+var_4C], ecx .text:6FAB5110 jnb D2GetSCmdLength_BadSCmd .text:6FAB5116 mov ebx, [esp+64h+SCmdId] .text:6FAB511A and ebx, 0FFh .text:6FAB5120 lea edx, [ebx+ebx*2] .text:6FAB5123 mov eax, dword ptr D2LengthTable_110a.SCmdLength[edx*4] .text:6FAB512A lea esi, off_6FB76270[edx*4] .text:6FAB5131 cmp eax, 0FFFFFFFFh .text:6FAB5134 mov dword ptr [esp+64h+var_40], esi .text:6FAB5138 jz short D2GetSCmdLength_VariableLength ... .text:6FAB53BF D2GetSCmdLength_BadSCmd: ; CODE XREF: D2GetSCmdLength+60j .text:6FAB53BF push 1442h .text:6FAB53C4 push offset aCProjectsD2_22 ; "C:\\projects\\D2\\head\\Diablo2\\Source\\D2Cl"... .text:6FAB53C9 push offset aBcmdNum_scmds ; "bCmd < NUM_SCMDS" .text:6FAB53CE call Fog_10023 .text:6FAB53D3 add esp, 0Ch .text:6FAB53D6 push 0FFFFFFFFh ; int .text:6FAB53D8 call _exit ; (Nice error handling here, Blizzard....) ... .data:6FB76274 D2LengthTable_110a dd 1 ; SCmdLength .data:6FB76274 ; DATA XREF: D2GetSCmdLength+73r .data:6FB76274 ; sub_6FAB54C0+11o ... .data:6FB76274 dd 0 ; SCmdHandler1 .data:6FB76274 dd offset sub_6FAB2130 ; SCmdHandler2 .data:6FB76274 dd 8 ; SCmdLength .data:6FB76274 dd 0 ; SCmdHandler1 .data:6FB76274 dd offset sub_6FAB2180 ; SCmdHandler2 .data:6FB76274 dd 1 ; SCmdLength .data:6FB76274 dd 0 ; SCmdHandler1 .data:6FB76274 dd offset sub_6FAB2160 ; SCmdHandler2 .data:6FB76274 dd 0Ch ; SCmdLength ... ; There are a number of other places that use the above table in a similar manner: .text:6FAB5677 cmp al, 0AEh .text:6FAB5679 mov [esp+10h], al .text:6FAB567D jnb short loc_6FAB56F1 .text:6FAB567F mov eax, [esp+10h] .text:6FAB5683 and eax, 0FFh .text:6FAB5688 lea ecx, [eax+eax*2] .text:6FAB568B lea eax, off_6FB76270[ecx*4] .text:6FAB5692 mov ecx, dword ptr D2LengthTable_110a.SCmdLength[ecx*4] .text:6FAB5699 cmp ecx, 0FFFFFFFFh .text:6FAB569C jz short loc_6FAB56AC [/code] | November 10, 2003, 2:29 PM |
smoke | I am 100% sure they are now in D2Net.dll. Infact both tables are in D2Net.dll. It kind of shocked me as well, as I expected to find them in D2Client.dll. Anyways, a little IDA Pro magic should get the the tables you need as well as the assembly subroutine that decodes variable length packet sizes. The tables have changed significantly enough it is not entirely simple to post the changes. -smoke | November 10, 2003, 3:43 PM |
Skywing | [quote author=smoke link=board=17;threadid=3357;start=15#msg28499 date=1068478996] I am 100% sure they are now in D2Net.dll. Infact both tables are in D2Net.dll. It kind of shocked me as well, as I expected to find them in D2Client.dll. Anyways, a little IDA Pro magic should get the the tables you need as well as the assembly subroutine that decodes variable length packet sizes. The tables have changed significantly enough it is not entirely simple to post the changes. -smoke [/quote] FWIW, the table I found matches the table you found, at least the packet length parts (recv table). | November 10, 2003, 4:15 PM |