A Sample .NET Deprotector - WHOLE ASSEMBLY PROTECTION
Updated on feb-13-06
Download (2.0 binaries and full source code) (4000 downloads since Feb-01-06, let me know whether it works) Download binaries for .NET Framework 1.1Browse Source Code String protection / deprotection article
This is a sample program that dumps out .NET assemblies loaded by a process inside the CLR engine. Whether the assemblies are encrypted or not, by the time CLR executes them, they must be in their original format with no protection, if at this moment , the assembly, protected ,,,,,,,,,,,
What is whole assembly protection
Whole assembly protection refers to a technique that encrypts a whole .NET assembly and then gets decrypted at runtime. It usually employs a tool to transform a .NET assembly into an encrypted format, and together with an embedded native loader to create a native image. Since the assembly is now a native image, same as those compiled from visual C 6.0, it will not be recognized by any .NET decompilers and disassemblers, and thus achieve protection. On the surface, it appears that a great deal of protection has been done, since all metadata (class, method names, MSIL code, resources, etc) is now hidden, and people can not observe a single details using regular .NET tools. This is why there are vendors that claim that their products protect everything . However, such a protection is unable to overcome this:. the .NET Framework runtime only understands assemblies in its specified .NET format in other words, by the time CLR engine is executing, the protected assembly must somehow recover to its original format with all protection and encryption removed. If at this moment, they are dumped out from the address space, then the original assembly is recovered, and the protection is perfectly defeated. Since .NET Framework is an open standard, they are many ways to get into its runtime address space. Therefore, it's very easy to undo whole assembly protection. Once decrypted, it protects nothing. It's dangerous if you see a product claims that protects everything. In general, security is not an easy one to tackle .How does the de-protector work
There are many ways to dump out assemblies loaded by the CLR runtime, for example, through DLL redirects, DLL injection, address space scanning, or through .NET specific APIs, such as profiling and debugging interfaces, and other undocumented features. Our sample deprotector right now utilizes two ways to defeat whole assembly protection. The first mechanism is to replace mscoree.dll (the runtime dll loaded by all .NET processes), the deprotector hooks the _CorExeMain () and _CorDllMain () methods and dumps out assemblies inside these two functions. The second way is through the standard profiling APIs, the deprotector implements a simple profiler that monitors assembly / module loading and unloading events, and dumps out modules from memory when modules are just finished loading. The profiling API provides an open mechanism to Interact with the clr.we ted The DeproTector on Several Protection Products on Market, And None of The Mket, And None of The Mark nd anti-trace tricks are usually used by those tools, the original assemblies can be retrieved by simply executing the protected assembly once through the deprotector. Since this is a fundamental flaw, it's impossible to overcome it. Some deprotection mechanisms might be blocked over time , for example, the profiling APIs can be blocked by disabling certain environment variables, but there will be always other mechanisms available to get into the process to undo the protection. there are a few more mechanisms that will be posted over time, such as fusion Hooking, Delegation Hooking, Win32 API Hooking, ETC.
Salamander Protector
Our salamander protector is not a whole assembly protection tool, and thus the deprotector discussed here will not defeat it. The protected assembly by Salamander Protector does not have its MSIL code inside the memory, therefore, any memory dump will not get the MSIL code . Our protector does not prevent people from viewing metadata, and the protected code remains valid .NET format, rather than in native format. After protection, all class / method names are still visible, with only the MSIL code is transformed, which is why We bundle the obfuscator in The Protector Package.potential Ways to Stop Deprotector
THIS CURRENT VERSION OF THE DEPROTECTOR IS Not Difficult To Stop. The Following Arembly Some Tricks That WHOL Assembly Protection Tools Can Use to Block this sample Deprotector:
Disable the Cor_Enable_Profiling and the COR_PROFILER environmental variables in the native loader, so the .NET profiling interface will be prohibited. Once a PE file is loaded, modify the PE header, so this DeProtector does not consider it as an EXE / DLL image, and Thus not get dumped. for more info, please check.cpp source. Examine The Time Stamp and Checksum of Those Common .NET DLLS (EG, MSCOREE.DLL), DON'T LOAD IF ARE Modified, Which Prevents DLL Redirects. This Has One Consequence, That Is The Protected Code May Not Execute IN FUTURE VERSIONS OF .NET FRAMEWORK.
FUTURE Directions
We will continue to release DeProtector versions using other technologies. A professional version of the DeProtector will be included into our free .NET Explorer package (http://www.remotesoft.com/dotexplorer), which will use much more advanced techniques to dump out assemblies from CLR engine. Source code may not be provided in the future. Overall, we truly believe whole assembly protection is not the way to go, and it is IMPOSSIBLE to block all potential places where memory can be dumped. We will show you , Stay Tuned.discussions and Comments
Comments and discussions can be posted through Huihong Luo's blog on the deprotector. We hope the discussion here can help us to better understand .NET source code protection. All deprotection mechanisms mentioned here are not targeting any specific vendor, instead we only discuss generic techniques that AP
