Reading symbols in User-Space while in kernel debugging mode

WINDBG
1

Hi everyone, So I am kind of new here so forgive me if I am creating a duplicate issue/question but I have failed to find an answer anywhere online for now.
I started reading an old book published around 2014 call "Practical Reverse Engineering" in this book they disassemble ntdll!NtCreateFile routine while they are in kernel mode still (haven't swtich context to a user-mode process or anything like that). Now this book is pretty old and they used windows 7 I think so I guess this worked back at the time. Trying to follow along I did the following:

  1. I started a kernel debugging session via network from vm1 running WinDbg in windows 10, and debugging a vm2 running also windows 10.
  2. I opened a cmd.exe in vm2 and I switched context to the cmd.exe process using the following command ".process /i /p <cmd.exe EPROCESS address>", then I continued execution to let the context switch complete and then loaded the user symbols using: ".reload /user"
  3. using "lm m ntdll" I validated that the symbols for ntdll were loaded
  4. I tried "u ntdll!NtCreateFile" to disassemble the NtCreateFile routine and it worked as expected
  5. I context switch back to the kernel process by finding the EPROCESS address using the following command: "!process 4 0" and then switch to it with: ".process /i /p "
  6. clicking g to make the context switch complete and now while I am in the context of the kernel I tried to disassemble the ntdll!NtCreateFile again and I got the following error:
ntdll!NtCreateFile:
00007ffa`6dc0da70 ??              ???
                          ^ Memory access error in 'u ntdll!NtCreateFile'

So it seems like I can't access any user-space memory from the kernel, I assumed this was due to SMAP possibly, I took a look at CR4 value and I noticed the 21bit flag is indeed on (20bit flag was off so no SMEP although I don't think SMEP should be an issue here any way) I tried turning off the SMAP flag in CR4 and continue execution and then I clicked break again and tried to run "u ntdll!NtCreateFile" again which failed with the same error. So I guess this wasn't related to SMAP.

My only other guess was it could be related to the mapping of Virtual Addresses, since CR3 had different value in the context of the kernel than it was in the context of the cmd.exe process and I was in the cmd.exe context when I loaded the ntdll moudle. But, I used the /p when switch context and I thought this will deal with such scenario, although I might misunderstood what /p exactly is doing.

Can you explain what happened? And is there a way to load ntdll module while running in the context of the kernel so I can look and disassemble routines found in ntdll? This is mainly for me to understand and learn more about what is going on and how it works rather then just for the book, I can follow along with the book even without being able to read user-space module symbols from kernel context.

Thanks a lot!,
Ben.

2

The only user-mode pages that are mapped in are those for the current process. Even if you are in kernel mode, there is an associated user-mode process, although you can't assume that DLLs are loaded at the same address in every process.

3

I context switch back to the kernel process by finding the EPROCESS address using the following command: "!process 4 0" and then switch to it with: ".process /i /p "

Well, here is a catch: The process with PID 4 is the "System" process. And as you can see from the output of WinDbg, it has no user-mode part:

6: kd> !process 4 0
Searching for Process with Cid == 4
PROCESS 84fcf8c8  SessionId: none  Cid: 0004    Peb: 00000000  ParentCid: 0000
    DirBase: 00185000  ObjectTable: 89e01b28  HandleCount: 533.
    Image: System

Hence, you will not see ntdll!NtCreateFile. But you can do with nt!NtCreateFile - that will work.

4

ntdll!NtCreateFile is not a kernel routine. It's in the user-mode in ntdll.dll. But tbh it's not very interesting to disassemble. It's just a syscall to the kernel.

If you're interested in the NtCreateFile from the kernel side, then it's in u nt!NtCreateFile.

But if your goal is to disassemble it (or to see how it works) I'd go with a static decompiler, like Ghidra. You will need to load ntoskrnl.exe into it (it's in your "C:\Windows\system32"). You will also need symbols for it. You can get them from the WinDbg cache in "<symbols>\ntkrnlmp.pdb\<guid>" folder. You can get its root from the WinDbg settings.