Writing Binary Data in WSH

It’s been said over and over again that VBScript does not support the creation of binary files. There also aren’t any objects available to WSH that provide that support. In fact, Microsoft will swear that it’s true. If you don’t believe me, just read their documentation. In light of that defining argument, today I’ll be showing you not one, but two ways to do the impossible.

Writing Binary Data to Files

The ability to write binary files directly was never provided in VBScript.  The powers that were decided that the functionality wasn’t necessary in Visual Basic’s Scripting Edition and that it would be too complicated to code it in, so it never was.  I stumbled upon a workaround quite some time ago; you may have seen it in action in my article Compressed Folders in WSH.

The concept is quite simple.  I learned to exploit the ADODB.Stream object that is used for creating Stream objects.  The ADODB.Stream can create both text streams and binary streams.  This worked out pretty conveniently, but it did require a bit of a workaround, as you’ll see soon.  VBScript doesn’t have built-in binary processing support, so it does not provide a way to create a true byte array.  But enough about that for now, let’s take a look at the code.

strPath  = "C:Zip.zip"

 

Const adTypeBinary = 1

Const adTypeText = 2

Const adWriteChar = 0

Const adSaveCreateNotExist = 1

Const adSaveCreateOverwrite = 2

 

With CreateObject("ADODB.Stream")

   .Open

   .Type = adTypeText

   .WriteText ChrB(&h50) & ChrB(&h4B) & ChrB(&h5) & ChrB(&h6)

   For i = 1 To 18

       .WriteText ChrB(&h0)

   Next

   .SaveToFile strPath, adSaveCreateNotExist

   .Close

   .Open

   .Type = adTypeBinary

   .LoadFromFile strPath

   .Position = 2

   arrBytes = .Read

   .Position = 0

   .SetEOS

   .Write arrBytes

   .SaveToFile strPath, adSaveCreateOverwrite

   .Close

End With

This code sample will write binary data directly to a file.  The result is a Compressed Folder.

{mospagebreak title=ADODB.Stream for writing binary files}

In order to make this work, I first had to determine what a compressed folder looked like in binary.  To do that I opened an empty compressed folder with a hex editor.  As it turns out, the file is nothing more than a string of twenty-two bytes as follows.

50 4B 05 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Binary data is typically written in hexadecimal representation, which consists of two digits ranging from 0 to F.  Hexadecimal is a base-16 number system, so each place can have one of sixteen different values.  The numbers 0 through 9 are used for the first 10 and then the letters A through F are used for the remaining 6 digits to avoid confusion.  In any case, what’s important here is that a byte is two hexadecimal digits.

With CreateObject("ADODB.Stream")

   .Open

   .Type = adTypeText

   .WriteText ChrB(&h50) & ChrB(&h4B) & ChrB(&h5) & ChrB(&h6)

   For i = 1 To 18

       .WriteText ChrB(&h0)

   Next

   .SaveToFile strPath, adSaveCreateNotExist

   .Close

The script begins by creating an ADO Stream object and setting its type as text.  The reason is that the binary type will only accept a true binary array.  This is a special data structure used for manipulating binary files that is not available in VBScript.

Once the stream is opened, we begin writing the binary characters to the stream as you saw earlier.  I’m simply supplying each of them in hex notation and using the ChrB function to write a binary character.  Characters are written one after another as if we were writing to a standard text stream object.

{mospagebreak title=Fixing the file contents}

All is well and good.  The stream can be saved to a file and then closed.  However, if you try to open the newly-created zip file, Windows will politely inform you that the file is corrupt.  When you examine the newly-created file in your trusty hex editor, you will soon see why. The ADO Stream object inserts two unwanted characters at the beginning of the file before we begin writing our characters.  That’s no good!  Since the ADO Stream object is the only thing we have available capable of reading binary input, we have to go back to it to fix the problem.

   .Open

   .Type = adTypeBinary

   .LoadFromFile strPath

This time we open a new stream but we open it in binary mode.  Reading a stream in binary mode will read the file contents into a true binary array.  We don’t have any way of manipulating a binary array, but that’s okay.  At least we have the binary data to work with.  The ADO Stream now contains the binary contents of our zip file.

   .Position = 2

   arrBytes = .Read

   .Position = 0

   .SetEOS

   .Write arrBytes

   .SaveToFile strPath, adSaveCreateOverwrite

   .Close

End With

This piece of code is where the magic happens.  The stream object is kind of similar to a recordset.  We can read it one character at a type from beginning to end, and a marker keeps track of where we are.  So by manually setting that marker position to 2, we can avoid reading the two unwanted characters at the beginning of our binary stream.

Once the binary data has been read, we can set the cursor position back to 0, or the beginning of the stream.  The SetEOS method is then used to set the End Of Stream marker to the current cursor position.  This effectively empties the contents of the stream object.  Now we can write the cleaned-up binary back to the file.

{mospagebreak title=Writing binary files with FSO}

I used the ADODB.Stream method of creating binary files for quite some time before stumbling across this method.  It works effectively, but I wasn’t happy about writing every file twice to get the job done.  The ADODB Stream object isn’t particularly inefficient, it just seemed as though I was doing twice as much work as I really should have had to.  Enter the FileSystemObject.

The FileSystemObject is not designed to work with binary files.  It’s doesn’t provide any binary support at all, as a matter of fact—and only one method of creating a file.  Let’s look at the solution.

With CreateObject("Scripting.FileSystemObject").OpenTextFile(strPath, 2, True)

   For x = 1 To 44 Step 2

       .Write Chr(Clng("&h" & Mid("504B0506" & String(36, "0"),x,2)))

   Next

   .Close

End With

The code really isn’t all that difficult.  The secret is in the use of the OpenTextFile method.  The first and second parameters instruct the FileSystemObject to open a text file For Writing.  The optional third parameter is a Boolean value that tells the FileSystemObject if the file should be created if it doesn’t exist, and that works perfectly for us.

When the FileSystemObject creates a file, it creates a completely empty file.  We can write our binary data directly to it without any problems.  We just need to determine how to do that.

I’ve wrapped this code in a For Next loop to simplify it a bit.  The secret is in the functions I’m using inside of that loop.  I’m starting with my binary information in a string.  I move through the string, grabbing those characters two at a time. (Each byte has two hex characters).

I then add a “&h” in front of those two characters.  That’s VBScript’s way of denoting a hexadecimal value.  Next, we exploit VBScript’s lack of strict data types.  Because this string looks like a hexadecimal number, VBS has no qualms when we instruct it to read the string value as a number with the Clng() function.  The Clng function converts a value into a numeric value of type Long.  This data type is wide enough to house our extremely large decimal values without losing any information.

We have to convert these hex values into decimal values because the Chr function only accepts decimal numbers.  As you may recall, it takes a decimal number and returns the ASCII character represented by that decimal.  It doesn’t care if the character is actually a non-printable character.  That allows use of the  FileSystemObject object to write the characters directly to the file without any problems.  Closing the File object saves the newly-written binary data exactly the way we intended.

There you have it.  Two exploits for writing binary data to files with a language that doesn’t support it, in an environment that won’t allow it.  Beware when using file streams, as is it very easy to run into memory issues if you attempt to read or write files that are too large.  It’s best to take them in chunks rather than attempting the file as a whole.  I hope you have fun with this one.  Until next time, keep coding!

[gp-comments width="770" linklove="off" ]