Prevent reverse phase projects for Visual Basic .NET or C # code
Release Date: 12/28/2004
| Update Date: 12/28/2004
Gabriel Torok and Bill Leach
This article assumes that you are familiar with .NET and C #
Summary
One of the advantages of the .NET architecture is that the assembly constructed with the architecture contains many useful information, using the intermediate language disassembler iLDASM to restore this information. But this will bring another problem, that is, people who can access your binary code can restore the original source code with very similar means. The author will introduce the programs in the text, which can be used as a means of preventing reverse phase engineering. In addition, they will discuss the available different types of fuzzy processing technology, and demonstrate the new blurred treatment tools included in Visual Studio .NET 2003.
This page
Anti-applying anti-compilation in-depth understanding of fuzzy treatment renamed metadata deletion non-basic metadata other technology to use dotfuscator community Edition check mapping file fuzzy handler's defect summary
To date, from the burden of mitigation deployment and version control, you may have been familiar with all the benefits of these metadata's rich Microsoft® .NET Framework architecture. You may not know that the ease of use of metadata is currently not noticed for most developers. Programs prepared for public language runtime (CLR) are more likely to perform inverse engineering. Anyway, this is not the defect in the .NET Framework design; it is just a reality of a modern, middle compile language (Java language application has the same feature). Both Java and .NET Framework use rich metadata embedded in executable code: In Java is a byte code, in .NET is the Microsoft Intermediate Language (MSIL). Since there are many advanced machines than the binary machine code, the executable file is full of information that can be easily cracked.
With a tool such as ILDASM (with the MSIL disassembler released by the .NET Framework SDK) or an anti-assessment like Anakrino and Reflector for .NET, anyone can easily view your assembly and will The reverse phase project is readable source code. Hackers can search for safety defects to explore, steal unique creative and decipherous procedures. This is enough to make you hesitate.
Despite this, please don't worry. There is a fuzzy handling solution to help you prevent reverse engineering. Fuzzy treatment is a technique that provides seamless renames for symbols in the program, which also provides other techniques to prevent disassembler. If appropriate, fuzzy processing can greatly enhance the application of the application to prevent reverse engineering, while maintaining the complete application of the application. Fuzzy treatment technology is often used in the Java environment, has helped many companies to protect their intellectual property based on Java technology products.
There are now a number of third parties responded by creating a .NET code. Microsoft in Visual Studio by working with our company Preemptive Solutions? The .NET 2003 contains Dotfuscator Community Edition, and Preemptive Solutions has also launched a variety of fuzzy handler packages.
By using Dotfuscator Community Edition, this article will teach you all content related to fuzzy processing (simply introduce disassembly), usually the type of fuzzy processing, and some issues that need to be solved when using the fuzzy processing program.
To demonstrate anti-compilation and fuzzy treatment, we will implement an open source of the classic VEXED game. Vexed.net is written by RoEy Ben-Amotz, available from http://vexedddotnet.benamotz.com. This is a puzzle game, your goal is to move similar blocks together to make them disappear. Below is a simple way in vexed.net source code: public void undo () {
IF (Numofmoves> 0) {
Numofmoves -
IF (_USERMOVES.LENGTH> = 2)
_USERMOVES = _USERMOVES.SUBSTRING (0, _USERMOVES.LENGTH00);
this.loadboard (this.Movehistory [Numofmmoves)
(NUMOFMOVES / 50) * 50]);
this.drawboard (this.gr);
}
}
Disassembly
The .NET Framework SDK has an anti-assembly utility called ILDASM, which allows you to compile the .NET Framework program set to the IL assembly language statement. To start ILDASM, you must ensure that .NET Framework SDK is installed, enter Ildasm in the command line, then you want to make an offline program name. In the current example, we will enter "ildasm vexed.net.exe". This will start the ILDASM UI, which can be used to browse any configurations of the .NET Framework application. Figure 1 shows the negative UNDO method.
Back to top
Anticipation
If you think that only a few talents who really understand the IL assembly language will see and understand your source code, keep in mind that the anti-compilation will not be here. We can use the anti-compiler to create the actual source code. These utility can directly compile the .NET assembly to advanced languages such as C #, Visual Basic .NET, or C . Let's take a look at the undo method generated by an ANAKRINO disassembler:
Public void undo () {
IF (this.numofmoves> 0) {
this.numofmoves =
THIS.NUMOFMOVES - 1;
IF (this._usermoves.length> = 2)
THIS._USERMOVES =
THIS._USERMOVES.SUBSTRING (0, this._usermoves.length - 2);
this.loadboard
THIS.MOVEHISTORY [this.numofmoves -
THIS.NUMOFMOVES / 50 * 50]);
this.drawboard (this.gr);
}
}
You can see that the result is almost identical to the original code. Later, we will return to see the results after fuzzy treatment.
Back to top
In-depth understanding of fuzzy treatment
Fuzzy treatment is achieved using a set of related technologies. The purpose of fuzzy treatment is to hide the intent of the program without changing its runtime behavior. It is not encrypted, but for .NET code, it may be more win better than encryption. You can encrypt the .NET assembly to make them completely unreadable. However, this method causes a typical inlet and retreat, because the runtime must perform an unencrypted code, the decryption key must be saved with the encrypted program. Therefore, an automated utility can be created to restore the key, decrypt the code, and then write it to the disk as the original form of IL. Once this happens, the program is completely exposed under anti-compilation.
We can compare the encryption as a package that will contain six dishes into the box. Only a predetermined dinner (CLR in this case) has a key, and we don't want anyone to know what he or she will eat. Unfortunately, all foods will be completely under the public. Fuzzy treatment work is more like putting a package containing six dishes into a mixer, then put it in a plastic bag to the diners. Of course, everyone can see the food being delivered, but in addition to happening to see a complete pea or some beef, they don't know what the original food is. The diners still got what he wanted, and this dining still provides the same nutritional value as before (fortunately, the CLR is not picky). The trick of the fuzzy handler is to make the spokesman, and the program can still submit the same product to the CLR. Of course, fuzzy treatment (or encryption) is not more than 100%. Even if the compiled C may also be disassembled. If hackers persevere, he can regenerate your code.
Figure 2 Fuzzy treatment process
Fuzzy treatment is a process that applies to compiled .NET assemblies rather than source code. The fuzzy handler will never read or change your source code. Figure 2 shows the flow of the fuzzy treatment process. The output of the fuzzy handler is another set of assemblies, featured with the input assembly, but the program is converted in a way to obstructive phases. Now we will discuss the two basic technologies used by Dotfuscator Community Edition: rename and delete non-basic metadata.
Back to top
Rename the metadata
The first defense of fuzzy treatment is to rename meaningful names as a meaningful name. As you know, you can draw a lot of valuable clues from your carefully selected name. They help to make your code self-documentation and act as valuable clues that reveal them. CLR does not care about how a name is descriptive, so the fuzzy handler can freely modify these names, usually modified to a single character name similar to "a".
Obviously, the fuzzy processing program is limited to the number of renames that a particular program can perform. In general, there are three common renames.
If your application consists of one or more independent assemblies (ie, the code that is not fuzzy processing does not depend on any assembly), the fuzzy handler can freely rename the assembly regardless of the visibility of the name. How, as long as the name and reference to the name are consistent in the program set group. The Windows Form Application is a good example. As an ultimate example of a reverse, if your application design is to use code to use without fuzzy processing, the fuzzy handler will not change the names or members of the client visible to the customer. An example of this type of application includes something such as a shared class library, reusable components. The two are those in the framework that intends to insert an existing unforgettable process. In this case, the fuzzy handler can rename anything that is not accessible when it is running, regardless of the visibility. The ASP.NET application is a good example of this type of application.
Dotfuscator Community Edition uses a patented rename technology called "overloaded", which can be added to the rename. After detailed analysis of the domain detailed, the method identifier obtains the maximum overload. The heavy-duty restriction technology is not replaced with the old name as a new name, but will rename a lot of methods as the same name as much as possible to confuse those people trying to understand the anti-compilation code.
In addition, as a good side effect, the size of the application also becomes smaller due to the smaller string stack contained in the assembly. For example, if you have a name with a length of 20 characters, rename it "A" will save 19 characters. In addition, space is saved by saving the string stack to continuously rename the rename. Rename it "A" means "a" only stores once, each method or field that is renamed "A" can point to it. The overload is increasing to enhance this effect because the shortest identifier will be reused. Typically, a heavy-duty summary project will be renamed "a". To understand the impact of renaming the anti-compile code, check the undo method after renamed processing:
Public void c () {
IF (THIS.P> 0) {
THIS.P = THIS.P - 1;
IF (this.R.Length> = 2)
THIS.R = this.r.substring (0, this.r.length - 2);
THIS.A (THIS.Q [this.p - this.p / 50 * 50]);
THIS.A (this.e);
}
}
You can see that this method is already difficult to understand without any fuzzy treatment.
Back to top
Delete non-basic metadata
In compiled, based on .NET-based applications, not all metadata will be used at runtime. Some of these data will be used by other tools (eg, designers, IDE, and debuggers). For example, if you define a property named "size" on the type in the C #, the compiler will omit the metadata "size" and associate the name with those methods that implement GET and SET. (They are named "get_size" and "set_size" respectively). When you start writing a code for setting a size property, the compiler will always generate a call to method "size-size" itself, and will never reference this property through its name. In fact, the name of the property is used for IDE and developers using your code; the CLR never access it.
If you use your application instead of other tools, the fuzzy handler deletes this type of metadata is secure. In addition to attribute names, event names and method parameters are also in this category. DotFuscator Community Edition deletes all of these types of metadata when it thinks so security.
Back to top
Other technology
Dotfuscator Community Edition uses the technologies we just introduced to provide good blurring, but you should know that fuzzy processing technology can also prevent reverse phase engineering while providing more powerful protection. DotFuscator Professional Edition achieves many other technologies, including control flow fuzzy processing, string encryption, incremental fuzzy processing, and scale reduction.
Control flow is a powerful fuzzy processing technology that is the purpose of hiding a series of instructions and does not change logic. More importantly, it can be used to delete those trails that the anti-compiler is in order to loyal the advanced source code statement (such as if-kilse statement and loop). In fact, this technology tries to destroy the work of the disassembler.
To view the running effect, after using renaming and control flow fuzzy processing, study the anti-compiled UNDO method again (see Figure 3). You can see that the disassembler does not generate the original nested IF statement, but generate an IF statement, two nested while loops and some of the GOTO that is bundled together. The label I1 is referenced, but it is not generated by the anti-compiler (we assume that it is an anti-compiler error).
String Encryption is a technique that applies a simple encryption algorithm to a string embedded in your application. As mentioned above, any encryption (or special case decryption) performed at runtime is not safe. That is to say, the technically superb hacker is actually able to crack it, but for the string in the application code, it is worth it. The fact that we face is that if hackers want to enter your code, they will not blindly start searching for renamed types. They may do search for "Invalid License Keys", which will direct them directly to the code that executes the license. Searching for strings is very simple; string encryption settings are protected because there is only an encrypted version in the compiled password. Incremental fuzzy processing helps publish patches to solve the problems that customers encounter during the face of fuzzy treatment. Creating or deleting classes, methods, or fields often created or deleted when errors in the code. Changing code (for example, adding or deleting a method) may result in subsequent fuzzy processing to run, so that the renaming of things is slightly different. The name called "a" may now be called "B" now. Unfortunately, how to renam the renaming and different renaming differently, but it is not easy to figure out.
Incremental fuzzy processing can solve this problem. Dotfuscator will create a mapping file to tell you how it is renamed. However, this mapping file can also be used as input to DotFuscator in subsequent run to indicate that the rename previously used should be used again in any possible place. If you release your product, then patch some classes, dotfuscator will run in a way that mimics its previous rename scheme. This way, you can only post the patching class to your customers.
The reduction is not strictly to prevent reverse phase projects, but it is still mentioned here because the fuzzy handler must almost always perform dependencies on the input assembly. Therefore, the fuzzy processing program can not only make fuzzy processing, but it is better to use the code that does not use the code for your application. It looks a bit strange, in fact, deleting unused code is very easy, then who wrote these unused code? The answer is that all of our people. In addition, we have written, reusable libraries and types, and reused libraries.
Reusable code means there is some reference code that can handle many use cases; however, in any given application, you usually only use one or both of these many cases. Advanced Fuzzy Processors can determine this and delete all unused code (and is deleted from the compiled assembly instead of the source file). As a result, the output contained in the output is the type and method that your application is no longer needed. Smaller applications have the benefits of saving computing resources and shortening load time. These benefits are particularly important for applications or distributed applications running on .NET Compact Framework.
Back to top
Use dotfuscator community edition
Let us now use Dotfuscator Community Edition to fuzzy to process the Vexed application. Dotfuscator Community Edition uses a configuration file to specify a fuzzy processing settings for a particular application. It allows a GUI to help you easily create and maintain profiles and run a fuzzy handler and check out. In addition, the command line interface of Dotfuscator Community Edition allows you to easily integrate fuzzy processing into your automatic generation. You can launch the GUI directly from the Tools menu of Visual Studio .NET 2003.
To configure VEXED for blurring, you need to specify 3 items in Dotfuscator Community Edition GUI: Enter an assembly, mapping file location, and output directory. Enter an assembly (Dotfuscator is called "Trigger assembly") specified on the TRIGGER tab. You can add any more assemblies you need to add, but you only need one for the Vexed application. Specify the location of the mapping file on the "Rename | Options" tab (see Figure 4). The mapping file contains a clear name mapping between the original name and the name of the fuzzy processing, which is critical. What is important is that after the application is fuzzy, save the file; if not it, you cannot easily find the fuzzy process. Due to its importance, Dotfuscator does not override existing mapping files by default unless you explicitly select the "OverWrite Map File" box.
Finally, the "Build" tab allows you to specify the directory of the applying the fuzzy process. After completing the above work, the application can be blurred. You can save the configuration file for use, then you can press the "Build" button on the "Build" tab, or use the "Play" button on the toolbar. DOTFUSCATOR displays progress information in the GUI's output pane when constructing. Select Quiet or Verbose on the "Options" tab to control the amount of information displayed here.
Once you are finished, you can browse the results on the Output tab, as shown in Figure 5. As you can see, dotfuscator displays an application graphical view similar to an object browser. The new name is located directly below the original name in the view. In this figure, you will see the class named "Board" is renamed "H", two methods with different signatures (INIT and TIMAGE) are renamed "A".
Back to top
Check the mapping file
The mapped file generated by dotfuscator is a file in XML format, which includes some statistics that include statistics, which indicate the validity of the rename process. Figure 6 summarizes the statistics of the type and method for fuzzy processing of the VEXED application.
The mapping file is also used to perform incremental fuzzy processing. This process allows you to import names from previous running, which notifies the fuzzy handler to perform renames in the same way as before. If you publish a patch (or new plugin) for a fuzzy-processed application, you can use the same name set as the original version to fuzzy. This is especially useful for corporate development groups that maintain multiple interdependence applications.
Back to top
Defect of fuzzy processing programs
Fuzzy treatment (especially renaming) for complex applications is more difficult, it is highly sensitive to proper configuration. If inadvertent, the fuzzy handler interrupts your application. In this section, we will discuss some common problems that may occur when using a fuzzy handler.
First, if your application contains a strong name assembly, you need to do more work. Strong Name The assembly is a digital signature, allowing the running library to determine if the assembly has been changed after signing. Signature is a SHA1 hash value that uses the private key of the RSA public key / private key. This signature and public key are embedded in the metadata of the assembly. Because the fuzzy handler will modify the program, it is important to sign after fuzzy treatment. Before the development process and fuzzy processing, you should delay the signature and complete the signature process. See the .NET Framework documentation for more information on delay the signature assembly. Keep in mind that when testing the assembly of the latency signature, turn off the strong name verification.
Using the Reflection API and Dynamic Class Load will also increase the complexity of the fuzzy process. Since these utilities are dynamic, they are better than the static analysis used by most fuzzy processing programs. Consider the following C # code snippet, the code snippet gets the type by name and dynamically aliftesse, then returns the type conversion to the interface: public myinterface getNewType () {
TYPE TYPE = Type.gettype (GetUserInputString (), TRUE
Object newinstance = activator.createInstance (TYPE);
Return newinstance as myinterface;
}
The name of the type comes from another method. GetUserInputString may require a user to enter a string or a string can also be retrieved from the database. No matter which method is used, the code is not displayed in the code, and therefore, it is not possible to understand which types in the input program set may be instantiated. The solution used in this case is to prevent all potential load-up types that implement MyInterface (note that the method and field rename can be renamed). Therefore, manually configuring and masters some knowledge about the application to make fuzzy processing is very important. Dotfuscator Community Edition provides you with a variety of tools to prevent renaming selected types, methods, or fields. You can select and select a unique name; or you can use the regular expression and other standards (such as the visibility of the scope) to write exclusion rules. For example, you can exclude all public methods outside of renaming.
Using a fuzzy handler will generate another problem when you deploy a fuzzy-processed application and try support. Assume that the application will throw an exception (which will happen to most people) and the customer sends you the following stack dump:
System.exception: a serious error HAS OCCURRED
AT CV.A ()
AT CV..ctor (HashTable A_0)
AT Ar.A (DI A_0)
AT ae.a (string [] A_0)
Obviously, the information contained in the above stack dumps is less than information contained from the procedure from an unflavish treatment. Good aspect is that you can use the mapping file generated during fuzzy processing to decode the stack track back to the original code. Bad aspect is that the message in the stack track is sometimes insufficient to explicitly retrieve the original symbol from the mapping file. For example, please note that the method returns the method in the dump. In applications with enhanced overloaded rendering algorithms, it may be renamed to the same name only if the method of returning type is different. Therefore, stack tracking may be arbitrary. In most cases, you can narrow the search range so you can get the original name. To get help, Dotfuscator Professional provides you with a tool to automatically convert the stack tracking back to the original way you like.
Back to top
summary
You can prevent hackers from using the ILDASM utility that is accessible to your application maliciously. You can protect the code with a fuzzy handler. Fuzzy treatment can effectively prevent reverse phase projects. Dotfuscator Community Edition provided in Visual Studio .NET 2003, you can make good fuzzy processing with just a few mouse.
Related article, see Inside Microsoft .NET IL Assembler by Serge Lidin (Microsoft Press, 2002) Dotfuscator FAQ For background information, see Ildasm.exe TutorialAnakrinohttp: //vexeddotnet.benamotz.comhttp: //www.preemptive.comGabriel Torok is President of Preemptive Solutions. He is with others with JavaScript Primer Plus and Java Primer Plus, both of which are published by Macmillan. Gabriel issued a speech at the development meeting around the world and taught the course.
Bill Leach is the Chief Technology Officer of Preemptive Solutions. He is the architect and technical supervisor of the Dotfuscator product line. BILL also serves as a software development book and articles of articles.
Go to the original English page
Back to top
