On the .NET platform, the code is run in the form of an intermediate language, which is the basis of a large advantage of .NET. But in stand-alone desktop applications, it brings a threat to the security of source code. This article explores the cause of this problem and analyzes possible solutions.
In the Visual Studio.NET (VS.NET) system, the compiler such as VB, Visual C , and C # compiles the source program into MSIL. MSIL, or Microsoft Intermediate Language, it is compiled as a machine language before execution (Just-in-Time Compile, JIT). However, you may have nothing to know more about when you click the Build button in VS, or if your private source code and information are safe in front of the voyeur, when you put the IL code to the customer if you guarantee The code is not tampered with. Below we will deeply go deep into .NET's internal work process, explore the characteristics of VB.NET system MSIL and some questions you have to care.
You have to figure out the following questions. First, .NET is designed for client / server systems and web applications. Software development is gradually developing to the Internet and client / server-based applications, many applications no longer have traditional interface interfaces, but providing interfaces with browsers. .NET also follows this trend.
Second, in desktop applications, we cannot protect the code in the form of managed MSIL, if you feel very important to protect intellectual property (ie, source code), then .NET is not suitable for desktop applications. Although MSIL's commitment is heart-moving, although .NET platform and CLR (Common language runtime are very stable, from a secure point of view, all of this lacks practical significance for an independent desktop application. In .NET, as a VB programmer or even C # programmer, you can only write management, unprotected code.
Due to this limit, if you want to protect the code in your desktop app, you must use non-managed C . The only truly effective way to protect intellectual property is: use non-managed C component package code, then call it through the COM collaboration interface from the .NET managed code.
You must also clearly, because Active Server Pages.Net (ASP.NET) is running all over the server, ASP.NET applications are safe. In fact, this is the ideal realm of .NET - run code on protected servers, so that the code is far from anyone who wants to study it. ASP.NET simplifies web development to an unbelievable level, and Visual Basic.net is a good tool for writing ASP.NET applications.
Master VB.NET needs to learn hardships, and comprehensive acceptance .NET is a slow process. Migrating from VB6 to VB.NET is not easy, you still need to provide support for VB6 applications in time before the VB6 app is ported to VB.NET. Many developers will still use VB6 in a long time in the future.
Second, intermediate language In order to understand what happened during the process of constructor with VB.NET construction, we need to create an example of generating code and assembly: Open vs.net, create a new Visual Basic engineering, in the form Add a text tag (Label), then change the text attribute of the text tag to "Good Bye Visual Basic 6.0" (Figure 1), named this app as Goodbyevb6.
Figure 1 Before you go deep into the .NET system, we need to know some marginal knowledge and terminology about .NET. First, IL (intermediate language) is not a new concept, VB, C compiler generation and use IL already has a few years of history, but few people disclose it or write documents for it. One of the largest changes in .NET is the code generated by the compiler. In addition to the name, the new MSIL and the VB6 compiler have very little class. Therefore, if you have been in contact with IL before, you have to learn from the beginning. See Figure 2, which is a MSIL code snippet app for Goodbyevb6: Figure 2 This code snippet sets an 8-byte stack, then put the THIS pointer stack, call the GET_Label1 method. Next, the code presses the label text to be set into the stack and then calls the setText method.
Traditional CPUs use registers and stacks to complete all work. The execution engine provided by the CLR has only one stack, and its operation is very similar to a reverse polish representation calculator. If a process call has multiple parameters, the execution engine will put the parameter stack before sending a call. The return value of the function call is also passed through the stack.
The local variables in MSIL are easy to identify, they use .locals keyword statement. If the symbol exists, you will see the variable name; otherwise, you will see the variables such as V_1, v_2:
.locals init32 x, [1] int32 y, [2] float64 z, [3] class system.string vb_t_string_0)
The LDARG instruction puts the parameter into the stack, the LDC instruction puts the digital constant into the stack, and the STLOC instruction saves the value to the appropriate local variable:
// 000064: DIM X as integer = 100 IL_0001: ldc.i4.s 100 IL_0003: STLOC.0
In this example, the constant 100 is pressed into the stack as a 4-byte integer, and then this value is saved to the first partial variable. For a complete description of the MSIL directive, see the ilinstrset.doc file for the IL programmer reference.
All MSIL outputs in this article are based on the debug version of Goodbyevb6. Non-debugging versions do not bring a line and variable name, but still provide a large amount of useful information. When viewing MSIL code, the debug symbol is important, but it is not essential.
When we run a compiler, it is not the executive file we are familiar with today, but an assembly (Assembly). The assembly is a collection of files, and the files in the program set can be deployed as a single whole. In the current Windows system, we can see a single executive file as an assembly. But from a stricter sense, the assembly aggregates the execution file and all its support files, including DLL, graphics, resources, and help files.
In general, an assembly consists of at least two files: execution section, manifest (English word origin: cargo list, passenger list). Manifest is a list of all files in the program collection. The executable portion in the program set is also referred to as a module. Conceptually, the module corresponds to a DLL or EXE file; each module contains metadata in addition to the metadata included in the parent assembly. The assembly is a enhancement version of the currently portable executable, PE.
As shown in Figure 3, the beginning of the file is a standard PE header. The inside of the file contains the CLR header, and the CLR header is the description data necessary to load the code in the process space - ie metadata. Metadata provides a lot of information for the execution engine, including: how to load the module, which support files, how to load support files, how to interact with COM and .NET runtime environment. In addition, metadata also describes the methods, interfaces, and classes included in the module or assembly. The information provided by metadata makes the JIT compiler to compile and run the module. At the same time, metadata exposes a large amount of internal information about the application, making it more convenient to obtain valuable code from the disassembled IL. Figure 3 Core problem with .NET code is being managed. The managed code is a code written specifically under the CLR control, which can be created in languages such as VB.NET, C #, and C , but C is the only language that can create .NET platform is not managed by management. We can't create non-managed code with VB6 for .NET platform, because we compile code into i386 instead of IL code in VB6. Just as using VB.NET, if you want to use the managed code, you can only compile the code into IL.
Now let's take a look at what is the advantage of using this new MSIL code. If the code is compiled into MSIL, we can install and run this code on any platform that supports the CLR. As far as it is, this may not be very attractive, because the platform currently supports .NET is very small: only 32-bit Windows. But soon, 64-bit platforms and .NET for Windows CE will provide this support. Compiling code into MSIL format allows us to seamlessly transplant application to all of these platforms and future new platforms.
Another advantage of MSIL is that the JIT compiler compiles the MSIL code into machine instructions on the target machine installed, which can optimize the code according to the specific situation of the target machine. This is useful, for example, it can optimize code for special registers of the target machine, or optimize operation code for hardware devices with special processors on the target machine. Please click on the VB6 Engineering Properties window Compile tab to learn more. Due to the metadata in the program, the JIT compiler knows what the code is doing and which platform it supports, so that it can quickly optimize the decision, improve the performance performance of the code.
Another advantage involves two Validation .NET, Validation, Verification. The inspection is a series of checks for modules to ensure metadata, MSIL code, and file format. The code that cannot pass these inspections may cause the execution engine or the JIT compiler to crash. Once the module passes the test, the code is correct and can start running.
The JIT compiler converts the MSIL code to the machine code, which is checked for the code, which is a dial data to ensure that the program does not access the memory or other resource that does not have the corresponding license. The verified code is the type of security (type-way) code. This verification is also done even when the program is directly compiled into a machine code, unless verified by the JIT compiler, this verification is not 100% accurate, because the verification results depend on the metadata from other assemblies . If the source program is directly compiled into machine code, we face a risk: changes in the target machine, causing the program no longer type security.
Using the JIT compiler to ensure that the inspection and verification is performed on the current version of all related assemblies. These operations ensure that the executor is always type security, and the program always operates at a safe license. You can use the .NET SDK's Peverify tool to inspect and verify the code itself.
Third, the reverse project When the assembly is published in the form of MSIL instead of machine code, the most concerned issue should be safe. As mentioned earlier, the assembly contains Manifest on all modules in the package and describes metadata of each module in detail. The .NET SDK provides a tool named ILDASM, which is an IL disassembler that can reverse the IL code from the module and the metadata description of each module in the application. As can be seen from Listing 1, it is extremely convenient to implement reverse projects for code using ILDASM. [Listing 1] The following is part of the IL disassembler ILDASM output. It shows a private method called LeavingMessage in the application, and the rear section is the code to call the LeavingMessage method. CLR puts the parameter into the stack, performs the call, and then recover the stack to prepare for the next operation.
.method private instance void LeavingMessage (class System.String & strText) il managed {// Code size 10 (0xa) .maxstack 8 // 000059: Private Sub LeavingMessage (ByRef strText As String) IL_0000: nop .line 60 // 000060: debug.Write (strText) IL_0001: ldarg.1 IL_0002: ldind.ref IL_0003: call void [System] System.Diagnostics.Debug :: Write (class System.String) .line 61 // 000061: End Sub IL_0008: nop IL_0009 : Ret} // end of method form1 :: LeavingMessage
Code to Call LeavingMessage Sub
finally {IL_002d: nop .line 73 // 000073: LeavingMessage ( "Goodbye Dear Friend") IL_002e: ldarg.0 IL_002f: ldstr "Goodbye Dear Friend" IL_0034: stloc.3 IL_0035: ldloca.s _Vb_t_string_0 IL_0037: callvirt instance void GoodbyeVB6 .Form1 :: leavingmessage (class system.string &) il_003c: endfinally.Line 74 @ 000074: end} // end handler
People have realized this problem, a common refutes are: In reality, the application is large, and the scale of IL disassembly output will exceed the limits that can endure. However, it may make a hobby from a hobby, but you can't stop a person who is interested in code. The actual situation is: Compared to the anti-assembly results of the machine code, ILDASM's disassembly results should be readily read more, any organization that is interested in this can learn about the information from IL disassembly results.
According to Microsoft's opinions, we must ensure that corporate confidential security, we should put all modules containing enterprise confidentiality on protected servers. This is no problem with ASP.NET client / server applications, but for standard desktop applications. So how can I protect intellectual property? MSIL assembler documentation refers to a command line parameter / Owner:
ILASM ... / OWNER ILASM ... / OWNER = FERGUS
This option encrypts the code with a password to prevent the code from being disassembled. The problem is that Microsoft is ready to cancel this option because it doesn't look a good way. In this way, it is very difficult to protect intellectual property rights for desktop applications written with managed C , C # or VB. Net Beta 1. But hope is still existed. Before the .NET finally released, Microsoft may provide a blurred device program that modifies the private method of MSIL, making no one outside of the CLR JIT compiler can read these private methods. However, it does not hide the public (global) method of the application and the call to the external library, because: If the name of the global call or hides these calls, the CLR will no longer be linked to an external function. Therefore, the hackers are still able to find various information of the application calling system DLL by viewing IL code. This way, now we can only use one way to protect the intellectual property of the desktop application, using non-managed C to write critical code, then access it from VB.NET to access the interactive mechanism provided by the non-administrative code. Of course, this may be more difficult for VB developers.
Since all managed code must be released in MSIL, JIT compilation cannot be performed before the release. However, when installing applications on the target machine, we can compile the code into compilation form. It seems very good from the surface, but the code is still in the installation disc, we can manually extract the code from the installation disk, but separate them. Since the application is completed, it exists in the form of compiling code rather than IL. In addition to security, it can also increase the speed of the application, because we no longer need JIT compiler to compile IL code.
Fourth, conclude if you are a desktop app provider, you know what you should do. You can write code with non-managed C and then call it from managed VB. Design application with this method, you can confirm the security of the code. However, if you are a third-party vendor, and prepare to replace the managed code with non-managed code in the component, you are to force users to give up .NET advantage, let them face them today The problem. Managed code prevents destructive operations from memory spaces used by the application itself or other applications, and is one of the reasons for the support of managed code. Some users may view the IL programs of the managed code, and even possible to analyze the application's algorithm implementation. If you don't correctly understand the advantage of .NET, third-party suppliers may refuse to use managed Code writes a variety of software components.
Vb.net/vs.net has many advantages, just the reason for the IDE (integrated development environment) is enough to be our reason for us to upgrade to VB.NET; linguistic enhancement brings us a lot of new programming support, for the bottom The simplification of the OS access makes our declaring variables, objects, and call low-level functions more convenient. VB.NET is an excellent tool for creating security ASP.NET applications; however, if your primary goals are concentrated in the client or desktop applications, you should carefully consider the possible problems. What help is Microsoft to provide desktop app developers? We will wait and see.
