4

How does a debugger set breakpoints if the image is in read-only memory? I know there are hardware breakpoints, but in the debugger I use (OllyDbg) those have to be set specially using a different dialog than normal breakpoints.

Explanation:

Here is a routine in a debugger that is comparing itself to a copy of itself. EDX points to the running image, EBX points to the known good copy of the image. The breakpoint on 4010CE only is reached if there is a mismatch. The character being compared is in the AL register. As you can see the debugger shows EB F6 at 10CE, but this is false. 10CE actually has CC in it, as you can see by looking at the AL register. This is because the debugger has secretely inserted the CC to perform the breakpoint.

enter image description here

informatik01
  • 16,038
  • 10
  • 74
  • 104
Tyler Durden
  • 11,156
  • 9
  • 64
  • 126

3 Answers3

3

The debugger first has to change the memory protection of the page it wants to write to. This can be done with VirtualProtectEx. After that it is able to write with WriteProcessMemory and then set the protection back to the original value.

typ1232
  • 5,535
  • 6
  • 35
  • 51
3

Let me preface this with a disclaimer that I'm not familiar with your particular toolset.

If you haven't enabled hardware breakpoints, the only remaining breakpoint type is a software breakpoint. These are only hit (on x86 because that's what I'm most familiar with) when you replace the first byte of an instruction with a trap instruction, and will only be routed through the breakpoint mechanism of your OS to your debugger if the correct trap instruction for your OS is used and the debugger has already registered itself with the OS as a debugger for this process. In order to cause the software breakpoint to happen at the correct moment, the trap instruction must be written into your code segment over the first byte of your correct instruction.

The two answers that got here first explain the two scenarios which could get you here (at least, the only two I can think of):

  • The kernel always has write access everywhere, except for hardware-protected pages (ie on some sort of ROM), which your process' memory is almost certainly not. It has the ability to write the breakpoint instruction regardless of the permissions exposed to the user process being debugged.

  • The debugger must use some syscall to change the access rights on the memory of the target process before inserting the breakpoint.

Personally, I'm guessing the first thing is happening. The segment permissions are only in place to protect your target process from itself, not from a debugger process or from the kernel. Debugging mechanisms in operating systems pretty regularly violate "normal" permissions to allow the debugger to do whatever it wants to the target process. This, of course, is why some operating systems require you to enter a password before you're allowed to use the debugger in certain scenarios.

However, you can test if it's the second one by attempting to write to the code segment from inside the target process after a breakpoint has been set. If the write succeeds, you know the permissions have been lowered by the OS (to allow the process to be debugged). It would be pretty awkward for the OS to require a debugger to jump through this hoop since it can already insert arbitrary code into the writeable parts of memory and then force a jump to it by generating a stack frame overflow.

Dan
  • 7,155
  • 2
  • 29
  • 54
  • OllyDbg is a user mode debugger, so its definitely not case 1. I know I could write a bunch of experimental code to figure out what is happening, but I thought it would be easier to offer a bounty and get the attention of someone who is expert in these matters. – Tyler Durden May 22 '13 at 19:28
  • 1
    Unless you're doing kernel development, debuggers always run in user mode. However, they can still issue requests to the kernel through syscalls. What I'm saying is that one of the syscalls will tell the kernel to modify the memory of the process being debugged. The kernel has unrestricted access to memory so this would be no problem for it. – Dan May 22 '13 at 20:18
  • Also, I don't consider myself an expert, but I do work on two debugger-like tools for Solaris (DTrace and mdb). mdb uses the mechanism I'm suggesting. The mechanism is a bit different for DTrace since it is a service which runs in the kernel, but it is also not an ordinary user mode debugger. – Dan May 22 '13 at 20:20
2

The debugger takes advantage of the WriteProcessMemory() function to alter the instruction in place. It'll keep a copy of the instruction. When the bp is hit it will reset the old byte value and set EIP back to the previous instruction so the real instruction can execute.

bannedit
  • 21
  • 1