This idea is still very theoretical; I'm in the process of doing the actual research to see if there's anything worth pursuing.
That said, couldn't the guts of the keysniffer be written as an NT kernel driver? You would have to be sure that the identifier associated with the driver (its 'name') was something obscure/misleading, just like all the other keysniffers. Once installed, the driver would wait for eqgame to become an active process. Once eqgame was active, a kernel equivalent of MapViewOfFile could be used to get the entire footprint of eqgame into kernel space. An IOCTL to the driver from user space would return the same information that all these user mode keysniffers are returning but without ever touching the eqgame executable (other than the first copy).
I don't think a keysniffer using a method like this is going to be identified as quickly as others. Then again, this method may not even be possible. Like I said, this is very theoretical. NT driver land is not somewhere I have spent a lot of time in. And asking people to install the Windows DDK to be able to compile the source might be asking too much.
