EQ2 Packet Sniffer

[Acid1789]

Hi,

For those of you who dont know, I have been working on figuring out the eq2 packet stream for some time.

I have a working eq2 packet sniffer. It decrypts and decompresses as well as identifies every packet.

You can download the source to it here: http://www.pptournament.m6.net/eq2

[LordCrush]

Wow thank you

[int 21h]

I've been playing with this a bit, but I never recieve many packets. The last packet I recieve is the unimplemented opcode 5 in loginstream.txt. Is it the same for others? After that I no longer have any other packets logged...

[int 21h]

Actually, it looks like the decryption key isn't being returned by getEQ2key()

....

I imagine the key moves with patching of the game executable, when I look at that location in memory I see a bunch of the crypto functions, but I am not sure which key I am looking for. Any hints on this Acid?

[Alethal]

Hi,

Indeed, the key moves each time the game is patched. I have not looked into this deeply but here is what I *think* I know:

- Like MadMonkey said, the key is an offset into an object. EQ2GetKey knows where in memory the pointer to the object will be stored, then it adds an offset (0x60) and grabs the key from there. Each time the game is patched, the area where the pointer is stored changes.

- There is an easy way to find where that area is. The point is only to find again the function that reads/stores the pointer. I only looked into this for 30 minutes yesterday but basically, it's the function in which there is a call to _srand somewhere. The offest is before all the "mov esi[...] eax[...]" calls. It should not be difficult to have the program automatically detects the new area. (check the version of the game, check the version stored, look for a pattern of bytes - which, hopefully, will be unique-, deduces the key position)

Right now my concern is more to know how Acid found this. I tried starting from the recvfrom() and sendto() calls and make my way slowly to the function that decrypts/encrypts the stream but it's way too tedious...

[Acid1789]

I released a new version with updated information. Should work with the latest patch.

Thanks again to those who have donated.

http://pptournament.m6.net/eq2

[Acid1789]

Yet another update.

Adjusted key offset to work with the latest eq2 client.
Added new packets to match eq2 client.
Restructured the code to be more modular and easier to modify.
Added new SSE2 brute force algorithm to break keys(currently disabled)
Fixed a few instability issues.

http://www.pptournament.m6.net/eq2

[Acid1789]

New version, for anyone who is interested

Adjusted key offset to work with latest update
Fixed a few instability bugs.
Added support for zoning!

http://www.pptournament.m6.net/eq2

[Megaton]

Nice work! :-)

I wish I had more time to try and figure out the structures, there are SO many good uses for a decrypted data stream :-)

-
Megaton

[Alethal]

By the way, EQ2 does use a "bubble"-like system for spawns. You only have the list of the mobs that are in a certain radius from you. I am not sure about harvest nodes, someone was saying it might send all the nodes in the zone.

What is interesting is that there is a way to know in-game whether a mob is up or not (similar to the trick used by mages in EQ1), I wonder to what extent that could be used to populate a full list of mobs in the zone.

[Acid1789]

Yes, EQ2 does only send ghost info for a small area around your character. This includes harvest nodes, ?s, widgets, npcs, monsters, players, etc.What trick are you refering to in eq1?

[int 21h]

Tracking extends out of the bubble, how is it implemented?

[Acid1789]

Im not really sure how tracking works (havnt played a tracker class). But from what I have seen, my guess is that it doesnt extend outside of the bubble.

Trackers dont seem to be able to track mobs that are all that far away (1000m or so).

[Megaton]

Hey Acid1789, would you mind explaining a bit about how this all works? Like how channels / streams fit together, and also where XOR Compression fits in?

[Acid1789]

Yeah sure,

A stream is a 'connection' between the client and the server. Each stream can have up to 4 communication channels. A channel contains sequenced packets. This is all independant of the actual game data, EQ1 shares the same protocol.

EQ2 is only using 1 channel and mostly only 1 stream at a time. Every time you zone, the client connects to a new zone server and creates a new stream. All eq2 messages are on channel 0. Due to their encryption implementation, they are incapable of using the other channels unless they changed the way encryption is done.

Channel packets are all sequenced. Fragmented packets are reconstructed in order. A fragmented packet is basicly one large packet spread over smaller sequenced packets. Once a packet is complete, it is decrypted using the RC4 cipher. If the packet is compressed, it is decompressed with a single call to inflate(zlib). The packet is then processed by the packet handler.

Some eq2 packets have Compressed XOR buffers. This is a simple delta compression scheme. The way it works is, if you have a buffer you are repeatedly sending (position info), you XOR the current data with the last data. This turns all the bytes that are the same into 0s leaving you with only bytes of data that are different. Then the buffer is compressed using a byte level RLE scheme to 'remove' all the zeros. The decompress is the inverse, expand then xor with the previous data.