Simple yet powerful, sometimes confusing but eventually logical: There is no better way to describe the JavaScript parser. Once you understand the parser, you will be able to understand how to use the code to your advantage.

The examples in this chapter show you how to change the value alert(1) to a different representation, yet have it execute the same code. In case you are not familiar with alert, here is a simple explanation. The window object in JavaScript is the container of all global variables. You can have window objects in different locations in your code, and therefore separate global objects. When executing functions or reading values JavaScript automatically assumes the window object is the current object and all variables are global, unless a local variable is declared. If you are used to other programming languages, you may find this concept confusing; it helps to just be aware that JavaScript has global variable reliance at its core.

When we call alert we are using the window object's alert method. You can see this by running the following code in a browser of your choice:

As you can see, the alert box appears twice with the same value, 1. The last box shows you that alert is a native function of the browser. This means it's already defined before you enter any code. Let us see what happens when we define our own function called alert:

Here, we simply defined our own function called alert, with no arguments between the parentheses. The curly braces indicate the body of the function. In this case, our function does nothing. We get no alert from the browser, and we have successfully overwritten the native method of the window object. Although this will not help you with obfuscation, it should help you to understand how the code can be manipulated.

Something that will help you with obfuscation is the square bracket syntax of JavaScript. This is one of the most-used parts of the language and it shares the syntax with array literals. An array literal consists of a starting square bracket ([) and an ending square bracket (]). The values between the brackets can be any JavaScript object and are separated by commas. They can also be deeply nested to form multidimensional arrays. Let us make an array literal with some values in it. Before running the following example, try to guess the value returned by JavaScript.

If you guessed /a/, you are correct. JavaScript arrays are indexed from zero. First we assigned the array to x, and then we added a list of JavaScript objects, separating them with commas. Next, we executed alert, which returns the fourth element of the array. Notice the difference between the square bracket syntax when accessing an object and declaring a literal.

Now things will get slightly more complicated and interesting. Take a look at the next example, which shows how the object property is accessed:

In the preceding code, the curly braces declare an object literal. The ‘objProperty’ string is the name of the object's property, and the value 123 is assigned to it. We access the object literal using the square brackets. Notice how the square brackets look like an array, but in fact are accessing an object property. This is important syntax to understand, as these core techniques can enable powerful obfuscation. In this instance, the rightmost statement is returned to access the property (i.e., the last comma of the statement inside the square bracket notation).

Now we will look at a slightly different way of doing the same thing, this time enclosing the contents with parentheses. This enables you to group statements, and return the last statement within another statement. The following example shows two groups of parentheses. The first group returns the next group and the last group returns the string ‘objProperty’ because this is the last statement of that group.

The next step of the JavaScript learning process is to understand how strings are created. Strings are the basis of obfuscation, as without them, we cannot create our code. JavaScript supports many more ways to create strings than you may think. For instance, you can use the normal methods that JavaScript provides, such as the new String(‘I am a string’) and the standard “I am a string” and ‘I am a string.’ Although the new String constructor is less convenient than the standard syntax, and therefore is rarely used, in your quest for obfuscated code it helps to know the various ways to create a string. Let us look deeper into strings and see other ways we can create them.

In the preceding code, the first alert contains a regular expression, as indicated by the starting forward slash and ending forward slash. JavaScript does type coercion and converts our regular expression into a string when using +. The second example uses the standard source property of the regexp object (every regexp object has a source property), and it returns the text used for the regular expression without the starting and ending forward slashes. Lastly, the array is used as a string because each array has a toString method, and it is called automatically when accessing an array without specifying an element.

There is yet another way to use square bracket notation to access strings. This nonstandard method of using strings—which has been adopted by the major browsers (IE8, Safari, Opera, Firefox, and Chrome)—involves using strings in an array-like fashion: specifying a number will return the various parts of the string, just like an array. This is very useful for obfuscation when combined with various methods of obtaining a string.

The preceding example returns the letter a, as this is the first character of the string. This is not a true array, as it still retains the string methods, and you cannot assign to a position of the string.

All browsers behave differently. They sometimes follow the ECMA standard and sometimes follow their own path. This is a good hunting ground for obfuscation ninjas to lurk. If we can spot specification diversions or nonstandard functionality we can often use these features in unintended ways. Browser quirks also make it more difficult to deobfuscate code because the software needs to account for these features. Learning more about browser quirks will increase our knowledge of the languages in general and can be a lot of fun in the process.

JavaScript supports Unicode characters using hex escape sequences. This allows JavaScript programs to represent international characters using their Unicode hex values. Unicode escapes can be used with standard characters, and generally can be used as a variable or function reference. Firefox 2 at one time supported Unicode-encoded parentheses; this was very useful for obfuscation, as function calls could be fully encoded. Major browsers currently do not allow Unicode to be used in this way, including Internet Explorer, Opera, Firefox, Safari, and Google Chrome.

The escape sequence is always a backslash followed by a single u and then a hex sequence of four characters. Following this convention, the variable a can be represented by the Unicode escape sequence u0061. To the JavaScript parser this is exactly the same as writing the actual character. The following example shows how to duplicate the same code on one line with mixed Unicode:

Already, with just this basic encoding, we have an obfuscated vector. Both lines are exactly the same and execute alert(1). The example encodes the character a and the t of alert. It doesn't end there, though. We can also use Unicode escapes within strings and regular expressions. In this case, the Unicode refers to the string rather than the variable reference. To use these strings for obfuscation we need to evaluate the result of the strings using JavaScript native functions, such as eval, Function, and setTimeout. The following code, in which we partially obfuscate the letter a, shows how to do this:

The first example in the preceding code shows the string “alert(1).” This is because the Unicode escape is being used as a string escape. The second example is confusing because the backslash is escaped, forcing the string to be sent to eval as a Unicode escape that is not converted. Because Unicode is allowed instead of the letter, as in the previous snippet, the actual string sent to eval is u0061lert(1), which calls the function.

Unicode can be used in yet another way within regular expressions. Literal expressions support the raw Unicode escape, which matches the character provided in the escape sequence. Using the RegExp constructor allows you to use string escapes as well as RegExp escapes, which allows you to encode Unicode multiple times. In addition, the RegExp object is a function in many browsers, including, at the time of this writing, Firefox, Chrome, and Opera. This allows a regular expression to be called and returned as an array which then can be used to execute obfuscated code.

Here are some examples of using regular expressions to create obfuscated code. The first line in the following code contains the string ‘alert(1)’ and the replace function is called. This function accepts two arguments: the regular expression to match and the function to call in the second argument or string.

The last example in the preceding code, labeled doubled regexp unicode, uses the RegExp constructor to create a string which is encoded first with Unicode, and then is encoded again as it is decoded when it is sent to the RegExp constructor. The source property is used to get the contents of the regular expression text, which itself is escaped. Then the whole string is matched again using replace, and a RegExp constructor object is used again to match the string, but is heavily escaped as Unicode escapes are valid within the resultant regular expression. Finally, the eval function is escaped with standard Unicode.

This is a small example of how JavaScript regular expressions can be used for obfuscation. Examples of more advanced techniques are provided in the section “Combining encodings.”

There are four forms of hexadecimals within JavaScript: string escapes, the number literal, regular expression escapes, and type coercion. The string escape is probably the most popular in terms of obfuscation, as it provides an easy way to produce an alternative character. To create a string escape you use the backslash character followed by a lowercase x and a two-character hex sequence to represent the Unicode character. The number literal also supports automatic conversion of a hexadecimal number when the prefix 0x is used; for example, 0xFF will return 255 in JavaScript.

Fortunately, we can use this automatic conversion to our advantage. As demonstrated with Unicode, regular expressions also support hex sequences, which allows us to double-encode our hex escapes. Type coercion in JavaScript will automatically convert a hex sequence within a string without the x prefix if the string contains 0x, which allows us to double-escape hex escapes without regular expressions. It is worth noting that JavaScript does not allow you to use hex escapes in the same way as Unicode escapes. Hex escapes are only supported within strings and cannot be used as a reference to a variable or object.

JavaScript supports three forms of octal encoding. This is a common source of coding mistakes, because one way to represent octals is to use a zero prefix before a standard number literal, and in such cases, developers often think they are getting a decimal number when in fact they are receiving an octal (e.g., 0100 is 64, not 100). However, we can use this to our advantage for obfuscation, as the decoder or person reading the code will have to account for all forms of representing a number. Within strings, an octal is declared by escaping a number sequence which returns the character from the octal number:

Now that you are aware of the various encodings/escapes in JavaScript, let us combine them to produce some obfuscated code. The following example will call alert(1) using all the techniques we have discussed thus far. This should help you to understand how to use each type of escape.

In the preceding code, first we used the RegExp constructor to create our string. This allows us to use string escapes and regular expression escapes, as demonstrated in the “Unicode Escapes” section earlier in the chapter. The Unicode escape is performed and it converts a to u0061. Then, because it's a string, we can escape the Unicode escape, so u0061 becomes x5cx75x30x30x36x31; this still represents the letter a. Next, source returns the text content of the RegExp, which results in u0061. Then we use the octal escape 0154; the leading zero indicates an octal number, which is sent to String.fromCharCode as 108 when it is automatically converted from the octal number 0154; the number 108 is the character code for the letter l. We then use a string split by u00 and a hexadecimal number to create a Unicode string of e. The r is created using a Unicode literal RegExp, and uses the Firefox-, Chrome-, Safari-, and Opera-specific functionality to match a string sent to the RegExp which is hex-escaped. As a result, x72 returns r. Finally, we use an octal escape to create a backslash, 134, which, once assembled, creates a final Unicode escape for the letter t with the (1) at the end, before calling eval which executes our vector.

In JavaScript, variables may be used to store numbers, strings, and other objects. A variable can be instantiated in two ways, with or without the var keyword. Variables can contain any alphabetic character along with each of the following:

Each of these may be used for obfuscation purposes. In particular, _, $, and Unicode characters can be used to develop JavaScript statements that do not even contain alphanumeric characters. In fact, nonalphanumeric JavaScript is such a rich field for Web obfuscation that an entire chapter of this book (Chapter 4) is dedicated to such techniques.

A typical variable assignment takes the following form:

However, there are other ways to assign variables in JavaScript, depending on the context. For example, each of the following is valid JavaScript for assigning a string to a variable:

Using alternative syntax such as these either alone or in conjunction with various string concatenation tricks is one of the most straightforward ways to bypass simplistic Web application firewalls (WAFs). For example, early versions of an anonymous WAF would correctly detect injections such as the following:

But they failed to detect injections such as this:

JavaScript includes many built-in variables that are useful for interacting with browser objects. For example, the document object provides access to the Web page's DOM, URL, cookies, and other properties. Many of these variables are consistent among different browsers; however, some are browser-specific. A few of these variables are especially useful for obfuscation purposes.

Comments are quirky in VBScript. You can use ancient REM-style comments, and because VBScript is case-insensitive, the comments are quite hard to distinguish from normal code. There is an overlap with JavaScript which turns out to be confusing as well; in JavaScript, strings can be declared with single quotes, but in VBScript, single quotes are comments!

When VBScript is executed from an event a special declaration is supported that can force a particular scripting language. This can be done in two ways: either in a separate language attribute or as the first part of an event declaration. The language attribute is supported wherever an event is supported. On an HTML tag, the default is JavaScript, but we can change this by using the language attribute with VBScript, or the abbreviation vbs.

In VBScript, functions can be called like JavaScript, with parentheses. However, you can also call them without parentheses. This is useful for filter evasion where a certain limitation of characters has been placed, or an IDS system checks for “(” and ”)”. It can also help with obfuscation, as reading the code can make it difficult to know where each function argument begins and ends. As VBScript deals with the DOM, it can also share functions with JavaScript, such as window.alert and document.write. Unlike JavaScript, these calls are case-insensitive. This means VBScript supports the execScript function too, which is very useful for obfuscation as you will see shortly in the section “The execScript function in VBScript.”

The end of statement is considered to be a new line (not a semicolon, as in JavaScript). There is, however, one trick you can use for a new line to continue a string rather than execute the next statement: using multiple-line syntax you can create a string across multiple lines that is useful for obfuscating function calls.

You can also combine this with HTML entities. For instance, you can split the strings with &_ and then HTML-encode those operators again with an HTML entity for a new line between each. The code executes “Obfuscated” in a VBScript message box. The first &_ operator is HTML-encoded and the others are displayed as normal, making very strange-looking strings. As you can see, the &_ operators can be right next to the HTML-encoded new lines.

Microsoft implemented a specific script type to include encoded scripts within a script tag. This was designed to prevent casual attackers from viewing the source code. I say “casual” because the encoding can be broken quite easily, as it involves just a simple substitution cipher. For obfuscation, it's actually quite cool because Microsoft also implemented it in some unusual ways which many people are not aware of. The following code demonstrates the standard method of including encoded scripts:

The vector uses Microsoft's script encoder to encode a simple “MsgBox 1” function call. This is quite cool for obfuscation because, as you can see, the encoded code no longer represents the original code, and different code will be encoded differently depending on the position of the characters in question. If you remember from an earlier example in the “End of Statement” section that the language attribute contents could also be used inside events. The same can be done using vbscript.encode, and because we are inside an event, we can take advantage of HTML entities as well. Double-encoded vectors become possible, and even more are possible depending on the context and type of execution. The next examples show vbscript.encode being used inside events and being encoded with HTML entities.

Internet Explorer also supports another method of executing code. The execScript function is supported by VBScript and JScript. It is similar to the standard JavaScript eval statement, but with one important difference: A second argument is supported which declares the language that is evaluated. This allows you to call JScript code from VBScript and vice versa. The following code shows VBScript executing JScript code using execScript:

At this point, you may be wondering whether the function accepts something other than VBScript and JScript. It does, and this makes it very useful for combining obfuscated code. We can include vbscript.encode as the second argument to execScript, which allows us to execute code in the context of a scripting event and a VBScript string, resulting in even trickier obfuscation techniques. The next example shows how to use the second argument and combine VBScript strings, events, and HTML entities:

The preceding code combines the tricks we discussed in the previous examples. First it forces VBScript inside the event using vbs:. Then it uses execScript to execute some encoded VBScript. It then splits the encoded script using the VBScript chr function, which returns the character based on the character code supplied. Finally, it encodes parts of the encoded output with HTML entities. You could fully encode the output using all of these methods, but I have partially encoded it for clarity.

JScript is Internet Explorer's flavor of JavaScript and it supports some of the techniques described in the section “VBScript.” Additionally, there is an interesting language value which supports JScript for mobile devices. This is one of the discoveries that does not obscure code, but is worth knowing about, as in the future, additional techniques may be discovered, whether they involve new event protocol handlers or other undocumented functionality. If you declare JavaScript with jscript.compact this will force Internet Explorer mobile compatibility mode, which forces semicolons for each statement and disables eval.

JScript also supports encoding built into the language attribute and event protocols such as VBScript. This is yet another string in our bow to obfuscate our code. The more methods you combine, the more difficult you make it to decode the code. I say “difficult” because encoding can always be defeated in time, but the more difficult you make it the more likely someone will give up decoding your code. Browser-specific code is also good for protecting your code because any decoder would have to account for the features used in your encoder, making decoding more difficult. Here is how to use jscript.encode for JavaScript. Although alert(1) is encoded in the examples, you can encode your own custom code by using the Microsoft Script Encoder which is available at http://msdn.microsoft.com/en-us/library/cbfz3598%28VS.85%29.aspx.

JScript supports conditional comments. These can be directly embedded into code or within comments. To activate them, JScript looks for the @cc_on token. This token can appear as many times as you like, but it must be used at least once before a conditional statement is used. Inside comments, the @cc_on token will only be executed if it is the first statement inside the first comment; otherwise, it will be ignored. You can layer statements and comments to add further complexity and confusion, as a statement can be initiated outside the comment and finished inside the comment, with an unlimited amount of padding.

As conditionals are supported outside comments, this technique also extends the syntax of JavaScript itself. This is useful for decoder evasion if the decoder only scans for traditional JavaScript syntax. To successfully decode the JavaScript a decoder would have to parse this extension of JavaScript as well, or remove it. However, removing the code could pose a problem, as conditional statements can be embedded. Therefore, the only reliable way to decode conditional comments is to extend a decoder to support them. This makes them very useful for obfuscation, but consider that the code that is created will only work on Microsoft Internet Explorer.

Here is how to continue code from outside a comment to inside multiple comments. This really demonstrates the power of conditionals for obfuscation. First, the @cc_on token is used within JScript to enable the use of @if syntax. Then a further @cc_on statement is used for padding, followed by a ∼ operator which is then continued with an alert statement inside a comment. Then the function call is actually initiated inside multiple layered conditional comments, and is ended with the @end comment which closes the if block that was started at the beginning.

As with VBScript, JScript supports execScript, and allows us to call VBScript code from within JScript as well as use the jscript.encode technique. Because we can do this, it is possible to transfer VBScript to JScript and back again. The final JScript example shows how to use execScript and event protocols to use jscript.encode multiple times. Originally, the event is a JavaScript event; then a jscript.encode handler is used, and execScript is passed a further encoded jscript before it is further encoded with HTML hex entities.