A conventional breakpoint is set by replacing an opcode with "int 3". This is fine in an EXE file, but how exactly does this work in a DLL? If I understand correctly, DLLs map the same memory into several processes' address space - this being their main attraction, as this uses the physical memory only once. But surely then an "int 3" instruction would be seen and executed in all processes that share a DLL?

One theory I had was that they are mapped with copy-on-write semantics, where the OS transparently makes a copy of the modified page, and then makes the change. Presumably this would require that the first write faults, the OS makes the copy and then repeats the write invisibly.

If this is so, can I somehow tell if a particular DLL page is "real" or "copied", in OllyDbg? If this is way off, how do DLL breakpoints *actually* work?

...you could look at something called a CONTEXT.

Find out how it works, what its structure is like and you should be good to go.

Have Phun

if you have set a bp on ollydbg and you wish to see it from the same ollydbg it is not feasible if you come to think of it

but you can see the byte 0xcc set if you view the debuggees copy of dll from another debugger

windows maintains a copy of dll in every process and only the process own copy will have the modificiations and the page that holds the copy will be marked DIRTY is the term iirc

see in ollydbg i set this bp in ntdll



if i use windbg local kernel debugging facility to view the debuggeee msgbox.exe

i can see 0xcc

Another possibility for detecting a copy-on-write page - use QueryWorkingSet and check the Shared and ShareCount fields of the returned data. For code sections of system dlls the Shared bit should be set, meaning the page is shareable. If it has been cleared it's supposed to mean that the page has been written to (i.e. a breakpoint set) and copy-on-write has taken place.

As described in the entry for VirtualQueryEx:




http://msdn.microsoft.com/en-us/library/ms684946.aspx
http://msdn.microsoft.com/en-us/library/aa366907.aspx



I haven't tested the above assumption, but I think we can see the results with Sysinternals VMMap. In the first snapshot below we're looking at the memory details of Notepad loaded into Ollydbg - without any breakpoints set. Notice that Private WS (the amount of physical memory assigned to the type or region that cannot be shared with other processes) for the code sections of kernel32.dll and ntdll.dll is empty. In other words, the .text sections are still virgin. (look for the mouse pointer in the snapshot)

In the second snapshot I have set regular breakpoints on an API in both kernel32 and ntdll for the loaded Notepad, and refreshed VMMap. Notice that there is now an entry for Private WS for the .text section for both dlls. That looks to me like an indicator that copy-on-write has occured because of the breakpoints. There are other changes as well, but Private WS seems to be the clearest sign.

Note that this won't work if a page has already been made private because of a previous copy-on-write event, i.e. Comodo firewall automatically hooks a couple of kernel32 API's in the Notepad debugee process when it starts, and any subsequent COW because of a breakpoint setting can't be discerned using VMMap. (I ran those tests on a basic XP system under VM)

Kayaker

24912492

Thanks everyone, especially Kayaker - exactly what I was after.