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 way called LeavingMessage in the app,
The surface part is the code to call the LeavingMessage method. CLR puts the parameters into
Stack, execute call, and then restore 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 friends")
IL_002e: ldarg.0
IL_002F: LDSTR "Goodbye dear friends"
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 Try
} // 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.
