Setting user mode break points from KD aka .process /i vs .process /r /p

debug When performing KD(Kernel Debugging) in Windows with Windbg if you have to set a break point in a user mode process we should always use .process /i address; g; .reload /user. Lot of good content is written on the internet on this command, but nothing seemed to explain why this command should be used instead of the familiar .process /r /p address. I would like to shed some light on this. Before reading any further I would strongly encourage you to read about it from above link. In this article I assume some basic knowledge on how kernel debugging is done with Windbg. Also, I would like to start with the following question.

If the debugger has read/write access to the user mode process via .process /r /p why cannot it insert int 3 in user mode process when performing KD? Why do we have to make the user mode process the current process context by running .process /i ?


To explain this we need to quickly understand how break points work.

How do break points work in user mode debugging

Below are the steps involved for a break point to work in debugging a user mode process.

  1. bp address – you are just instructing the debugger to make a note of “address” and replace the byte at that address with 0xcc (int 3) when target resumes to execute
  2. g – when you hit “g” the debugger replaces the byte with 0xcc and stores the original byte with it
  3. After execution when processor execute the modified byte (0xcc) this causes the debugger to break in and debugger puts back the original byte as if nothing has happened to the program
  4. More details: http://vineelkumarreddy.com/2016/09/04/how-does-breakpoints-work-in-debuggers/

Step 2 is very important because only when you instruct the debugger to resume the target the break point should be set not before; As it causes incorrect view for the programmer(example: otherwise u address prints int 3 not the original instruction!). Step 2 also makes setting up user mode break points from KD interesting

User mode break points from KD

When debugging a user mode process from KD the steps works exactly same as above but with a slight twist.

    1. Let’s assume during KD, when the debugger broke, the processor is executing a process named mulithasher.exe(see note below)
    2. When you switch the windbg’s _view_ to a different process(fscapture.exe) by .process /r /p <fscapture address>, you are not changing the underlying execution of the processor. !process -1 0 still shows multihasher.exe
      1. With /r /p you now have read/write access to the fscapture process. This confirms the first part of the question
    3. bp address  – same as above, you are instructing the debugger to make a note of “address” and replace the byte at that address with 0xcc (int 3) when target resumes to execute
    4. g – when you hit “g” the debugger replaces the byte at address with 0xcc in the currently executing process which happens to be multihasher.exe not fscapture.exe!
    5. Before break point getting updated UsermodeBreakPointFromKD1
    6. Setting the break point UsermodeBreakPointFromKD2
    7. After break point is updated UsermodeBreakPointFromKD3
    8. This means, “g” command used to resume the target is the culprit(may be it is by design). This answers the second part of the question
    9. So by using .process /i <address>;g; windbg will break under your process context(how?). After which setting a break point and hitting “g” will cause the debugger to actually put int 3 in your process not somewhere else

NOTE: I initially made multihasher.exe the process context by using .process /i <multihasher address>;g;

Setting breakpoints in system dlls

This .process /i is not required if you are putting breakpoints in system dlls like kernelbase, ntdll etc because these dlls are loaded at the same virtual address in all the user mode processes and they have a single copy in the physical memory. So once a break point set in a process the break point is visible in all other processes which uses that system dll. Below we illustrate this by setting a break point in ntdll.dll. (Even here just make sure when you broke initially you are not in System process as it will not have ntdll! 😊)

  1. Break point is set only in ntdll of explorer process UsermodeBreakPointFromKD4
  2. Break point set in ntdll of explorer gets reflected in ntdll of notepad also 😊 UsermodeBreakPointFromKD5

References

  1. Analyst’s Perspective: Analyzing User Mode State from a Kernel Connection
  2. How Windows Debuggers Work?

Happy debugging!

 

Leave a comment

Leave a Reply