We are all looking for a long time. A method that fully protects code security. Countless tools and solutions are used. In powerful Il and decompilation and shelling, yundun is stabbed under the spear.
Recently, the author has been suffering from headaches, but has combined some previous solutions. I came up with a new solution.
OK. To put it short, the practice is quite simple.
Most shelling methods on the Internet are to put programs or libraries into resources and then read and run them. This method is good, but when this layer of shell is cracked, the code is still exposed.
My practice is actually similar to the above method. However, I directly generate a binary code using the IO method of the program or library, this code is then used to generate a byte [] array (very simple, that is, to read it with filestreamreader, and then write it with streamwriter, and process it when writing it) and store it in. CS file (I directly generated a CS file ). Copy and paste the file to the project. In this process, we can also process byte [] In this. CS file to make these binary codes shorter and more difficult to crack.
Then generate a console Program (or other programs), load it using appdomain. Load (byte []), and run it.
Well... Such a shell program is ready. However, a friend may have a headache after trying it. This method can only load one program and cannot contain other DLL and resource files required by the program. What should we do?
Hey, it's easy. Generate the resource and file as byte [] in the same way as above, and then use the assemblyresolve event in appdomain to load the Assembly that fails to be loaded, so that it can be used correctly.
After testing, all programs, including remoting, can run correctly. But there is a small problem, that is, the objects stored in the hard disk file after serialization cannot be used correctly. I believe there will be a better solution soon.
This method also applies to EXE and DLL after obfuscation and shelling by other tools, and can be obfuscated and shelled again after the program is decompiled, you can only see a lot of 01 code that you don't understand, and the same is true for IL. Do not try it.
This article from the csdn blog, reproduced please indicate the source: http://blog.csdn.net/jhkemail/archive/2009/06/15/4269491.aspx