Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
See top answer here: Obfuscation at source-code level more effective than obfuscators?, specifically "Code it in a language so not easy to decompile such as C/C++"
I'm looking to write a new application that will be sold for $500 per license, so I'd like to prevent decompilers.
Should C# be avoided, or is using an obfuscator sufficient to prevent this sort of thing?
C# assemblies contain metadata that c++ assemblies do not, which can aid in decompilation. C# also compiles down to an intermediate language which maps much better to the original source code than does C++'s machine code output. Obfuscators can help, but you can't prevent reverse-engineering; you can only make it harder.
In practice, nobody wants your code for free anyway. Companies want to be legitimately licensed; they don't want to go to the trouble (or legal exposure) of hacking your code to get a free license. At $500 per license, it's unlikely you're targeting ordinary consumers, so the only ones who will be interested in hacking your software will be those folks who aren't in your target market anyway.
So take sensible precautions, like having a licensing scheme, install codes, phone home, or whatever the latest thing is for securing your software, and focus your efforts on adding new features to make your software better and more attractive, choosing the language that provides you with the best possible productivity.
NB: If you aren't getting ripped off occasionally by the hackers, your software isn't important enough. At that point, you can probably hire someone to issue takedown notices and work on better technological solutions.
Fundamentally, any executable program can be disassembled and inspected. The ease with which a reverse engineer can recreate the original source code depends on how much information or meta-data about the original source code exists within the executable. Can the reverse engineer discover the original variable names, functions, data structures, etc.? A compiler essentially "compresses" source code, turning it into a format which is more amenable to machine execution, such as native machine code or byte code which is processed by an intermediate runtime. But generally speaking, the compression is lossy, meaning that a lot of information about the original source code is simply not there. However, certain compiler outputs are more lossy than others.
C and C++ generally compile directly to native machine code. But neither the C nor C++ standard describes the layout of a binary executable created by the compiler. An optimizing C++ compiler, for example, is free to do many things to increase performance, including optimizing out certain variable declarations or removing entire functions and classes. Very little information about the original C++ code necessarily needs to exist in the binary executable. A reverse engineer would still be able to disassemble it, but gleaning any C or C++ code out of the assembly would be an act of guessing and interpretation.
C#, however, compiles to CIL (Common Intermediate Language). Typically, a lot more information about the original source code, such as object oriented concepts including class structure, can be gleaned from reading the CIL than from reading, let's say, highly optimized x86 machine code produced from a C++ compiler.
C# shouldn't necessarily be avoided. I work for PreEmptive Solutions on their Dotfuscator team, though this is a fairly unbiased answer. (without a single plug :) )
C# is inherently easier to decompile into source code because it contains meta-data and most C# code must comply with a set of rules called "verifiable code". Decompilers take advantage of the adherence to these rules along with attached metadata to make decompilation much better than equivalent C++ decompilers. It's hard to get into with a thorough understanding of IL, but basically each class in your code will end up having metadata. It's how .Net prevents you from having to ship header or symbol files for someone to use an assembly/API you write. And for the verifiable code bit, it basically means that you can only use code that the .Net runtime can verify is "safe". The runtime is limited in it's static analysis capabilities, so there is a lot of code that can be verified is "safe and correct", but won't be verifiable by the runtime. Decompilers take advantage of this set of rules.
If you're shipping a product in C# and have IP you want to protect, you basically have to use an obfuscation product. It's the same in similar languages/runtimes such as Java. Obfuscation products for .Net do a variety of things:
goto and reorder everything)FooBar into a)Depending on which obfuscator you use, these methods can make it so for all intents and purposes the code is a huge "black box" without diving into the IL and hand deobfuscating it(very time consuming)
C++ has the plus that obfuscation isn't nearly as important. There is no metadata so decompilers have a much harder time. However, there are still a great deal of hackers that can read x86 assembly. And C++ applications very commonly get cracked. (good) C++ obfuscators are also much harder to come by. This is because they are about as difficult to obfuscate as they are to decompile. .Net has a set of rules that obfuscators use to both read your code, and obfuscate it. C++ doesn't have these rules.
So, in summary
Also, as one more note. C# obfuscators which produce verifiable code basically give you an application which will run everywhere, as long as they have a new enough version of .Net. C# obfuscators which don't produce verifiable code will usually work everywhere, but they aren't guaranteed to. It's possible Microsoft would come out with some JIT optimization in the next version of .Net that will break your unverifiable obfuscated code. C++ code inherently does not usually run "everywhere", but it usually does. Obfuscated C++ code will probably work everywhere you intend to, but it's not guaranteed. Writing correct and thread-safe C++ is hard enough, much less worrying about an obfuscator screwing that up.
