Creating a COM Accessible DLL in Visual C# for EnScript

A while back, I came across a thread on the EnCase EnScript forum asking for assistance in getting EnScript to recognize the interfaces for a DLL created in C#.Net through COM. I created a self-contained C# demo project to help out. The original code can be browsed on github for branch “v0.1”. This post is an update to the information in that thread with extra references and an update on 64-bit OS usage. I recently updated the code which, as of this posting, can be found on github for branch “v0.2” or on the EnScripts page of the website. If you’re still interested, please download the code and follow along. If you’re a glutton for punishment, feel free to read all the links in their full MSDN glory.

In the scenario, the same DLL would work just fine when accessing its methods and properties through VBScript, but EnScript wouldn’t “see” any of them. This wasn’t so much an EnScript or, necessarily, a .NET problem. It’s actually an issue with the early binding that EnCase requires in combination with the lack of registration on the part of .NET.

Making the Code Work:
There are, however, a few things to take care of in the code before worrying about registration. Your interface should be set to InterfaceIsDual, your class interface type can be set to None, and you should set ComVisible to true on both of them. In the code below, you would replace InterfaceGUID and ClassGUID with your own previously generated GUID values. If you’ve worked with Visual Studio for any length of time, you’ll soon discover that you should generate your own GUIDs ahead of time using guidgen.exe and manually assign them, otherwise Visual Studio will create new GUIDs every time you run Regasm.exe (which is annoying). The below code can be found in the demo in CDemo.cs.

[Guid("InterfaceGUID"), InterfaceType(ComInterfaceType.InterfaceIsDual)]
public interface _COMDemo
[Guid("ClassGUID"), ClassInterface(ClassInterfaceType.None)]
public class COMDemo : _COMDemo

Before we get any further, I should also mention in passing that it’s always best to use Strong-Named Assemblies.

After your code is all set, we need to deal with the registration issues. The first thing we need to do is register our DLL in the Global Assembly Cache using Gacutil.exe or a capable installer:

gacutil.exe /i CDemoLib.dll /f

Next, we’ll register the assembly for COM access using Regasm.exe:

regasm.exe CDemoLib.dll /tlb:CDemoLib.tlb

Creating the TypeLib using Regasm.exe generates a default interface with no methods. VBScript makes only late-bound calls into the assembly; it doesn’t use the TypeLib so it doesn’t care that the default interface is empty. Here’s what that gets us:

Regasm.exe also fails to add all of the keys in the registry that are required for early-binders and these can be hard to track down. Take a look at the keys that are missing below.

Windows Registry Editor Version 5.00

HKEY_CLASSES_ROOT is an alias for HKEY_LOCAL_MACHINE\SOFTWARE\Classes. These keys are essential for the methods and properties to be COM accessible to early-binders. The Control key identifies our object as an ActiveX control. The MiscStatus key takes its values from the OLEMISC enumeration. The Typelib key points to the GUID of the Typelib, which is the GuidAttribute of the assembly (found in AssemblyInfo.cs). And Version is pretty straightforward. This article mostly applies, despite its age. After adding our custom entries:

After you’ve thrown in all the extras, you should be ready to go with EnScript! Fire up EnCase and take a look at the sample EnScript that’s included with the code. The first thing you’ll notice at the top is the typelib instruction.

typelib aCDemoClass "CDemoLib.COMDemo"

This tells EnCase to retrieve the CLSID for the assembly from HKEY_CLASSES_ROOT\CDemoLib.COMDemo\CLSID, then locate the CLSID at HKEY_CLASSES_ROOT\CLSID\{ClassGUID} and import the TypeLib specified. If we got everything right, you should see this in the EnScript Types tab of EnCase:


You can see the properties and methods are showing up just fine. Next we’re going to declare our variable using the newly imported class and call Create() to instantiate the object.

aCDemoClass::COMDemo acd;

That’s it! You can see from the demo code that we can set and retrieve the values of our properties:

Console.WriteLine("Value1: " + acd.Value1());
Console.WriteLine("Value1: " + acd.Value1());

Value1: 0
Value1: 1000

And we can also utilize the methods from our DLL:

Console.WriteLine("acd.PlusFive(7): " + acd.PlusFive(7));

Output: “acd.PlusFive(7): 12

Recently an acquaintance was having issues with getting the project to work in a 64-bit OS, so I updated the example registration files for version 0.2. The only real difference is that you run the 64-bit version of Regasm.exe from the Framework64 directory. This inserts the necessary info for use with the 64-bit version of EnCase. The same registry keys we inserted above still apply because Windows aliases the proper section of the registry for 64-bit usage. The latest version of the code updates the project to Visual Studio 2010 and I’ve confirmed testing for .NET Framework versions 2 and 4 with the new project.

Got Errors?
If you forgot to perform any registration at all, you’ll probably see, “Expecting ‘field or method declaration’, Custom dotNet COM Object(13,13).”

Depending on the version of Regasm.exe used, if you don’t add the custom registry keys, when you run the script you might see a “Class not registered” error or something similar.

Anything I missed? Drop me a line in the comments.

NYC4SEC Meetup with Ovie Carroll

I just got back from the NYC4SEC Meetup held at Pace University. It was a welcome opportunity to see old colleagues and friends and meet many people in the industry with whom I’ve conversed electronically. The turnout was great – probably about 30 people – and it was definitely a success! It’s great to be able to swap war stories and share experiences with peers in the forensics world.

The speaker tonight was Ovie Carroll, Director for the Cybercrime Lab at the Department of Justice, Computer Crime and Intellectual Property Section (CCIPS) and an adjunct professor at George Washington University. Ovie was in town to teach the SANS Forensics 408 course and agreed to stop by and speak to our group. Ovie is a fantastically engaging speaker with a quick wit and more jokes than Steve Martin. I think it’s fare to say the crowd, which represented diverse experience levels, thoroughly enjoyed his presentation. His style of presentation really brings the audience into the conversation.

Ovie touched on a lot of things from basic knowledge on where to look for physical pieces of evidence to very specific artifacts. He showed some intelligent timeline presentation graphics and underscored the value of trace pieces of evidence by discussing a prominent case he dealt with and how they tracked the suspect down from a seemingly innocuous screenshot.

The overarching theme of his presentation was that forensic analysts have to be smarter about how they approach different problems and also how they interface with counsel or those requesting the analysis. He discussed the need to develop an investigative plan, just as one would do with non-digital evidence and investigations. This plan should involved counsel as early as possible and you should push back on those that say, “Just give me everything!” (My addition: As experts this is exactly what we get paid to do – not just to nod and go digging for everything, but to tell the client and counsel what our expert experience says they should be looking for and what its value is!!!)

There’s often a first reaction for analysts to say, “I can’t do anything with this drive yet, it’s not imaged!,” and Ovie would say that’s dead wrong. He pushed the idea of triage quite a bit, pointing out that you might not get all the benefits of a full forensic exam, but you might get just enough to have a conversation with the subject of your investigation and bring more value in the process. Triage is not going to put an end to forensic exams, it’s just another tool that gets you a few pieces quickly. The key to making this useful is that it must produce output that’s easy to understand for non-technical people, otherwise the usefulness of fast data retrieval declines rapidly.

The other pain point Ovie listed is one I’m sure everyone feels: an overwhelming amount of evidence to deal with. For law enforcement, more and more digital evidence is being seized as officers and prosecutors become more familiar with the value of digital evidence; for corporate investigators, enterprises are adding more varied devices to their technology lineups that analysts need to keep on top of. This is an issue everyone has been dealing with for a while now and Ovie, like all of the rest of us, is searching for the light at the end of the tunnel. Of course, no good digital forensics presentation would be complete without the Find All Evidence button!

Thanks to Ovie for his great presentation, to Doug Brush for organizing, to J-Michael Roberts and his wife for the delicious USB dongle-shaped cake (!!!), and to Pace University for hosting us! Joe Garcia is trying to line up some great folks from the industry for upcoming meetups. I’m sure everyone is looking forward to our next great get together, so keep an eye on the schedule and please join the Meetup group to stay informed!

GitHub is Pretty Swell!

I’m slowing starting to move all my current code over to GitHub. GitHub is an online collaboration environment for use with Git, a fast, distributed version control system. It’s used by some pretty heavy hitters in the development world. On Windows, I use PortableGit because it’s easy and self-contained; on Ubuntu, Git can be found in apt/Synaptic.

You’ll see a new link in my menu at the top pointing to my public GitHub repositories. From here you can browse the code or download entire projects. For the meantime I’ll keep posting zip files to the EnSCripts page as they’re often easier for non-developers to deal with. Consider learning Git and moving your own projects to GitHub if you’re still self-hosting. Just, uh, don’t commit passwords. Enjoy!

Getting Started

Well I put off getting started as long as possible. Maybe I waited too long?

The truth is I’ve been outside the veil now for about a year and I’m consistently becoming re-involved in Real ForensicsTM. I occasionally made time in the past to speak about my passion with others, but as I spend more and more time on it again I’d like to share some things as I plod along. The first thing that comes to mind is EnScript, as I’ve published a few over the years. A decent number of questions pop up and these are answered by a few usual suspects: Lance Mueller does an awesome job posting new relevant stuff ; Jon Stewart has been posting on the Three Laws of EnScript; and Paul Bobby has recently been churning out illustrative scripting guides. You can also expect posts on general forensics, e-discovery, weirdo technical issues with my favorite email client Lotus Notes, and all kinds of other tech issue beasties that affect us every day. I hope that the topics I post on are interesting to general practitioners and developers alike, and if you’re keen on a particular subject please let me know!