none
CLR Intermediate Language RRS feed

  • Question

  • We all know that compiled assembly in .NET using Intermediate Language code. Thin IL code can be decompiled and back to any .NET Language like C# or VB.

    The problem is :

    When I try to make a production software with .NET , other people may decompiled it and take the code.

    I have read about .NET obfuscator and I need to buy this software from this 3rd party.

    My Question :

    Is there anyone can help me how to make this IL cant be decompiled again , so anyone cant steal my code or my software design ?

     

    Tanx I appreciate for helper.



    It's hard to be advanced programmer
    Friday, January 30, 2009 3:01 AM

Answers

  • You need to take a look at the game industry. Game companies, some spent huge amount of money and time to prevent unlicensed copies, failed to protect the big names from being cracked within days of release. Note that almost all these games are written in native code rather than managed code.

    If you cann't trust your customer base, put your code on a web server.

    MSMVP VC++
    • Edited by Sheng Jiang 蒋晟 Friday, January 30, 2009 10:48 PM typo
    • Marked as answer by IRW7 Monday, February 2, 2009 12:59 PM
    Friday, January 30, 2009 10:47 PM

All replies

  • Speaking as someone who's both both written copy protection and licensing code, and done large-scale dissasembly (for entirely legal and legitmate reasons) professionally...

    My advice: obfuscation really doesn't stop someone who's determined to disassemble your app.

    And anyone who's good enough to disassemble your app (obfuscated or not) could probably write the code themselves, and save themselves the hassle of a well deserved copyright infringment lawsuit. It's not like you could seriously DO something with the stolen code.

    Unless, I suppose, you have some realllly funky algorithm that you want to protect. (I can't honestly think of one). In which case it will fall to disassembly no matter what you do. You can make it slightly inconvenient. But that's about it.

     

     

     

     

    • Proposed as answer by Robin E Davies Friday, January 30, 2009 7:05 AM
    Friday, January 30, 2009 6:54 AM
  • My advice: obfuscation really doesn't stop someone who's determined to disassemble your app. 

     


    In my knowledge they can disassembly using .NET library itself like Reflection.

     Is there other way to read IL code not using .NET library ? Maybe using binary read and parse that code ?

    I think if we can only disassembly using .NET reflection, is there any attribute I can use to hidden class or method ?

     

    Tanx


    It's hard to be advanced programmer
    Friday, January 30, 2009 7:50 AM
  • You need to take a look at the game industry. Game companies, some spent huge amount of money and time to prevent unlicensed copies, failed to protect the big names from being cracked within days of release. Note that almost all these games are written in native code rather than managed code.

    If you cann't trust your customer base, put your code on a web server.

    MSMVP VC++
    • Edited by Sheng Jiang 蒋晟 Friday, January 30, 2009 10:48 PM typo
    • Marked as answer by IRW7 Monday, February 2, 2009 12:59 PM
    Friday, January 30, 2009 10:47 PM
  • Hello,

    1) There are tools to disassemble a managed assembly without using System.Reflection. 2 good examples are: ildasm (part of .NET Framework SDK) and .NET Reflector (http://en.wikipedia.org/wiki/.NET_Reflector).
    2) There is no attribute or anything like that to hide classes or methods in System.Reflection. If runtime itself can read all the content from an assembly, there is no point in hiding that stuff from user as the runtime's way of reading the content can be duplicated in an external tool.

    Note that while obfuscators don't prevent others from disassembling your code in general, they make it much harder to read the disassembled code. Try to use an obfuscator on your code and then try to disassemble it - you will see that there are missing local variables names, changed names of classes and methods, etc. All these modifications make it really hard to understand the disassembled code without source code.

    -Karel

    Monday, February 2, 2009 5:46 PM
    Moderator