A Sample .NET DeProtector - whole assembly protection

转载 2006年06月19日 20:47:00
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.1
Browse 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 assemblies are dumped out from memory, protected assemblies are decrypted. This illustrates that whole assembly protection is not a good way to protect intellectual properties.

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't 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 tested the deprotector on several protection products on market, and none of them can survive this simple deprotector. Even if anti-debug and 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 won't 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 are some tricks that whole 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 the SaveFile () method of the Dump.cpp source.
  • Examine the time stamp and checksum of those common .NET dlls (e.g., mscoree.dll), don't load if they 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


assembly, 这里把它翻译为配件, 以示和组件(Component)加以区别.     一个配件有时候是指一个EXE或者DLL文件, 实际上是一个应用程序(就是指带有主程序 入口点的模块)或者一...
  • wangzhe2xxx
  • wangzhe2xxx
  • 2007年09月14日 14:13
  • 482

dotfuscator 在混淆.Net Framework 4.0以上版本的时候报错的解决方法

在混淆的时候报错了,错误描述大致如下: Could not find a compatible version of ildasm to run on assembly C:\xxx.dll This...
  • winnyrain
  • winnyrain
  • 2013年12月05日 14:50
  • 11635


dotfuscator错误包括: ===== Loading Assemblies... Could not find a compatible version of ildasm to run o...
  • qq168213001
  • qq168213001
  • 2015年09月25日 22:38
  • 1826

"this whole ARM thing is a f*cking pain in the ass"

  • wu20093346
  • wu20093346
  • 2015年02月24日 21:16
  • 1659

A Cubic number and A Cubic Number

Problem Description A cubic number is the result of using a whole number in a multiplication three ...
  • xcd1997
  • xcd1997
  • 2017年09月17日 13:08
  • 329

76.Which statement is true about a whole consistent database backup on a database running in ARCHIVE

76.Which statement is true about a whole consistent database backup on a database running in ARCHIVE...
  • dwj19830118
  • dwj19830118
  • 2016年07月26日 21:30
  • 684

ORA-01502& ORA-14086: a partitioned index may not be rebuilt as a whole

收集分区表统计信息的时候遇到了ORA-01502分区表索引失效的错误。 重新REBUILD分区表的分区索引后能正常收集分区表统计信息。 rebuild分区表分区索引的方法:ALTER INDEX &i...
  • lwei_998
  • lwei_998
  • 2011年06月21日 17:48
  • 6620


  • Eye_cng
  • Eye_cng
  • 2015年12月12日 13:49
  • 1217


requisitePro安装完成后, 我在使用的时候频繁出现以下错误,之后就退出程序,无法进入 requisitePro。    Message 1001: a non-continuable pro...
  • flm2003
  • flm2003
  • 2007年01月31日 19:02
  • 1571

.NET 查找程序集路径(CLR关于Assembly的搜索路径的过程)

最近在回顾.Net应用程序的执行环境,这里做一个很小的总结,方面以后需要的时候进行查找: CLR必须可以找到正确的Assembly,Net提供了Assembly搜索算法,可以根据.config文...
  • wangjunhe
  • wangjunhe
  • 2011年08月16日 16:34
  • 5270
您举报文章:A Sample .NET DeProtector - whole assembly protection