The Microsoft Script Encoder uses the following syntax:
SCRENC \[/s\] \[/f\] \[/xl\] \[/l defLanguage \] \[/e defExtension\] inputfile outputfileWhere:
/s is an optional switch that specifies that the script encoder is to work silently.
/f is an optional switch that specifies that the input file is to be overwritten by the output file, destroying the original source file.
/xl is an optional switch that specifies that the <@language> directive is not added at the top of .asp files.
/l defLanguage is an optional switch that specifies the default scripting language (JScript or VBScript) to use during encoding. Script blocks within the file being encoded that do not contain a language attribute are assumed to be of this specified language. If omitted, JScript is the default language for HTML pages and scriptlets, while VBScript is the default for ASP. For plain text files, the file extension (either .js or .vbs) determines the default scripting language.
/e defExtension is an optional switch that associates the input file with a specific file type. Use this switch when the input file's extension doesn't make the file type obvious. Recognized file extensions are .asa, .asp, .cdx, .htm, .html, .js, .sct, and .vbs.
inputfile is the name of the input file to be encoded, including any necessary path information relative to the current directory.
outputfile is the name of the output file to be produced, including any necessary path information relative to the current directory.
Example:If c:\temp\netbiosdomain.vbs contains:
dim WshNetwork, strDomainName Set WshNetwork = WScript.CreateObject("WScript.Network") strDomainName = WshNetwork.UserDomain Wscript.Echo WshNetwork.UserDomainrunning SCRENC c:\temp\netbiosdomain.vbs c:\util\netbiosdomain.vbe produces a c:\util\netbiosdomain.vbe file that contains:
#@~^rAAAAAWhen I run cscript //nologo c:\util\netbiosdomain.vbe, it outputs:
The Microsoft Download Center page Script Encoder contains the following overview:
Script Encoder is a simple command-line tool that enables script designers to encode their final script so that Web hosts and Web clients cannot view or modify their source. Note that this encoding only prevents casual viewing of your code; it will not prevent the determined hacker from seeing what you've done and how.
Web designers use scripting on Web pages and server-side active server pages (.ASP) to add virtually every kind of feature you can imagine. In addition, scripting is used by the Windows® Scripting Host (WSH) and in a number of other applications with equally impressive results.
Up to now, one of the shortcomings of using scripts is that they afford no protection of the intellectual property contained within, nor do they provide any assurance that what users get is what you created. Clever algorithms and carefully designed scripts were always completely visible because they were stored as plain text. As a result, script users at every level could see the script designer's code and could then take it, modify it, and make it their own. Obviously, this is not good if you're trying to get an edge in a very competitive environment.
With the introduction of scriptlets, protecting the source code becomes even more important. Script designers want to use this simple component architecture, but they don't necessarily want to share their source code with the world. After a script is encoded, changing any part of the resulting file will render it inoperable, thus ensuring the absolute integrity of your encoded script.