Runtime monitoring
In order for Signpost to be able to match against the knowledge base description, it has to know about the programs behavior. Its does this by employing a runtime monitoring system. There are several ways that this can be achieved - if you are interested my thesis describes each of the ways I considered (goto downloads) and their performance impact, but to save time I initially used Mutek's BugTraper (both company and product have been renamed to Identify's AppSight). Using a commercial product to gather runtime behavior saved a lot of time in a research area that is very well understood (and thus didn't add anything to the core thesis), however I am plainly aware that some readers are interested about runtime monitoring so I'll outline the general principals used and point people to further information.
There are several ways of achieving runtime monitoring and in my opinion the most usable of these is binary modification for two prime reasons
- No need for source code - for vendor libraries, source code is often unavailable but Signpost must be able to gather its behavior
- Monitoring is on a per execution basis - the overhead of monitoring may be considerable and only useful under certain conditions (when searching for bugs). Having to recompile programs or having the performance hit over the entire programs is undesirable
The general process of binary modification is outlined in the following diagram
There's quite a lot about this particular technique out on the web. Florida Tech has one implementation called HEAT (Hostile Environment for Application Testing), Microsoft has another called Detours, and there are plenty of others.