I have been studying DotNet related materials recently, and sscli is really a good thing :P.
While studying, I synthesized the knowledge and made this small tool.
The protection principle is similar to the Chinese remotesoft and maxtocode. The encrypted program also needs to be accompanied by a runtime library when it is released.
However, unlike those two, the included runtime library is not a pure native dll, but a C++/CLI hybrid assembly.
The tool has taken shape and the overall kernel framework has been completed. Used to encrypt a sample and it runs normally.
Some aspects even exceed maxtocode.
1. Does not rely on Microsoft's ildasm and ilasm programs.
Both IL disassembly and IL assembly are implemented programmatically.
Assemblies containing native code can be encrypted.
2. Anti decompilation tool, maxtocode encrypted assembly cannot be viewed directly with reflector, but after running the program, use pedumper, and after dumping, you can use reflectotr to view the structure. Of course, you still cannot see the code.
The assembly encrypted by dnguard is better than I expected. The encrypted assembly cannot be viewed with reflector, and the dumped assembly cannot be viewed with the reflector plug-in.
I feel that reflector is still a bit weak. Similar software, Disa# and Xenocode fox, can directly open and view maxtocode and dnguard encrypted assemblies.
To this end, I tried to add structural obfuscation to the dnguard encrypted assembly. It had an effect, that is, when viewing the structure in Disa# and fox, there will be some confusion, that is, functions of class A may be displayed in class B. The effect is not very good, there are only a few functions in each class that will cause problems.
3. The new features of Anti .Net 2.0 are not very strong. The strength is similar to that of maxtocode 3.13 (internal version). I heard that maxtocode has released 3.14. I don’t know if the strength has been enhanced (Looking at the reply in Jason’s blog, it seems to be the same as 3.13). same). Max 3.12 can be used by patching only a few bytes, and reflection can be used. 3.13 is not much different, and the number of bytes required to be patched is even less than that of 3.12.
There is now a better solution in this regard, which can greatly increase the intensity without affecting efficiency. But it cannot completely prevent dumps.
There is also a relatively perfect anti-dump solution, which needs to be implemented in conjunction with another protection technology.
We do not plan to discuss this aspect in depth. After the DNGuard encryption shell is completed, we will start another protection technology and finally combine the two protections.
4. Use ildasm and ilasm to restore the assembly after Anti dump. In addition to the new anti-dump features of anti .net 2.0, DNGuard also adds anti, a dumper I made in the early days. In addition, the feature of C++/CLI hybrid assembly is also used to prevent ildasm after dump. However, this is not very strong, and small assembly can be easily repaired to implement IL assembly.
There is still a lot of work that needs to be done. The encryption algorithm has not yet been worked out, and the protection of the runtime library itself has not yet been done. I found that you can find ready-made protection tools for purely native DLLs, such as thmida, which is very good. The runtime library of maxtocode uses this shell, but I have never been able to find a good method for C++/CLI DLLs. It seems that we can only manually add a layer of protection, and we have already started testing it. Now we are going to add a simple encryption shell. After this is completed, we will put a demo of DNGuard on it.
After DNGuard encrypts the assembly, use reflector to view:
Use reflector to view the DNGuard encrypted assembly dump:
The assembly encrypted by Maxtocode is viewed with Reflector:
After Dumping the Maxtocode encrypted assembly, view it with Reflector:
