If you’ve been creating or are planning to create VBScript or JScript scripts to run under the Windows Script Host environment and then distribute those scripts to users on your network, you can save yourself time and frustration if you encode your scripts before you pass them on. Here’s why.
Windows Script Host scripts written in either VBScript or Jscript are simple ASCII text files. Anyone can open the scripts with Notepad and begin tinkering around. While most folks don’t intend to wreak havoc when they go exploring, it can happen. And whose job is it to fix scripts that no longer function correctly or destroy data? You guessed it; it’s you.
Microsoft has provided the Script Encoder tool, which allows you to encode your script files so that they appear to be compiled executables. It doesn’t provide the protection that encryption would, but it will prevent some people from viewing or modifying the code in the script, thus helping to thwart mischief. In this Daily Drill Down, I’ll explain how the Microsoft Script Encoder works and show you how to use it to encode your scripts.
What does encoded mean?
Before I go any further, it’s important that you understand the type of protection provided by the Script Encoder. To begin with, encoding and encrypting are different. Encrypting is a more secure form of protection than encoding.
The Script Encoder was originally designed to prevent script code that appeared in HTML files on the Web from being viewed. The goal was to protect the intellectual property of the script, thus preventing unscrupulous surfers from copying the script code, modifying it, and using it as their own. After all, it can take a lot of time and effort to develop an ingenious script. With this in mind, you can see that all the Script Encoder is really designed to do is mask the actual code to prevent it from being seen and copied, while still allowing it to perform its task.
Now, when it comes to protecting script files designed for the Windows Script Host, the goal is expanded a bit and the environment is different. In this case, the goal is not only to prevent users from seeing and modifying the code, but also to prevent them from wreaking havoc. What makes the environment different is that the script will actually exist in a location where the user can easily access it and open it.
When you use the Script Encoder to encode a file designed for the Windows Script Host environment, the encoded file is still an ASCII text file, but it doesn’t contain any intelligible text. This means that anyone can open the encoded script file in Notepad, but all they’ll see is a bunch of gibberish—much like they’d see if they were to open an executable file in Notepad.
The hope is that upon seeing this gibberish, the user will simply close Notepad and forget about the file. However, if they change just one character of the encoded text, they’ll render the script completely inoperable. If you attempt to run the script after a change has been made to the encoded text, you’ll receive an error message and the script won’t run.
While this will mean that you’ll still have to answer a call for assistance and then replace the script, there will be no chance of damage caused by the script.
It’s important to note that the encoding scheme employed by the Script Encoder won’t prevent a determined hacker from seeing what you’ve done and how. In fact, several sites on the Internet provide algorithms for cracking the Script Encoder. For example, the hacker site AstaLaVista.com has published an article titled Breaking the Windows Script Encoder.
Getting the Script Encoder
Before you can protect your scripts with the Script Encoder, you have to download and install it. Doing so is quite easy. To begin, just point your browser to the Microsoft Windows Script Technologies download site. Once you download the file, double-click on the self-extracting executable file and follow the online instructions.
When you complete the installation procedure, you’ll find a link on the Start menu that will load the Script Encoder’s Help file. You won’t find a link to the program because the Script Encoder is a command-line tool. I’ll show you how to invoke the Script Encoder in a moment.
Looking at the syntax
Since the Script Encoder is a command-line tool, it has several parameters that you can use when you invoke it. The Script Encoder’s executable file is Screnc.exe. The syntax for using the Script Encoder is:
SCRENC [/s] [/f] [/xl] [/l language] [/e ext] sourcedestination
Each of these parameters is described in Table A.
PARAMETER | DESCRIPTION |
/s | Enables silent mode, in which no messages are displayed |
/f | Allows the source file to be overwritten |
/xl | Excludes the language directive; for use in ASP files |
/l language | Specifies the default scripting language to use in encoding |
/e ext | Overrides the default file extension |
source | The name of the file to encode |
destination | The name of the encoded file |
Configuring Script Encoder for easy use
Since the Script Encoder is a command-line utility, to run it, you have to shell out to a Command Prompt in Windows NT or Windows 2000 or to a MS-DOS Prompt in Windows 9x/Me. You can also launch the Script Encoder from the Run dialog box.
When you install the Script Encoder, the installation procedure places the executable file Screnc.exe in the C:\Program Files\Windows Script Encoder folder. Having the executable file in this folder isn’t very useful since you either have to change to this folder in order to use it or drill down to it in your command line. Either way, it’s very inconvenient.
A better solution is to move the Script Encoder’s executable file—Screnc.exe—to a folder that’s in the system’s Path statement. For example, you might want to put it in the C:\WINNT folder in Windows NT or Windows 2000 or in the C:\Windows\Command folder in Windows 9x/Me. That way, you can easily run the Script Encoder from within any folder from both the command line and the Run dialog box.
Preparing script files for encoding
Using the Script Encoder is actually very easy. To begin, prepare your script file to be encoded by inserting a special code at the beginning of your script. If your script file is written in VBScript, then the code will be this line:
‘**Start Encode**
If your script file is written in JScript, the code will be this line:
//**Start Encode**
For example, suppose that you’ve written a small script file in VBScript called Today.vbs that uses the Now function to retrieve the current date and time and then displays that information via the MsgBox function, as shown here:
tn = Now
MsgBox tn
To prepare this file to be encoded, you’d add the special code to the beginning of your script file, as shown here:
‘**Start Encode**
tn = Now
MsgBox tn
Once you add the special code to the beginning of your script file and save it, you’re ready to encode it.
Encoding script files
When encoding files for use under the Windows Script Host environment, you’ll need to rename the file extension as a part of the process. For example, you’ll rename VBScript file extensions from .vbs to .vbe and JScript file extensions from .js to .jse. Both of these new file extensions are associated with their appropriate scripting engines and help to identify the file as being encoded.
For example, to encode the Today.vbs file, you’d access the command line, change to the folder containing the script file, and type this command:
Screnc Today.vbs Today.vbe
Once the new file is created, you can take a look at it. To do so, simply open the file in Notepad, as shown in Figure A.
Figure A |
When you open an encoded script file in Notepad, the code appears as gibberish. |
Working with Windows Script Files
If you’re using Windows Script Files instead of straight VBScript or JScript files for your scripts, you may be wondering if the Script Encoder can handle the Windows Script File format. The answer is no, it cannot.
However, you can distribute encoded scripts via Windows Script Files. To do so, you’ll create your standalone script files, using either VBScript or JScript, as you normally would. Once you have the scripting working the way you want it, use the instructions above to encode your script file.
Now, create your Windows Script File as you normally would. At the point in the Windows Script File when you’d put your VBScript or JScript code, you’ll include the encoded script file using this line:
<script language=”VBScript.Encode” src=”encodedfile.vbe“>
As you can see, the <script> tag is modified so that the language=”scriptlanguage” argument specifies that the script is an encoded file. Then, the src=”filename” argument specifies the name of the encoded file.
For example, to include the Today.vbe script in a Windows Script File, you’d use this line:
<script language=”VBScript.Encode” src=”Today.vbe“>
Conclusion
The Windows Script Encoder does a nice job of providing a deterrent to curious employees who want to meddle with your scripts. It’s simple to use and doesn’t require as much effort as encryption to deploy. Script encoding is not without its detractors. Some say it provides a false sense of security because it simply masks the code from users. However, while encoding your scripts is not a foolproof way to eliminate all unwanted intrusions, it does provide a layer of protection that will make it useful for many situations.