Valhalla Legends Archive

I just didn't even consider the possibility that I wasn't capturing the entire packet. I was unaware of the snaplen variable and once Ringo pointed me in the direction that my input might be bad, well, I just focused on that and with some help saw the problem.

J

QuoteYou're going to want to hack the D2 application

That's like telling me that all I need to do in order to be rich is to win the lottery

How do I go about hacking D2 that way? where do I even start?

J

Hi,

I'd like to set a couple of facts before I actually ask my question.

Layout - I have a linux gateway that's connected to the internet, all the traffic goes through it.

Goal - A computer on my network will start D2-LoD and enter a game. I'd like to be able to build a valid packet on the linux gateway and send it to b.net.

Now, what do I mean when I say "valid packet"? As you're all probably well aware of, all the traffic to and from b.net is TCP (at least D2GS packets, which interest me), which means I can't just make up a D2GS packet and send it to b.net because there are things to consider. Things like sequence numbers, ack numbers and so on.

My question is - How can I "hook" onto the existing tcp stream that's comming from the computer running D2 and send packets from my gateway which will seem legit to b.net servers? is it even possible to do from that gateway, or do I have to do it from the computer actually running D2?

I'd like to code this in perl, but any help on this matter will be appreciated.

thanks,
J

QuoteI think you're thinking too deep on this. :-p

Then throw me a bone here 
I'm just trying to understand this the best way possible.
You're acting like doing this is the easiest thing ever, and I don't think it is or at least, I can't see how.

QuoteNow, if one of the many game servers went down, all the other servers wouldnt let people join the game, because of the offchance they are inside agame on the server that is down.
But they dont, because 1 lagy/broken serevr would disable the whole network

Could you please rephrase?

I interpert what you said as: If you *somehow* managed to desynch a game, the b.net network recognizes that specific server as  desynched and doesn't allow people who are currently on that desynched server to join games on different servers (i.e "game does not exist") because those people might still be in a desynched game, BUT[/b] that's not the way thing happen today because if things actually happened this way then alot of people won't be able to join different games all the time and b.net would seem to be very unstable. So, as of today, b.net allows you to join other games (on synched servers) even if you were spotted on a game server that is currently marked "desynched"?

Is that correct?
J

Alright, I'm on the brink of despair.

I must have checked my input and decode functions a dozen times, I used both ethereal and tcpdump and I cannot see anything wrong with my input. As far as I know, I'm passing on the data correctly, as opposed to what Ringo suggested earlier. I'm not saying Ringo is wrong, I'm just saying that I cannot see anything wrong with the data I'm handling.
I also read every possible post/thread relater to this subject of decompressing/parsing incoming packets.

Like I said in my previous post, I posted my capture file from tcpdump (it's filtered to only show S->C packets, because that's what I'm having problems with). It can be opened with ethereal too ofcourse.
I asked if someone could please grab the file and run it through thier decoder. No one did, so far.

Can someone please, pretty please (with a bit of sugar on top  ) decode that file for me and post here, or send me even a pm with the result?

Thanks,
J

EDIT: Ringo solved my problem! it seems my tcpdump snaplen was wrong and I wasn't capturing the entire packet, but only 68 bytes of it, which it tcpdump's default.
Thanks again Ringo![/b]

Ofcourse, but there's a difference when it happens to you by "mistake" and when you make it happen.
The questions I asked warz are still relevant (for me anyway).

J

Like I mentioned, I read that  sending some packets to b.net could be a bad idea,it seems like you know which packets can be sent without causing the server to kick you out, would you mind sharing which packets? or at least share which action the packet you sent represented?

A bigger question that came into mind, after reading this post again, is that I actually have no idea how one can actually tell when a game is desynched.
How do you know for a fact that the game you're in right now is desynched? and for how long will it stay that way?

thanks,
J

Hi,

QuoteYou will need to abuse some feature of the game and make the server itself slow for a little bit

That's easier said than done, isn't it?  
It would be great if could elaborate on this. Please.
I haven't tried it myself yet, but I read that generating packets and sending them to b.net servers is a quick way to find yourself banned. I might be wrong.. so correct me if I am.

Did you use some sort of packet manipulation to achieve desynching?

J

Did anyone managed to do this? any who cares to shed some light on how he accomplished it?
What are the qualities of desynching a game anyway? doesn't it drop the player right away from the game? or does it keep the player in the game but the server isn't fully aware of what the player is doing?

I feel like the "desynching" term isn't quite clear, could anyone  explain?

J

Quote from: Ringo on June 14, 2006, 05:34 AM

Quote from: Juniper on June 12, 2006, 04:03 PM

Code Select Expand

[DECODE] [DEBUG] Was passed array 'f2 05 04 60 c8 3f 07 02 8b 30 4c 6a 3e 1b 2d 35 0d c2 a6 08 5c 19 07 e0 e0 51 48 ac 35 ba b0 64 1f 83 81 44 c0 13 1a 8f 86 da 0c 2f 05 e1 e0 32 00 a2 c8 0b 1e 1c 1a 52 08 81 a0 65 2f b8 56 35 04 06 cf 4a 2c d8 2f 05 c7 0c 00 28 64 31 00 ce 1a 52 41 82 f1 dc 77 70 72 6a 09 cd 9e 94 59 b0 5e 0b 63 c0 5c 46 31 98 8f 30 07 1f 7f ff ff ff c0 19 52 08 81 a0 65 2f b8 53 35 03 c6 cf 4a 2c d8 2f 05 a7 0b 28 c6 23 13 ee 11 52 14 00 50 e6 5d 70 94 6a 0d 0d 9e 94 79 94 80 09 04 10 a0 02 87 32 e9 2c 67 44 b4 fa d4 0b a2 5a 7c 05 20 5d 12 d3 e5 c4 0b a4 70 d6 09 82 88 30 48 e1 a8 0c 03 41 71 23 86 71 40 77 04 c9 1c 31 83 40 5c 04 61 40 05 0e 65 d2 a3 86 53 50 6a 6c b4 8e 03 cf 9d 8f fc 89 01 a0 7c 5c 30 04 2e 14 00 50 e6 5d 0e 43 f1 15 6a 20 f9 21 1a 52 08 83 f0 dc 86 70 60 6a 05 4d 9e 94 59 b0 5e 0b 0e 44 00 a0 06 62 bb 80 10 52 08 81 a0 65 2f b9 10 6a 06 cd 9e 94 59 b0 0f 2e 83 20 0e 18 09 c3 a2 d1 28 79 09 0b e0 10 52 08 81 a0 65 2f b9 0e 6a 07 8d 9e 94 59 b0 10 52 41 82 f1 dc 77 70 74 6a 0a 8d 9e 94 59 b0 23 03 f0 a0 02 87 32 e9 a9 2c 36 1d 90 03 12 20 33 03 d2 28 e8 ba 0c 80 38 5c 27 0e 8b 44 a1 e4 24 2f 80 10 52 0d 8b ad 81 47 0a 86 a0 6c d9 e9 45 9b 00 34 02 b3 63 46 c1 68 5e 18 0d 0e c8 08 ca 64 25 8f 21 21 74 a2 1a 14 0a c8 30 5e 3b 8e e8 c1 d1 a8 2a 36 4a 94 d6 14 00 50 e6 1a 58 14 00 50 e6 5d 09 46 a0 d0 d9 69 74 19 80 70 c4 4e 1d 16 89 43 c8 48 5f 10 52 08 83 f0 dc 86 70 5e 6a 05 4d 9e 94 59 b0 10 52 0d 8b ad 81 47 0a 46 a0 70 d9 e9 45 9b 00 10 52 08 81 a0 65 2f b9 10 6a 08 4d 9e 94 59 b0 1f 52 14 00 50 e6 5d 72 18 d4 0f 1b 3d' for processing

I think your compression buffer is broken, because the message is only 106 bytes long, followed by a singlely compressed ping responce (07 1f 7f ff ff ff c0).
So i would say that F2 05 is part of a broken compressed packet. (check your recv buffer, that handles incoming data from the socket)

[EDIT]:
eh, i think your compressed data (quoted data), is currrupt through out.

You believe the data I'm giving the script is wrong/curropted?
Right now I'm passing onto the script the packets I get from tcpdump, I then strip them from their IP and TCP headers and process the data as mentioned above.

I've decided I'm going to post my original capture file.
The capture file can be found at: http://www.box.net/public/eg7dxlfbv6
If someone could decode/decompress this then I believe I'll be able to track down my problem and figure out why I'm not processing the input correctly.

Could someone *please* decode/decompress the capture file I'm posting and post/pm me back the result - I'll greatly appreciate it.

Thanks,
J

Quote from: warz on June 14, 2006, 07:26 AM
D2 game server programming looks fun. Hm. Reverse engineering warden might be fun too.

Perhaps, but I'm still at a point where I'm trying to figure out why my script for dcoding/decompressing data comming for b.net  isn't working perfectly

J

Hi everybody,

Something else/new is bothering me at the moment. I am happily decompressing/decoding a lot of D2 packets already, but every
now and then I stumble on a packet that throws everything out of wack.
Let me paint you some context.

Here are 2 subsequent D2 payloads that my capture prog (tcpdump) is feeding into my script. I feel I should mention that I am
looking at traffic coming from b.net on TCP port 4000 (so D2GS S>C traffic).

OK, here come the packets:
[D2 PAYLOAD] 12 44 02 8f ad 40 ba 22 e1 f5 a8 17 44 3f 9f 5a 81 70
[D2 PAYLOAD] f2 05 04 60 c8 3f 07 02 8b 30 4c 6a 3e 1b 2d 35 0d c2 a6 08 5c 19 07 e0 e0 51 48 ac 35 ba b0 64 1f 83 81 44 c0 13 1a 8f 86 da
[D2 PAYLOAD] 0c 2f 05 e1 e0 32 00 a2 c8 0b 1e 1c
[D2 PAYLOAD] 1a 52 08 81 a0 65 2f b8 56 35 04 06 cf 4a 2c d8 2f 05 c7 0c 00 28 64 31 00 ce

SO we have 4 packet payloads here. They are the data portions of 4 TCP segments following eachother in the TCP flow coming from port 4000.
The size byte of our first packet is 0x12, which is 17 decimal, so everything is there. I am decoding this to:
DECODE] 07 88 03 80 04 02 07 90 03 80 04 02 07 98 03 80 04 02 (18 bytes)
And then splitting it into real D2 packets:
[DECODE] SPLIT: 07 88 03 80 04 02 (6 bytes) = [ACTION] MAPADD (= 07)
[DECODE] SPLIT: 07 90 03 80 04 02 (6 bytes) = [ACTION] MAPADD (= 07)
[DECODE] SPLIT: 07 98 03 80 04 02 (6 bytes) = [ACTION] MAPADD (= 07)
This completes the processing of our first payload. Untill now, everything for me looks OK (of course, please correct me if I am wrong).

OK, now, our next payload:
[D2 PAYLOAD] f2 05 04 60 c8 3f 07 02 8b 30 4c 6a 3e 1b 2d 35 0d c2 a6 08 5c 19 07 e0 e0 51 48 ac 35 ba b0 64 1f 83 81 44 c0 13 1a 8f 86 da
The first byte is greater than 0xF0, thus we use the first 2 bytes to calculate the size. I won't go into details here, since all of you are familiar with how it's done, but the size calculated from 0xF2 0x05 is 517.
Now, we only have 40 bytes here, so to get to our 517, I will have to append some packets to this one, before I actual start to decode/decompress it. I do this (with more packets than the 3 in my example, since those 3 don't add up to 517 yet, I just didn't want to spam too much).

About 5 seconds (and a lot of TCP segments) later I have enough bytes to make it add up to 517.
The end result is:
[DECODE] [DEBUG] Was passed array 'f2 05 04 60 c8 3f 07 02 8b 30 4c 6a 3e 1b 2d 35 0d c2 a6 08 5c 19 07 e0 e0 51 48 ac 35 ba b0 64 1f 83 81 44 c0 13 1a 8f 86 da 0c 2f 05 e1 e0 32 00 a2 c8 0b 1e 1c 1a 52 08 81 a0 65 2f b8 56 35 04 06 cf 4a 2c d8 2f 05 c7 0c 00 28 64 31 00 ce 1a 52 41 82 f1 dc 77 70 72 6a 09 cd 9e 94 59 b0 5e 0b 63 c0 5c 46 31 98 8f 30 07 1f 7f ff ff ff c0 19 52 08 81 a0 65 2f b8 53 35 03 c6 cf 4a 2c d8 2f 05 a7 0b 28 c6 23 13 ee 11 52 14 00 50 e6 5d 70 94 6a 0d 0d 9e 94 79 94 80 09 04 10 a0 02 87 32 e9 2c 67 44 b4 fa d4 0b a2 5a 7c 05 20 5d 12 d3 e5 c4 0b a4 70 d6 09 82 88 30 48 e1 a8 0c 03 41 71 23 86 71 40 77 04 c9 1c 31 83 40 5c 04 61 40 05 0e 65 d2 a3 86 53 50 6a 6c b4 8e 03 cf 9d 8f fc 89 01 a0 7c 5c 30 04 2e 14 00 50 e6 5d 0e 43 f1 15 6a 20 f9 21 1a 52 08 83 f0 dc 86 70 60 6a 05 4d 9e 94 59 b0 5e 0b 0e 44 00 a0 06 62 bb 80 10 52 08 81 a0 65 2f b9 10 6a 06 cd 9e 94 59 b0 0f 2e 83 20 0e 18 09 c3 a2 d1 28 79 09 0b e0 10 52 08 81 a0 65 2f b9 0e 6a 07 8d 9e 94 59 b0 10 52 41 82 f1 dc 77 70 74 6a 0a 8d 9e 94 59 b0 23 03 f0 a0 02 87 32 e9 a9 2c 36 1d 90 03 12 20 33 03 d2 28 e8 ba 0c 80 38 5c 27 0e 8b 44 a1 e4 24 2f 80 10 52 0d 8b ad 81 47 0a 86 a0 6c d9 e9 45 9b 00 34 02 b3 63 46 c1 68 5e 18 0d 0e c8 08 ca 64 25 8f 21 21 74 a2 1a 14 0a c8 30 5e 3b 8e e8 c1 d1 a8 2a 36 4a 94 d6 14 00 50 e6 1a 58 14 00 50 e6 5d 09 46 a0 d0 d9 69 74 19 80 70 c4 4e 1d 16 89 43 c8 48 5f 10 52 08 83 f0 dc 86 70 5e 6a 05 4d 9e 94 59 b0 10 52 0d 8b ad 81 47 0a 46 a0 70 d9 e9 45 9b 00 10 52 08 81 a0 65 2f b9 10 6a 08 4d 9e 94 59 b0 1f 52 14 00 50 e6 5d 72 18 d4 0f 1b 3d' for processing

So now the above packet is decoded to:
[DECODE] AC BD 2A C5 41 13 00 AF 11 8A 16 80 11 1C E4 00 00 AA 01 BD 2A C5 41 0A 69 FE 01 69 BD 2A C5 41 09 AF 11 8A 16 00 00 04 00 00 EF EF 81 F6 88 63 8B 81 01 BF 00 0A 32 FB 65 97 01 E6 11 A9 16 01 00 0D 4B 00 05 96 ED 01 F2 88 61 0B 84 01 FC 0A 00 BB 02 00 7F 7F 01 C6 11 B1 16 01 00 0D 4B 00 05 96 EC 81 ED 08 60 0B 82 00 5C 00 8F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 5C 52 00 AB BF F7 97 01 E3 11 A7 16 01 00 0D 4B 00 05 96 EB 01 EA 08 5F 0B 03 01 D3 0A 45 88 7A 95 01 D8 11 BF 16 01 00 0D 82 00 4D 4F B0 D0 00 2F 00 06 00 00 0C 00 00 00 0A 00 05 00 00 1F 30 15 00 00 80 04 02 07 80 03 88 04 02 07 80 03 90 04 02 0A 01 FE AF DF BB 0A 01 FD 9F BF 57 0A 01 FA 3F 7F AF 0A 01 F5 BF B9 94 00 DE 88 7A 95 52 01 F7 11 C1 16 80 19 91 03 20 98 00 00 00 E8 8D A8 57 09 AA 01 DE 88 7A 95 22 2A 33 80 07 29 0A 0E 00 4D D2 93 75 06 00 18 09 11 9C 16 01 00 0D 4B 00 05 96 E9 01 E2 88 5C 0B 02 01 4F B3 AB BF F7 97 01 E2 11 A4 16 01 00 0D 4B 00 05 C9 00 01 04 00 00 A0 18 05 DC 7C 80 38 82 D6 02 00 00 71 42 D2 FB 65 97 01 E0 11 A7 16 01 00 0D 4B 00 05 CF 0A 00 BB 02 00 7F 7F 01 C7 11 B4 16 01 00 0D 4B 00 05 34 CC DE 88 7A 95 11 30 1B 7E 04 BC E2 F9 CA F0 1F 95 BD 85 ED 40 7C 80 38 82 D6 02 00 00 4F B3 C3 95 FF 9B 01 E4 11 A4 16 01 00 0D 4B 00 05 8D 7B 13 00 05 00 00 08 05 64 5A 5D 10 20 A0 00 65 0C 39 82 D6 02 0D 2E 06 04 69 B8 BA 7F 7F 08 C7 11 B4 16 0D 0D 11 00 DE 88 7A FC 05 3F 88 7A 95 D8 11 BF 16 80 95 BE 85 F4 40 7C 80 38 82 D6 02 00 00 2C 0A 32 93 75 06 00 18 96 14 00 9C 16 01 00 0D 4B 00 05 CF 0A 73 02 80 00 9B 01 E1 11 A5 16 01 00 0D 4B 00 05 71 42 D2 FB 65 97 01 E2 11 AA 16 01 00 0D 4B 00 05 29 00 0A 45 88 7A 95 01 CE 11 A7 16 01 00 (566 bytes)

And then I start splitting it up:

[ACTION] [DEBUG] The action ID is AC which has the length of 17 bytes.
[DECODE] SPLIT: AC BD 2A C5 41 13 00 AF 11 8A 16 80 11 1C E4 00 00 (17 bytes)
[ACTION] COMASIGNMENT - A computer player has been  assigned a location in our view (= AC)

[ACTION] [DEBUG] The action ID is AA which has the length of 10 bytes.
[DECODE] SPLIT: AA 01 BD 2A C5 41 0A 69 FE 01 (10 bytes)
[ACTION] COMINFOADD - An object came into our 4 screen view (= AA)

[ACTION] [DEBUG] The action ID is 69 which has the length of 12 bytes.
[DECODE] SPLIT: 69 BD 2A C5 41 09 AF 11 8A 16 00 00 (12 bytes)
[ACTION] COMSTATEASIGN - A computer player stats have changed (= 69)

[ACTION] [DEBUG] The action ID is 04 which has the length of 1 bytes.
[DECODE] SPLIT: 04 (1 bytes)
[ACTION] Message ID 04: *** UNKNOWN ***

[ACTION] [DEBUG] The action ID is 00 which has the length of 1 bytes.
[DECODE] SPLIT: 00 (1 bytes)
[ACTION] Message ID 00: *** UNKNOWN ***

[ACTION] [DEBUG] The action ID is 00 which has the length of 1 bytes.
[DECODE] SPLIT: 00 (1 bytes)
[ACTION] Message ID 00: *** UNKNOWN ***

And here my script fails. The next byte, after splitup is 0xEF and that's something that, as far as I know, is just not right, I should never bump on a 0xEF packet.
Now, I have no idea, really, where I went wrong exactly. Ringo posted something a while ago (http://forum.valhallalegends.com/index.php?topic=11756.msg123533#msg123533) that had some code there as an example to show people how packets were split up. I used this and changed the input array to hold my packet (the F2 05 04 ... one). The output then shows the packet being decoded the same way as I do it. You see it being split up exactly like my script is doing and then you see it crash ... at the same byte (0xEF) as my script.
Now, since I don't think that there is actually anything wrong with what Ringo coded, I am thinking that I am being wrong in trying to decode/process the F2 05 04 ... packet. But I don't find any reason why I shouldn't be doing it. That's just where the packet(s) start and I have no idea why or if I should skip anything.

I know this is probably a longshot, but does anybody have a clue what I might be doing wrong here?

Thanks in advance!

Juniper

I don't like to bounce threads, but I'm really stuck without some help on my previous post 

Can anyone help me out?

thanks,
J

Hi!
Me again!

Using the tips you guys gave me here I am now able to glue a lot of S>C traffic back together and then decompress it.

There are still some packets that are confusing me though.

Take this packet for example:
01 dc 8a 17 8b 40 18 be 38 87 cc 9e 8a 21 68 92 17 83 92 59 24 ac 4c 0c c1 88 1c 84 01 3c 47 11 42 e8 49 0e c5 e4 20

This is the data portion of a given TCP segment. My previous D2 packet ended in the previous TCP segment (meaning all bytes required to fill whatever was in the D2 size byte were found in the previous TCP segment).
So this means I need to start processing this packet as a "new" one.

This would also mean that the D2 size byte is "01" meaning that the data portion of our D2 packet is zero bytes in length. That's already fairly odd.
If I for a minute assume this to be correct, that would mean that the first D2 packet to be found in this TCP segment is "01" and then the next one starts with "dc". The size byte in the 2nd packet is "dc" and processing could continue afterwards, having whatever is missing here be appended from following TCP segments, and so on.

The problem I am facing though is when I do as I just described then all the output of the packets/segments that follow this one stop making sense. If I ignore this packet (and all other packets where there apears to be more than 1 D2 packet to be found in the same TCP segment), then all my output continues to make sense. I am able to append segments to eachother forming new/real D2 packets as required by the D2 size byte and they decode/decompress to packets that actually seem to be correct for the situation in question.

So anyway, I guess my question is; if anyone were to encounter the packet I pasted above, how would it be processed? Assume that this is the output of ALL D2 bytes, so INCLUDING the header.

thanks,

J