locked
Can a C++\CLI wrapper for unmanaged library make the unmanaged code visible in dis-assemblers

    Pregunta

  • We have a C++ (Mixed Code) library (.LIB) used to perform product activation and we do not want anyone to see how it is being done internally. We want to use this LIB in our .NET projects for which I created a C++\CLI wrapper library and it works fine. The only downside that I see is that I can open the C++\CLI library in any dis-assembler (ILSpy, Reflector etc) and see what's going on inside it. I am not sure if the dis-assembler can let users see the unmanaged C++ code along with the small wrapper code that I've written. I do see a lot of Cpp stuff in the dis-assembler and I know that the required unmanaged code is getting pulled into C++\CLI library and is self contained. Do I need to worry? My main class 'Activator' is an unmanaged class inside the LIB.

    I also tried creating a simple Win32 DLL, hoping it will not open in a dis-assembler but because the .LIB is a Mixed Code library, the DLL became a mixed code (I guess) and I was able to see the stuff.


    Click the 'Vote as Helpful' arrow if this post was helpful.
    viernes, 03 de febrero de 2012 11:19

Respuestas

  • As Paul said there are obfuscators that work on .NET assemblies that try and confuse tools like ILSpy/Reflector by removing the metadata and by reorganising the IL such that the IL=>C# or IL=>VB.NET features do not work. These features use common IL patterns to recognise common langauge constructs such as foreach loops in those languages. The simplest of the obfuscators use lots of jumps in your method but it is still the same code if you unravel it. But this can only go so far as your code still has to run and not be so slow that your users get frustrated by it.

    ILSPY and Reflector only work on managed assemblies i.e. .NET and will not decompile your native libraries.

    Use of obfuscators may not stop a determined hacker with access to your code, but since you are happy to use the activation library already as-is (native/assembly) then I assume you have assesed this threat and are prepared for it i.e. you know a hacker with time and patience can possibly break your activation but you don't want it to be too easy.

    There are other obfuscators but these work against the source code and were popular in javascript; less so now - unless you still count the minimised.

    miércoles, 08 de febrero de 2012 4:51
  • To add to what Shaun said:

    The native portion of your code is not viewable by IL based disassembly tools such as Reflector. That doesn't mean that someone can't disassemble the native part with some time, effort, and other tools - but it won't be as simple as using Reflector.

    HTH,

      -Noah

    viernes, 10 de febrero de 2012 7:55
    Moderador

Todas las respuestas

  • Hi, 

    As I know, there are some obfuscators for .NET assembly that will protect the IL and metedata. But I do not know whether they can work with Win32 Dll, I think you'd better post in Visual C++ General forum.

    Thanks for your understanding.


    Paul Zhou [MSFT]
    MSDN Community Support | Feedback to us

    martes, 07 de febrero de 2012 9:17
  • As Paul said there are obfuscators that work on .NET assemblies that try and confuse tools like ILSpy/Reflector by removing the metadata and by reorganising the IL such that the IL=>C# or IL=>VB.NET features do not work. These features use common IL patterns to recognise common langauge constructs such as foreach loops in those languages. The simplest of the obfuscators use lots of jumps in your method but it is still the same code if you unravel it. But this can only go so far as your code still has to run and not be so slow that your users get frustrated by it.

    ILSPY and Reflector only work on managed assemblies i.e. .NET and will not decompile your native libraries.

    Use of obfuscators may not stop a determined hacker with access to your code, but since you are happy to use the activation library already as-is (native/assembly) then I assume you have assesed this threat and are prepared for it i.e. you know a hacker with time and patience can possibly break your activation but you don't want it to be too easy.

    There are other obfuscators but these work against the source code and were popular in javascript; less so now - unless you still count the minimised.

    miércoles, 08 de febrero de 2012 4:51
  • ILSPY and Reflector only work on managed assemblies i.e. .NET and will not decompile your native libraries.

    Does this mean that I should  not worry about the unmanaged code linked from .LIB file? I am only concerned about the unmanaged code in my .NET mixed code assembly.

    Click the 'Vote as Helpful' arrow if this post was helpful.

    miércoles, 08 de febrero de 2012 5:00
  • To add to what Shaun said:

    The native portion of your code is not viewable by IL based disassembly tools such as Reflector. That doesn't mean that someone can't disassemble the native part with some time, effort, and other tools - but it won't be as simple as using Reflector.

    HTH,

      -Noah

    viernes, 10 de febrero de 2012 7:55
    Moderador