A misunderstanding of. Net encryption Shell

New Features of. NET 2.0 have been publicly used to obtain IlCodeThen, the encrypted shell becomes a weakness.
As tankaiha said, "There is nothing new to reverse under. net. A Software Version Upgrade is not as good as a single upgrade." due to inherent limitations, this has become a bottleneck in the strength of the encrypted shell.

However, a considerable number of people think that 1.1ProgramSet encryption is secure.
In fact, most of the 1.1 Assembly encryption can also be deshelled by means of launching.
(Note: The shelling only refers to the encrypted protective case. obfuscation cannot be restored. For example, a software now provides both encryption and obfuscation functions, and shelling only removes the encryption protection part)

. NET 1.1 does not have any new features in 2.0. How can it be shelled by reflection? The reason is simple, because most of the 1.1 programming sets can run in the 2.0 Framework.
For example, for encrypted DLL, we can use 2.0 to write an assembly to load it. We have a runtime environment of 2.0.
The encrypted EXE can also be used. Microsoft allows users to force a specified. NET Framework version to run a program by modifying the program configuration.
Assume that a.exe is an encrypted 1.1 assembly.
We only need to create a file named a.exe. config and put it together. The file content is as follows:

<Configuration>
<Startup>
<Supportedruntime version = "v2.0.50727"/>
<Requiredruntime version = "v2.0.50727" safemode = "false"/>
</Startup>
</Configuration>

When you run a.exe again, the system automatically enables. NET 2.0 Framework as the runtime environment.

If only one function can be used to obtain the Il code, encryption protection has some practical value.
However, reflection shelling has already taken the finished product offline, making encryption completely a weakness.

For reflection, the encrypted shell still has some space, but its function is very limited, and its symptoms are not a permanent cure.
That is to say, destroy reflection and make reflection unable to work normally.
That is, the reflection is destroyed by damaging the system formation code or code path that is running normally.
As long as the reflection is fixed, you can continue to use offline shelling.

This will move the battlefield to the traditional Win32 layer.
However, due to the limitation of the. NET kernel framework, the damage is always limited. It is easy to get familiar with the Assembly and understand some underlying. net mechanisms and to fix them.

Of course, you must first find a sample to analyze the solution. If there is no sample, there is no way.
In this case, a new shell version will not be released for trial use.
This has a little effect on security, that is, the patch repair method that someone else finds when the new version is released.
However, as long as an encrypted Protection Program is released, there will be an analytical sample, and the results can be imagined.

The strength of the encrypted shell is not guaranteed. Of course, the protection of multiple layers is always good. Among the many protection methods, encryption has become the most vulnerable.