2007-08-24 12:57:11

Fooify your VBScript

As any system administrator knows, due to the Windows Scripting Host (WSH), VBScript is a native language to Windows machines. By native, I mean that you can execute the file without running it through a compiler, as WSH does that on the fly at runtime.
So what do you do if you need to write a script to perform a task that requires alternate credentials? You can't just put the username and password in the script because anyone can open it in notepad and see everything. Or can you? Enter the Windows Script Encoder (download).
This program will take your VBScript and encode it, making it incomprehensible by the naked eye. Why did I say it like that? Because your script isn't being encrypted, it's only being encoded. What's the difference? If the script was encrypted, unless you had the decrypting key there is [almost] no way to convert it back to the original text. But since this only encodes, it is possible to figure out how it was encoded and decode it. So this is, basically, a "security through obscurity" step, and "security through obscurity" steps should not be your only line of defense as they are NEVER enough.
But as long as you're not putting the username and password with the keys to the kingdom into your VBScript, this may be a valid option. Here's how it works.
After you write your script, let's call it script-before.vbs, you will run it through the Windows Script Encoder:
Picking that command apart, the first switch/argument pair is to tell it what language your script is in (the encoder can handle multiple languages). The second switch/argument pair is to tell the encoder what the default extension of your script it, in our case, vbs. Then we specify the source file followed by the destination file. Notice that the extension for the destination file is "vbe", meaning VBScript Encoded.
Once you have your encoded script, it's time to execute it. I always (except when I want to pwn myself) run vbscripts through cscript on the command prompt instead of double clicking the icon, which will invoke wscript. The main difference, any output from your script will appear in dialog boxes (popup windows) when invoked through wscript, whereas with cscript it just appears as text in your already open command prompt window. So back to executing the script... there are two ways. First, you can rely on cscript to figure out that your script is encoded and know what to do with it:
Or, what I recommend, is to force cscript to read the file as if it were encoded.
As a programmer, writing polymorphic code (code that can figure out what to do and change how it runs to accommodate whatever it encounters) is a good thing to do because you don't want the user of your program to have to know how it works, just that it does indeed work. But if the programmer gives you a way to specifically tell the program how to act, you should ALWAYS do that. That way, there is less of a chance for things to go wrong.
So that pretty much wraps up this little tutorial in encoding vbscripts. Let me just reiterate that any information you put in an encoded vbscript can be decoded, so be careful. Script encoding should be just one of many steps in your security plan.

Back

Post a comment!

Name:
Comment: