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 :D ), 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 ?

[wiz60]

The mapping can be done - it will take the following to accomplish this:

1. Queue IO from reader app.
2. At entrance to driver - turn off interrupts - actually you need to move to the kernel ring to do this properly.
3. Locate eqgame task in memory - fairly easy
3a. Using process header - you will get necessary physical memory offsets for the process.
4. Map process pages to appropriate portion of driver address space. There are driver primitives to make this happen.
5. Extract the key
6. un-map page
7. re-enable interrupts

The sequence is critical - you cannot assume that the page you are interested in will be memory resident, and cannot guarantee that an interrupt might not cause it to be relocated in physical memory. The system must verify the page is in memory, it must do this procedure each time - with interrupts disabled.

It is possible to that Verant could turn on trapping in the virtual memory management hardware for the physical page - but that would be silly and frought with problems of its own.

[MisterSpock]

Here is a nifty little utility that uses the native kernel calls to dump physical memory (from our good friends at Sysinternals).

I've been working on integrating it with my existing keysniffer to get around any nasty side effects of monitoring debug mode, readprocessmem, etc.


Go here for some tidbits:
http://www.sysinternals.com/ntw2k/info/tips.shtml#KMem


This is the link to the physmem application and souce code:
http://www.sysinternals.com/files/physmem.zip


Oh... one more thing...

It is my opinion that we should not be entering debug mode to run the ReadProcessMemory. I suggest using either the ACL maneuver, or running the application as SYSTEM.

Additionally, we must be very careful to make sure we close any handles to eqgame.exe that we open. There is another api (non native) that can read the memory of an app in blocks knowing only its pid. I'm looking into the use of it as well.

Also, if you launch your actual keysniffer from a second "service" program ( a good strategy, in my opinion ), here is a thought.
Inside your actual keysniffing application, consider using a 'critical section' for the bulk of the code.

[curio]

MisterSpock, check out this article from Phrack..

http://www.phrack.com/phrack/59/p59-0x10.txt


Its got some discussion of reading memory w/o using ReadProcessMemory, by making a \Device\\PhysicalMemory mapping.

I couldnt get the win2000 code example winkdump.c to compile on my winxp / lcc system (ditto for sysInterals code), but perhaps this technique can be applied by someone more savvy than I.

[Kraken]

Geez, you guys took all the fun out of it. I was hoping to make this 'project' into a nice little system blue screening/learn the hard way project :)

Anyways, I would definitely like to inform the masses who might actually use a kernel driver as to the possible consequences. This is for the people who might not know what something running at kernel level can really do once installed.

You've seen the messages on the board concerning being very careful accepting an EXE from someone because of the dangers involved. Be aware that once something is running in kernel mode, it is God. No security, no safeguards, and its error handling if someone OOPSES is a pretty blue screen with lots of confusing numbers and letters.

That said, I'm looking forward to seeing what finally comes of this. But next time I'll keep my ideas to myself so I can hog all the fun and glory :)

[lostinspace]

Nice, some concrete info at last :)

Well, about reading memory from user and kernel mode, this is nice info with names of some kernel mode undocumented API functions:

http://sarc.com/avcenter/reference/memory.scanning.winnt.pdf

As for above mentioned ways that EQ can detect user-mode sniffer, they all rely on EQ inserting hook into (or modifying) some kernel DLL, and modifying behavior of operating system. That is , I believe, too risky and intrusive for Sony, since that can be legaly challenged.

It is one thing to passive invide privacy by reading information from our PC that we did not give permision. It is another thing if they send that info back to Sony. And it is yet third and most intrusive thing if they actively modify operating system to do so.

So, at least untill we have proof that they will risk changing OS behaviour, is there ANY way that anybody know that EQ can use to detect ReadProcessMemory , without modifying Kernel part of OS? If there is, I think we should focus on that one.

BTW, it is interesting post about /dev/PhysicalMemory. I also tried using kernel mode physical memory reading ( using 3rd party sys driver), but main problem was how to determine Physical memory from some process memory and offset. Same problem would be if usind /dev method. Article I listed offer kernel mode API functions to get list of processes, maybe some of them return base Physical memory of process, but I couldnt test.

Any ideas how to obtain Physical memory address from process ID and offset (virtual address within that process) ?