En-CODE With FSO
When it comes to encoding your scripts, forget about the command line.
- By Chris Brooke
Last month, I shared instructions for encoding your scripts with the
use of the Windows Script Encoder. As I wrote in that column, encoding
is primarily designed to ensure code integrity. When you deploy an encoded
script to a client machine, it will do exactly what you programmed. Along
the way, it’ll also prevent the casual observer from being able to read
As it was the assigned homework, this month I’m going to look at an alternative
method for encoding scripts. This method is invoked via script code and
utilizes the FileSys-temObject (FSO) instead of the command-line uti-lity,“screnc.”
Have no fear of compatibility issues, my friends. Both the FSO and the
command-line script encoder use the same encryption engine—they just go
about it in different ways.
This script encodes a .WSF script
encodes a .WSF script
/Target: [path and
filename of script]
and filename of script to encode" type="string"
Dim strSource, strDest, strSourceFile,
get the file and read it into a buffer
encode it and write it to the encoded file
strSource, 0, 0)
“e” & objFile.Name
I admit it. Technically, I’m not using the FSO to perform this encoding.
I’m actually using the Encoder object. Both of these objects are
packaged as part of the scripting runtime. In fact, virtually every object
we normally think of as part of the FSO—from drives to folders to
files—is packaged as a separate object within the scripting runtime.
Now, many of these objects can only be instantiated by executing a method
from the FSO itself. As a result of this dependency, the scripting runtime
itself is generally referred to as the “FileSystemObject.”
Ironically, the Encoder object can be instantiated separately—and
that’s just what I did.
The first thing you may notice is that, in addition to the standard runtime
tags, there are two object tags: one for the FSO and one for the Encoder.
The rest of the objects used in the script are created by the FSO. They
objFile—This object gets the file information for the source script file.
It provides the information needed to create the file name and saves it
in the same directory.
objStream—This TextStream object allows you to read the entire script
file into a string variable, which is required by the EncodeScriptFile
objEncFile—This TextStream object allows you to write the encoded text
into a new file.
The interface of the Encoder object consists of only one method: EncodeScriptFile.
All relevant data must be passed as arguments when this method is called.
These arguments are:
File extension—In this case, I must use the .sct file extension
to tell the encoder that this is a scriptlet.u Text to encode—This
argument must be a string. I can’t simply pass a file name here.
The source script file must be read into a buffer (a string variable)
to be encoded.
Flags—This argument is passed as a Long Integer and can specify
any optional settings, such as those set using the command-line switches.
Default language—This corresponds to the “/l” switch
of screnc. It specifies the default language (VBScript or JScript) to
use during encoding. This is only necessary when the language is not set
in the <script> element.
While it’s true that using the script encoder object
to encode a script does have a few extra steps, there are occasions when
doing so will really save time.
Because you’re already working with the FSO and you’ll have
to rely quite heavily on it to accomplish the above task of encoding an
entire directory of scripts, that will be your homework. In the process,
I’ll wrap up my exploration into the FSO, and you’ll have
a gem of a script for your toolkit.
Chris Brooke, MCSE, is a contributing editor for Redmond magazine and director of enterprise technology for ComponentSource. He specializes in development, integration services and network/Internet administration. Send questions or your favorite scripts to [email protected].