locked
Managed DLL vs Unmanaged DLL RRS feed

  • Question

  • Hello,

    I have been trying to search the web for reasons to use a Managed DLL vs a Unmanaged DLL.

    I would like to know mainly the security reasons on why each is better or the strengths of each.

    This is what I know:

    Managed Code
    -Is managed by the CLR (Common Language Runtime) when compiling.
    -The CLR is the virtual machine component of Microsoft's .NET framework and is responsible for managing the execution of .NET programs
    - In a process known as “just-in-time compilation”, the compiled code is converted into machine instructions that, in turn, are executed by the computer's CPU
    - Some of the great features that a CLR is it has offers services like garbage collection, run-time type checking, and reference checking.
    -Managed Code uses Code access security that lets the administrator specify which operations a piece of code can perform, stopping inappropriate behavior before it can start.

    Unmanaged Code
    -Unmanaged code does not compile to a Common Language Intermediate (CLI), it instead compiles straight to machine language or native language.
    -No free memory management or anything else the CLR provides.
    -Because it does not use the CLR, the security checks from a wrapper function that are from a managed source will have to check the unmanaged code for buffer overrun errors, exhaustive parameter checking from caller methods, and permission to write to memory with code access security.
    -There is no garbage collector thus you are in charge of the memory leaks that can occur.
    -Any call into unmanaged code is regarded as a highly protected operation and is protected with a security check from any managed code.

    Now, I have just distinguished the difference between Managed and Unmanaged so no need to clarify.

    I would like to know the strengths of using Managed and Unmanaged DLLs from a security standpoint.

    What I have been told (verbally):

    -Unmanaged DLLs are much harder to reverse engineer (Why is this and a source would be nice).
    -Without the .lib file it is much harder to rebuild the DLL. (I think this is all DLLs)
    -Method calls in an unmanaged DLL need to be exported and have the correct linker to the entry name. (unmanaged C++ for ex)

    So this is pretty much all I know that are the differences with regards so DLL security usage, but some sources and explanation would be nice.

    Kind Regards

    Tuesday, April 8, 2014 2:00 PM

Answers

  • The decision between managed and unmanaged should really evolve around whether you're going to use C++ or a managed language.  From that everything else falls out.  If you are going to use C++ then you're going to be creating an unmanaged DLL.  If you're going to use C#/VB then it'll be managed.  C++/CLI could be used for C++ and managed but it is really for interop scenarios.  I don't know of any major project that actually uses it.

    - Unmanaged code is harder to disassemble but there are tools to do it so it isn't impossible.  What makes it hard is the lack of metadata and the complexity of C++ more than the unmanaged part.

    - The LIB doesn't really have anything to do with it.  The LIB is what the linker uses to hook up the DLL to the object code.  By itself it is just a list of exports.  You can get that without the LIB file (see Depends.exe).

    - Whether it is managed or unmanaged doesn't matter, all methods that are usable must be exported.  The difference is that managed code doesn't expose (most) members and hence the export needs are minimal. 

    As of today if all you care about is disassembly of your code then unmanaged code is clearly the winner but I don't know that disassembly alone should be the determination to go unmanaged.  Because even unmanaged code can be disassembled (using the freely available tools) so it still doesn't solve anything (unless you obfuscate, which managed code can do too).  Recently MS has announced .NET Native for WinRT apps.  There are plans to port it to Win apps.  When that occurs you will get the benefits of managed code with the performance (and security) of unmanaged.  But that is a ways away.

    I really believe you should evaluate the language you want to use based upon the problem you're solving and the skillset of the devs.  This will determine whether you go managed or unmanaged (or perhaps a mixture of both if needed).

    Michael Taylor
    http://msmvps.com/blogs/p3net

    • Marked as answer by moxman99 Tuesday, April 8, 2014 3:40 PM
    Tuesday, April 8, 2014 3:05 PM
  • Just a word of caution that it doesn't matter what type of obfuscating you're doing on the key, once you've decrypted it then it is visible to anyone who can debug your code as you are likely storing it in memory.  To be more secure you should probably consider keeping the encryption all in unmanaged code (and not store a decrypted version of the key outside the stack).  This still isn't completely secure but it does make it harder. 

    I think your C# UI in combination with a C++ library is reasonable.  If you don't mind working in both languages then you'll get the performance (and disassembly) benefits of C++.  I personally don't find that obfuscating .NET code to be useful so you might consider whether it really gains you anything or not.  Of course if it is already working then there is no reason to change it.

    I cannot think of any other security-related benefits of unmanaged code vs managed.

    Michael Taylor
    http://msmvps.com/blogs/p3net

    • Marked as answer by moxman99 Tuesday, April 8, 2014 3:40 PM
    Tuesday, April 8, 2014 3:38 PM

All replies

  • The decision between managed and unmanaged should really evolve around whether you're going to use C++ or a managed language.  From that everything else falls out.  If you are going to use C++ then you're going to be creating an unmanaged DLL.  If you're going to use C#/VB then it'll be managed.  C++/CLI could be used for C++ and managed but it is really for interop scenarios.  I don't know of any major project that actually uses it.

    - Unmanaged code is harder to disassemble but there are tools to do it so it isn't impossible.  What makes it hard is the lack of metadata and the complexity of C++ more than the unmanaged part.

    - The LIB doesn't really have anything to do with it.  The LIB is what the linker uses to hook up the DLL to the object code.  By itself it is just a list of exports.  You can get that without the LIB file (see Depends.exe).

    - Whether it is managed or unmanaged doesn't matter, all methods that are usable must be exported.  The difference is that managed code doesn't expose (most) members and hence the export needs are minimal. 

    As of today if all you care about is disassembly of your code then unmanaged code is clearly the winner but I don't know that disassembly alone should be the determination to go unmanaged.  Because even unmanaged code can be disassembled (using the freely available tools) so it still doesn't solve anything (unless you obfuscate, which managed code can do too).  Recently MS has announced .NET Native for WinRT apps.  There are plans to port it to Win apps.  When that occurs you will get the benefits of managed code with the performance (and security) of unmanaged.  But that is a ways away.

    I really believe you should evaluate the language you want to use based upon the problem you're solving and the skillset of the devs.  This will determine whether you go managed or unmanaged (or perhaps a mixture of both if needed).

    Michael Taylor
    http://msmvps.com/blogs/p3net

    • Marked as answer by moxman99 Tuesday, April 8, 2014 3:40 PM
    Tuesday, April 8, 2014 3:05 PM
  • Hi Michael,

    Great answer.

    I am using a C# winform application that has an unmanged C++ DLL. The C++ DLL has methods I import to the C# and then I am able to use them. The DLL has information in it such as keys for encryption/decryption. I use a "shifting of the bits" technique so that key it self is not in the clear and is scrambled.

    I am also obfuscating both the C++ and C# but like you have stated above, it is still not impossible to rebuild the solution, just time consuming for a hacker.

    So the definitive answer for using an unmanaged DLL is because Unmanaged code is harder to disassemble. The lack of metadata and the complexity of the C++ language is what makes it difficult.

    I am sorry I forgot about the dependency walker to see the entry points so this as a security measure is out of the question.

    Are there any other reasons to why this might be a good path to go down with regards to assembly rebuilding?

    Tuesday, April 8, 2014 3:29 PM
  • Just a word of caution that it doesn't matter what type of obfuscating you're doing on the key, once you've decrypted it then it is visible to anyone who can debug your code as you are likely storing it in memory.  To be more secure you should probably consider keeping the encryption all in unmanaged code (and not store a decrypted version of the key outside the stack).  This still isn't completely secure but it does make it harder. 

    I think your C# UI in combination with a C++ library is reasonable.  If you don't mind working in both languages then you'll get the performance (and disassembly) benefits of C++.  I personally don't find that obfuscating .NET code to be useful so you might consider whether it really gains you anything or not.  Of course if it is already working then there is no reason to change it.

    I cannot think of any other security-related benefits of unmanaged code vs managed.

    Michael Taylor
    http://msmvps.com/blogs/p3net

    • Marked as answer by moxman99 Tuesday, April 8, 2014 3:40 PM
    Tuesday, April 8, 2014 3:38 PM