. Net encryption principle, compatibility and security of the encryption Shell Core (6)

We have introduced the core implementation principles of mainstream double-layer encryption shells,
At the same time, we mentioned compatibility and simplified the encryption Shell Core while considering the security.
This article mainly discusses security and compatibility considerations.

Security mainly deals with two types of scammers.
1. Static Analysis shelling
For this type, the effective method is to increase encryption.AlgorithmNumber and complexity.
The impact of the implementation of the encryption shell core can be ignored.

2. dynamic framework core layer Interception
There are two types of defense for this category. One is to detect the core layer of the framework and reverse the hook.
The second is to construct a reasonable encryption Shell Core mode, which limits the core data to the encryption shell Runtime Library,
The attacker cannot intercept all required information out of the encrypted shell Runtime Library.

There are two main types of compatibility
1. Compatibility with unknown framework Environments
Because the physical addresses of different functions in different frameworks may be different, this is the biggest difficulty in compatibility,
Therefore, as few core functions as possible can increase compatibility with unknown frameworks.

2. compatibility issues with other encrypted Shells
This situation is rare, but it cannot be ignored.

For example, A. Net Middleware vendor uses a to encrypt its products, while another software company uses the middleware, and the company uses B to encrypt its own products.
In this case, two encryption shell cores appear in a software environment.
However, in this case, there is basically no need to worry too much. Generally, the two companies can coordinate and solve the problem.

However, in another case, it is difficult to do the following:
If you deploy two web applications with different encryption shells on the same virtual host, you also need to face this problem.

How can this problem be solved??
In terms of security, the framework is tested and the anti-system intercepts the scammers. This will cause problems with the 2nd compatibility.

Therefore, the ideal solution is to use the second method to construct a reasonably encrypted Shell Core to enhance security, without negatively affecting compatibility.
Of course, if you decide not to consider compatibility with other encrypted shells, you will not need to worry about this issue.

Let's take a look at the second article of compatibility.
The root cause of the trouble is the unknown function address, especially for function addresses in mscorwks. dll, there is no reference point.
The only compatibility method is fuzzy search, so try to reduce the number of hooks in mscorwks. DLL to improve compatibility.

The functions in mscorjit. dll are easy to accurately determine, because another entry function address can be obtained directly,
Then you can get the lower-level function address. Of course, this requires a small disassembly engine. It is basically okay to search for layers 1 to 3.

Conclusion: mscorwks. dll is the bottleneck of the compatibility of double-layer encrypted shells.

As mentioned above, the Framework detection will affect compatibility. In fact, this method does not greatly help improve security.
The main reason is that compatibility (compatible with unknown frameworks) andProgramEfficiency, so it is impossible to fully inspect the framework, and the detection range is limited. Because of the diversity of hook methods, the detection success rate is also relatively low.
Some beginner users may receive some results.

So what should we do??
Next, we will introduce the core compatibility and Security win-win implementation mode of the encrypted shell, and the implementation of the pure JIT layer core.