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