Mr. Script


When it comes to encoding your scripts, forget about the command line.

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 your code.

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

         This script encodes a .WSF script

         C:\cscript encodewsf.wsf /Target: [path and
         filename of script]

path and filename of script to encode"          type="string"


      <object id="objFSO" progid="Scripting.FileSystemObject"/>
      <object id="objEncode" progid="Scripting.Encoder"/>

      <script language="VBScript">
      Dim objFile, objStream, objEncFile
      Dim strSource, strDest, strSourceFile, strNewFile

      'First, get the file and read it into a buffer
      Set objStream=objFSO.OpenTextFile(strSourceFile)

      'Now, encode it and write it to the encoded file
      strSource, 0, 0)
      Set objFile=objFSO.GetFile(strSourceFile)
      strNewFile=objFile.ParentFolder & “e” & objFile.Name
      Set objEncFile=objFSO.CreateTextFile(strNewFile)
      objEncFile.Write strDest


Objective Thinking
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.

FSO-created Objects
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 are:

 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 method.

 objEncFile—This TextStream object allows you to write the encoded text into a new file.

Encode Arguments
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.

About the Author

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].

comments powered by Disqus
Most   Popular