Of course names that are part of APIs are not mangled otherwise the program will work incorrectly. APIs can be standard (builtin language functions) or user-defined (for 3rd-party libraries that the developer decided not to obfuscate). Names of symbols that are part of APIs are referred to as "obfuscation exceptions" or simply "exceptions".

The following obfuscation methods are supported:

• Md5 sum with user-specified "salt": sample replacement is zd7b6a02ec5. The salt, number of characters from hexified version of md5 sum and a prefix ("z" in the sample above) are the options of this mangler;
• Combinations of characters from a user-specified set: e.g. if set is "l" and "I" (i.e. capital 'i' and small 'L'), it will generate names like "lIIlllIl". If the set is all lowercase letters, names like "bjhepjsdlrf" will be generated. Manglers take three options: a set of characters, salt string and length of resultant name;
• Shortest possible symbol name (great for minimizing output size) - so-called JavaScript compression mode. All JavaScript in the project will be studied and symbol use count calculated.
• Prefixing symbol: listOfCustomers becomes; MyPrefix_listOfCustomers — great for debugging, since all error messages identify which symbol in the input file caused the problem;

The results of all the methods (called "symbol name obfuscators" or "symbol manglers" in documentation ), except the last one (listOfCustomers-> MyPrefix_listOfCustomers) cannot be reveresed. This guarantees obfuscated JavaScript code cannot be recovered and makes it hard to analyze,

All "symbolname manglers" can be applied to JavaScript Protection Projects consisting of an arbitrary number of files.

Mapping between the original and replacement symbol names are stored along with the project so developers can always recall the original name of symbol.

Users have an option to manually specify symbol replacement.

Users have an option to specify symbols that shouldn't be renamed (lists can be attached to each individual file). Strictly speaking, there are 2 types of such lists, ones in which symbols are checked case-sensitive, and others in which symbols are checked case-insensitive.

Users can also define lists of suffixes that should be kept in symbols as-is (so everything before the suffix is mangled, while keeping suffix the same) — that is if _onClick is in the list of such suffixes to keep and md5 symbolname mangler is active, then openBtn_onClick it will be replaced with something like zd8ac37d6e_onClick, Lists of symbols for standard interfaces used by JavaScript are shipped with JavaScript Obfuscator. Users can easliy disable some of the "exceptions" in these shipped lists by listing some symbols as "antiexceptions" (these can be individually specified for each JavaScript file in the project).

There is an option of storing a symbol map as a comment inside protected version of each file.

Obfuscation of numeric constants make code harder to read - e.g. iteration from 1 to 5 will be totally non-obvious if loop limits are obfuscated this way.

The replacement expression can be made different even for the same constant, but in different places in your code (e.g. in one place and (0xd99+5451-0x21fc) 2 lines below it), or it can be the same for a given numeric constant. This makes analysis of changes between different builds of your code more difficult.

Of course there is an option not to obfuscate numeric constants.

This obfuscation stage makes the JavaScript code more difficult to understand at a first glance, more difficult to search for error messages and so on.It slightly increases the size of the code, though.

International characters in the strings will be left as is. There is also an option to replace strings with expressions that are create from individual characters using character codes, e.g. "cust" will look like this: String.fromCharCode((0xd9+11-0x81),(0x1a34+3389-0x26fc),(0xb52+3745-0x1980),(0x902+2536-0x1276)) . Of course it will increase size of your obfuscated code even more.

There is also an option to not obfuscate strings at all.

Comments can be completely removed. Since JavaScript Obfuscator is very flexible and powerful tool, there are other ways to obfuscate them (besides keeping them as is):

• Leave only newlines in the comments. I.e. comments will span same number of lines but there won't be any text in them. This will keep line numbers of the protected code same as in original code (if you specify newlines in the protected code are not to be removed),
• Replace all characters but newlines with 'x'
• Replace all characters but spaces and newlines with 'x'

These additional JavaScript obfuscation options demonstrate how well the original code was commented which may aid in selling the code.

This JavaScript obfuscation stage removes all spacing and identation in the code. This makes the code more difficult to read, and greatly reduces its size.

This step won't do anything with linebreaks in the code.

Of course this stage is optional.

This JavaScript obfuscation stage turns all the code into single line. Statement separators will be inserted in the appropriate places. This makes even looking at code difficult, since the viewer will have to scroll back and forth.

There is a setting to rewrap the code into several lines, each being no longer than specified number of characters.

Sometimes it's better not to apply this step if your code is not well-debugged and you wish error messages to contain line numbers matching your original code.

Of course this stage is optional.

Encoding means hiding JavaScript code by converting it into a special form that completely hides program structure. It also adds special advanced code that will decode the encoded script at runtime and execute it. Since the decoding code is automatically included into each protected file, no standalone decoders or interpreters are needed for running protected files.

By default, encoding is applied to the result of obfuscation, but it's possible to apply encoding to original source directly. This allows effortless code hiding that does not require any adaptation of the JavaScript code.

Of course this stage is optional too.

See samples for how encoded JavaScript looks like.

JavaScript Obfuscator and Encoder obfuscates all JavaScript code inside <script>, provided the code is client-side and the developer has specified client-side JavaScript protection, or if it is server-side code and the developer has specified server-side JavaScript protection in the project settings.

The code language is determined using various attributes (type or language) of the <SCRIPT> tag. If the language is not specified, it is assumed to be JavaScript code, provided that developer specified to treat all code in unspecified language as JavaScript code.

It is possible to add special attribute (by default its name is stunnix-obfus-skip, but it can be changed in the options) to the <SCRIPT> element to tell JavaScript Obfuscator and Encoder not to protect code inside it.

it is also possible to specify that JavaScript Obfuscator and Encoder not to protect any code inside the document. This is useful if developers wish to use JavaScript Obfuscator and Encoder to mangle markup and content of html, asp, php, xml and other types of documents.

JavaScript Obfuscator and Encoder obfuscates all JavaScript code found in values of attributes that may contain code, e.g. onclick="some_code_here()" or href="JavaScript:myfunction()".

Obfuscation of code inside value of href attribute is an unique feature of JavaScript Obfuscator and Encoder.

All HTML-style comments - i.e. text between <-- and --> are removed from documents. This removes any hints about the structure of your page and hides blocks you've temporarily disabled by commenting them out.

This works not only in html, but in all documents with server-side markup known to JavaScript Obfuscator and Encoder.

Special markup like Server Side Includes are not preserved, since JavaScript Obfuscator and Encoder differentiates them from HTML-style comments.

This can, of course, be turned off.

All non-needed spaces and line breaks are removed from the client-side portion of documents. This is done intelligently, with respect to name of html tags they are in, e.g. no spaces and newlines will be removed inside <PRE> block.

Removing extra spaces and newlines makes your document look like single line, making it easy to study.

This can, of course, be turned off.

Each character inside the client-side portion of the documents - inside text between tags or inside values of attributes - can be converted into a numeric entity. E.g. <div align=left>the text</div>

becomes the following when mangled:

<div align="&#x6c;eft">&#x74;&#x68;&#x65; t&#x65;xt</div>

International characters are not mangled this way to avoid possible problems.

it is possible to specify a percentage of characters to be converted into entities. Converting less than 95% of characters into entities makes them appear more random.

It is also possible to separately configure the conversion of characters inside the document content and in attribute values.

This can, of course, be turned off.

In order for client-side markup to look more confusing in .html, .php, .jsp and .asp files, the case of the letters in tag and attribute names can be randomly mixed. E.g. <div align=left>the text</div>

becomes the following when mangled:

<DiV aLIgN=left>the text</dIV>

It's possible to separately configure the alternation of case of letters for tag and attibute names

This can, of course, be turned off and original case can be preserved. There are also options to foce all characters into uppercase or lowercase.

JavaScript Obfuscator has special modes that assign local variable names a shortest name possible (considering the scope of variable) like YUI Compressor does. In fact, a modified and optimized version of YUI compressor is used for such modes - thus it's very reliable and well-tested.

After local variables are assigned shortest names possible, these name assignments can be kept (while mangling all other symbols using other mangler - e.g. md5) resulting in very short output. Alternatively, the assigned names can be also mangled after that, like all other symbols - this resulting in different resulant name being assigned to variable of the same name in different scopes.

An interesting special case is when mangler "none" (that does not alter symbol names) is used for all other symbols - all public API of your scripts is preserved (so you don't have to compose lists of exceptions and test your code extensively), while name of local variables get shortest meaningless names. The output will have much smaller size compared to size of input files.

Minifying locals works for server-side or client-side code, located in raw .js files or in files with .html markup (while YUI compressor can handle only .js files). Working Java runtime should be installed for this to be available.

See a detailed comparison of JavaScript Obfuscator and YUI Compressor

GUI of JavaScript Obfuscator has special "string browser" tool - available in Symbols ⇒ View strings encountered in code. That page has several tabs. One tab allows to browse all string constants that match symbols used in the project (most probably you'll have to list those symbols as exceptions). Another tab is "all strings containing some symbol used in the project" (e.g. strings used in eval() calls). Third tab is "strings looking like symbol". Forth tab is "all strings".

Such tool greatly simplifies creating list of exceptions - i.e. symbols that should not be modified.

JavaScript Obfuscator is a suite of Perl applications. The Windows version includes Perl interpreter and all necessary files. Perl interpreter is already preinstalled on Mac OS X, Linux and most Unix OSes, so the package for Mac OS X and Linux/Unix is the same and doesn't include any Perl interpreter (it utilizes Perl already installed in the system and uses no non-standard modules).

By default, JavaScript Obfuscator encodes the result of script obfuscation, which makes studying even the structure of the code much harder (the number of functions, presence of conditionals and so on). Encoded JavaScript still runs on any compatible JavaScript interpreter.

The encoding performed by it cannot be undone by the majority of JavaScript decoders on the market.

It is possible to encode only a subset of the files of a JavaScript project.

It is also possible to encode only selected parts of the source code by activating special functionality of JavaScript Obfuscator.

JavaScript Obfuscator has a state of the art support for checking licensing conditions:

• making obfuscated and encoded JavaScript scripts expire (i.e. scripts will stop working after particular date), with ability to select the current time source;
• binding to server (single allowed host name, list of hostname tails, regular expression a server name must match) with ability to select the source of server name &mdash for client-side and server-side code;
• user-implemented checks that allow the implementation of any other checks (like making scripts not work on Sundays);

There is an option to show a custom notification message before the termination of the JavaScript code.

All licensing checks are assigned to a block of code by means of a special initialization code. Without this code, the JavaScript code won't work correctly. As well, the whole block of JavaScript code is encoded to protect it from analysis and modification. Removing this block of code from the script body will make the script malfunction.

See more details here.

Obfuscation Project Manager uses the concept of projects as a way to describe lists of files and protection options for JavaScript and html . Each JavaScript obfuscation project has several JavaScript protecting modes that specify settings to be used to obfuscate the JavaScript code and html markup around your JavaScript code.

A single JavaScript protecting mode can be attached to a given file; modes inherit settings from other modes (typically predefined ones) which requires very little effort to configure protection for the project. The mode concept allows the handling of some files in the project as files with server-side JavaScript to be obfuscated, other files - as with client-side JavaScript to be obfuscated, others - as html files to be used as a source for names of HTML objects and form elements, and other group of files - as static files that are either copied as is to output directory, or are not copied at all. Modes also specify whether or not to encode JavaScript, so each JavaScript obfuscation project can partly contain files that have been JavaScript encoded and other JavaScript parts that have not been encoded, but are still obfuscated. Files with obfuscated JavaScript can have different copyright headers than other files; the mangling of strings or comments can also be performed differently in different files in the project.

Obfuscation Project Manager is designed to be a more convenient alternative to Makefiles so it has functionality present in all IDEs for managing the project - i.e. Build, Rebuild Changed, Clean operations.

Users who prefer to use the command line interface or single-click obfuscation and encoding of JavaScript and html in an entire project are able to compose a so-called build script. A build script is a special project-specific perl program that is a smart stand-alone replacement for a project-specific Makefile which already includes the functionality of the Make utility. For a project using Obfuscation Project Manager for JavaScript Obfuscator, just invoke that buildscript to perform operation such as cleaning all output files, reprotecting only changed files or reprotecting all files (with ability to specify only a subset of files).

You can see JavaScript Obfuscator Project Manager running on our site in demo mode (destructive and editing operations are disabled in it).

Obfuscation Project Manager GUI allows easy generation of lists of symbols of some APIs (e.g. used in the project's code). Just put the library public API definitions (or even implementation files for the library) in to any directory, go to Tools->Extract symbols from the directory with source files and specify the name of that directory, and the types of symbols you wish to extract (global functions, global variables, type names etc).

Stunnix JavaScript Obfuscator, unlike other tools, can protect JavaScript inside string constants in any file with any programming language like C/C++, Java, C# or Pascal. String constants should obey C-like syntax (begin with single or double quotes, end with same quotation character, and use C-style escape sequences with use of slashes); the constants to be protected should be wrapped into a call of some function or method.

Developers just have to pass the name of that method (even with the name of object it's called on) to JavaScript Obfuscator and it will protect all source code in any string constants found between parentheses, even if other expressions appear between those parentheses - e.g. variables being concatenated, or even some other functions being called.

Consider the following C# code in .aspx.cs file that generates javascript:

protected void AddJs()
{
    StringBuilder sb = new StringBuilder();
    sb.Append(GenUtils.JSCODE("var r = prepareReport(reportView,'" + reportName +
    "','" + getReportId("mainReport",0) + "');/* now set title */ " +
    " r.titleOf = \"Report - standard view\"; r.instance = 0; "));
}

It even contains slash-escaped double quotes (near the end of the JSCODE argument). Here is how it's protected with JavaScript Obfuscator:

protected void AddJs()
{
    StringBuilder sb = new StringBuilder();
    sb.Append(GenUtils.JSCODE("var z04526a1d1b = z7438ad78d7(ze4f536b204,'" + reportName +
    "','" + getReportId("mainReport",0) + "'); " +
    " z04526a1d1b.zde89a9b289 = \"Report - standard view\"; z04526a1d1b.z0d2e08cd5a = (0x148a+4382-0x25a8); "));
}

As you see, comments are removed, integer "0" has been mangled, and of course variables have been renamed to match names used in raw javascript files (that will be located on the same server where .aspx.cs file is being executed on). C# code surronding it was not changed, even the string constant inside of the call of getReportId().

The commandline used was:

js-obfus -E othercode,dynamic-scripts-by=GenUtils.JSCODE impl1.aspx.cs

Of course it's possible to achieve the same effect using Project Manager GUI, without writing a piece of commandline code - just assign mode "standard: pieces of JavaScript inside the code of some programming language (e.g. Java or C++)" to such files.

This allows users to create complex projects consisting of files with JavaScript, files with HTML markup and client-side JavaScript code in them, and some raw server-side code files (like Java or C# or C++) that refer to client-side code defined elsewhere, and the names of all symbols will be changed in the same way.

A special obfuscation mode is present in JavaScript Obfuscator that quickly adapts projects for obfuscation. When this mode is active, all symbols are prefixed using the same user-specified string (e.g. listOfCustomers becomes MyPrefix_listOfCustomers) thus making it easier to understand the error messages the script interpreter generates. Also, when this mode is active whitespace removal and integer and string mangling are turned off. There is no need to waste valuable time performing the trial-and-error process of obfuscation preparation!

Due to the unique ability to extract symbols from html files (that allows the extraction of the ids of html elements and names of form fields) and the unique ability to extract all symbols exported by a given ActiveX or OCX control — not available with any other products — the preparation process is as short as possible.

The following ways of generating obfuscated names are supported:

• prefixing symbol: listOfCustomers becomes; MyPrefix_listOfCustomers — great for debugging, since all error messages allow instant recovery of the symbol in the input file that caused the problem;
• using md5 sum with user-specified "salt": sample replacement is zd7b6a02ec5;
• using combinations of characters from a user-specified set: e.g. if set is "l" and "I" (i.e. capital 'i' and small 'L'), then names like "lIIlllIl" will be generated;
• shortest symbol name possible (great for minimizing output size) - so-called JavaScript compression mode.

All these ways (called "symbol name obfuscators" or "symbol manglers" in documentation ), except the first one (listOfCustomers-> MyPrefix_listOfCustomers) are irreversible. This guarantees that obfuscated JavaScript is unrecoverable and difficult to analyze.

All "symbolname manglers" can be applied to JavaScript Protection Projects consisting of an arbitrary number of files.

Mapping between original and replacement symbol names is stored along with the project so that the original name of a symbol can always be recalled.

Users have the option to specify symbol replcement.

Users have the option to list symbols that shouldn't be renamed (can be file specific). Strictly speaking, there are 2 types of such lists: ones in which symbols are checked case-sensitive, and others in which symbols are checked case-insensitive. Users can also define lists of suffixes that should be kept in symbols as-is (so everything before the suffix is mangled, while keeping suffix) — eg - if _onClick is in the list of suffixes to keep and md5 symbolname mangler is active, then openBtn_onClick it will be replaced with something like zd8ac37d6e_onClick, A symbols for standard interfaces used by JavaScript are shipped with JavaScript Obfuscator. User can easliy disable some of the exceptions in these shipped lists by designating some symbols as "antiexceptions" (these also can also be specified for each JavaScript file in the project).

There is an option to store a symbol map as a comment inside the protected version of each file.

All aspects of JavaScript syntax are supported.

JavaScript Obfuscator supports scripts containing statements terminated with newlines (i.e. not with semicolons). When such file is obfuscated with whitespace and newlines removal, semicolons will be inserted in the corresponding places to make the code valid. Most obfuscators on the market make such code invalid.

JavaScript Obfuscator also supports literal text format or the RegExp constructor function (i.e. code like this: var rx = /\d+\s+\w+/i; will be correctly handled), and there are options to precisely control the handling of such fragments.

JavaScript Obfuscator obfuscates and encodes JavaScript both client-side or server-side, emebedded into HTML, ASP and ASP.NET files, as well as Windows Scripting Host and Windows Scripting Component files - by the use of special extractor and merger engines for HTML, for WSC, for WSH, for ASP and ASP.NET files, and client-side JavaScript in PHP files.

Files with HTML markup in which JavaScript scripts are to be obfuscated can contain SSI (supported by IIS and Apache), ASP, ASP.NET and PHP fragments in them at any location - inside scripts (even inside string constants of the script!), inside event handlers and inside html markup (i.e. between < and >) - this feature is available only in JavaScript Obfuscator.

Values of internalName attributes inside WSC files are obfuscated automatically.

A special stand-alone utility to extract names and ids of form fields and other elements is also included with JavaScript Obfuscator. It is invoked automatically for files of JavaScript Protection Project that are declared as files from whcih ids and names of form fields are to be extracted.

JavaScript Obfuscator is also an html obfuscator. It can remove html comments and redundant white space between html tags. Just assign a proper mode to the files that you wish to mangle. Html files with server-side markup (like .jsp, .asp, .php, .cfm) can also be mangled - html markup will be scrambled in them without touching server-side markup.

JavaScript Obfuscator supports obfuscation and encoding of dynamic JavaScript - e.g. if pieces of JavaScript code computed from various variables are output to the client using document.write() by the client-side JavaScript code, the content of these pieces (e.g. names of variables in them) can be obfuscated.

Also if client-side JavaScript code is output by any server-side language (e.g. ASP, ASP.NET, JSP, PHP, C/C++ or Perl), then the pieces of JavaScript code can be obfuscated inside the strings that are arguments of the desired method calls of the server-side language (i.e. JavaScript Obfuscator can modify any server-side language too!).

The arguments of those methods can include expressions that compute pieces of JavaScript code using any operators and calls of other functions and methods; but only strings will be treated as JavaScript code and their content will be obfuscated.

More information and samples are available in the manual.

JavaScript Obfuscator, unlike other JavaScript obfuscators or encoders, was designed with multi-file complex projects in mind. This means that with the same set of obfuscation parameters given to a JavaScript symbol name will be obfuscated to the same name independant of its position and file location.

In case some of the input files are changed, users can reprotect and redeploy only that file, without the need to reprotect entire JavaScript project.

JavaScript Obfuscator also has support for code that uses eval() or any other statement that uses string containing names of variables or methods. Once properly marked up (by splitting the string into an expression that joins parts of the string and turning parts that contain only the name of variables or methods into calls of a special function), names of variables and functions in the string will be obfuscated properly. This allows the obfuscated JavaScript code to work as the original. This functionality was first introduced in JavaScript Obfuscator among all obfuscators for JavaScript. This manual "markup" gives 100% stability accross project rebuilds and is much more useful than automatic guesswork performed by other obfuscators for JavaScript.

If JavaScript code contained in a string is too complex to split into parts by a programmer, users can use the unique feature of JavaScript Obfuscator - the ability to obfuscate dynamic JavaScript code. More information and samples on obfuscation of dynamic JavaScript code are available in the manual.

As with all Stunnix products, JavaScript Obfuscator suite has many options to tightly control each aspect of operation. GUI (Obfuscation Project Manager) and commandline interfaces are equally capable.

All names and semantics of commandline options are convenient and intuitive and follow GNU recommendations, forms in GUI are also easy to use and understand.

To get an idea of how many options are available, please view the online demo .

Among the variety of options that control each aspect of JavaScript obfuscation and encoding, are ones that make obfuscated non-encoded versions of the same JavaScript source code different from each other. This makes analysis of changes between different versions of the software much more difficult. Another use is distributing unique versions of the obfuscated JavaScript code to each customer - this way developer can track which customer violated license conditions that resulted in distribution of the product on the internet.

Key internal parameters of JavaScript encoding already depend on random values so the encoded version of the same file will be different on each run. Developers just have to run JavaScript Obfuscator to produce file specific to each customer.

A very rich set of exception tables is included with JavaScript Obfuscator for JavaScript core functions, ECMAScript core functions, W3C html model, non-standard Mozilla and MSIE html models, DOM, DOM Events, CSS model, SVG, XPATH and even XUL. Also exceptions for ASP, ADO, WSH and WSC frameworks are included. Each table is stored in a separate file whic makes it easy to select which sets of tables to use.

Users have an option to list symbols that shouldn't be renamed (such list can be attached to each file individually). Strictly speaking, there are 2 types of lists, ones in which symbols are checked case-sensitive, and others in which symbols are checked case-insensitive. Users can also define lists of suffixes that should be kept in symbols as-is (so everything before the suffix is mangled, while keeping suffix the same) — that is if _onClick is in the list of such suffixes to keep and md5 symbolname mangler is active, then openBtn_onClick it will be replaced with something like zd8ac37d6e_onClick, User can easliy disable some of the exceptions in these shipped lists by designating some symbols as "antiexceptions" (these also can also be specified for each JavaScript file in the project).

Due to the unique ability to extract symbols from html files (that allows the extaction of the ids of html elements and names of form fields) and the unique ability to extract all symbols expored by a given ActiveX or OCX control — not available with any other products — the generation of custom lists of exceptions is easy, fast and almost fully automated.

Unlike output of some JavaScript Obfuscator encoders, the JavaScript code obfuscated and/or encoded by JavaScript Obfuscator runs on any fully-compliant JavaScript interpreter, including ones that are included with most popular browsers.

JavaScript Obfuscator fully supports JavaScript.NET and ECMAScript - including encoding and support to ensure license conditions. JavaScript.NET for scripting applications is supported as well.

This support is available independently of the platform JavaScript Obfuscator is run on - Windows, Mac OS X or Linux.