Hi all, just a quick question.
Since there is a .NET Reflector written by LR which disassemble an exe/dll file, i can't find anything nor a better solution to get secure.
How are we suppose to write a secure .NET app since it can be disassemble
Is there a way to do it or perhaps possibility
Or what's your recommendation / suggestion
Regards,
David [.NET NEWBIES]

.NET Assembly Security
Sune Henriksen
Buy this tool http://www.preemptive.com/products/dotfuscator/index.html
DOtFuscator can translate your code to other unreadable lang for certain security level.
For vs2005, MS offer six month trial of TFS for US$3.50
try it!
Art Vandolay Jr.
Hi Michael,
Is it possible for us to disable or encrypt the CLI during application rebuild or installation
As for other software with their dll file, Lutz Roeder's .NET Reflector can not open dll file that does not contain a CLI header.
Or is there any other open sources software or other solution other than using this DotFuscator
REgards,
David
George2
http://www.aspose.com/Products/Aspose.License/
http://www.aspose.com/Products/Aspose.Obfuscator/
Aspose offer this for free.. but use it at your own risk.
fflores
codeveil can disable CLI header
http://www.xheo.com/products/enterprise/codeveil/
mizan1214
As I mentioned above there are decompilers available for VB6. Even without one, all the person trying to figure out what your application is doing has to do is run it, and watch the instructions cross the CPU. They can monitor which Win32 APIs it calls and get an ever better idea of what's going on. If the attacker has access to your code, all you can do is raise the bar -- its up to you how high you want to raise it.
-Shawn
lp75
Hi all,
I agree to Sikkeng: Microsoft gives us a good tool with VS 2005, with securities, encryptions, ... but anybody can download a free decompiler and see the code. Cool !
Ok, we can obfuscate the EXE but paying at least 500$ for that. I'm a "little developper" trying to sell my applications at a low cost but need to pay for not seeing my programs decompiled.
I think that it must be an automatic (and free) process during the compilation. I almost regret my old VB6.
Bye. Paul
RamyM
I read your comments and my question is:
How can i disable CLI header
Please tell me that.
thanks a lot
Elham Sarikhani
Once the code is on your client's machine, if they really want to look at it they can. All you can do is raise the bar. The easiest code for them to figure out is the output from a standard .NET compiler. From there, obfuscating the code makes it more difficult to interpret, but it's still doable if they want to. Moving some of your sensitive logic into a COM component and then using interop to call it raises the bar again -- however a determined user will still be able to figure out what you're doing (think of how often a crack comes out for games compiled to native code).
The only way to ensure that your users don't reverse engineer your code is to ensure that they don't have a copy of your code in the first place. The easiest way to do that is to only make the core logic available via calls to a web service that you control. As long as the user has a copy of the code, if they're determined enough they'll be able to figure out what it does.
-Shawn
Morn
You cannot disable the CLI header in a managed application. Without that header the CLR will not know how to run your code.
-Shawn
Shaantu
There are certainly disassemblers for VB6, x86, x64 and IA64. Sure Reflector provides a nicer interface, which is enabled via the extra metadata in a .Net assembly. Obfuscation will help make the metadata less useful to someone reverse engineering your application, however like I said in my previous post this is only raising the bar.
Code that exists on the client machine, no matter in what form, be it a .Net assembly, native machine code, Java bytecode, or VB 6 can always be reverse engineered by a user who is determined enough. You can make it more difficult for them to do it, but at the end of the day a series of machine instructions are going to have to be executed by the processor -- and the user can just interpret those if need be. The only way to ensure that nobody can figure out how your code does what it does is to not allow them access to the code itself, in any form.
-Shawn
kendy
So, if CLI header is not available, we cannot open the assembly in the .NET Reflector. Interesting.
Does MFC applications written in unmanaged code has the CLI headers
Where can I get the informations regarding this CLI header
Thanks,
Nanda
Bilberry71
Hi David,
The best way to protect an Assembly from beeing decompiled is to use an obfuscator like Dotfuscator from PreEmptive Soluctions. It does basically rename all your non public and internal types so nobody else can understand it's meaning easily. You still can decompile them.
VS (2005 and 2005) ships with the Dotfuscator Community Edition. Further details on this tool are avaliable here: http://www.preemptive.com/products/dotfuscator/index.html
Regards,
Michael
ascanio
Is that mean without web services, the client still would be able to disassemble the .exe file, .dll file.
I can't find any tool recently can disassemble VB 6 exe file.
In this case, what the point of security enhancement in .net
What am i focus is on Windows application. Encryption in here would be pointless, since the client can see your encryption module everything. if they also have a programmer to copy the code and recompiled their own.
spribyl
While I know any program can be broken with enough effort. It seems to me that Microsoft's change to the .Net format has just made life much easier for code breakers while making it harder for Individuals writing code to sell small programs to protect their code. I used Obfucation of code with code I have written since the early versions of basic. But now it takes nothing to decompile the code and then work on figuring it out. While programs compiled in Native code it took much more to decompile and break the code where small specialized programs usually were not worth the effort to break.
Why doesn't Microsoft continue to provide native code compilation for VB.Net programs to allow small business / Self Programers the same level of code protection that VB6 provided. While it could be broken the process involved often required more work than the reward was worth.