Please enable JavaScript to view this site.

Memory Validator Help

Navigation: Overview

How does Memory Validator work?

Scroll Prev Top Next More

 

The Stub and the UI - more than the sum of its parts

 

Memory Validator has two main parts - the stub and the user interface.

 

The stub is typically injected into the target program and communicates with the Memory Validator user interface.

 

The stub is injected into the target program using the CreateProcess() or CreateRemoteThread() Win32 function. Communication between the stub and the user interface is via named pipes. There is no human readable data sent between the two parts of the program. Both the stub and the user interface are multithreaded.

 

The stub rewrites the DLL import address table and the delay loaded import address tables to make functions call into the stub's hooks. For functions that are not present in the import address tables, the stub rewrites the function prologue and function epilogue using proprietary techniques.

 

For COM objects. the stub rewrites the function prologue and function epilogue for the AddRef(), Release() and QueryInterface() functions in each COM object.

 

The stub can also be linked if required, for example in order to use the API in order to track custom memory heaps.

 

Memory Validator can be extended by user supplied extension DLLs. These can be used to augment either the stub or the user interface.