Could a kernel driver be used?

[Kraken]

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.

[Ratt]

You could really muck up a lot of things doing it this way, but if you could pull it off, it would be great.

[Yueh]

I was looking into this as well. I have a skeleton put together but am going to wait until I can afford to deal with the havoc I'm sure to create The question is, if we get a ring 0 kernel keyreader rolling, what route does VI use to detect it? Is it truely undetectable?

[a_necro00]

Sorry Folks.

As EQ likes to run with administrator privileges they could just intercept ReadProcessMemory and catch everyone looking some particular address (like 0x00773b90) at some particular process id. It's much more difficult to do this at XP & 2000 but it's doable and as Ratt said their programmers are not dumb.

Your ring 0 kernel driver need to call this routine to lookup the memory, so it would be detectable.

You will probably need to mimic the sniffer to behave like another program (like memory optimizers, they are legal ), they look at big chunks to do the reorder. And on that big chunk you could do the lookup inside.

As is discussed in another thread, undetectability is impossible.

[MisterSpock]

Actually, I don't think a kernel mode driver would use ReadProcessMemory.

I was looking at a little program yesterday that reads NT/2000/XP physical memory and runs as a kernel mode driver. It did not use any of these higher level api's.

[a_necro00]

Interesting Mr. Spock. I didn't know that. Have some example code from Microsoft and they use standard APIs.

If you are right, then that barrier is gone. I saw yesterday some posts about EQ locking his memory to prevent or trigger something if any app read his memory, but as Memory Optimizers need to read it that approach will not protect them, and surely they will not trigger in case of ring 0 reads.

So, in theory, we need at ring0

1.- Get Starting Base Address of eqgame.exe wihtout API calls
2.- Lookup the address manually and sniff

Edited: I receive yesterday a new version of the Windows DDK, looking for anything that could help to do step 1.

[a_necro00]

Yueh, under what mode is your skeleton created? after some research, there are two types of device drivers. The ones that run in User Mode and have Win API access and the ones that run in Kernel Mode and don't have anything except some RTL & Kernel Functions.

As the goal is to be really undetectable, driver needs to run in Kernel mode. In that mode, documentation is clear that drivers do not have access to User Virtual Space unless that app call the driver.

If that happens (which is not impossible, I believe that you can mimic a current driver writing a redirector) it's possible to have access to a section of the current NT process using some Zw functions (at home now, tomorrow I will edit this with the exact function)

This could of course be the real undetectable sniffer because there is no way for EQ to catch fingerprints at Kernel space (NT, 2000 & XP only), problem is that it's construction is not only tough, but each OS have it's restrictions.

[lostinspace]

Can someone (a_necro?) post link to any post that shows how it is possible for user application to intercept ReadProcessMemory ?

Would be helpful to decide what not to do in sniffer, or what to try and check. So far I didnt find some info on how they can really intercept it, or detect memory reading.

Not saying that it can not be done, but it would be more productive if people post exactly how it can be done and help rest of sniffer program users guard agains it, instead of just repeating "there are number of ways to detect" and not showing any of those ways . I'm sure that Sony programmers can find info from other resources too, so examples of ReadProcessmemory detection could only help sniffer users.

[mvern]

API hooking the easy way:

http://research.microsoft.com/sn/detours/

Fairly invasive, and interestinly enough, the same method macroquest uses to do some of it's dirtywork.

Going the kernel level driver route sounds like a fun thing to play around with. I was thinking of looking into this, but MS no longer offers the DDK for download.

[a_necro00]

I have used two hours looking for a document, that I am starting to believe is no longer on the MSDN CDs (sic, yesterday I installed the October version, I read it in the July version) anyway I am looking for it, as it explained how to do it in the different OS.

I can upload the DDK to my company public FTP site, I believe that the DDK license allowed this (anyway I don't even care, is just a DDK not the holy grail).

Tell me which version you need it, I have each one except the one that includes the XP SP 1 (minor changes anyway).

[Flappy]

http://www.sysinternals.com/ntw2k/source/regmon.shtml

Complete sample (with source) on how the folks at sysinternals tap into the Registry API.

[mvern]

If you can toss up the xp ddk that'd be great. MS offers it on cd for just shipping costs, but a d/l site would be much easier for me

[a_necro00]

Ok mvern

XP DDK is going up soon (my CD librarian is out to lunch)

I sent you a private message with the IP address. If anyone else need it or want to help with this titanic task send me a message.

[Spook]

Thanks for the generosity. It sets a fine example about what a coopertive project is supposed to be about. I think a lot of fine people/programmers who come by thinking about pitching in are put off by those who seem to enjoy crack more being helpful.

More people, like you, is what the project needs. Hell, break it down to PR; a helpful community will get a much better public response than those that promote the hacker stero-types being anti-social elitist. Most of the long timers, who contribute to the project seem to be decent folk, it's just the few who seem to have nothing better to do than smoke crack and through their ego around.

Thanks, again, and to all those who contribute positively.

[Spook]

It works.

The board is eating my PMs so:

Ratt, how much detail you want posted here ? These things are detectable but it takes effort. Post the skeleton I used then let the masses figure it out from there ?