Script Encoding with the Microsoft Script Engine Version 5.0
Andrew Clinick

Tired of exposing your Web scripting code to prying eyes? With version 5.0 of the Microsoft Script Engine and Internet Explorer 5.0, you can now encode your VBScript and JScript work so curious users can't grab it. Scripting has become a very popular component for people developing for the Internet or intranet. This popularity has been accelerated not only by its dynamic development environment and the ubiquity of script support in browsers and servers, but also the ability to see what programming tricks others have employed simply by loading a page into Notepad. While this is a great asset for the beginning script programmer, people who are developing increasingly complex, script-based applications want to be able to protect their hard work. Version 5.0 of the Microsoft® Windows Script engines introduces a new feature, Script Encoding, that takes the first step toward protecting script from prying eyes.

    The goal of Script Encoding is four-pronged: to provide an encoding mechanism that can be implemented without significantly affecting performance, exported without regulatory headaches, embedded within HTML and any application that uses scripting, and implemented cross-platform.

    Now let's see how these requirements affected the design of the Microsoft script engines. The first and perhaps most important consideration is that the script is encoded, not encrypted. Encoding means that the script is passed through a text-encoding cipher, which replaces the original text. Therefore, the encoded script could be decoded by any program that can decipher the text cipher, without the need for an encryption key. Encoding was introduced not to provide a watertight protection mechanism for scripts (Microsoft is working on that for the future), but to provide a format that would require a prospective pirate to go through a specific decoding process to get your script code. If you have a copyright statement in your code (more on that later), it'll be far easier to show that your work was illegally copied.


How Does Encoding Work?

      All Microsoft (and many third-party) applications that use VBScript or JScript® employ the ActiveX® scripting interfaces (see Figure 1). These interfaces allow applications to integrate compatible script engines with a minimum of effort. This flexible mechanism for integrating script engines is also used without modification by Microsoft® Internet Explorer and Microsoft Internet Information Services.



      Figure 1: Script Encoding Architecture  


      Version 5.0 introduces a feature that lets script engines read encoded script, so any application that uses VBScript and JScript can use the encoding feature. The encoding features of the script engines are enabled when you set the language name to VBScript.Encode or JScript.Encode. The .Encode suffix on the language name means that the same script engine is used, but its ability to interpret encoded scripts is turned on and its debugging features are turned off. This is meant to ensure that people don't load up the script debugger and take a look at your code.

    Setting an engine to deal with encoded script is only one side of the equation. How do you encode your script? There are two mechanisms to do this: a command-line script encoder and a COM-based object model that lets you build encoding into your application. Since most of your script will probably be included in HTML and Active Server Pages (ASP), I'll cov