0

How reliable is hooking for changing a single static memory address when it hits certain values?

What I'm used to doing is using read/write memory out of a basic c++ application, though I find sometimes this is not reliable for addresses that change 1000+ times per second. Often time my application cannot catch the value at the address with a case function in time enough to change it to another value. How exactly does this concept of hooking work, and does it ever miss a value change? I'm using Win 7 Ult. x86

Scott Grissom
  • 41
  • 4

2 Answers2

2

(reusing an answer I gave to a question I thought was related, but turned out not to be.)

There are environment-specific ways to detect when a variable is changed. You can use the MMU access control flags (via mprotect or VirtualProtect) to generate an exception on the first write, and set a dirty flag from inside the handler. (Almost every modern OS does this with memory-mapped files, to find out whether it needs to be written back to disk). Or you can use a hardware breakpoint to match a write to that address (debuggers use this to implement breakpoints on variables).

Ben Voigt
  • 277,958
  • 43
  • 419
  • 720
  • Both of those sound like they would slow the program down. I have an idea in my head, but I'm not sure if it's right. Basically would I be able to make that single instruction redirect to a function of a DLL I inject, do the comparison checks, and then redirect it back to that instruction? Thousands of random values pass through this instruction and I only want to change specific ones. I'm not entirely sure how DLL injection works so I'm not sure if this is plausible. – Scott Grissom Mar 20 '13 at 04:37
  • @Scott: Is there only one instruction in the whole process that touches that memory location? If so, then hooking can work. Otherwise, taking advantage of hardware that does address comparisons is your only hope of efficiency, and both methods I listed use hardware to filter addresses. – Ben Voigt Mar 20 '13 at 05:08
  • 1
    Hey @BenVoigt I don't suppose you have any references handy for the methods you mentioned do you? Sounds like an interesting read. – Jason Larke Mar 20 '13 at 05:21
  • 2
    @Jason gdb does hardware breakpoints so that's probably the best way to start looking for documentation. In general the concept can be found under `hardware breakpoint`, `watchpoint` or `debug registers`. x86 for example has [debug registers](http://en.wikipedia.org/wiki/X86_debug_register). You may be interested in [this](https://www.kernel.org/doc/ols/2009/ols2009-pages-149-158.pdf) – Voo Mar 20 '13 at 06:23
  • 1
    [Example of using VirtualProtect + SEH](http://stackoverflow.com/q/8004945/968261). – Alexey Frunze Mar 20 '13 at 10:14
0

Hooking can be done in many ways. Most require you to have code inside your target process making ReadProcessMemory obsolete (just use pointers and dereference them). If you want to hook though you can do it like this: Find out what instruction(s) write to that address (debugger memory breakpoint), it will most likely be a function so what I usually do is just patch some bytes near the beginning to redirect execution flow to my code where it will be executed every time that function is called, what I sometimes do is also alter the return address on the stack so that I can examine and control the return value as well as execute code I want executed after the function is finished (for example, get some info from the stack because I am either too lazy to dig out the structures used to store it or if it's temporary it will be discarded and never saved).

  • AFAIK, `ReadProcessMemory()` won't cause an exception and won't affect guard pages unlike direct pointer dereferencing. – Alexey Frunze Mar 23 '13 at 07:16