We are pleased to release another free tool for your pleasure....
For the Impatient
Download Binaries -
http://www.foundstone.com/resources/termsofuse.htm?file=dotnetmon.zip
Download User Guide -
http://www.foundstone.com/resources/downloads/Foundstone_DOTNETMon_White
paper.pdf
For the Less Impatient
Introduction
Flow tracing is an useful part of application debugging and analysis.
For every test case written to check the reliability of the code, the
ability to follow the execution flow and check for code coverage seems
to be of immense value to developers, debuggers, and testers. Foundstone
introduces .NETMon(tm) to equip developers and debuggers with a tool
which will allow them do organized flow tracing of applications and to
identify security loopholes.
Background
The .NET Common Language Runtime (CLR) provides many features for better
application development. Some of these features include a comprehensive
class library, interoperability with native code, and cross language
exception handling. Another, not so widely known, feature of the .NET
framework is the .NET profiling API. This API is capable of providing a
substantial amount of runtime information about any .NET application.
The CLR is the heart for any .NET application execution and provides
place holders to insert hooks to study the details of the program at
runtime. The hooks are capable of providing very detailed information
about the system level working of a process.
The information from these hooks can be used to build tools capable of
analyzing code timings, exception handling, and memory usage.
Foundstone's interest in the profiling API was to develop a flow
analysis tool that gives auditors the capability of following the flow
of function calls to better understand the code execution and ferret out
the vulnerabilities that may exist in the application.
The profiling APIs do not require any code additions or modification
which eliminates any changes needed to profile an application. Its event
driven design allows the definition of the events that should be sent to
the 'listener' application. With the current version, there is some
performance impact because the events are being monitored by the
FunctionEnter and FunctionLeave hooks which are fired for each Managed
Method executed by the CLR. This issue will be addressed in the next
version of .NETMon which will resolve the function's signature (return
type, namespace, method name and parameters) asynchronously.
Read more in user guide.....
Thanks to Dinis Cruz who developed this tool under contract
Mark Curphey
http://www.foundstone.com
