Had a quick question.

How does olly know when there is a change in the memory region of a loaded executable (i.e. external process uses WriteProcessMemory to modify some value).

I'm sure it doesn't continuously scan the memory for changes.

Your help is appreciated.

The x86 hardware features debug registers that if set up correctly, will trigger an interrupt when the specified event happens in the debugged program.

You can set up a read, write, or execute breakpoint.

That's how it's done.

Thanks a lot.

Is there an example of using these debug registers to detect changes in any part of the memory for a specified process (this link only attempts to use them for the current process http://www.codeproject.com/KB/debug/hardwarebreakpoint.aspx)?
Also from what I can tell, attempting to access time requires the use of privileged instructions?

Edit: Nevermind, SetThreadContext() is probably my answer

From what I can see the debug registers can only set a max size breakpoint of 8 bytes, so how would this allow olly to detect modifications throughout the entire process?

You can also the virtual memory system, for example, VirtualProtect.

olly does pop in the "first application" when a "other application" use WriteProcessMemory ?
hardware breakpoint will sure work if it happens in the same application
it would be good to know if olly does if its a other application

What about setting a page guard (using VirtualProtect) for the entire process. That should fire an exception on any write operation is done. I think that's what squidge was trying to say.

Edit: Elenil, olly does indeed resolve any (external and internal) changes in the loaded process's memory correctly. Hm, using guard pages to detect a read or write operation might work, but if it's a write operation the how would the debugger know what was to be written in the first place.

Hardware breakpoints are local to the thread. Evaluation registers are part of the context record. Upon entering the interrupt handlers, traps and fast system call of the context containing the debug registers is reloaded to the kernel. Therefore, on the side of the kernel debug break will not happen. Watch for handling kernel to user memory will not work.

Yes, hardware breakpoints won't help in my case. Guard pages work well for memory breakpoints but still leave me wondering, how olly detects any change in process memory that an external process has changed (i.e. WriteProcessMemory()).

I've been reading everything I can, and still lack the method.

Guard pages are also not help, the attributes page to set the required record.
Olly probably just remembers the dump, and then compares. From usermode not possible to track the read/write memory remotely. This problem can be solved only in two ways - emulation of a local segment or hook some code in the kernel, which is used in memory operations.
By the way simulation is quite simple, you can use to protect their code, and to capture the party http://openfile.ru/473081/ (Doc describing the mechanism, in Russian).