automatic offset finder

[pooz]

Just tossing out an idea....

As you know finding the offset for the key in memory involved searching for a specific signature in the eqgame.exe.

namely, C1 E0 08 99 09 05

The subsequent four bytes of data is the address in the memory where the decryption key is stored.

Everytime the eqgame is patched this offest changes as well as the offsets where playerinfo, zonename, spawnlist, and target are located in memory.

I know CMB's got experience looking at the data in memory and a few others in the community have the experience as well.

Anyway, my thought is, it should be possible to find a 6 byte signature in the eqgame.exe for each of these 4 offsets needed to run myseq.

If we can scan the eqgame.exe for those offsets rather than manually finding them EVERY minor patch it will keep myseq a bit more reliably usable.

If anyone knows some reason why this won't work, let me know. Also, let me know if there's a reason why we shouldn't do this :P (security of inspecting code manually to look for memory scanning / counter-SEQ activity).

I'll be playing with this tomorrow evening and see if i can reliably find the offsets in eqgame.exe

[user387]

http://seq.sourceforge.net/forums/showthread.php?s=&threadid=3135

there was some reason why this wasn't the best thing to do (TM)

It's just that I can't remember what that reason was....:rolleyes:

[Elmo]

I believe the primary reason against doing this was that if you "blindly" run an automatic offset finder program and start using MySEQ with the new offsets, you risk running right into a trap set by SOE for you. They know as well as you do how these offset finders are working, and if they wanted to, they could modify the real signature, put the old one in a different place, and watch for people to read from the fake offset.

They could, for example, make the faked offset a place in memory that is never read by the normal program operation so that any detected read could be categorized as suspicious. They wouldn't even necessarily need to go out and ban the people they found this way--they could just make a list of them and have a GM start watching those people for suspicious behavior.

People can and have debated back and forth about how hard it would be for them to detect it and to distinguish from other "legal" memory reads, the likelihood that they would bother doing it, privacy issues, etc. However the general point remains that doing it offline using a method like Cavemanbob is using (i.e., dumping memory to a file, and examining the file offline to find the offsets) is at least somewhat safer than just letting the program make assumptions on its own--there's at least some chance that by manually examining things you might discover the trap before you fell into it.

Along the same lines, when the client changes, having someone decompile the client and look for possible detection code before using a memory/key reader on it would also reduce the risk.

There was a lot of effort put into the original key sniffers to make the reads difficult to detect by using low level Windows kernel operations that might bypass the majority of detection methods SOE could use, and I know Cavemanbob mentioned that he might look at that type of thing at some point (but had not done so yet).

[cavemanbob]

It's so easy to find the offsets anyway, it literally takes a couple of minutes if they haven't changed the data structures. This could be useful to root out possible hits though, just to narrow down what to look at, but verifying what it's telling you would be a must.

I'm not sure what to do about detecting memory reads, but I really don't like using debug functions like ReadProcessMemory. For a stop gap solution I'm looking at magotboy's keysniffer to see if that read code couldn't be modified for a server. Using the detours library is another option, but I have no idea how to use that yet.

[Elmo]

Cavemanbob, I think a big part of the reason that Maggotboy's sniffer is difficult to detect is because it is a DLL that is injected into the eqgame.exe process space. Therefore, I think the way you would modify it to work with MySEQ would be to change the injected code to read the memory offsets you need instead of the decryption key, and send the information to the MySEQ client.

You might need to alter the client/server interaction, because I'm not sure if there would be any good/safe/easy way to request the data from the injected code. Instead, you could follow the way the sniffer currently works, just periodically sending updates to the client.

In essence, you would be replacing your server with a modified version of the Maggotboy sniffer, sending the memory structures used by your client instead of the decryption key.

[cavemanbob]

That's pretty much what I was thinking, another option could be to use IPC to communicate between a modified version of the current server and the injected dll.

[Elmo]

My first question about trying IPC would be if the injected code is doing all the memory reading, and is capable of sending the data to a client at an arbitrary IP/port, what else is left that the external server would be doing? Assuming that the injected code would work (I don't think I could write it, but I don't see any glaring obstacles based on what that sniffer already does), it would seem to me that the simplest architecture would be to just replace the server with it.

I also don't fully understand how the IPC would work, since the injected code is part of the eqgame.exe process. I'm far from an expert on the subject though. Even so, if you're sending data to the eqgame.exe process, it seems to me that the IPC transmissions would be pretty easy to detect, and might actually eliminate the privacy issues because SOE would just have to watch for data to be sent to its own process. It might defeat the purpose of trying to make it more stealthy.