Reverse Engineering is Easy
Perhaps the single biggest concern with shipping your assembly as MSIL instead of compiled code is security. Remember, the assembly has a manifest of all the package's modules, and the metadata describes each of the modules in detail. The .NET SDK ships with a program called ILDASM, an IL disassembler that takes the module and dumps well-formatted IL code and metadata descriptions for all your application's modules. It can't get any easier to reverse engineer your code (see Listing 1).
One common retort to this perceived problem: A real application is big and the volume of IL dumped would be overwhelming. This might stop an amateur, but it won't bother someone who really wants to crack your code. The truth is this: The dump from ILDASM is much easier to read than the dump from a disassembly of compiled code. An interested party can learn a lot about your application from the IL dump.
Keep your company secrets secret, according to Microsoft, by putting any module containing company secrets on a protected server. That's fine if your program is an ASP.NET client/server application, but it doesn't work well if your application is a standard desktop application. How do you protect intellectual property then? The MSIL Assembler documentation cites a reference to the command-line parameter /owner:
ilasm ... /ownerilasm ... /owner=fergus
This option encrypts an assembly with a password to prevent it from being disassembled. The problem is that Microsoft is going to remove this option, which didn't do a good job in the first place. So you can't protect intellectual property in your desktop applications written with managed C++, C#, or VB code for .NET beta 1.
But there's hope. Before the final .NET release candidate is completed, Microsoft might introduce an obfuscator that alters your MSIL's private methods to make them unreadable to anyone except the CLR JIT compiler. However, this won't hide your application's public methods or calls it must make to an external library. Changing the names or hiding these public calls would make it impossible for the CLR to link to the external functions. So a hacker can still see any slick tricks you use when calling to the system DLLs when he or she digs through your IL code (see the sidebar, "Obfuscators Hide Vulnerable Code").
You can use only one method now to protect your intellectual property on a desktop application. As a VB developer, you might find this difficult, but you must write your critical code in unmanaged C++ and access it from your VB.NET application using the interoperability mechanism provided for accessing unmanaged code.
You can't JIT-compile the code before shipping because all managed code must ship as MSIL. But you can compile the code to assembly form when you install it on the target machine. This sounds fine at first. The code on the install disk is still IL, however, so you can extract it fr
相关文章
 我来说两句 |
对此文章发表了评论 |
评论列表 （最新 评论仅限网友观点！）
推荐文章
