2

I know that in 32-bit architecture the kernel mode virtual memory is mapped between 0x80000000 and 0xFFFFFFFF.

It contains some structures as EPROCESS , ETHREAD ... etc and also the page directories and tables for the current process.

While trying to fetch the virtual address of a certain function is ntoskrnl let's say "nt!NtReadFile" I find that's it's mapped in the kernel virtual address 0x89421130 for example.

I tried to patch some nops after the RET with a random instruction and when switching to another process context I found that the instruction I put is still there.

Does that mean that virtual memory where Ntoskrnl is loaded stays unchanged in every process virtual address space ?

Thanks.

JohnnyCat
  • 203
  • 1
  • 15
  • afaik this should not happen because those kernel pages are getting mapped for each process from physical memory to virtual memory. you also should not be able to actually modify such a page because they are code pages. write access to a code page should be prevented by the page manager. I'm not that into os dev but if you have not luck on SO you could ask here: http://wiki.osdev.org/Main_Page (see Forums) – Stefan Falk Apr 30 '14 at 19:35
  • DLL functions and data are shared between processes. That's kind of the whole point. – ooga Apr 30 '14 at 19:36
  • Actually I'm patching using kernel mode debugging under WinDbg – JohnnyCat Apr 30 '14 at 19:37
  • Oh okay. I misunderstood the qeustion a little here. Then this might answer you question: http://stackoverflow.com/questions/2846310/are-dll-files-loaded-once-for-every-program-or-once-for-all-programs – Stefan Falk Apr 30 '14 at 19:40
  • Yeah , I already have an idea about what they're saying here. But they're talking about user-mode modules. And when performing patching or hot-patching in a usermode DLL in a specific process address space it doesn't infect other mappings in other process' virtual address spaces , So it might be that the kernel module is mapped into each process virtual address space and when a specific instruction is patched it also affects other mappings , hence patching the shared resource in physical memory !!!?? – JohnnyCat Apr 30 '14 at 19:47
  • 2
    Kernel routines are unique and they usually reside in non-paged pools. What is duplicated are the tables and structures used to reach them since they usually have per-CPU data. I don't remember the internals of a Windows operating system but you should definitely study kernel driver programming before diving into something like that. Also: assuming you have the privileges to do that and you could patch some bytes there, keep in mind that patching/modifying kernel memory unless you know what you're doing is the sure recipe for disaster (stack protections will puke at you). – Marco A. Apr 30 '14 at 19:52
  • 1
    @Marco: **many** Windows kernel functions are not in NPP (and hence cannot be called at high IRQL). Also, patching code won't trip stack protection - it's not on the stack. You may be thinking of PatchGuard. – nobody Apr 30 '14 at 20:39
  • @AndrewMedico right, PatchGuard not stack protection. Sorry for the mistake – Marco A. Apr 30 '14 at 20:43

1 Answers1

3

Does that mean that virtual memory where Ntoskrnl is loaded stays unchanged in every process virtual address space?

Yes. There is one copy of the kernel in memory on a running Windows system, and the exact same kernel address space (i.e. 0x80000000-0xFFFFFFFF on 32-bit) is mapped into every process.

nobody
  • 19,814
  • 17
  • 56
  • 77