Re: intercept nt/2k kernel api?
From: Roland Postle (mail_at_blazde.co.uk)
To: "firstname.lastname@example.org" <email@example.com> Date: Wed, 21 Apr 2004 17:42:20 +0100
On Tue, 20 Apr 2004 11:52:38 -0700, firstname.lastname@example.org wrote:
>>*. Can I write to kernel memory being in kernel mode (executable
>Yes, but it isn't trivial. Device\\PhysicalMemory is probably what you
>are going to want to play with. Even with this, you still have to figure
>out the physical-virtual mappings to really do what you are asking. Theres
>a phrack article on this: Playing with windows /dev/(k)mem (phrack 59-
Afaik there's no reason to get into physical memory. Everything you
want should be mapped in the address space of your device driver. The
tricky part might be finding it because you can't rely on symbols being
available on the target machine as is usual with Linux. If it's
something hardware related (like you want to patch the IDT to intercept
all calls from user mode as soon as they happen) you can find the
structures with the right instruction (eg. SIDT). If it's something
more kernel related, windows has certain structures at predictable
places (the FS register points to a lot of useful stuff). For patching
replacement system calls it's relatively easy to find the system call
table. And from that table you could also find the executable code for
the calls and modify that directly. For patching other drivers (that
get loaded at random places) there are kernel calls to help you track
If you're doing any complicated write involving more than a single 32
bit value you need to make sure nothing will steal control while things
are in an inconsistent state. That's easy enough by disabling hardware
interrupts, and it might be neccesary to make sure the memory you're
working with is paged in at the time (there's some kernel calls to do
this), depending on what you're doing.
Device\\PhysicalMemory, incidentally, could be used to install a
rootkit from user mode (assuming you have appropriate permissions of
course) but it seems to me more complicated than just going into kernel
mode yourself where you have more direct control.
>>*. Can I write to kernel memory belonging to another vxd or kernel
>>itself (data memory)?
Same issues. There's no reason for blue screens if the code is well
thought out and well tested, as any rootkit would be.
>> *. Does M$ really use non-executable flag for pages in XP service pack 2 for XP kernel and system applications on new amd 64bit cpus?
No idea, but you could turn it off easily enough if you were already in