Add the following code that calls the C# function. But make sure to to copy ExtensionUtils.tlb and ExtensionUtils.dll files to directory that has been added to the (additional) include directories in the project settings.

June 5, 2012

I wrote a simple script for Windbg that finds deprecated functions in the modules of the process address space. It parses the name of the imported functions in the Import Address Table (IAT) of the PE image. Each API name is matched to a list of deprecated API names. If there is a match the script prints the API name out.

Here are some browser test have been done with the script. The result, in short, is all browsers use banned APIs that are flagged unsafe by Microsoft.

Chrome
I randomly chose modules in the Chrome's process address space, and found the following banned API.

This is not a comprehensive list, I randomly chose modules in the process address space.

MSDN says "These functions [memcpy] are deprecated because more secure versions are available". Also "Security Note These functions [strcpy] incur a potential threat brought about by a buffer overrun problem".

Note
It's important to note that the presence of banned APIs doesn't mean the application is vulnerable, it means those shouldn't be there according to the Security Development Lifecycle Guideline because it's easy to go wrong with them.

If you want to try the script out I put it here. The script requires a text file containing the banned APIs, and you can get it from here.

June 2, 2012

The book is written from software development point of view. Examples reference to source code. Information is used in debugging examples taken from source code and from debugging symbol files. Therefore some examples are not applicable on binaries without source code information.

Most of the debugging examples rely on SOS and SOSEX Windbg plugins. Online help for those plugins are already available, and this book doesn't seem to add new information to them, albeit it demonstrates examples with snippet copied from Windbg command window.

ILDasm is a great tool but there is so little about it in this book. Particularly, I'd like to see, for example, that the information extracted from binaries by ILDasm can be used during debugging; a kind of guide to use statically acquired information during dynamic analysis.

The author describes some low-level structures in an accessible manner, but some topics aren't discussed while others are overwhelmed with theory. There is very little information about IL instructions, however I'd expect more on that because that's a key area to understand to effectively debug .NET programs.

The author doesn't go beyond a certain point when discussing certain topics, for example, it's not discussed how the code generation works that would be useful to match IL code blocks to their native counterparts. (MSDN describes how can be done this via profiler or debugging interfaces of .NET Framework.)

The figures about internal structures or flow charts, etc. seem to be simple and easy to follow them, I liked these parts.

I particularly liked the Managed Heap and Garbage Collection chapter.

If you're an engineer who wants to troubleshoot software failures this book is a good one to start with. However, if you're a reverse engineer who wants to debug binaries without having debug or source information available you might need an other book with different approach.