Application Security Testing: An Integral Part of DevOps
Last year, I wrote an article on using delegates and events with Managed C++. That article illustrated how to set up a publish/subscribe scenario where a publisher defines an event to which one or more clients (or subscribers) can subscribe. Each subscriber needing notification of the event basically adds its handler (in the form of a delegate) to the list of handlers that will be called when the event fires. Creating an event-driven architecture is a popular and effective use of delegates. However, another important use for delegates is in the area of callbacks, which this article discusses.
Delegates as Callback Functions
A function often will perform work asynchronously and call the client either when it's done or periodically while it's processing the client's request. For example, when calling the Win32 EnumWindows function, a client will pass a function pointer representing a callback function. The EnumWindows returns almost immediately to the caller and begins enumerating the open windows on the system. As it locates each window, the EnumWindows function invokes the client's specified callback function (passing the handle to the window).
However, one problem with callback functionsespecially in C/C++is the lack of type safety with regards to ensuring that the specified callback function is what the called function expects. This is due to the fact that you can pretty much cast any function pointer to the needed function pointer type in order to get your code to compile. However, since the stack is manipulated in order to dynamically invoke the callback function, the typical results of passing a function pointer with an incorrect signature are along the lines of stack corruption and access violations.
This is where delegates come in. Delegates are essentially typesafe method pointer declarations, which are perfectly suited for being passed as callback functions. While delegates are .NET types, they can also be used when calling native Win32 API functions from Managed C++.
Defining Delegates for Native Functions
The only real challenge in using delegates as callback function pointers with native functions is that the callback function often is defined as needing parameters that are not directly supported as .NET types. As an example, consider EnumWindows, which is defined as follows:
BOOL EnumWindows(WNDENUMPROC lpEnumFunc, LPARAM lParam);
As you can see, EnumWindows requires a function pointer of type WNDENUMPROC to be passed as the first parameter. Because this will dictate how the delegate must be declared, you look it up to find its definition as follows:
typedef BOOL (CALLBACK* WNDENUMPROC)(HWND, LPARAM);
As you can see, this callback function must be defined as taking two parameters: HWND and LPARAM. However, these types are not defined in .NET. So, you look for a type that will basically occupy the same amount of space on the stack. In cases of pointers and handles, that type usually can be the .NET IntPtr type. Knowing this, you can define the delegate (using the __delegate keyword) as follows:
__delegate bool EnumWindowsCallback(IntPtr hwnd, IntPtr lParam);
Now, you have the delegate defined and you can proceed to importing the native function into your code so that your code compiles properly.
Importing a Native Function
In the case of a Managed C++ application needing to call a native function, you need to import the native function's prototype. This is accomplished via the DllImport attribute. When a given method name is "decorated" with the DllImport attribute, that tells .NET that the specified method is exposed by the indicated native DLL as a static entry point. Here's an example of how to import the definition of the EnumWindows function:
using namespace System::Runtime::InteropServices; ... [DllImport("user32")] extern "C" int EnumWindows(EnumWindowsCallback* callback, int lParam);