Another detection avoidance idea

[DontWannaSay]

Just another generic idea that could easily be coded into any of the existing sniffers that would make detection somewhat harder for Sony.

First - this would require that your process is not in memory/attached to EQ all the time. It should run, attach, grab the key, detach, and exit off the process list. Now, assuming that your sniffer does work this way - if the very first thing your sniffer does is set its own priority as high as it can go (realtime, whatever that numerical value happens to be I don't feel like looking right now) theoretically it should have sent the key off to SEQ before EQ gets a single CPU cycle to detect it with. If a few CPU cycles do get through to EQ chances are that it was in the middle of drawing a frame on the screen for those few cycles. This would basically force Sony to somehow get an interrupt when EQ's memory is scanned and respond immidiatly instead of going with a polling approach always watching for scanners.

Combined with proper security settings and running EQ and the sniffer under accounts with only the rights they need, it should be virtually impossible for EQ to know it's being watched.

[Lestat]

Interesting idea. You might want to also concider installing a remote admin program on the EQ box (ie: back orifice) and having it allow you to telnet into a dos command prompt, thereby allowing execution to happen via the linux box, which will remove the need for EQW.

Or what about thinking like a virus....have the sniffer "attached" to another program.....might be harder to detect that way....unless EQ is constantly monitoring memory (which i think would slow down gameplay dramatically)

btw for priority sake via command line just do this:

START /REALTIME sniffer.exe

[Whitefire]

Only problem I see with the idea, at least for me, is that I run a Duel Processor MB. I would have to look at it, but I am almost 100% sure that with a duel processor system even if the sniffer was set to real time, EQ would still get CPU time.


Whitefire

[lildr00d]

I just use GPS mode till I get to the zone I want to hunt in then use Telnet from SEQ to EQ box and run the program.


I even went a step further and copied the exe file to the seq box and samba from EQ to SEQ box (Not for security) when the program runs it save the keyfile and since its allready on the SEQ machine I just use the load keyfile command. Then I Ctl C the exec so it stops scanning memory. Only active for a few seconds.

Not a perfect system but it seems to work.

[Flappy]

This load only on demand thing is a good way to go. Telnet is the easy choice, and I wish I had thought of that earlier.

Here's what I did to "be different". I packaged the code into a COM DLL and then made it accessible through a web server. This has 3 benefits: (1) The code is packaged differently from most people here. (2) It runs under a common windows process (dllhost.exe). (3) It loads on demand.

I'm slightly paranoid - I hope this approach keeps me off the radar.

[DontWannaSay]

Actually - my current experimentation is simmilar to Flappy's, except instead of a COM DLL I'm using a .NET Web Service (code is in mverns thread). I think I'll have problems while sitting inside of IIS though if I start trying to change my threads priority and give myself debugger permissions.

My next project though will get a bit more advanced. I don't think Sony will be watching so much for people reading it's memory (IMHO harder to do), but will be simply checking to see if the current process is being debugged (easy to do and can be done under user-level privs). Scanning the task list is meaningless unless you actually look into what the processes are doing, so my plan is to write a server that will listen on a port and otherwize do nothing. Upon receiving something on that port it will set its own priority to realtime, attach, get key, detach, set its priority back to normal, and send the key back to SEQ (likely using the new UDP-key-send that was added in the latest release).

If EQ scans the proc list it will see an innocent exe in RAM along with the many other windows processes currently running - that process will not be attached to EQ, or be doing anything else unordinary that would show up. During the time that it is doing funny stuff, EQ won't get enough CPU time to find out about it. Should be able to run it as a service under XP and then have it run as the System account, and have EQ run with as few privs as I can get it to run with.

Whitefire (or others with SMP systems) - just spawn a second thread during the key grab that is also at realtime priority and just eats CPU cycles for .5 of a second and then terminates. Should be more than enough to keep EQ in the dark while not causing you to lag too much (keeping with the idea that this should only occur when you zone and SEQ needs a new key).

[Lestat]

My semi-final way of running my sniffer was to use telnet as well. Simplest way I found was to actually code a pseudo telnet client with the only purpose of launching the snffer I wrote. The sniffer sets itself to REALTIME priority via windows API calls, reads the key, writes it to a file, sends it via upd to SEQ, and also displays it in my telnet client. Until I have a reason to believe that SoE has implemented anything to monitor any process that reads EQgame.exe's memory, I'm satisfied.

[maggotboy]

It doesn't matter how high you set your priority ... EQ still has the potential of enumerating it.

First off, the CreateProcess() function is a demanding one. Once WinMain is called, even if your very first call is SetProcessPriorityClass, you're still doing several things beforehand ...

MainMainCRTStartup was called before you got to WinMain. CRT initialization was done. This involves several API calls.

Anytime you make an API call which forces a context switch into KERNEL mode, you risk losing the CPU to another thread. Of course, your program is *always* at risk of losing the CPU, but context switches often trigger a loss of CPU cycles.

Forget about solutions that require the full attention of the CPU -- you're not going to get it in USER mode. Verant knows it, we know it, it just aint gonna happen.

I don't like the memory-resident solution, either. I also don't like the out-of-process solution, since it has to open the process and read its memory. Too many context switches while the game is running, IMO. In addition, the out-of-process method has a weak underbelly. All Verant needs to do is use a moveable global memory block that is unlocked and locked on demand, and the out-of-process method is irrevocably broke. Handles can't be inherited across processes, and there'd be no way to retrieve the handle so you could lock and unlock the mem block to read the key.

Maggotboy

[scottie]

Just as a bit of an aside. If you were to use the idea of something "innocent" constantly running in the background, you could write a tftp frontend so it appears that you're just running a little tftp server but make it so that if a specific file on the system is requested (could be any file, real or imaginary), it actually triggers a routine to sniff the code and sends back the key as if it were sending back the file you requested.

Of course, this has all the problems inherent with not being in the same process as eqgame.exe. I'm sure SoE will eventually write moving and locking code to keep outside processes from sniffing it's memory easily.

[Lestat]

If you were to use the idea of something "innocent" constantly running in the background

Even if the sniffer were compiled into an "innocent" program, the calls and functionality still remain constant, so we are stuck with the same conundrum.


I don't like the memory-resident solution, either. I also don't like the out-of-process solution, since it has to open the process and read its memory. Too many context switches while the game is running, IMO. In addition, the out-of-process method has a weak underbelly. All Verant needs to do is use a moveable global memory block that is unlocked and locked on demand, and the out-of-process method is irrevocably broke. Handles can't be inherited across processes, and there'd be no way to retrieve the handle so you could lock and unlock the mem block to read the key.

And also true, if Verant strarts doing some sort of modification of the private/public blocks we are relativley broken in the out-of-process approach. But in retrospect, is there a way to not have an out-of-process application recieve the key?