C# An Example of a COM Parser, Embed COM Interface DLLs in a *.cs file

This is an example of how you may take a COM *.dll file, and binary-embed it inside your C# project as a *.cs file. You can create a fully functional COM interface in managed enviroment using the steps described in the project.

Introduction

I wanted to prove that I can take any external COM Interface DLL and make it into a C# class object that can be used internally instead of Dynamically linking it.

When you add a resource COM interface, you actually dynamically link your project with a DLL file that will later show up in your project compilation output directory ..\bin\debug or ..\bin\release. In my opinion, this is not clean coding especially when you are using external DLLs that you have a license to use but don't want others to use them without a license. There are a few applications out there that can 'embed' your DLL files inside your executable, but those are just wrappers. What I'd like to demonstrate here is how we go back from Managed C# coding to the beginning of it all: Binary..

Background

What I have done is to create a simple [took me less than 2 hours] COM/DLL parser that can take any external COM *.dll resource file and convert it into Binary and then back into Managed C# code using the 'System' and 'System.Reflection' Namespaces and even add the COM classes and functions as C# methods.

The main objective is to convert the entire DLL into managed code!

The parser is not complete, of course, since it's just an example, but it is living proof that even with managed code you can access and embed the low-level binaries. So it's nice and you may (or not) even learn something. I hope someone will see this as a challenge and continue this parser, since it's a lot of 'dirty work', it's not hard enough to be interesting, and I'm too lazy to complete all the options (interfaces, variables, enums, etc... and then recursion of it all (classes inside classes and so on...)). But the main engine is already built, so...

Using the Code

I added the entire solution, and a demo executable. The entire parser is just a small class that uses the System.Reflection.Assembly to rebuild the DLL file back from binary after I embed the binary itself inside the C# file. After that, you may parse and use the DLL classes and methods as if you are using any other C# method, internally.

Points of Interest

This is a project output example, the highlighted file is the Shell32.dll:

Reason for my vote of 5Great idea! This way one can zip COM dll before embedding it (reduce size); and one can sign and/or encrypt it. This way thieft will be able to extract it, but modification will become much harder. The biggest issue I see here is 32/64 bit hell: afaik you MUST use 32 bit COM DLL or (another absolutely different) 64 bit COM DLL depending on the hardware.

1) it makes your executable super big2) if you need to fix something in the COM DLL, you need to ship the COM DLL and the EXE although its one huge chunk of crap3) dropping DLLs at runtime is super ghetto and generating the wrapper at runtime is expensive

You talk about an interpreter, that sounds pretty "hard and interesting" - while possibly rabbidly inefficient. You are after all talking about interpreting PE executables. Or did I get you wrong, have you found a way to execute the functionality exposed by the image? Or am I looking at a kind of ILMerge? "COM *.dll file, and binary-embed it inside your C# project as a *.cs file." seems to indicate the first option, that's what cought my attention, as it would have been really interesting to see this done

As stated above, I don't think that downvoting your work is fair. On the other side it's not really a strong protection. If the executable gets too big, it would make me curious if not suspicious, especially if the program does not appear to use enough resources (like graphics) to justify its size. And then I would examine its contents to find out what might be embedded in it.

You are a bit hard on him. He wants to embed the DLL into the executable as a byte array. You can see some of it at the bottom of the last screenshot. At runtime a Assembly object is constructed from the array in memory.

All this is supposed to protect the DLL from being copied and used by the users of your application. Granted, that's still only a weak protection as the stealing users probably would be developers themselves and would have little trouble extracting the embedded DLL once they see through this little trick.

Check out my solution for that in 'Alternate 1' I added. This way you can embed the COM directly from the downloaded memory, which will make it only a bit harder to sniff the packets downloaded (you can even encrypt it, etc..), since nothing is saved on the end-user side This will ofcourse require to download the com each time the end-user starts the app.. But it's a great way to make a crackers life interesting

The main reason for this example is to explain how to embed binaries and interact with them under managed C# coding. It's not supposed to be effective, it's supposed to be a demonstration of how to run a dll (or any byte data for that instance, could be an executable, an image etc...) from inside a class object. In my opinion grading or downgrading an example like this is meaningless

Why not use COM ref. you ask?

1. Maybe it's not a COM at all.. or maybe it's a purchased COM that you have the license to use but don't want others to be able to access it.

2. Maybe it's a unique version of the DLL, that will not be found on the end users computer

3. Maybe you want to download the binary dynamically from a website and then run them from the memory, instead of hard coding refs [Read the alternate I just added to understand how to do that]?

In a short version: COM refs are good, but knowing how to use the binaries dynamically is great