Does your code are safe?
(Green Apple Studios) June 13, 2001 01:10) Create great advantages to developers in the VS.NET environment, but exposes VB.NET to the desktop. In the Visual Studio.net framework, the compiler like VB, Visual C and C #, compile the source program into the Microsoft Intermediate Language (MSIL), which is further in this intermediate language before executing. Compile becoming a machine language. However, you may not fully understand what happened in VS.NET when you click the Build button? Or, when you load the IL code to the client, whether private code and information are safe? Let's go to the internal .NET framework work to show you what new content, and explain what problems should be paid attention to when you use MSIL under VB.NET. First of all, you should know. First, .NET is designed for client / servers and web applications. The software has been transferred to the Internet area and becomes a client / server-based application, so many applications now look more like a browser, not an old style interface. .NET will comply with this trend. Also note that if you want to protect your intellectual property rights, .NET does not apply to desktop applications because you cannot protect the code managed in MSIL on your desktop. This is very shocking! Although MSIL's goals are very good, the .NET framework and the public language runtime environment (CLR) are also stable, from a secure perspective, they are not practical or unable to work in a separate desktop application. . As a VB programmer, even a C # programmer, in .NET, in addition to this unprotected manageable code, you can't write other things. Due to this limitability, if you want to protect the code in the desktop application, you must write no managed C code. The only way to protect the intellectual property is: Package the code package in the unbearable C component, and use the COM shared interface in the .NET management code to call it. Unfortunately, this option is not effective for VB or C # programmers. You should also know that Active Server Pages.Net (ASP.NET) application is secure because they run on the server. This is .NET's paradise: running code is hidden on a protected server, there is no way to get the code. ASP.NET makes the development of the Web are simple, and Visual Basic.net (VB.NET) is a good tool for writing ASP.NET applications. Learning to VB.NET will become easy to get started, but .NET will experience a slow acceptance process as a whole. It is not easy to transition from VB6 to VB.NET. Before you, you need to support VB6 applications. MSIL is old, and it is also a new look. What happens when building a project file in VB.NET: Create a sample engineering file to generate code and assembly. Open vs.net, create a new Visual Basic engineering file, add a Label (label) control to your form, change its text attribute to "Good Byevisual Basic 6.0":
Note: You will write a Goodbye VB6 app, not a standard Hello World application. Before entering .NET, you need to know some rules and terms. First, the concept of IL is not fresh. The VB and C compilers have generated IL for many years, but no one publicly discusses, and no one records it. The only difference between the method of shipping the app with you is the code generated by the compiler. In addition to the name, the new MSIL and the VB6 compiler's IL is almost no different. Therefore, if you have used IL in the past, then you should prepare a new experience. Please see a MSIL fragment generated in your Goodbyevb6 application:
This code sets an 8-byte stack, then push the THIS pointer into the stack and call the GET_Label1 method. Then push the required label text into the stack and call the set_text method. When you run a compiler, generates a truly executable program that is not what we know today. It is called a assembly assembly (see Glossary). A assembly is a set of files configured as a single file. Today, we can use an executable as a compilation. More specifically, a compilation will be combined with all supported DLLs, images, resources, or helper files. Typically, a compilation contains at least two files: executable files and a list. A list of all files in the list assembly. The executable content in the assembly is referenced separately as a module. Conceptually, the module corresponds to DLLS or EXES, each module contains metadata, and there is a metadata assembled. The assembly format is the enhancement version of the current portable execution file (PE: Portable Executable) format. The standard PE header begins in the file. In the file, it is a CLR header, followed by loading the code to the data required for its program space, which is the metadata: metadata to the execution engine describes how to load the module. What file does it still need to load those Additional files and how to interact with COM and .NET runtime. Metadata also describes the methods, interfaces, and classes included in the module or assembly. The information provided by metadata allows the JIT compiler to compile and run the module. The metadata portion exposes something inside the application, making it easy to transform from the decomposed IL to the useful code. The core of configuring the .NET code is a problem with the management code: means the code written in order to run under the CLR control. You can create manageable code from VB.NET, C # or C , but C is the only language that can create no management code on the .NET platform. You can't create no management code with VB6 for .NET platform, because you ship in VB6 is a code that combines i386 instead of IL. When you use the manageable code, you can't shipment other than IL, just like VB.NET. Take a look at what benefits to using the new MSIL code. When you stay in the MSIL phase, you can install and run on any platform that supports the CLR. Now this may not be very significant for you, because the platform currently supports .NET is very small: only 32 windows. But it will soon increase, including 64-bit platforms and .net of Windows CE devices (PC). In the future, keep the code as MSIL to make you freely convert between these platforms and other new platforms. Another advantage of MSIL is that the JIT compiler converts MSIL to local code for the target machine. Therefore, the JIT compiler can utilize specific hardware and optimize the code for that particular platform. This is very convenient, for example, when optimizing the code of some registers or some OP-code with special processor hardware. Take a look at the Advanced Options button on the compilation tab in the VB6 project file attribute. Using metadata in assembly, the JIT compiler will know what code does and the platform support, so you can make optimized selection decisions, thereby enhancing the performance of the code. Another advantage of MSIL is: confirmation and check. Confirm is a series of tests you implemented on the module to ensure the consistency of metadata, MSIL code, and file format. Cipher that cannot pass this test may conflict with the execution engine or JIT compiler. Once the module is confirmed, the code is correct and ready to run. When the JIT compiler converts the code from MSIL to the local code, the code checks. The check includes checking metadata so that the program cannot be used without any permissions, or other resources. The verified code is also safe.
Even if the program is compiled directly from the local code, only the JIT compiler will perform this check to reach 100% accurate, because the results of the test depend on metadata from other assembly. If you compile the local code before shipping, you will face the risk of another compilation modification on the target machine, which will make your program "type unsafe" error. Using the JIT compiler to ensure that all relevant compilation of the current versions of all related compilation are considered. This process ensures that the running program is type secure, and it is running in the case of proper secure license. You can use the .NET SDK's Peverify tool to confirm and verify the code. The inversion project is very simple to ship the assembly as a MSIL rather than compiled code is security. Remember, assemble the list of all modules in the package, and metadata describe each module. The .NET SDK shifted a program named ILDASM, which is an IL reverse pollier that obtains module information and puts the formatted IL code and the metadata description of all application modules. Therefore, the reverse code becomes simpler:
.method private instance void LeavingMessage (class System.String & strText) il managed {// Code size 10 (0xa) .maxstack 8 // 000059: Private Sub LeavingMessage (ByRefstrText 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 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 has a usual counterattack for this issue: a real application is very large, so the stacked IL capacity will be very huge. Although this will stop some amateur, but what you really want to invoke your code, this is nothing. The real situation is this: the accumulation from iLDASM is much easier to read than the contrast of the compiled code. Interesteders can learn many things from IL accumulation in the application. According to Microsoft, if you want to keep your company's secret, you can put all modules containing company secrets on the protected server. If your program is a client / server application in an ASP.NET, it is very good. But if your app is a standard desktop program, this method is not too effective. So how should I protect intellectual property? The MSIL assembler document references the public parameters / Owner: ILASM ... / OWNERILASM ... / OWNER = FERGUS This option is encrypted with a password to prevent it from being disassembled. The problem is that Microsoft will cancel this option, because the first is that it is not very good. Therefore, in a desktop application written in VB with manageable C , C # or .Net Beta 1, you cannot protect intellectual property rights. But there is still hope. Before the final .NET candidate release, Microsoft may also introduce an Obfuscator that changes the MSIL's private method, making it unreadable to anyone except the CLR JIT compiler.
