En-CODE With FSO

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.

<package>
<comment>
EncodeWSF.wsf
This script encodes a .WSF script
</comment>
   <job>
      <runtime>
         <description>

         This script encodes a .WSF script
         </description>

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

         <named
         <name="
Target"
         helpstring="
path and filename of script to encode"          type="string"
         required="true"

         />
      </runtime>

      <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
      strSourceFile=WScript.Arguments.Named.Item(“Target”)
      Set objStream=objFSO.OpenTextFile(strSourceFile)
      strSource=objStream.ReadAll
      objStream.Close

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

      </script>
   </job>
</package>

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.

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

Featured

  • Close Up Dollar Bill Graphic

    Price Increases Coming to Power BI, Microsoft Teams Phone

    Microsoft is preparing to implement the first price increases for two standalone products: Power BI and Microsoft Teams Phone.

  • Dynamics 365 Getting Data Security Boost from Druva

    Druva is working to extend its SaaS-based data security platform to support Microsoft's Dynamics 365 Sales and Dynamics 365 Customer Service products.

  • Image of a futuristic maze

    The 2024 Microsoft Product Roadmap

    Everything Microsoft partners and IT pros need to know about major Microsoft product milestones this year.

  • Microsoft Offers Monthly Billing for Annual Cloud Subscriptions

    Microsoft described a new monthly billing option for customers that have signed annual contracts for services like Microsoft 365, Windows 365, Power Platform and others.