locked
Is the Intermediate Language a security risk? RRS feed

  • Question

  • We are creating a new product where the main value will be in the data, and there will be a relatively small amount of code that will process that data.  The data will be encrypted so competitors will not be able to use it, but I'm assuming it would be a simple matter to look at the Intermediate Language and determine how to decrypt and use the data.  We are considering doing this in C# but could also do it in C++, but we want to use .NET in either case.

    Is my assumption about the Intermediate Language correct, that any of our competitors could easily reverse engineer our code by purchasing one of our products and examining the Intermediate language?

    Does C++ also create this intermediate language when using .NET?  I realize that machine code can also be reverse engineered, but it's not nearly as verbose and more can be done to hide the details.

    Harry Strand
    StrandControl, LLC
    www.homedomination.com
    hstrand@homedomination.com
    Wednesday, January 18, 2006 5:24 PM

Answers

  • C++ code can go two ways... in one case if you build a regular .NET app or library in C++ it will be compiled to MSIL and suffer from the same potential issue as C#, VB.NET or any other high level .NET language.

    Another C++ option is to enable managed extensions within the code, but not specifically compile it into MSIL (ie building an MFC app with CLR support).

    One solution to the potential problem of reconstructing an application from it’s MSIL is obfuscation. One of the easiest solutions (that also comes for free with Visual Studio) is Dotfuscator from Preemptive Solutions.

    Obfuscation works by removing and renaming aspects of a .NET assembly making it much more difficult to understand the inner workings of it and with the higher versions (which they do sell) you are able to do more advanced alterations like string encryption and much much more.

    Wednesday, January 18, 2006 5:35 PM

All replies

  • C++ code can go two ways... in one case if you build a regular .NET app or library in C++ it will be compiled to MSIL and suffer from the same potential issue as C#, VB.NET or any other high level .NET language.

    Another C++ option is to enable managed extensions within the code, but not specifically compile it into MSIL (ie building an MFC app with CLR support).

    One solution to the potential problem of reconstructing an application from it’s MSIL is obfuscation. One of the easiest solutions (that also comes for free with Visual Studio) is Dotfuscator from Preemptive Solutions.

    Obfuscation works by removing and renaming aspects of a .NET assembly making it much more difficult to understand the inner workings of it and with the higher versions (which they do sell) you are able to do more advanced alterations like string encryption and much much more.

    Wednesday, January 18, 2006 5:35 PM
  • Thanks, that gives me some options.  I appreciate the help!

    Harry Strand
    StrandControl, LLC
    www.homedomination.com
    hstrand@homedomination.com
    Wednesday, January 18, 2006 7:13 PM