What are the problems in using an obfuscator tool to "hide" our most valuable asset, the .net code...?
I suppose a lot of people use those tools, otherwise wouldnt it be easy to copy the code, using those reverse engeneering tools.
Thanks a lot for any information on this!
Sorry Talal, but I didnt quite get what you meant. Did you say its not important to "hide" our code?
We develop app for the financial market down here in Brazil, and I believe there are hundreds of relevant formules and algorithmics in our C# code a lot of people would die to have contact with (specially the concurrency). So I thought there might be a way to keep this out of wrong hands...
Dear, I meant to say that if it is really worth then why microsoft didnt protect its code from disassembling? Actually it was my question not a reply to your question 
. I am wondering that we can see their libraries, code and algorithms in those files, so why not microsoft protect its code with these types of tool.
Any body any idea or comment?
Hello,
Raulsassaa wrote:
What are the problems in using an obfuscator tool to "hide" our most valuable asset, the .net code...?
Main problem that this is no way to obfuscate code to be on 100% sure that nobody will be able to retrieve your algorithm. I think some sort of custom compilators will particularly do their job, however in this way you can lose advantages of the platform.
Look into Assembly Lockbox at http://alb.gibwo.com
This tool encrypts the assemblies without losing reflection or the other benefits of the platform. It has been in development for 3 years and in beta testing for 2 years. It really is different from the other tools that attempt to do this and it makes it a fast and easy process to encrypt your code just before you ship your product.
In order to run on the client machine, those dlls need to be unencrypted, so they will be in memory in their unencrypted form. Can't evil crackers just take a snapshot of the memory that holds the unencrypted dll, after it's been decrypted?
I don't think having your lock dlls written in C++ is going to make it harder for them to be reversed engineered, It's been quite some time (thank god) since I used assembly language but reading assembly becomes quite quick and easy if you've worked with it for a while.
I notice you don't mention any actual encryption algorithms that are curently regarded secure in the eyes of current cryptanalysts. This may not help sales as for all we could know, you may have invented the encryption yourself and it's not been analysed by recognised experts at all.
Check out everything Bruce Schneier has to say on security by obscurity
A basic rule of cryptography is to use published, public, algorithms and protocols. This principle was first stated in 1883 by Auguste Kerckhoffs: in a well-designed cryptographic system, only the key needs to be secret; there should be no secrecy in the algorithm. Modern cryptographers have embraced this principle, calling anything else "security by obscurity." Any system that tries to keep its algorithms secret for security reasons is quickly dismissed by the community, and referred to as "snake oil" or even worse.
Good luck with your product though
Ed
Credit Card transactions are protected with publicly known encryption algorithms everyday. Once the assembly gets into the hands of the CLR it is up to the CLR to protect its own memory. Unless you are storing Americas nuclear launch codes in an application being shipped then most people (competitors) are unlikely to bother trying to crack Assem directly. Just in case they would however we have packed our C++ with measures to confuse those trying to do so. The point of Assembly Lockbox is not to be impossible for the CIA to crack but rather impossible for decompilers or an average software developer to crack and even if ONE gets cracked all others remain uncracked. Take for example the DVD Jon hacker. Once he cracks a DVDs protection he can share that crack so many other DVDs can be cracked. Assembly Lockbox uses something we call "Lockcores". Just like in physical locks each lockcore is "keyed" differently. In addition Assembly Lockbox customers can add extra "tumblers" to the lockcores to make them absolutely unique from all other lockcores... this eliminates the threat of crack once crack all... or "golden keys". In future releases even more layers will be added such as allowing hardware devices such as USB uniquely IDed keys etc... to be added to the lockcores.
One extra note... Microsoft and Intel are working towards making certain areas of RAM protected at the hardware level. This combined with things such as further expansion of the .Net System.Security.SecureString class will allow in memory encryption. This all of coarse will be taken advantage of in Assembly Lockbox as it becomes available. Of coarse you still would not want to store nuclear launch codes like this because the military and I am sure others can read straight off the RAM chips themselves...
Thanks for the support and I hope this product helps many businesses feel safer about their investment in their .Net software.
My recommendation would be to try to keep sensitive code on the server and expose the functionality using services. If you have to distribute it then, yes, using an obfuscator is a good line of defense. The drawback, if you can call it that, is that it only makes it harder to steal your code. Someone who is intent and patient enough can usually still figure it out. But at least it makes it harder to steal your code at a relatively minor cost. If the algorithms themselves are IP, I'd also look into what kind of legal protection you can get based on where you are doing business (such as patents in the US).
To answer the question about Microsoft and why they don't use it, I can only guess, but my guess is that they don't consider the .NET Framework to be sensitive code nor do they really have to worry about competitors stealing IP on that point. After all, who would use an alternative .NET Framework? For third parties, however, obfuscation of code-based IP is a valuable tool because the threat of a competitor stealing the code and coming to market with a similar product is a real possibility.
I've seen a few different ways to do this, including the various obfuscators that rename labels and the like, to make life a little harder, but not impossible. Another way I've seen used a resource file to hide the code, so that it can't be reflected, but even with that, if you really wanted to look at the code, you could work it out, I'm sure.
I've seen quite a few human ofuscators too, developers who for one reason and another write the most difficult to follow code ever!
The way I see it, if you hide your code, people may think you have something to hide, and it be a bigger challenge to them. I would see it that if people wanted to reverse engineer anything I ever produced, I'd feel flattered, but that's a different thread topid, I guess.
You really have to ask yourself if it's worthwhile going to the trouble of hiding something, if it means losing the ability to reflect onto the assembly through your own code. My personal view is that writing the best application keeps you out there in the market, instead of hiding some code you think that someone might want to steal. They could mimic your interface regardless if they wanted too?
Link?
Yep. Look here - Running Assembly Reflector Add-in
