Coding a Custom Object with WSC - Protecting your intellectual property
(Page 5 of 5 )
Okay, so you’ve taken the time to write your own custom component and you’d like to begin distributing it, right? There’s just one small problem—you don’t want people jacking your code, do you? So let’s talk about how you can protect your code before you start passing it around.
If you’ve ever protected your script source in the past, you’re probably familiar with Microsoft’s Script Encoder tool. It’s a tool that can encode your script’s contents so that it can’t be read. It’s similar in nature to encryption, but it’s not done on a binary level, and the source file remains a simple text file. The scripting host is able to read and decipher this encoded script with no problem at all.
So you set out to use the Script Encoder, only to run into an error when you try to encode your WSC file. It’s not supported? It’s still just VBS code, there must be a way—and there is.
The problem is that the script encoder can not process XML files. (This same concept applies when trying to encode WSF jobs as well.) But there is a viable workaround. Since the code inside your WSC file will still be interpreted by the same scripting engine, all you need to do is encode your VBScript portion.
So go ahead and open up your WSC file and cut the actual script portion of your component (that’s everything between the <![CDATA[ and the ]]> ), paste it into Notepad or some other text editor, and save it with a .vbs extension. It doesn’t matter that the code won’t execute properly; it just needs to be saved in a format that the Script Encoder can understand.
Once your script is encoded, you will probably have a file that now has a .vbe extension. This is the executable VBScript Encoded file type. Open this file in Notepad and you should see one really long string of unreadable characters. This is your encoded script. Copy it from this file and paste it back into your original WSC file between the <![CDATA[ and the ]]> where the original script used to be. You should end up with something similar to this:
<script language="VBScript.Encode">
<![CDATA[
#@~^ZxYAAA==9b:~wE^V1m:@&fb:~1m:n@&Gk:,KlDt@&GrhP;W!xO@&9rsPG4NjtVs
]]>
</script>
Make certain that you copy the encoded file and paste it exactly as it was. Altering even one character will render it useless. Your editor may wrap the line on the screen, but the code should be one single continuous line.
Finally, you’ll need to got back to the <script> element and change the language attribute from VBScript to VBScript.Encode (or Jscript.Encode for Jscript). This change tells the scripting engine that it’s dealing with an encoded script.
That’s all there is to it. You now have all the tools you need to begin creating and distributing your own custom COM objects without the need for compiled code or expensive development environments. Have fun with this concept and see what you can come up with. Until next time, keep coding!
You can download a working example of this component here.
| DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware. |
