is Your Code Safe?
Vs. NET ' s with Microsoft intermediate Language creates big advantages, but exposes to vb.net on the desktop.
by Dan Fergus
Url:http://www.vbpj.com/upload/free/features/vbpj/2001/05may01/df0501/df0501-1.asp
In the Visual Studio.NET (vs.net) Framework, compilers such as VB, Visual C + +, and C # compile their source programs into M Icrosoft Intermediate Language (MSIL), which is subsequently Just-In-Time (JIT)-compiled into native machine code before E Xecution. But you might not know exactly what happens at vs.net when you click on the Build button, or whether your code and information are safe from prying eyes and tampering when your ship IL code to your customer. I ' ll step through the inner workings of the. NET Framework to show you what's new and explain what you concerns should E with MSIL under vb.net.
What you need:
vb.net Beta 1
You are need to be clear about several points. The. NET is designed for Client/server and Web apps. Software is moving to the Internet and to client/server-based applications, so many applications RS than the Old-style interface. . NET follows this trend.
Also Note this. NET isn ' t suitable for desktop applications if to care about protecting your intellectual property becaus E can ' t protect it in managed MSIL code on the desktop. This is a shocker to me. Although MSIL ' s premise are good and the. NET Framework and Common Language Runtime (CLR) are stable, they ' re just not feas Ible or workable in a standalone desktop application to security standpoint. As a VB programmer, or even a C # programmer, you have no way to write anything but this unprotected managed code in. NET.
Because of this limitation, your must write unmanaged C + + code if you are want to protect the code in your app. The only sure way to protect intellectual property:wrap the "code into" unmanaged C + + component and use the COM interope Rability interface to call it from. NET managed code. Unfortunately, this isn ' t a workable option for VB or C # programmers.
You are also should know that Active Server pages.net (asp.net) applications are safe because they run entirely on the server. This is the nirvana of-net-running code that "s buried away on a protected server far Sted in looking at your code. ASP.net makes Web development incredibly easy, and Visual Basic.NET (vb.net) are a good tool for writing asp.net.
VB.net has a steep learning curve, and. NET as a whole would experience slow. Migrating from VB6 to vb.net isn't easy, and you'll need to support VB6 applications for some time before porting. VB6 might now is the Microsoft stepchild, but many developers would use it for a long to come.
MSIL is old-but New
What happens when you are build a project by VB.NET:Create a sample project can use as for you generate code and ASSEMBLI Es. Open vs.net, create a new Visual Basic project, add a Label control to the form, and change it Text to "good Bye Visual Basic 6.0 "(Figure 1). Instead of the standard Hello World app, you ll write a GoodByeVB6 app.
Figure 1 | Create an App Under. NET.Click here.
You are need to know some boundaries and terms before into. NET. The idea of IL are nothing new. The VB and C + + compilers have generated IL for years, but no one discussed this publicly and no one documented it. The single biggest change from the way to the shipped applications in the past was in the code the compiler. The "other than" name, the new MSIL bears little resemblance to the IL of the VB6 compilers-so if I ' ve worked with IL in T He past, prepare yourself for a whole new experience. Look at a MSIL fragment generated from the GoodByeVB6 application (look Figure 2).
This code sets up a stack of eight bytes, then pushes the
ThisPointer onto the stack and calls the Get_label1 method. Then the code pushes the desired label text onto the stack and calls the Set_text method (the "Read the sidebar," IL, "for a more detailed explanation of the structure).
When you run the compiler, your generate a program that's not a true executable as we know it today. Instead, it ' s called an
Assembly(The Glossary sidebar). An assembly was a grouping of files deployed as a single file. In the Today's architecture, you might the a single executable as a assembly. More accurately, a assembly groups the executable file with any support DLLs, images, resources, or help files.
Figure 2 | Treading on Unsafe Ground. Click here.
An assembly almost always consists the at least two files:the
executableand the
Manifest. The manifest is a list of "All" files that exist inside the assembly. The executable content inside the assembly is referred to individually as a
Module. Conceptually, modules correspond to DLLs or exes; Each module contains metadata, in addition to the metadata of its parent assembly. The assembly format is a enhanced version of the current portable executable (PE) format.
The standard PE header comes at the beginning of the file. Inside the ' file is ' the CLR header, followed by the ' data required to load the ' code into its process space-referred to as
metadata(Figure 3). Metadata describes to the execution engine how the module should is loaded, what additional files it needs, how to load th OSE additional files, and how to interact with COM and the. NET Runtime. Metadata also describes the methods, interfaces, and classes contained in the module or assembly. The information the metadata provides allows the JIT compiler to compile and run the module. The metadata section exposes much of your application ' internals and eases the transition from disassembled IL to useful Code.
Figure 3 | of Modules and MetadataClick here.
At the heart. NET ' s code deployment is the issue of managed Code-code written exclusively to run under the CLR ' s control. Can create managed code from vb.net, C #, or C + +, but C + + is the "only language" can create
unManaged code on the. NET platform. Can ' t use VB6 to create unmanaged code for the. NET platform because your ship assembled i386 instruction code rather t Han IL code with VB6. You can ' t ship anything but IL code when you use the managed code, as you must with vb.net.
Now look at the benefits of using the new MSIL code. When you leave your code at the MSIL stage, you can install and run it in any platform that supports the CLR. This might isn't being a big deal to your now because the list of platforms that currently support. NET is short:only 32-bit Wi Ndows. But soon that list would include 64-bit platforms and. NET for Windows CE devices (Pocket PCs). The Leaving your code as MSIL allows to the "move seamlessly" to "and" to "and" other new platforms in the future.
Another advantage of msil:the JIT compiler converts the MSIL to native code on the target machine. So the JIT compiler can take advantage of the specific hardware and optimize the "code for" specific. This is comes in handy, for example, when optimizing the code for particular registers or op-codes on found certain That has a particular processor. Look on the Compile tab ' s Advanced optimizations button in VB6 ' s Project Properties. Using the metadata in the assembly, the JIT compiler knows what your code does and what the platform, supports Optimization decisions for your on the fly, and enhances your code performance.
Yet another benefit concerns the two v. Net:validation and verification. Validation is a series of tests with can perform on your module to ensure the metadata, MSIL code, and file format are cons Istent. Code that can ' t pass these tests might crash the execution engine or the JIT compilers. Once you validate your module, the ' Code is correct ' and ready to run.
The code is verified when the JIT compiler converts it from MSIL to native code. Verification involves checking the metadata to ascertain the program cannot access memory or other resources it doesn ' t ha ve permission for. Verified code is also type-safe. This check was done even if the program was compiled directly to native code, but it's not 100-percent accurate the J It compiler does it, because the test results depend on metadata to other assemblies. If you are compile to native code before shipping, run the risk of another assembly changing on the target machine, which 'll make your program type-unsafe.
Using the JIT compiler guarantees all related assemblies ' current versions are considered when the validation and Verifica tion are done. This is procedure ensures the running program would be type-safe and that it'll run with the correct security Permissio Ns. You can verify and validate your code yourself using the. NET SDK ' s PEVerify tool.
Reverse Engineering are easy
Perhaps the biggest concern with shipping your assembly as MSIL instead of compiled of-code is security. Remember, the assembly has a manifest of all package's modules, and the metadata describes each of the modules in Deta Il. 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 no easier to reverse engineer your code (in the Listing 1).
One common retort to this perceived problem:a real application are big and the volume of IL dumped would are overwhelming. This is might stop an amateur, but it won ' t bother someone the WHO really wants to crack code. The truth is this:the dump from ILDASM was 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 the Any module containing company secrets on a protected Server. That's fine if your program are an asp.net client/server application, but it doesn ' t work the If your is a STA Ndard desktop application. How does your protect intellectual property then? The MSIL assembler documentation cites a reference to the command-line parameter/
owner:
ILAsm .../ownerilasm .../owner=fergus
This option encrypts a assembly with a password to prevent it from being disassembled. The problem is's is-going to-remove this option, which didn ' t does a good job in the. So can ' t protect intellectual the 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 a obfuscator that alters your MSIL ' s priv Ate 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 the to a external library. Changing the names or hiding these are public calls would make it impossible for the CLR to the external functions. So a hacker can still and any slick tricks you with the calling to the system DLLs as he or she digs through your IL cod E (The sidebar, "Obfuscators Hide vulnerable Code").
You can use only one of the 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 fro The M your vb.net application using the interoperability mechanism provided for accessing to unmanaged code.
You can ' t jit-compile the code before shipping because all managed code must ship as MSIL. But can compile the code to assembly form while you install it on the target machine. This is sounds fine at a. The code on the install disk are still IL, however, so can extract it from the setup file manually and disassemble it s Eparately from the install. Once the image is installed on the user ' s disk, it's in assembly form rather than IL. In addition to security, this buys your a little speed when the application of runs because the JIT compiler doesn ' t need to C Ompile the IL code then.
Third-party vendors might hesitate
As a application vendor for the desktop applications, you know what your have to do. You can write unmanaged C + + and use the it from your managed VB code. You designed your application and feel safe because your know the code is good and won ' t corrupt process spaces it shouldn ' T corrupt. Although managed code is guaranteed to behave itself, your unmanaged the code is stable and reliable, and it ' s yours. However, if you "re a third-party vendor and choose unmanaged code over managed code in your components, you force consumer S to step back from the benefits of. NET and open themselves up to the same problems they now. Part of. NET ' s beauty is the ability to write managed code and know this doing so won ' t corrupt the memory used by the process SPAC E of your application and other applications. But without that knowledge, vendors might avoid writing controls in. NET managed code to restrict consumer access to the I L and potentially to algorithms their application uses.
I Love Vs.net, and vb.net in particular. The IDE ' s enhancements themselves provide enough of a reason to change to vb.net (the
VBPJ. NET article in). The language enhancements add to your programming tools, and the simple access to the underlying OS makes your Declare lif E easier. VB.net serves as a fine tool for creating secure asp.net applications. However, if your main target is a thick client or desktop application, your might want to investigate the issues before Pping code with vs.net. We'll be what Microsoft does to help developers the WHO program desktop applications.
