I am trying currently to do my first large project taking apart a .NET program, having studied over the last couple weeks the various techniques that people employ and how to get around them. Most of them seems to rely on encryption, JIT hooking, general packing etc. I get all of this, have tested a lot of the tools and got my feet wet.

So I decided to pursue more interesting applications then the ones I was writing, protecting, and taking apart on my own (just doing a VS.NET console application project, and writing out a few strings to standard output, then using the trials of various programs for testing). Since I do routing and switching as my trade, I found a .NET application that used Cisco web services, and started with that.

However, for even my first project I am having difficulty understanding the technique they used. The primary assembly is in managed code, however all the methods are empty stubs, only the types are available. So I traced it to follow the assemblies its loading, and there is another assembly that is loaded that I *think* contains the functions, however it does NOT contains a CLR header so leads one to believe that it is unmanaged code. However, I have studied some techniques that used a native compilation technique to mask this as such to discourage reflection.

Is there a signature, or other attribute on the compiled assembly that can provide me more information on what was used for protection? My inkling says it was written in managed code, however some trick was used for unmanaged marshalling into the main caller. The only reference I see in IDA is BDS 2005-2007 and Delphi6-7 Visual Component Library...

What you probably have is a main app written in Delphi, with a protection on it that was written in .net. (Protection Plus has a .net module that you can use for your app.)

And, the protection plus module (.dll), is a mixed mode assembly. It has both managed, and unmanaged code in it. This threw me for a loop when I first looked at it as well. You reflect it, and you see it calling functions that only exist as a bare shell of a function. (These shells are just place holders for the unmanaged code that exists in the other "half" of the module).

So, I used IDA, and loaded the .dll in, and had it do it as a .NET assembly, and saved it, and then loaded it again and told IDA it was just a .dll, and it pulled out the unmanaged part. Then, you can look at the functions that are being called, and what they do, on both sides.

(assuming that you're good at X86, and not just CLR).