Tech Off Thread

29 posts

Methods of protecting .net exe's from decompilation?

Back to Forum: Tech Off
  • CodeGuru123

    I'm not looking for obfuscators.. I use commercial dotfuscator and it seems to do the job that all dotfuscators do..

    However, what other options are there from preventing our .net exe's being reversed?

    I know of solutions like:
    thinstall
    remotesoft
    http://www.xheo.com/products/codeveil/default.aspx
    .NET Reactor
    smartassembly

    But are there any others?

    I know some say to put your protected IP into native .dll's and invoke them, however if your calling .net exe is still reversable, the methods of accessing/using that .dll are still visible.

    Thanks.

  • evildictait​or

    CodeGuru123 wrote:
    

    I know some say to put your protected IP into native .dll's and invoke them, however if your calling .net exe is still reversable, the methods of accessing/using that .dll are still visible.



    Get your native entry points to look at the calling assembly's file, take a hash and compare it to your code, and do useful things only if there's a match.

  • AndyC

    evildictaitor wrote:
    
    Get your native entry points to look at the calling assembly's file, take a hash and compare it to your code, and do useful things only if there's a match.


    That's trivial to bypass. It is fundamentally impossible to verify the caller of a function, no amount of engineering a solution will rectify this.

  • gadget

    CodeVeil by xheo actually encrpyts your assembly and then decrypts into memory when it is ran.

    I haven't tried it though.

    http://www.xheo.com/products/codeveil/default.aspx

  • figuerres

    CodeGuru123 wrote:
    

    I'm not looking for obfuscators.. I use commercial dotfuscator and it seems to do the job that all dotfuscators do..

    However, what other options are there from preventing our .net exe's being reversed?

    I know of solutions like:
    thinstall
    remotesoft

    But are there any others?

    I know some say to put your protected IP into native .dll's and invoke them, however if your calling .net exe is still reversable, the methods of accessing/using that .dll are still visible.

    Thanks.



    first thing I always ask is why?
    then what is the risk?
    what is the benefit?
    what is the cost?
    what is the audience (users, who, sales market)?

    most of the time the users are not going to mess with the code and the cost far outweighs the benefit.

    if the users are tech-savy hacker types then the same thing happens as a determined cracker will break any protection if they are willing to spend the time and effort.

  • littleguru

    The thing is that if somebody really wants to crack your app s/he always can. Look at how fast games and software get cracked - even if they are compiled down to native. Crackers just don't care, they analyze the assembly code and fix it...

  • JPeless

    Write code so crappy that it is self obfuscated and no one would want to use it anyway? Big Smile

  • W3bbo

    littleguru wrote:
    The thing is that if somebody really wants to crack your app s/he always can. Look at how fast games and software get cracked - even if they are compiled down to native. Crackers just don't care, they analyze the assembly code and fix it...


    Cracking games for piracy is one thing, it just means unauthorised distributions can be made.

    That's different to disassembly where the consequences are much worse: commercial rivals can use your source to build a competing product with zero development expenses, then sell it for profit.

    By the time you get round to suing them for copyright infringement or other offenses they can change the source enough.

    ....okay, that's definately a worst-case scenario, but you get the point. Unlike simple piracy, where pretending the problem doesn't exist works, you cannot ignore Grand IP Theft like this.

    With problems like this, I think the best way forward for massivly distributed programs written in .NET is GPL licensing, that way you retain control and with licensing quirks get to charge your customers good money anyway. Look at how MySQL is licensed for an example.

  • CodeGuru123

    figuerres wrote:
    
    first thing I always ask is why?
    then what is the risk?
    what is the benefit?
    what is the cost?
    what is the audience (users, who, sales market)?

    most of the time the users are not going to mess with the code and the cost far outweighs the benefit.

    if the users are tech-savy hacker types then the same thing happens as a determined cracker will break any protection if they are willing to spend the time and effort.



    I often see similar types of responses when people ask about protecting their source..

    I guess some people simply don't understand..

    For a small operation like mine, code security is key to our business future. If we were to release our product in unencrypted .net, our competitors would gain substantial IP to help rocket them into markets where we already exist, and if our .net app could easily be reversed many new competitors would pop up.

    You see, not everybody is a adobe, or microsoft, or even winzip or nero...

    Some outfits have a lot of development time invested into developing product for consumers that have no current available options.. We invest heavily to make a product that most of the time, others don't know how to do. Again, if we released our .net unprotected well then these others would pop up out of the wood work.

    Now, most people say, well you provide great customer service and a great product and you won't have to worry about that. That only works if your target consumer is willing to pay the premium for those services. If your target consumer (unfortunately) wants the product at the lowest price that argument goes right out the door.

  • TimP

    If you're really that concerned, make it a web app or something and run it on a box you own. If you think your competitors will go to any length to reverse engineer your work, then don't give it out the EXE at all.

    I don't think many customers would be keen on this, though. Eventually if you make it too cumbersome to even use they'll go elsewhere regardless.

  • jh71283

    I use smartassembly - it also gives me the nice feature of error reporting, in case something goes wrong once the app is deployed....

  • stevo_

    CompGuy101 wrote:
    I use .NET Reactor and it works great. It injects the CLI header at runtime so when people try to open it up in .net reflector they just get errors. It also encrypts your source.


    Yea but no one would actually want to steal your source.. Tongue Out

  • stevo_

    TimP wrote:
    

    If you're really that concerned, make it a web app or something and run it on a box you own. If you think your competitors will go to any length to reverse engineer your work, then don't give it out the EXE at all.

    I don't think many customers would be keen on this, though. Eventually if you make it too cumbersome to even use they'll go elsewhere regardless.



    A web service vs a web app, but yes - remote services are a good way to keep the 'underwater' part of the iceberg away from your users..

    Then you just have to worry about protecting innovation on your client Tongue Out

  • figuerres

    CodeGuru123 wrote:
    
    figuerres wrote:
    
    first thing I always ask is why?
    then what is the risk?
    what is the benefit?
    what is the cost?
    what is the audience (users, who, sales market)?

    most of the time the users are not going to mess with the code and the cost far outweighs the benefit.

    if the users are tech-savy hacker types then the same thing happens as a determined cracker will break any protection if they are willing to spend the time and effort.



    I often see similar types of responses when people ask about protecting their source..

    I guess some people simply don't understand..

    For a small operation like mine, code security is key to our business future. If we were to release our product in unencrypted .net, our competitors would gain substantial IP to help rocket them into markets where we already exist, and if our .net app could easily be reversed many new competitors would pop up.

    You see, not everybody is a adobe, or microsoft, or even winzip or nero...

    Some outfits have a lot of development time invested into developing product for consumers that have no current available options.. We invest heavily to make a product that most of the time, others don't know how to do. Again, if we released our .net unprotected well then these others would pop up out of the wood work.

    Now, most people say, well you provide great customer service and a great product and you won't have to worry about that. That only works if your target consumer is willing to pay the premium for those services. If your target consumer (unfortunately) wants the product at the lowest price that argument goes right out the door.


    read what I posted....

    DID I say "Do Not Protect" ?
    no.

    I said there are a set of things to know; who the threat is, why, when, where etc....

    the company I work for has 3 people, I think I know what "small" is.

    and your reply sounds like a lot of them I have seen.

    WHO WANTS YOUR CODE?

    ARE YOU SURE OF THIS ?


    really I have to go back to what I posted:

    what is the threat?
    who are they?
    why do they want to steal your work?
    who are you selling to?

    your reply shows you are concerned not that end users will copy but that pros will copy your work.  that changes the threat.

    on one side you mention others cloning your work and on the other side you speak of the user wanting it cheap.

    sounds like you need to re-asses what you are developing and who you are selling to.

    have you got any real proof that your code is going to be stolen?
    how many copies a year do you sell ?
    are you selling direct on-line ? in a box( retail)?  thru a partner?

    possibly you do not want .net at all?
    afterall with .net you have to have the runtime and that tells the cracker a lot about what to look for.

  • CodeGuru123

    I take it your just trying to help.

    I'm not asking for assistance as to if I need .net protection, I know I do. I'm asking what options others use.

    The industry I am in is very competative. There have been src leaks and startups from reversing.. its real tough.

    We use .net as its real easy to develop GUI based applications, much quicker than it is in C or using other dev tools.

    I look forward to when a main stream vendor releases a product in .net, should be very interesting.

  • W3bbo

    CodeGuru123 wrote:
    I look forward to when a main stream vendor releases a product in .net, should be very interesting.


    There has been.

    The computer game "Arena Wars" (circa 2005) was made in C#/.NET1.1 and Managed DirectX and sold pretty well. They didn't bother with much besides running it through the version of Dotfuscator that comes with VS2003. I don't think their sales were hurt any.

  • figuerres

    CodeGuru123 wrote:
    

    I take it your just trying to help.

    I'm not asking for assistance as to if I need .net protection, I know I do. I'm asking what options others use.

    The industry I am in is very competative. There have been src leaks and startups from reversing.. its real tough.

    We use .net as its real easy to develop GUI based applications, much quicker than it is in C or using other dev tools.

    I look forward to when a main stream vendor releases a product in .net, should be very interesting.



    like say Norton Ghost ??  I have a copy that has a bunch of .net .exe and .dll files in it.  it's a version I paid for a while back...
    there are others out there, you just have to check the installs for .config and .manifest files.

    that aside I am asking questions to better understand the problem you want to solve.
    for example a leak of source code will in no way be fixed by any runtime protection so that comment leaves me wondering what the problem is? 

    and your statements like "The industry I am in is very competative. "
    do not help me understand the nature of the problem.

    thus back to my questions I turn.....

    and to my points from before:  if someone wants to crack/decompile/ reverse enginer some app they can and they will.

    the *ONLY* sure way to stop that is never release anything.
    short of that it's all a game of shall we say "Hide and seek" that is we play.

    there is a saying:

    you can have it fast
    or
    you can have it cheap
    or
    you can have it high quality

    pick any two you want, but you can't have all three.

    the third one will be the rub.

    fast + HQ means it will cost more
    fast  + cheap means it will have less HQ
    and so on....

    this tends to be very true....

    I have personally dealt with folks who spent so much time and effort  on a possible deal that they killed it by failing to get it "out the door"

    and I have seen folks worry about copy-protection when they were selling 10 copies a month to folks who did good to run the app, much less hack it.

    I am *NOT* saying that is you.  just telling you things I have seen.
    if your thing is so secret you will not share more info on why it needs protectioin and from who then it's imposible for us to really help you.

  • CodeGuru123

    I understand that no method of software protection is completely secure, and I'm not asking for such.

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

    I have a solution that works very well for me now, its one of the ones already listed in this thread.. however I'm not sure about the future of this solution as an option for us, as their prices and methods of licensing are drastically changing.

    The ideal solution for me, and for many .net users I'd imagine is something that:

    • 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

    That is my ideal list. I'm just trying to come up with a list of solutions that achieve this type of protection.

    According to my research, CodeVeil has unpackers available. Sad

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.