Obfuscation is one way, but it can't protect from breaking the piracy protection security of the application. How do I make sure that the application is not tampered with, and how do I make sure that the registration mechanism can't be reverse engineered?
Also it is possible to convert a C# application to native code, and Xenocode is too costly.
C# provides lot of features, and is the ideal language for my code, so writing the whole codebase again in C++ is out of the question.
Secure certificates can be easily removed from the signed assemblies in .NET.
You can't.
There are steps you can take to make it a little more difficult, but ultimately any executable on the local machine is crackable. Eventually, that code has to be converted into native machine code and every application that is runnable is vulnerable.
What you want to do is just make it difficult enough to crack to make it not worth peoples' trouble.
Some suggestions I have for you to help protect your application:
Obfuscate your code. Dotfuscator has a free edition and comes with Visual Studio.
Use public/private key or asymmetric encryption to generate your product licenses. This ensures that only you can generate your license codes. Even if your application is cracked, you can be sure that they won't be releasing a key generator for your application, because it is impossible to reverse the key generating algorithm.
Use a third-party packer to pack your .NET executable into an encrypted Win32 wrapper application. Themida is one of the better ones. This stops people from reflecting your application in .NET Reflector and makes it a pain to unpack for reversing.
Write your own custom packer. If the third-party packers are too expensive, consider writing your own. Sometimes custom packers can be very effective, because there aren't well published methods on how to unpack them. The tutorial How to write your own packer gives a ton of good information on writing your own Win32 packer.
Ultimately though, if people want your application cracked they will. Look at all the commercial software out there that has a vast amount of resources to protect their applications and yet they are cracked before the applications are even released to the public.
A skilled reverse engineer can fire up IDA-Pro and slice through your application like butter no matter what you do. A packed application can be unpacked and obfuscation only prevents it from making it a walk in the park. All your hard work with your complex license code can be undone with a single byte patch.
You just need to accept that there is a very real chance people are going to pirate your software. There are some people who are never going to pay for your application no matter what and these are the people you don't need to worry about.
There are however, many businesses out there who would never risk a lawsuit and happily buy software licenses and many computer users who either don't want to risk it, find it wrong or are not tech savvy enough to pirate. These are your true customers, and you should focus your efforts on providing them with a good user experience and ignore the people cracking your software.
I've had my application pirated before, and I took it as a personal affront. Here I was, a small-time developer, pouring my heart and soul into an application and these people had the gall to pirate from me?! They were taking money directly from my pocket!
I immediately added in a bunch of draconian DRM code and attempted to sabotage any person using an illegitimate or cracked copy. I should of course have been working on making my application better instead of trying to stop the inevitable. Not only that, but I was hurting my true customers will all these extra protections I was putting in.
After a long battle I realized I was fighting the tides and all this time wasted was for naught. I took out all the phone-home code except for the barebones license functions and never looked back.
You can't fully secure any application (managed or not). If systems like the Playstation and iPad can get cracked — where the vendor even controls the hardware — what hope does your app have? Thankfully, you don't really want to. In my opinion, you need to secure your application just enough that someone can't accidentally pirate your product, and no more.
For example, if you use a per-machine license, it shouldn't just work when you install it on a new second machine. You'll want a good error message to prevent extra support calls, but don't spend extra time making it too hard to work around and don't hit users over the head with it.
Another example is a time-limited trial. Don't even worry about simple things like if users can just roll back the system clock. Someone who does that knows they are breaking your license, and as long as a user knows when they are in violation you've done enough.
You need to do this much because users don't care about your license. Licenses are made-up things that nobody cares about until they need to. No one reads them, and they really shouldn't have to. Therefore the best way to tell the user where the boundaries are is if the out-of-the-box behavior for your application complies with the license. In this first case that means either failing to install or installing in trial-version mode the second time. For the latter, it might just mean checking a plain-text date in a configuration file. Either way, make sure you handle it in an elegant, helpful, and respectful manner.
So that explains what it means do just that much. But why not go any further? Why not plug every little hole you can find? The answer is in two parts. First, if someone will cross the ethical threshold of consciously breaking your license terms — even in a simple way — they'll also be willing to do something more difficult or dangerous like pull your application from a torrent site — and there is a certain amount of danger involved in running applications downloaded from untrusted sources. Making it any harder is only a minor annoyance for these users and risks causing problems with your paying customers. Keeping it simple may prevent someone from digging into your application and releasing a more comprehensive crack. Second, you have few eyes available to look for flaws; the hackers have many, and they have more practice finding them. You only need to miss one little flaw, and your app will have the same distribution on pirate sites as if you did nothing. You have to be right every time; they only have to be lucky once. So the effort required is very high, and the likelihood of any measure of success is very low.
Ultimately, if someone wants to pirate your application (as opposed to just using it), and that is their main goal, they will. There's nothing you can do to stop them. This is the nature of software; once the files that make up your product are on a user's computer they will be able to do with them as they wish. This is especially relevant in managed environments like Java or .NET, but it definitely applies to native code as well. Time is on their side, and given enough time any digital security can be broken.
Since you can't stop users from pirating your product, your best course of action is to engage this class of user in a way the uses them to your benefit. It is often possible to get them working for you rather than against you. With that in mind, no matter what your application is, it's probably worth it to keep a free version that is almost completely functional and doesn't expire. The difference between even a US$1 price tag and free is huge, if for no other reason than that the customer doesn't have to trust you with their credit card. A free edition of your product will not only effectively kill pirated distribution (why risk a pirated version when you can be legitimate for the same price?), it has the potential to dramatically expand your audience.
The result is that you may need to increase the price of the for-pay edition, so that in the end instead of 2,000 users at $20 each you have 100,000 free users, of which 500 are willing to pay $99 for the "professional" edition. This earns you more money than if you spent a bunch of time locking up your product. More than that, you can engage these free users and leverage the relationship in several important ways.
One is support. A pessimist would take this opportunity to complain about the increased cost of supporting 100,000 free users, but something amazing happens instead: your product becomes largely self supporting. You see this all the time with large open source projects that have no money for support costs. Users will step up and make it happen.
Free users generally have reduced support expectations to begin with, and for good reason. All you need to do is mark the free edition as only qualifying for community support and put up a user-moderated online forum for that purpose. Your support knowledge base is self-generating, and advanced users will shepherd those who need extra hand-holding on your behalf. Even more importantly, this will allow you to identify and correct bugs faster, ultimately improving the quality of your product and lowering total support costs. This wasn't possible before because your user base wasn't large enough, but when you treat the free users as customers it can work very well.
Another is feedback. By watching your forum, you learn important improvement ideas that you may never have considered otherwise. This can allow you to ultimately turn more of your free users into paid users and create a more compelling product that will attract an even larger audience.
Finally, you need to consider marketing. All these free users are now fans rather than adversaries, and they will act accordingly. Not only that, but when it comes time to release your next version these users will have all gone through your approved distribution channel, rather than some other unknown mechanism. That means for your next version you start out connected with a larger, highly interested and supportive audience.
The best features to reserve for the professional edition are tools aimed at making it easy to do corporate deployment and management. A cracker won't see these as a compelling enough reason to hack it for his own use, but for a business looking to buy 300 licenses and push it out company-wide this is a must-have. Of course, the professional edition will be pirated anyway, but again: don't sweat it because you probably wouldn't be able to sell the product to those pirates no matter what you did, so it's not costing you any revenue.
While psychologically it can be hard to give away your product this much, hopefully you can understand how it really is the best way to go. Not only that, it's the only way to go in the long term. I know someone is out there thinking that they don't want to do it this way. After all, they've got by just fine selling their locked-down $20 product for years. But that's just too bad, because if you don't do it this way, eventually someone else will. And their product will be just as good as yours, or close enough they can get away with claiming that. Then all of a sudden your pricing looks outrageous, sales drop dramatically, and there's nothing else you can do. You can opt for an additional middle tier if you must, but it's unlikely to help you.
In my experience, making your application or library more difficult to crack hurts your honest customers whilst only slightly delaying the dishonest ones. Concentrate on making a great, low friction product instead of putting a lot of effort into delaying the inevitable.
A secret that you share with lots of people is not a secret. If you have secret stuff in your code, obfuscating it is no protection; it only has to be deobfuscated once. If you have a secret that you don't want to share with your customers, then don't share it with your customers. Write your code as a web service and keep your super secret code on your own server, where only you can see it.
Broadly speaking, there are three groups of people out there.
Those who will not buy your software and resort to cracks, or if they don't find any, not use your software at all. Don't expect to make any money from this group. They rely either on their own skills or on crackers (who tend to prioritize their time depending on your useful and how big your audience is. The more useful, the sooner a crack will be available).
The group of legitimate users who will buy (pay for) your software, irrespective of what protection mechanism you use. Don't make life hard for your legitimate users by using an elaborate protection mechanism since they are going to pay for it in any case. A complex protection mechanism can easily spoil the user experience and you don't want this happening to this group. Personally, I'd vote against any hardware solution, which adds to the cost of your software.
A minority who will resort to "unethical" cracking and will only pay for your software because its features are protected by a licensing mechanism. You probably don't want to make it exceedingly easy for this group to circumvent your protection. However, all that effort you spend on protecting your software will pay back, depending on how big this group of people is. This entirely depends on the type of software you're building.
Given what you've said, if you think there is a large enough minority who can be pushed into buying your software, go ahead and implement some form of protection. Think about how much money you can make from this minority versus the time you spend working on the protection, or the amount you spend on a third party protection API/tool.
If you like to implement a solution of your own, using public-key cryptography is a good way (as opposed to symmetric algorithms) to prevent easy hacks. You could for instance digitally sign your license (serial no, or license file). The only way to get around this would then be to decompile, alter and recompile the code (which you could make harder using techniques such as those suggested in Simucal's answer).
You can't prevent people from cracking your software.
However, you can make them create cracks that will hurt your sales less. Keygenerators that can issue a valid registration code for your software are much worse than simple patches that remove registration incentives from your software. That's because a crack will work for one software version only, and will cease to work with the next software update you release. The keygenerator will continue to work until you change your registration key algorithm and that's something you don't want to do often because it will put off your honest clients.
So, if you are looking for a method to fight illegal keygenerators for your software and you do not want to use assymetric encryption because of the long registration codes this generates, you might have a look at Partial Key Verification.
Partial Key Verification makes sure that each illegal keygenerator works only for one particular release of your software. Basically what you do is to make sure that each release of your software only links with the code for checking SOME digits of the registration code. Which digits exactly is random, so crackers would have to reverse engineer many different versions of your software and combine all this into one keygenerator in order to release a keygenerator that works for all versions of your software.
If you release new software versions on a regular basis, this leads to numerous keygenerators spread on all kinds of software piracy archives which are not working anymore. Potential software pirates usually look for a crack or keygen for the latest version, so they will likely try a few of those and give up eventually.
I've used the Partial Key Verification in my (C++) newer shareware games and it has been very effective. Before we had plenty of problems with keygenerators which we could not fight. Afterewards there were lots of cracks and some few keygenerators that worked only for that particular version of the game, but no key generator that would work with all versions. We regularly released very minor updates of the game and to render all previously existing cracks useless.
There seems to be an open source .NET framework for Partial Key Verification, although I have not tried it.
Use online update to block those unlicensed copies.
Verify serial number from different modules of your application and do not use a single
function call to do the verification (so that crackers cannot bypass the verification easily).
Not only check serial number at
startup, do the verification while
saving data, do it every Friday
evening, do it when user is idle
...
Verify application file check
sum, store your security check sum in
different places.
Don't go too far on these kind of
tricks, make sure your application
never crash/get into malfunction
while verifying registration code.
Build a useful app for users is
much more important than make a
unbreakable binary for crackers.
You can..
Microsoft SLP ServicesInishTech's Software Potential offers the ability to help protect code without affecting the functionality of your applications.
UPDATE: (Disclosure: I work on Eazfuscator.NET) What makes Microsoft SLP ServicesSoftware Potential different is the ability to virtualize the code, so you definitely can. Several years passed since the question was originally asked; today there are more products available that also work on a similar basis such as:
Agile.NET
Eazfuscator.NET
.NET Reflector can only open "managed code" which basically means ".NET code". So you can't use it to disassemble COM DLL files, native C++, classic Visual Basic 6.0 code, etc. The structure of compiled .NET code makes it very convenient, portable, discoverable, verifiable, etc. .NET Reflector takes advantage of this to let you peer into compiled assemblies but decompilers and disassemblers are by no means specific to .NET and have been around as long as compilers have been around.
You can use obfuscators to make the code more difficult to read, but you can't exactly prevent it from being decompiled without also making it unreadable to .NET. There are a handful of products out there (usually expensive) that claim to "link" your managed code application into a native code application, but even if these actually work, a determined person will always find a way.
When it comes to obfuscation however, you get what you pay for. So if your code is so proprietary that you must go to such great lengths to protect it, you should be willing to invest money in a good obfuscator.
However, in my 15 or so years of experience writing code I've realized that being over-protective of your source code is a waste of time and has little benefit. Just trying to read original source code without supporting documentation, comments, etc. can be very difficult to understand. Add to that the senseless variable names that decompilers come up with and the spaghetti code that modern obfuscators create - you probably don't have to worry too much about people stealing your intellectual property.
Is it really worth it? Every protection mechanism can be broken with sufficient determination. Consider your market, price of the product, amount of customers, etc.
If you want something more reliable then go down the path of hardware keys, but that's rather troublesome (for the user) and more expensive. Software solutions would be probably a waste of time and resources, and the only thing they would give you is the false sense of 'security'.
Few more ideas (none is perfect, as there is no perfect one).
AntiDuplicate
Change the language, use the nice tricks that the authors of Skype used
License server
And don't waste too much time on it, because the crackers have a lot of experience with the typical techniques and are few steps ahead of you. Unless you want to use a lot of resources, probably change the programming language (do it the Skype way).
Apart from purchasing protection, you (or your developers) can learn to copy-protect.
These are ideas:
At first, try to write a program that writes itself to console. That's a famous problem. Primary purpose of this task is to practice writing self-referencing code.
Second, you need to develop a technology that will rewrite some code in a way
dependable on other methods' CIL.
You may write a virtual machine (yet in .NET). And put some code in there.
Ultimately, the virtual machine runs another virtual machine which runs the code.
That's for a part of rarely-called functions for not to slow the performance too much.
Rewrite some logic into C++/CLI, and mix managed code with unmanaged. This will harden the disassembling. In this case, do not forget to provide x64 binaries too.
If you want people to able to run your code (and if you don't, then why did you write it in the first place?), then their CPU needs to be able to execute your code. In order to be able to execute the code, the CPU needs to be able to understand it.
Since CPUs are dumb, and humans aren't, this means that humans can understand the code as well.
There's only one way to make sure that your users don't get your code: don't give them your code.
This can be achieved two ways: Software as a service (SaaS), that is, you run your software on your server and only let your users access it remotely. This is the model that Stack Overflow uses, for example. I'm pretty sure that Stack Overflow doesn't obfuscate their code, yet you can't decompile it.
The other way is the appliance model: instead of giving your users your code, you give them a computer containing the code. This is the model that gaming consoles, most mobile phones and TiVo use. Note that this only works if you "own" the entire execution path: you need to build your own CPU, your own computer, write your own operating system and your own CLI implementation. Then, and only then can you protect your code. (But note that even the tiniest mistake will render all of your protections useless. Microsoft, Apple, Sony, the music industry and the movie industry can attest to that.)
Or, you could just do nothing, which means that your code will be automatically protected by copyright law.
Unfortunately, you are not going to run away from this. Your best bet is to write your code in C and P/Invoke it.
There is a small catch-22, someone could just decompile your application to CIL and kill any verification/activation code (for example, the call to your C library). Remember that applications that are written in C are also reverse-engineered by the more persistent hackers (just look at how fast games are cracked these days). Nothing will protect your application.
In the end it works a lot like your home, protect it well enough so that it is too much effort (spaghetti code would help here) and so that the assailant just moves onto your next door neighbor (competition :) ). Look at Windows Vista, there must be 10 different ways to crack it.
There are packages out there that will encrypt your EXE file and decrypt it when the user is allowed to use it, but once again, that is using a generic solution that has no doubt been cracked.
Activation and registration mechanisms are aimed at the 'average Joe:' people who don't have enough tech savvy to bypass it (or for that matter know that they can bypass it). Don't bother with crackers, they have far too much time on their hands.
Yes. It is true. .NET code is extremely easy to reverse engineer if the code is not obfuscated.
Obfuscation will add a layer of annoyance to people trying to reverse engineer your software. Depending on which version you get, you'll get different levels of protection.
Visual Studio includes a version of Dotfuscator. Since it's a bundled version, you're definitely not getting the strongest obfuscation possible. If you look at their feature lists, you'll see exactly what you're missing (and exactly what the application will do to make your code more secure).
There are a couple of other free or open source .NET obfuscators out there (but I can't comment on the quality or the various methods they use):
Obfuscar
Babel.NET
In the end, nothing is perfect. If somebody really wants to see how your software works, they will.
Well, you cannot FULLY protect your product from being cracked, but you can maximize/enhance the security levels and make it a little bit too difficult to be cracked by newbies and intermediate crackers.
But bear in mind nothing is uncrackable, only the software on server side is well protected and cannot be cracked. Anyway, to enhance the security levels in your application, you can do some simple steps to prevent some crackers "not all" from cracking your applications. These steps will make these crackers go nuts and maybe desperate:
Obfuscate your source code, obviously this will make your source code look like a mess and unreadable.
Trigger several random checking routines inside your application like every two hours, 24 hours, one day, week, etc. or maybe after every action the user take.
Save your released application's MD5 checksum on your server and implement a routine that can check the current file MD5 checksum with the real one on you server side and make it randomly triggered. If the MD5 checksum has been changed that means this copy has been pirated. Now you can just block it or release an update to block it, etc.
Try to make a routine that can check if some of your codes (functions, classes, or specific routines) are actually have been modified or altered or even removed. I call it (code integrity check).
Use free unknown packers to pack your application. Or, if you have the money, go for commercial solutions such as Thamida or .NET Reactor. Those applications get updated regularly and once a cracker unpack your application, you can just get a new update from those companies and once you get the new update, you just pack your program and release a new update.
Release updates regularly and force your customer to download the latest update.
Finally make your application very cheap. Don't make it too expensive. Believe me, you will get more happy customers and crackers will just leave your application, because it isn't worth their time to crack a very cheap application.
Those are just simple methods to prevent newbies and intermediate crackers from cracking your application. If you have more ideas to protect your application just don't be shy to implement them. It will just make crackers lives hard, and they will get frustrated, and eventually they will leave your application, because it's just doesn't worth their time.
Lastly, you also need to consider spending your time on coding a good and quality applications. Don't waste your time on coding complicated security layers. If a good cracker wants to crack your application he/she will do no matter what you do...
Now go and implement some toys for the crackers...
There is a detailed comparison sheet for several .NET obfuscation tools:
Screenshoot taken from obfuscators.io
There's Salamander, which is a native .NET compiler and linker from Remotesoft that can deploy applications without the .NET framework. I don't know how well it lives up to its claims.
If Microsoft could come up with a solution, we will not have pirated Windows versions, so nothing is very secure. Here are some similar questions from Stack Overflow and you can implement your own way of protecting them. If you are releasing different versions then you can adopt different techniques for different version so by the time first one is cracked the second one can take over.
Managing features on a license basis for a C++ application
Secure a DLL file with a license file
Licensing / protection software?
.NET Reactor
Update
Jared pointed out that de4dot claims to be able to decompile it.
.NET Reactor provides complete protection for your sensitive intellectual property by converting your .NET assemblies into unmanaged processes which cannot be understood as CIL, and which no existing tool can decompile. Hackers have no access to any intelligible form of your source.
Powerful and flexible, the .NET Reactor licensing features allow you to enforce your license conditions and protect your revenue stream by using hardware and software locks. The license manager can build trial or permanent licenses, in a matter of seconds. A fully documented software development kit (SDK), complete with examples, allows you to call the licensing system directly from your code, allowing you to create custom extensions to the licensing system.
Here's one idea: you could have a server hosted by your company that all instances of your software need to connect to. Simply having them connect and verify a registration key is not sufficient -- they'll just remove the check. In addition to the key check, you need to also have the server perform some vital task that the client can't perform itself, so it's impossible to remove. This of course would probably mean a lot of heavy processing on the part of your server, but it would make your software difficult to steal, and assuming you have a good key scheme (check ownership, etc), the keys will also be difficult to steal. This is probably more invasive than you want, since it will require your users to be connected to the internet to use your software.
Anything running on the client can be decompiled and cracked. Obfusification just makes it harder. I don't know your application, but 99% of the time I just don't think it's worth the effort.
It's impossible to fully secure an application, sorry.
Obfuscate the code! There is an example in Obfuscating C# Code.
Bear in mind that 99%+ of your users aren't going to be interested in examining your executable to see how it works.
Given that so few people are even going to bother trying and that most obfuscators can be worked around, is it worth your time and effort?
You'd be better off investing the time into improving your product so that more people want to use it.
Just to add a warning: if you are going to use obfuscation, check that everything still works! Obfuscation might change things like class- and method-names. So if you use reflection to call certain methods and/or classes (like in a plugin-architecture) your application could fail after obfuscating. Also stacktraces might be useless to track down errors.
If it's written in .NET and compiled to CIL, it can be reflected. If security is a concern and obfuscation is to be avoided, then I recommend writing your application using a non-managed language, which is, by nature, harder to reverse engineer.
How to make sure that the application is not tampered with, and how to make sure that the registration mechanism can't be reverse engineered.
Both have the same very simple answer: don't hand out object code to untrusted parties, such as (apparently) your customers. Whether it's feasible to host the application on your machines only depends on what it does.
If it isn't a web application, maybe you can allow for SSH login with X forwarding to an application server (or Remote Desktop Connection, I guess, for Windows).
If you give object code to nerdy type persons, and they think your program might be fun to crack, it will get cracked. No way around it.
If you don't believe me, point out a high-profile application that hasn't been cracked and pirated.
If you go with the hardware keys, it'll make production more expensive and your users are going to hate you for it. It's a real bitch to crawl around on the floor plugging and unplugging your 27 different USB thingies because software makers don't trust you (I imagine).
There are packages out there that will encrypt your EXE and decrypt it when the user is allowed to use it
Of course, the way around it is to crack the "can-I-use-it" test so that it always returns true.
A nasty trick might be to use the byte values of the opcodes that perform the test somewhere else in the program in a dirty way that'll make the program crash with high probability unless the value is just right. It makes you linked to a particular architecture, though :-(
Just make a good application and code a simple protection system. It doesn't matter what protection you choose, it will be reversed... So don't waste too much time/money.
When it comes to .NET, if you're releasing a Windows Forms application (or any application where the client has the Portable Executable file), it's able to be cracked.
If you want to stick with .NET and want to minimize the chance of having your source code taken, then you may want to consider deploying it as an ASP.NET application across a webserver, instead of making it a Windows Forms application.
Frankly, sometimes we need to obfuscate the code (for example, register license classes and so on). In this case, your project is not free. IMO, you should pay for a good obfucator.
Dotfuscator hides your code and .NET Reflector shows an error when you attempt to decompile it.
What happens exactly when I launch a .NET exe? I know that C# is compiled to IL code and I think the generated exe file just a launcher that starts the runtime and passes the IL code to it. But how? And how complex process is it?
IL code is embedded in the exe. I think it can be executed from the memory without writing it to the disk while ordinary exe's are not (ok, yes but it is very complicated).
My final aim is extracting the IL code and write my own encrypted launcher to prevent scriptkiddies to open my code in Reflector and just steal all my classes easily. Well I can't prevent reverse engineering completely. If they are able to inspect the memory and catch the moment when I'm passing the pure IL to the runtime then it won't matter if it is a .net exe or not, is it? I know there are several obfuscator tools but I don't want to mess up the IL code itself.
EDIT: so it seems it isn't worth trying what I wanted. They will crack it anyway... So I will look for an obfuscation tool. And yes my friends said too that it is enough to rename all symbols to a meaningless name. And reverse engineering won't be so easy after all.
If you absolutely insist on encrypting your assembly, probably the best way to do it is to put your program code into class library assemblies and encrypt them. You would then write a small stub executable which decrypts the assemblies into memory and executes them.
This is an extremely bad idea for two reasons:
You're going to have to include the encryption key in your stub. If a 1337 hacker can meaningfully use your reflected assemblies, he can just as easily steal your encryption key and decrypt them himself. (This is basically the Analog Hole)
Nobody cares about your 1337 code. I'm sorry, but that's tough love. Nobody else ever thinks anyone's code is nearly as interesting as the author does.
A "secret" that you share with thousands of people is not a secret. Remember, your attackers only have to break your trivial-to-break-because-the-key-is-right-there "encryption" scheme exactly once.
If your code is so valuable that it must be kept secret then keep it secret. Leave the code only on your own servers; write your software as a web service. Then secure the server.
the generated exe file just a launcher that starts the runtime and passes the IL code to it.
Not exactly. There are different ways you can set up your program, but normally the IL code is compiled to native machine code that runs in process with the runtime.
As for the kiddies — you're deluding yourself if you think you can sell to them or anyone who uses what they redistribute. If they can't unlock your app they'll move on and find one they can or do without. They represent exactly $0 in potential sales; it makes little sense to spend too much effort attempting to thwart them because there'd be no return on your investment. A basic obfuscator might be fine, but don't go much beyond that.
Realistically, most developers face a much bigger challenge from obscurity than from piracy. Anything you do that prevents you from getting the word out about your product hurts you more than the pirates do. This includes making people pay money to get it. Most of the time a better approach is to have a free version of your app that the kiddies don't even need to unlock; something that already works for them well enough that cracking your app would just be a waste of their time, and not just a time or feature-limited trial. Let them and as many others as possible spread it far and wide.
Now I know that you do eventually need some paying customers. The key is to now use all the attention you get from the free product to upsell or promote something else that's more profitable. One option here is to also have a premium version with additional features targeted largely at a business audience; things like making it easy to deploy to an entire network and manage that way. Businesses have deeper pockets and are more likely to pay your license fees. Your free version then serves to promote your product and give it legitimacy for your business customers.
Of course, there are other models as well, but no matter what you do it's worth remembering that obscurity is the bigger challenge and that pirated copies of your software will never translate into sales. Ultimately (and of course this depends on your execution) you'll be able to make more money with a business model that takes advantage of those points than you will trying to fight them.
"...prevent scriptkiddies to open my
code in Reflector and just steal all
my classes easily."
Unfortunately, regardless of how you obscure launching, it's a matter of half a dozen commands in a debugger to dump a currently-running assembly to a file of the user's choice. So, even if you can launch your application as Brian suggested, it's not hard to get that application's components into Reflector once it's running (I can post a sample from WinDbg if someone would find it interesting).
Obfuscation tools are created from huge amounts of technical experience, and are often designed to make it difficult for debuggers to reliably attach to a process, or to extract information from it. As Brian said: I'm not sure why you're determined to preserve the IL and, if you want any meaningful protection from script kiddies, that's something you may have to change your mind on.
"They copied all they could follow, but they couldn't copy my mind, so I left them sweating and stealing a year and a half behind." -- R. Kipling
Personally I think that obfuscation is the way to go. It is simple and can be effective, especially if all your code is within an exe (I'm not sure what the concern is with "messing up the IL").
However, if you feel like that won't work for you, perhaps you can encrypt your exe and embed it as a resoource within your launcher. The simplest way to handle it would be to decrypt the exe resource and write it out too file and execute it. Once the exe has completed executing, delete the file. You might also be able to run it through the Emit functions. I have no idea how this would work, but here is an article to get you started - Using Reflection Emit to Cache .NET Assemblies.
Of course your decryption key would probably have to be embedded in the exe as well so somebody really determined will be able to decrypt your assembly anyway. This is why obfuscation is probably the best approach.
Copying my answer from this question (which is not exactly duplicate but can be answered with the same answer, hence CW):
A Windows EXE contains multiple "parts". Simplified, the .net Code (=MSIL) is only a Part of the EXE, and there is also a "real" native Windows Part inside the EXE that serves as some sort of launcher for the .net Framework which then executes the MSIL.
Mono will just take the MSIL and execute it, ignoring the native Windows Launcher stuff.
Again, this is a simplified overview.
Edit: I fear my understanding of the deep depp details is not good enough for really much detail (I know roughly what a PE Header is, but not really the details), but i found these links helpful:
NET Assembly Structure – Part II
.NET Foundations - .NET assembly structure
Appendix: If you really want to go deeper, pick up a copy on Advanced .net Debugging. The very first chapter explains exactly how the .net Assembly is loaded prior and after Windows XP (since XP, the Windows Loader is .net aware which radically changes how .net Applications are started)
As discussed in similar questions here and here I want to protect my code from reverse engineering.
My situation is as Simucal describes in his (excellent) answer here:
Basically, what it comes down to is
the only chance you have of being
targeted for source theft is if you
have some very specific, hard to
engineer, algorithm related to your
domain that gives you a leg up on your
competition. This is just about the
only time it would be cost-effective
to attempt to reverse engineer a small
portion of your application.
I have exactly this situation. A hard to engineer algorithm which is elegant and valuable for our specific domain.
After spending months fine tuning and developing this the end result is very compact (approx. 100 lines of code) and elegant. I want to protect this specific part of the code from reverse engineering or at least make it reasonable difficult.
The scenario is a rich-client application written in C# and I have to deploy this part of the code - I cannot execute it from a webservice.
I think extracting the code and rewriting it in a unmanaged native binary is not an option due to performance reasons (and cross boundary issues).
Initially I wanted to do simple obfuscation but given the small size of the code I don't think this will offer much protection.
Ideally I would like to protect my whole application but there are two main issues that seem to make ordinary obfuscaters and 3rd party packers difficult to use:
The application offers a plugin interface and therefore some assemblies (and interfaces/classes) should not be obfuscated and packed
We still want to be able to get to a real stack trace when receiving error reports - potentially this could be done my mapping obfuscation to the real code.
Setting these issues aside (although I would appreciate any input on this as well), what is a good way to protect a tiny part of my code from reverse engineering? I am not concerned about anyone altering or hacking the code but want to make it difficult to understand and reverse engineer it.
It cannot be done. If your code can be run, then it can be read and reverse-engineered. All you can do is make it a little harder and, believe me, it will only be a little harder. You may not like the fact but most crackers are far better at cracking than anyone else is at making things hard to crack. The amount of effort to protect your code is usually not worth it, especially if it disadvantages your paying customers. Witness the stunning non-successes of DRM.
My advice is to not worry about it. If your algorithm is truly novel, seek a patent (although that got a little harder with the Bilski decision unless you tie it to a specific hardware implementation). Relying on trade secrets is also useless unless you only distribute your software to those that sign contracts that ensure they will not allow unfettered access. And then, you have to have a way to police this. The minute you put the binaries up on the internet or distributed them without a contract, I believe you'll be deemed to have lost trade secret status.
Relying on licensing is also fraught with danger - you may think that you can insert clauses in your license that prohibit reverse-engineering but many jurisdictions around the world specifically disallow those provisions. And the Russian mobsters who whoever are responsible for most of the cracking are unlikely to honor said provisions anyway.
Why don't you just concentrate on making your product the best it can be? The goal is to stay ahead of the crowd rather than lock them out altogether. Being the first to deliver and always having the best product in a competitive group will ensure your prosperity far more than wasting a lot of effort on useless protection (IMNSHO).
This is just my opinion. I may be wrong. I've been wrong before, you only need ask my wife :-)
You should obfuscate the complete code since it gets harder to reach that small valuable part. The smaller the code gets, the easier it becomes to understand it. Most obfuscators should not mess with public interfaces since there are many obfuscated libraries out there.
However I think you should rather convince users that there are no special tricks there instead of trying to hide it. To quote Kaiser Soze, "the greatest trick The Devil has ever pulled is to convince the world that he doesn't exist".
And of course you can always file a patent for your invention and protect yourself legally.
Aside from obfuscation it is almost worthless, even Microsoft (ScottGu etc) basically say that people with the right amount of intent and ability will reverse engineer an application and in .NET a basic defense is licensing and IP instead of trying to guard your code through obscurity or some other means of preventing reverse engineering.
That is part of the reasoning of why they released the BCL source instead of keeping it private.
one option is to use the license key and/or hardware fingerprint to decrypt the sensitive code at runtime and emit it as IL; this will make it invisible to static reverse-engineering tools (e.g. Reflector)
also detect the presence of a debugger and refuse to run in debug mode, except possibly in very limited circumstances (i.e. on your machine)
note that this will make debugging very difficult for you, and nearly impossible for others (if this is an end-user app that's not a problem, but if it is a library or framework for other developers to build upon, that's a problem)
note also that making a copy of physical memory to disk and using offline tools on the memory-dump will reveal your decrypted algorithm, so it is fairly easy to defeat - but far more trouble than most people will bother with
the whole thing is a trade-off between difficulty for you vs deterrence for the few bad apples vs potential loss due to theft/plagarism
good luck, and let us know what you decide!
If your code is that sensitive, put it where nobody can get to it.
E.G. provide a client or web page for people to access some service that exposes your functionality.
That service can sit behind an external firewall and communicate with a backend server behind an internal firewall, where your sensitive code runs.
For extra measure, obfuscate that code.
This would require compromising several layers of security before getting to your code.
You can obfuscate it at the C# or CIL level but what is really going to make it impossible is that the IL compiler is designed to create the most efficient machine code that it can to actually execute.
So, to reverse engineer your algorithm, get the machine code and run standard disassembly tools on it. Trace the data through the system by following it forward from the standard input API calls to the standard output API calls.
Face it, if someone wants it, they can have it.
You can make it hard to casually figure it out. For example, I wanted to see what was in some database managed by a Java application. It turned out that the Java decompile was really messy, full of odd functions and classes and namespaces all with the same names, intentionally trying to hide what was really going on.
I could have fixed up the decompiler I was using so that it renamed everything as A_namespace instead of just A and then the function flow would have popped right out to the Eclipse call tracing graphs.
Instead I just threw up my hands and got on with real work rather than rewriting decompilers.
So, you can hide it from casually interested folks, sure.
Most obfuscators allow you to specify which methods/classes you want to keep from being obfuscated. SmartAssembly for instance let you mark methods or classses with attributes, while others let you select the methods in a UI to exclude from the process. You ought to be able to have pretty fine grained control of the process, and so you can have your cake and eat it.
You will however run into problems if you are using reflection.
I've heard good comments about the Spices.Net Obfuscator. It should be able to greatly increase the time necessary to get at the algorithm.
Learning from my last question, most member names seem to get included in the Project Output.
Looking at some decompilers like 9rays, Salamander, Jungle, many obfuscating techniques seem to have been already defeated, there's this one particularly scary claim:
Automatically removes string encryptions injected by obfuscators ~ Salamander
So is manual, source-code level obfuscating more effective than post-compile / mid-compile lathered, 'superficial' obfuscation by well known (easily defeated??) obfuscating programs?
Obfuscating source-code is going to be self-defeating in terms of maintenance.
If your project is so 'secret', I guess you have two choices:
Place the 'secret' proprietry code behind a service on a server that you control
Code it in a language so not easy to decompile such as C/C++
Maybe, debatably, but you'll destroy maintainability to do so.
Is this really worth it?
Actually this just comes down to security through obscurity, i.e. it's not security at all it's just an inconvenience. you should work fromt he assumption that any party interested enough will decompile your code if they can access it. It's not worth the pain you'll inflict on yourself to make it very slightly more time consuming for the evil haxxors. Deal with the real security problems of access.
As people stated obfuscation is about raising the bar. If you obfuscate your assembly you will stop a casual developer whose just curious but you won't stop a slightly motivated person from reverse engineering.
If you want to raise the bar a little further many obfuscation tools let you use non-printable characters as member names. use reflector on itself to have a look. This will stop a lot more people, I might look at obfuscated code to understand it, but if I can't read it, I'm not going to go through the pain of dumping it to IL, and renaming all the members manually, no motiviation for me to waste that much time.
However for some people there is a motiviation so you need to go another step if your business requirements nessecitate it. But no matter what you do if the computer can read it, there will be someone out there who can read it too. The goal is to reduce the number of people who can read it or would be motivated to read it.
There are also some tricks which you can use to make reflector break (Obfuscator from PreEmptive breaks reflector in some cases but of course you can still read the IL). I had an interesting conversation once with a developer of an obfusction tool and I won't be able to do it justice but he had a way to make reflector completly break by having the code jump dynamically around. For example one moment in your function a then you'd jump to the middle of function b. Doign this cause PEVerify to raise errors so they never actually implemented it but kind of neat idea.
annakata is correct. Really all you can do is make it more difficult (and costly) for the person to reverse engineer the software.
My company identified several areas in which we wanted to make it as difficult as possible for reverse engineering. For example our files are a binary format which each object in our hierarchy responsible for saving itself and reading back the correct version. This means for a person to read our files they would have replicate our entire hierarchy in the code they create to read our files. In addition much of the information in the Job file is useful without the corresponding bit in the shop standards files. So they have to do the work twice in order to understand what the job file is saying.
Several critical areas (dongle protection, communication with our metal cutting machines) reside in Win32DLL. Which means that they would have to know assembly and how to make DLL that replicate other DLLs signatures in order to reverse engineer our software. Plus our design with our CAM software is that it is highly interactive with the cutting machine (information being exchanged all the time)
From the few time we heard about competitors trying to deal with our machines alone they wound up replacing the electronics with their own in order to finish the job. Major bucks to do this.
Part of the steps we took was based on our own experience with trying to deal with competition's machine and software. We took that experience and learned how to tweak our setup. Of course we have limits in that we are not going sacrifice reliability or maintenance just for the purpose of defeating reverse engineering.
For your case, you will have to ask yourself what part of your software would be of interest to your competitors and proceed from there. If you are a vertical market developer (machine control, specialized accounting, etc) I suggest using a USB dongle for software control.
Otherwise use a serial number system and accept that people are going to pirate your software and build that into your business model. The purpose of a serial number scheme is that is relatively unintrusive, and hinders causal copying plus give you a remote chance of tracking down where the copy came from.
The problem there is you will be sacrificing readability to do it. If your project is that sacred to protect, I believe it is safe to assume two things:
The project is large enough that the hit in readability will come back to bite you in the ass.
The people who want to reverse-engineer it will do so anyway. It will just take a slightly larger feat of intelligence to determine what things do (instead of just reading the member names).
I am alarmed that you're even considering code level obfuscation. Won't you be obfuscating the code for yourself too? How do you intend to ever work on it again? For the sake of maintainability this shouldn't be done.
But consider this: -
Suppose there was a script/app that you can run that would open your project and cleverly obfuscate every string/variable name in your project and you compiled it afterward while your original code is securely untouched in a separate location.
Now that's some idea.
Actually code level obfuscation is less secure than what the obfuscators out there can do. This is primarily because obfuscators can take advantage of strict CLI implementation details that are not permitted by language compilers. For instance, it is entirely legal for private fields to all have the same name - but there isn't a compiler out there that will let you do that.
you can use a technique like this : http://g.palem.in/SecureAssembly.html using this you write in .net but you embed into a c++ executable your .net executable ,