Channel 9 Forums - Tech Off - Methods of protecting .net exe's from decompilation?

Tech Off - Methods of protecting .net exe's from decompilation?

CodeGuru123 — Fri, 28 Mar 2008 18:36:31 GMT

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.

Tech Off - Methods of protecting .net exe's from decompilation?

evildictaitor — Fri, 28 Mar 2008 19:18:58 GMT

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.

Tech Off - Methods of protecting .net exe's from decompilation?

AndyC — Fri, 28 Mar 2008 20:14:39 GMT

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.

Tech Off - Methods of protecting .net exe's from decompilation?

Darin Clark — Fri, 28 Mar 2008 23:50:57 GMT

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

Tech Off - Methods of protecting .net exe's from decompilation?

figuerres — Sat, 29 Mar 2008 01:08:09 GMT

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.

Tech Off - Methods of protecting .net exe's from decompilation?

Christian Liensberger — Sat, 29 Mar 2008 01:36:43 GMT

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...

Tech Off - Methods of protecting .net exe's from decompilation?

JPeless — Sat, 29 Mar 2008 01:54:51 GMT

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

Tech Off - Methods of protecting .net exe's from decompilation?

W3bbo — Sat, 29 Mar 2008 01:59:14 GMT

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.

Tech Off - Methods of protecting .net exe's from decompilation?

CodeGuru123 — Sat, 29 Mar 2008 04:33:39 GMT

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.

Tech Off - Methods of protecting .net exe's from decompilation?

TimP — Sat, 29 Mar 2008 08:02:41 GMT

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.

Tech Off - Methods of protecting .net exe's from decompilation?

John — Sat, 29 Mar 2008 09:27:40 GMT

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

Tech Off - Methods of protecting .net exe's from decompilation?

stevo_ — Sat, 29 Mar 2008 12:14:50 GMT

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..

Tech Off - Methods of protecting .net exe's from decompilation?

stevo_ — Sat, 29 Mar 2008 12:23:22 GMT

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

Tech Off - Methods of protecting .net exe's from decompilation?

figuerres — Sat, 29 Mar 2008 16:26:02 GMT

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.

Tech Off - Methods of protecting .net exe's from decompilation?

CodeGuru123 — Sat, 29 Mar 2008 18:09:52 GMT

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.

Tech Off - Methods of protecting .net exe's from decompilation?

W3bbo — Sat, 29 Mar 2008 19:51:39 GMT

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.

Tech Off - Methods of protecting .net exe's from decompilation?

figuerres — Sat, 29 Mar 2008 23:26:48 GMT

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.

Tech Off - Methods of protecting .net exe's from decompilation?

CodeGuru123 — Sun, 30 Mar 2008 17:47:15 GMT

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.

Tech Off - Methods of protecting .net exe's from decompilation?

W3bbo — Sun, 30 Mar 2008 18:54:23 GMT

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?

Tech Off - Methods of protecting .net exe's from decompilation?

CodeGuru123 — Sun, 30 Mar 2008 19:04:47 GMT

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...

Tech Off - Methods of protecting .net exe's from decompilation?

RoyalSchrubber — Sun, 30 Mar 2008 22:05:49 GMT

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.

Tech Off - Methods of protecting .net exe's from decompilation?

W3bbo — Sun, 30 Mar 2008 22:19:40 GMT

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.

Tech Off - Methods of protecting .net exe's from decompilation?

AndyC — Sun, 30 Mar 2008 22:22:31 GMT

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.

Tech Off - Methods of protecting .net exe's from decompilation?

stevo_ — Sun, 30 Mar 2008 22:36:21 GMT

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

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..

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

Tech Off - Methods of protecting .net exe's from decompilation?

numedia — Mon, 31 Mar 2008 00:11:26 GMT

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.

Tech Off - Methods of protecting .net exe's from decompilation?

evildictaitor — Mon, 31 Mar 2008 02:29:35 GMT

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.

Tech Off - Methods of protecting .net exe's from decompilation?

CodeGuru123 — Mon, 31 Mar 2008 02:35:01 GMT

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.

Tech Off - Methods of protecting .net exe's from decompilation?

CodeGuru123 — Mon, 31 Mar 2008 02:39:03 GMT

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.

Tech Off - Methods of protecting .net exe's from decompilation?

evildictaitor — Mon, 31 Mar 2008 02:41:57 GMT

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.