Tech Off Thread

29 posts

Methods of protecting .net exe's from decompilation?

Back to Forum: Tech Off
  • User profile image
    W3bbo

    CodeGuru123 wrote:
    My goal is to protect my investments and make it more difficult (not impossible) for would be crackers to break.


    I think that line there is your problem. You cannot fight the warez crowd, but you can woo over their audience.

    Just wondering, what makes you think that a protectionist stance is the best?

  • User profile image
    CodeGuru123

    Its the industry I'm in..

    We deal in low volume sales and our product caters to a specific market. We're able to stay ahead of our competition because we have resources that make us able to develop new products in our industry before our competitors do.

    Due to the nature of our product, it would be very easy for our competitors to gain key info from reversing our product which would allow them to tap into new customer bases.

    By protecting our product the way we do, the amount of time it would take to crack is similar to the amount of time it would take to develop the new products the hard way.. the way we currently do.

    If we released our application in unprotected .net form, it would be only a matter of time before our market share was decreased substantially due to the fact that we'd lose our edge of being first to market. We might still be first, but the second to market companies would follow very shortly after us, unlike now where we have a year or so or more...

  • User profile image
    Royal​Schrubber

    Ok, what industry you're working in? If you say it's industry then you're not the only one doing it right? What do you do?

    Also, if I can contribute - build your app with mvc paradigm in mind.. do Model and Controller in C/C++ and View in .net. You competitors are probably smart enough to do View(GUI) themselves, but it will be hard(er) for them to get to your algorihm code... or throw away .net completely and do it in c++/mfc, machine code can be much more obfuscated than IL.

  • User profile image
    W3bbo

    RoyalSchrubber wrote:
    Ok, what industry you're working in? If you say it's industry then you're not the only one doing it right? What do you do?

    Also, if I can contribute - build your app with mvc paradigm in mind.. do Model and Controller in C/C++ and View in .net. You competitors are probably smart enough to do View(GUI) themselves, but it will be hard(er) for them to get to your algorihm code... or throw away .net completely and do it in c++/mfc, machine code can be much more obfuscated than IL.


    MVC doesn't work for every program. It's geared towards 3-tier database apps, it wouldn't work well for Photoshop or Excel, for example.

    Anyway, re: the whole thing, I'd just go for a simple metadata stripping and .NET-header injection, that should be sufficient, otherwise I think you're just being paranoid. Often you don't need to see the source (or even know the algorithms) to see how a program works.

    ...unless your competitors know how your program works already, but want to know your algorithms, in which case you're teh b0rked.

  • User profile image
    AndyC

    W3bbo wrote:
    
    MVC doesn't work for every program. It's geared towards 3-tier database apps, it wouldn't work well for Photoshop or Excel, for example.


    I'd hazard a fairly good guess that both Photoshop and Excel have an MVC approach at their core, almost all document-centric applications work that way.

  • User profile image
    stevo_

    MVC pattern probably applies to most applications in some way.. hey - you could do an MVC on top of SOA.. Tongue Out

    I'm in a somewhat similar boat, where we're thickening our client on one of our products, we're well aware that the client is essentially open, but we accept that.. if anything it reminds some of the less hardened developers out there not to 'trust' the client..

    Our current plan is just to carry on as normal, but we may well instead 'come out' and just become entirely transparent about the 'framework' that exists on our client, if we're in fear of 'losing our ip', we might as well make some kind of publicitiy from it.. Expressionless

    Not to mention the gains you can get from open feedback and 'debugging' from your users.

  • User profile image
    numedia

    CodeGuru123 wrote:
    

    By protecting our product the way we do, the amount of time it would take to crack is similar to the amount of time it would take to develop the new products the hard way.. the way we currently do.

    If we released our application in unprotected .net form, it would be only a matter of time before our market share was decreased substantially due to the fact that we'd lose our edge of being first to market. We might still be first, but the second to market companies would follow very shortly after us, unlike now where we have a year or so or more...


    There seems to be this arrogance that code written in an application is the only way the job could have been accomplished. So if a competitor wanted to duplicate your application, he would need to write it exactly like you did.

    A couple years ago a huge portion of the Windows 2000 source was released. Did that instantly spawn new OSes and allow the competition to take over Windows? It's easier in most all cases to duplicate the functionality of an application by writing it yourself rather than trying to decompile and understand someone else's source code.

    So the questions asked earlier of who and why people would want your source code is very relavent.

    And yes, there are many many major applications written in .NET.

  • User profile image
    evildictait​or

    I think the big questions are what algorithms you guys are using, because (like it or not) the vast majority of the code for a normal windows application is fluff and wouldn't be copied even if you gave the source away free with the app.

    If you're releasing complex algorithms (such as compilers, or solution solvers or hashes or implementing protected network protocols) which might legitimately be sought after with the intent of gaining knowledge or algorihms (but not code) then you should be looking to build those algorithms in C and use a commercial grade obfuscatior over it.

    Frankly, for most apps the Dotfuscator product that you get free with VS will be more than enough to deter any prying eyes, and unless you have good reason to do otherwise, I'd just concentrate on getting the product out of the door rather than wasting time enhancing the security of code that nobody wants to steal.

  • User profile image
    CodeGuru123

    Its not arrogance. Please don't be so close minded.

    We develop software tools that interface with hardware built by others..

    (These are just examples to get open your thought processes)
    For example, it could be iPods, cell phones, pda's, etc.. devices built by vendors who we have no communication with and in many cases do not even know about us.

    So in our src is methods and keys to access these "devices". So yes, to do what we do you would have to write the SAME exact code as there is one and only one way to do these things. These keys and methods are also not published by the manufacturers and are VERY, i repeat _VERY_ hard to come by.

    And I know someone is going to say to put these secure pieces in a native dll or something else.. however the methods and keys are not as simple as you would think. They are actually very complicated and are really embedded into the parent .net program. To extract them into a seperate DLL would really muck up the entire program structure..

    I think the list I came up with on the first page is a great list.

  • prevents viewing the MSIL from both a reflector type app and also via RAM dumpers.
  • Packs the exe into a loader application that isn't easily unpacked.
  • Prevents .net extraction via modification of the native core .net dll's.
  • Prevents debugger attachments, softice, etc...
  • Disables .NET profiling
  • Protects against ProcDump
  • Does not require packing the entire .net framework into the exe to achieve the above protection

    Also, if you think that list is unrealistic, there is an app on the first page that does the above. It is also the most expensive one listed by far. I'm looking for more options.

    Edit: I know a lot of you are trying to help..  As if I was your "average" coder trying to protect something that didn't need to be protected, or wasn't informed about software security. I know I didn't provide ALL the facts in my original post either, I didn't feel I needed to.

    I'd love for this thread to be about my original question though, methods for protecting .net applications. Lets pretend the reasons for protecting the .net app are not important but instead discuss ways to do so, for even the most simple "hello world" application. Smiley

  • User profile image
    CodeGuru123

    evildictaitor wrote:
    If you're releasing complex algorithms (such as compilers, or solution solvers or hashes or implementing protected network protocols) which might legitimately be sought after with the intent of gaining knowledge or algorihms (but not code) then you should be looking to build those algorithms in C and use a commercial grade obfuscatior over it.


    Bingo.

    We do exactly that for the VERY sensitive algo's we include in our app.

    We also do include a hardware key for some sensitive algo's too, however our app requires a crippled functionality w/o the hardware key so we're forced to do the method you described as well.

  • User profile image
    evildictait​or

    CodeGuru123 wrote:
    Its not arrogance. Please don't be so close minded.

    We develop software tools that interface with hardware built by others..

    (These are just examples to get open your thought processes)
    For example, it could be iPods, cell phones, pda's, etc.. devices built by vendors who we have no communication with and in many cases do not even know about us.

    So in our src is methods and keys to access these "devices". So yes, to do what we do you would have to write the SAME exact code as there is one and only one way to do these things.

    And I know someone is going to say to put these secure pieces in a native dll or something else.. however the methods and keys are not as simple as you would think. They are actually very complicated and are really embedded into the parent .net program. To extract them into a seperate DLL would really muck up the entire program structure..

    I think the list I came up with on the first page is a great list.

  • prevents viewing the MSIL from both a reflector type app and also via RAM dumpers.
  • Packs the exe into a loader application that isn't easily unpacked.
  • Prevents .net extraction via modification of the native core .net dll's.
  • Prevents debugger attachments, softice, etc...
  • Disables .NET profiling
  • Protects against ProcDump
  • Does not require packing the entire .net framework into the exe to achieve the above protection

    Also, if you think that list is unrealistic, there is an app on the first page that does the above. It is also the most expensive one listed by far. I'm looking for more options.



  • Okay. The first thing you need to do is identify and eliminate every use of reflection within your entire program. Reflection by definition makes use of metadata embedded within the source program (such as method names, how types are stored etc). Be thorough when you do so - things like the binary and XML serializer also use reflection to obtain data about how your program works.

    The next thing you really must do is migrate all of your code to one project so you can eliminate DLL dependencies. You'll hate me for even suggesting it, but every call out to a DLL (in .NET or native) conveys a certain amount of information with it, particularly in the case of .NET. By migrating all of your code to one solution you can build the whole thing without dependencies (excepting the main dependencies such as System and System.Windows.Forms) and any .NET profiler worth it's salt will show you redundant code paths that you can eliminate as well.

    Do everything now that you want to do testwise as you will not have the opportunity to do so later. This includes profiling and tests. You should then ask the CS compiler to compile with maximum optimisations and generate a big EXE in .NET.

    You should now run a .NET obfuscator over the assembly, and then using the result and an NGEN make a native executable. It'll be big, and you should ask the program to make sure that all metadata is eliminated. You should now check that the program still works (if it doesn't that means there was probably some reflective code in the original CS, such as using the Object.ToString() on an object that doesn't overload it.

    Now you should be able to run a commercial grade native obscator over the program, and you should then do final testing to make sure that the output is still the expected output. Try using various decompilers to see what code is outputted.

    Now if you're really really paranoid, you can zip up the file (with a password or then encrypt it) and write a C app that unencrypts the file and de-zips it into memory and then runs it. You should run a commercial grade obfuscator over the C app if you do so, and you may find that the zipping process makes the program smaller (but slower) too.

  • Comments closed

    Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.