The blog continues at

June 18, 2012

Calling C# Code from Windbg Extension

It could be useful to write functions in C#, and to call some of those from Windbg plugin. Here is an approach how to achieve this.

Create a new project from Class Library template in Microsoft Visual C# 2010 Express.

Go to project properties an tick Register for COM interop off.

Enable ComVisible by editing AssemblyInfo.cs like below.
[assembly: ComVisible(true)]
Here is a simplified implementation to add.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace ExtensionUtils
    public interface IManagedInterface
        int Func();
    public class Utils : IManagedInterface
        public int Func()
            return 1;
When compiling the code both ExtensionUtils.tlb and ExtensionUtils.dll have been created.

Open the Windbg plugin in Microsoft Visual C++ 2010 Express.

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.

#import "ExtensionUtils.tlb" named_guids 
    HRESULT hRes; 
    ExtensionUtils::IManagedInterface *pManagedInterface = NULL; 
    hRes = CoCreateInstance(ExtensionUtils::CLSID_Utils, NULL, CLSCTX_INPROC_SERVER, 
     ExtensionUtils::IID_IManagedInterface, reinterpret_cast<void**> (&pManagedInterface));
    if (hRes == S_OK)
        int ret = pManagedInterface->Func();
That's how I did.

June 5, 2012

Banned APIs Used by Browsers

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.

I randomly chose modules in the Chrome's process address space, and found the following banned API.
0:012> $$>a< c:/work/BannedApi.wds chrome.dll c:/work/BannedApiList.txt
IAT Address: 01643000, Size: 000009b4
1909 APIs scanned in IAT, 1 APIs have the name of deprecated APIs.
MSDN says "Important  This [IsBadWritePtr] function is obsolete and should not be used".

By the way, Chrome guys do pretty good job because this was the only one banned API I found in the address space albeit I didn't check all of the modules.

Here are the banned APIs found in Firefox.
0:011> $$>a< c:/work/BannedApi.wds plugin_container c:/work/BannedApiList.txt
IAT Address: 00002000, Size: 000000d4
221 APIs scanned in IAT, 1 APIs have the name of deprecated APIs.
0:011> $$>a< c:/work/BannedApi.wds mozjs c:/work/BannedApiList.txt
IAT Address: 00169000, Size: 0000020c
546 APIs scanned in IAT, 2 APIs have the name of deprecated APIs.
0:011> $$>a< c:/work/BannedApi.wds xul c:/work/BannedApiList.txt
IAT Address: 00a27000, Size: 00002230
7672 APIs scanned in IAT, 18 APIs have the name of deprecated APIs.
0:034> $$>a< c:/work/BannedApi.wds firefox.exe c:/work/BannedApiList.txt
IAT Address: 00003000, Size: 0000013c
359 APIs scanned in IAT, 8 APIs have the name of deprecated APIs.
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".

Internet Explorer
Some banned APIs in IE.
0:020> $$>a< c:/work/BannedApi.wds iexplore.exe c:/work/BannedApiList.txt
IAT Address: 00001000, Size: 0000020c
392 APIs scanned in IAT, 1 APIs have the name of deprecated APIs.
0:020> $$>a< c:/work/BannedApi.wds jscript9.dll c:/work/BannedApiList.txt
IAT Address: 00001000, Size: 000003c4
743 APIs scanned in IAT, 2 APIs have the name of deprecated APIs.
0:020> $$>a< c:/work/BannedApi.wds MSHTML.dll c:/work/BannedApiList.txt
IAT Address: 00001000, Size: 00000fd4
3209 APIs scanned in IAT, 4 APIs have the name of deprecated APIs.
0:020> $$>a< c:/work/BannedApi.wds XmlLite.dll c:/work/BannedApiList.txt
IAT Address: 00001000, Size: 00000090
106 APIs scanned in IAT, 2 APIs have the name of deprecated APIs.
0:020> $$>a< c:/work/BannedApi.wds IEFRAME.dll c:/work/BannedApiList.txt
IAT Address: 00001000, Size: 00001640
4478 APIs scanned in IAT, 4 APIs have the name of deprecated APIs.
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

Thoughts on Advanced .NET Debugging book

Here are some thoughts on Advanced .NET Debugging book.

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.
  This blog is written and maintained by Attila Suszter. Read in Feed Reader.