A thought...

[Catt]

While playing with Cavemanbob's new take on SEQ an idea formed, I'm not sure that it hasn't been considered, but I don't recall reading anything similar.

The idea is that the EQ client must have an entry point for the network traffic stream, after it's decrypted, the point where the opcodes are used to decide what to do with each packet/payload.

Once this point is located, why would we not be able to echo this data stream out to SEQ?

[Megaton]

A problem I see with this is having something trigger your memory reads.

Currently the memory reading apps are all externally triggered, they either have a timer or something similar that says, 'Go read memory address X now'.

The place in memory where the packets arrive will most likely be a buffer, with everquest receiving data and acting on it. This will get overwritten with new packets as they arrive. You would need to read this memory after it arrives and before it gets overwritten by the next packet.

One such way would be to install a detour, to hook the processing function and copy that packet out before letting eqgame.exe have it.

Of course, installing a detour means modifying code, and will be detected by the new memory check routines. Unless you detour those as well...

[CybMax]

Well.. i dont know excactly what you mean by this Catt, but to give you a clue about what happens with the datastream and myseq is :

data goes from eq servers to your eq client. Data is then decrypted/decoded in memory. MySeqserver reads this memory in the clients memory where the unencrypted info is, and send it to the myseq gui to show.

So.. to put the data to use "after" the decryption is done, you have to read memory directly.. hence cavemanbob's server software that is running on the client machine.

I would assume that instead of making 2 "layers" in the eqclient, ie. data_in_crypt -> decrypt -> data_in_unencrypt -> eqclient memory, i really think the "data_in_unencrypt" is skipped and data is put directly in eqclient memory after decryption.. So you could not mirror the datastream directly that way.

Yeah.. was a lot of nonsence.. hopefully something useful can be gotten from this Catt :)

[high_jeeves]

I think Catt's point is that somewhere, there is a function in EQ that takes a packet, and converts it to its unecrypted, unencoded form. He is suggested reading the output of this function (actually, reading the memory where this function puts it output, to be more precise). I had considered doing this a while ago, but quite frankly, it is more difficult, and less reliable.

There are timing issues, as discussed by Megaton. We would have to increase the polling speed of the memory readers, inducing possible processor and/or network lag. There is a large amount of data that is in the datastream, that we dont care about. Most (if not all) of the data we care about can be pulled directly from their final memory locations (if we can find it).

--Jeeves

[cavemanbob]

I had considered something along these lines early on, but ended up not doing it largely because I couldn't figure out how to find the offset given the highly dynamic and at the time lacked a way to access it properly. A detour could probably be used, but you'd have to find a function that has the unencrypted data and this would be fairly easy to break, so I just gave up and went the easier route.

[mudtoe]

I think it would be quite difficult to tap into the decoded data stream inside the EQClient code without consequences. You would have to do it in one of two ways, either by passively polling, or by installing some sort of hook in the EQclient code. Both methods have severe drawbacks.

The polling method has the potential to put an unacceptable drain on the CPU resources of the client machine, unless the client machine were a multi-cpu machine, in which case the EQ client and the polling process could run simultaneously on different processors. This is so because the polling program would have to run at a higher priority that the EQ client itself so that it could be assured of not missing a message because the EQ client had control of the CPU. Due to the way Direct3D is written, an application using it for all practical purposes is in a continuous loop itself, so lower priority work never gets a chance to run anyway. Also, the polling interval would have to be small enough that a message would never be missed as it traversed the targeted code, which means we are probably talking continuous millisecond level polling, unless there were a way to watch the incomming traffic on the IP stack and only go into "fast" polling when a message arrived on the stack destined for the EQClient.

The hook method eliminates the need for polling, but obviously a piece of software that hooked the EQ client by replacing some instructions would be very easy to detect. I suppose there might be a way to cause some external event to be triggered when the code started executing on the page you wanted to watch (I'm a mainframe OS/390 operating system person, not a Windows person so I don't know exactly how the Windows APIs work, but you can passively monitor code execution on the mainframe if you are running in supervisor state (the mainframe equivalent of ring 0)). However, like the memory sniffers now, it's possible for the EQClient as long as it's running with administrator privledges, to find out who is snooping in it's memory, if they really wanted to go to the trouble of doing it. Also, in this case the snooping goes on permanently, not just once per zoneing event like the previous sniffers.

Either way it's not a nice picture.


mudtoe