Unknown. Net encryption Shell

my friend asked me this evening to talk about his OA system (Asp. net) updated today. Registering the algorithm seems to have changed. It seems that the encryption shell has changed. Ask him to help him.
it is a DLL Program and it is net2.0. It should be nice. The resource manager used the big icon view mode to check the version information of all DLL files and found no suspicious files. Let's take a look at the ildasm structure and analyze the protection methods. A Red Cross dialog box is displayed, indicating the protected module.
it is unexpected to use reflector. This tool is too fragile. Use 9ray to see the part.
However, these tools are too weak. If dis # is relatively powerful, you can use it to open the scene and see clearly.
name obfuscation occurs, and the names are all obfuscated into names similar to "o10l1o0l. No obfuscators have such name obfuscation features.
except for some methods, you can see the Code . Most methods cannot see the code, but they should have an encrypted shell.
pinvoke call is found. Khan called a database access layer DLL (from the DLL file name). After analyzing the file, we found it was a native DLL. It seems that this file is tricky to hide.
after reading the export table, you can see several functions in the maxtocode Runtime Library. However, the export function of this database is much larger than the export function of the maxtocode Runtime Library previously seen, and the size of the runtime database is much larger.

No matter what shell it is, just use the Reflection Method for a try. The result is obviously not good. This shell anti reflection.
I suspect this is the latest version of maxtocode. I posted a description document on its website to check the update records.
* Added The Decompilation function of ildasm and The Decompilation tool that uses APIs to access source data.
(Later I found that it actually only anti ildasm 2.0, strictly speaking, only effective for the official ms)
* Tested, currentlyNoneThe Decompilation tool can completely read the encrypted structure, not to mention the encrypted code.
(See the instruction document to introduce ildasm, reflector, and spices which cannot be read. It seems that other tools, especially dis #, are not introduced #. These three cannot be consideredNone: P)

First, use maxtocode for troubleshooting. Try to use maxtocode 3.16 for reflection. It seems that there is a little effect and some method attributes can be obtained, but there is still no il code.
I have read the instruction document and mentioned that the maxtocode 3.2 Enterprise Edition uses multi-core segment protection. Will there be a mounted service in the JIT layer? We scanned the JIT field and did not find any exceptions.

It should be in the mscorwks. dll field.
I was wondering if it would be used.ArticleThe third or similar method mentioned in "mscorwks. DLL's position in. NET and Its Application in. Net code protection? Although the solution has been rejected by me, this shell may be like this.
I scanned Area A and Area B and found exceptions in both areas. It seems that the road to reflection is not easy to go.

Try the JIT layer shelling method directly. OK, you can get the method body code correctly.
Because it is a DLL release, you can install jithook first and then load the encrypted assembly. No methods are missing from JIT. If it is an EXE, you may need to hook functions such as Global loadlibrary, in mscorjit. the jithook is completed during DLL loading. In addition, you must pay attention to the flexibility and variety of hook locations to prevent reverse hook mechanisms on the shell.

The content of methods in the JIT layer has been converted into several class structures. Fortunately, their definitions can be found in sscli, which makes the reconstruction of the method body much easier.
Hvm is always working on the JIT layer, so I am very familiar with this part. Rebuilding is just a little troublesome for sehtable.

A friend only needs the code of several key functions, which reduces the workload. I saw a modified version of ildasm in the snow, because the MS official version was attacked.
Open the Assembly, find the token value of the required method, and write it down. Find the method through reflection and invoke it, and let it go through JIT, jithook (based on token) to dump the obtained method body. In order to save trouble, we first dumped an empty shell assembly using reflection and shelling. Then manually fill back the method Body obtained by jithook (no automatic backfilling tool is yet available ).
To enable automatic offline, you have to save all the method bodies in the jithook according to the module, and then make an automatic backfilling tool to fill in the Assembly.

The features of this shell are similar to those described in the new version of maxtocode. From the export table of the Runtime Library, the original Module name is attick. dll, which seems to be the original name of the maxtocode Runtime Library. In addition, the export function contains the export functions of the previous maxtocode Runtime Library, including getcpuid, getdiskid, getmacid, and other functions.
In addition, we also see some chaotic structures similar to dnguard V1.0 and the Processing Methods of static constructor.
The metadata header is similar to that of dnguard V1.0. It is estimated that the Framework API is also used for processing.
This method can increase the encryption speed significantly. Like the update records of maxtocode 3.16, it also says that the encryption speed is greatly improved.

Although it is similar, it is still called an unknown shell.