0

I would like to monitor a var (preferably in heap) for any kind of writing change.

To be exact, I would like to monitor a specific address range in my own process with a length of N bytes.

The reason: A second process might change the value of the var externally via WriteProcessMemory and an event should be triggered as soon as its address range has changed the value.

How can I monitor this?

This seems so unprofessional:

while true do
begin
 if VarToMonitor <> OldMonitorValue then ...
 // sleep (100) ???
end;

EDIT:

I would like to monitor this without a debugger at runtime.

Ben
  • 3,380
  • 2
  • 44
  • 98
  • 1
    Why would you do this? If the external process wants to change your memory, and has the right to do so, why should you stop it? Having your cake and eating it: http://stackoverflow.com/questions/13166670/who-is-allowed-to-write-to-an-allocated-address – David Heffernan Jun 22 '15 at 13:28
  • @DavidHeffernan I have not mentioned anything about stopping or interrupting the writing process to an address range. I asked to be able to get a kind of event or trigger to be able to tell when and what has been changed. – Ben Jun 22 '15 at 13:31
  • 1
    I don't think such events exist – David Heffernan Jun 22 '15 at 13:31
  • @DavidHeffernan Ok, thank you. Please despite the situation of non synchronization, locking, etc. This is all considered already with Mutexes. I just want to know if there is a way to get an immediate trigger as soon as a value has been changed (just like Delphi's property write method) – Ben Jun 22 '15 at 13:34
  • 1
    I'm not sure how data breakpoints work to be honest. Perhaps a special debugger feature. But I suppose it does hold out hope that you can get a notification. – David Heffernan Jun 22 '15 at 13:38
  • @DavidHeffernan I might add that I want to monitor this at runtime without a debugger. – Ben Jun 22 '15 at 13:39
  • 1
    I know. But a debugger doesn't need to be the IDE's debugger. A debugger doesn't need to show UI. A debugger is just a special process that has extra power over its debuggee. – David Heffernan Jun 22 '15 at 13:40
  • @DavidHeffernan I appreciate the effort of your thoughts and ideas here but there might be a better solution for this. Worst case scenario - I am forced to use an infinite loop to check the value. – Ben Jun 22 '15 at 13:45
  • 1
    This might give you some ideas, if only because it implies memory-write breakpoints are possible: http://www.codeproject.com/Articles/28071/Toggle-hardware-data-read-execute-breakpoints-prog (and the Delphi debugger supports changed-memory breakpoints) – MartynA Jun 22 '15 at 14:11
  • @MartynA this seems to be a very interesting topic. I will have a look at it and see if I can use this. Thank you! – Ben Jun 22 '15 at 14:18
  • 1
    If you care about data integrity then one strategy is to make a custom class that includes hashing or parity (or both) - point changes to those variables could then be detected as a hashfail or parity error, etc, when reading. This won't detect an attack immediately, but it would detect it before the value was used. Nothing is attack-proof, but this would certainly be much harder to circumvent. – J... Jun 22 '15 at 14:24
  • 1
    If you know the second process then you can hook `WriteProcessMemory` calls in it. [How can I hook Windows functions in C/C++?](http://stackoverflow.com/questions/873658/how-can-i-hook-windows-functions-in-c-c). Also googling for `windows api hooking` you will find some articles. – Abelisto Jun 22 '15 at 14:44

0 Answers0