Adventures With Javascript Packer

Web developers, and others who use web based technologies to build applications upon, have always been keen to prevent end users seeing the business end of their applications.  Early on in the history of the web - during JavaScript’s first boom - there were plenty of scripts which created annoying functions like stopping users left clicking (in a vein attempt to stop people ’stealing’ their code - like it was the best thing on the web, but more likely to try and cover up simple exploits in their code) or scripts that would completely scramble the HTML should a user view the page source making it unreadable to humans.  This trend seems to be coming back in a big way.

More and more I am seeing JavaScript’s which are unreadable to human eyes but which can still be understood.  In the past, scripts that scramble the code made websites bloated and ‘heavy’ for users to view - not to mention that the encryption key that had been used to scramble the HTML was readily accessible to any viewer who knew where to look.  These days however the scripts which ’scramble’ are intended (initially at least) to compact the script to help sites load faster.  It is an unexpected bonus that the code is also unreadable to humans.  Ever seen something like “eval(function(p,a,c,k,e,r){…};”?  Want to know what’s really going on?

The fundamental problem with web based applications is that the end user’s browser needs to be able to understand the data it is given.  Browsers are able to send and receive information securely, but once that information is delivered to the client it is effectively there’s to do with what they will.  Let’s face it, if the browser couldn’t understand and interpret the data then there would be no web!  So web developers write code in a way that browsers understand (and sometimes in the case of IE, they don’t understand).  JavaScript’s also need to be understandable to the browser because they are processed on the client unlike a host of other languages which are processed on the server side.  With a server side language, the script is processed and a web page is outputted and sent to the client.  With a client side language, the script is sent to the client, the script is processed and the output displayed on screen.

But wait, the script that I have is ‘packed’ like the example above!  How can that be?

Well the answer is rather logical and right in front of you.  The script that is ultimately run is sent to you inside another script.  The container script is a simple compression script which, when run by the browser, outputs the ‘real’ script which, in turn, is run by the browser.  Rather nifty!  However this script-in-a-script setup means that should the user view the page source they will only see the packed script which is unreadable to humans.  Even better!

So how do we see what the actual script is?  There are a few ways.  Firstly, it is possible in Firefox to select an area on the page and view just the selected source.  This source isn’t just a cropped section of the page source (what is downloaded from the web server) it is an output of the page actually displayed by the browser.  This means you see what the page looks like after the scripts have run.  But the catch is that most JavaScript’s are contained in the head of the page meaning they cannot be selected.

The next option is to open up the error console in Firefox (Tools>Error Console or Ctrl+Shift+J) and paste in the packed code with “eval = alert;” in front of it.  This will then pop up a dialog box which contains the code that has been packed.  The output of this code isn’t very pretty but it works in most cases.  The only issue I have run into is that when you are unpacking unusually large scripts it becomes cumbersome (if not impossible) to get the entire script.  Also, the data isn’t formatted very well.

So my quick solution to this (which I am sharing with you now) was to throw together a couple of scripts that I found online which decode the packed script passed to it and then display it in an easy to use way.  There is both a code view for easy on-screen reading and a text-box view which makes for easy copying into another application.  It does take a few seconds to finish decoding (most of that time is spent waiting to be honest) so don’t be too hasty to click Decode! again.

Hopefully this helps people out.  You can download the files to your computer and run the tool offline.  Let me know what you think.

User Defined Background

You will notice, with TheStable’s new look, that as a user you can change the background colour to your favourite colour. At the very top of the page, on the right, there is a drop down box which lets you choose which background colour you would like to use with the site.  I had some difficulty working out exactly how to achieve this effect in the simplest way possible so I will document what I have done here.

I have played around with colour changing backgrounds or user selected styles in the past but they all revolved around having each style or scheme in a different style sheet.  The user can then decide which scheme they want and their browser will load that sheet.  This is a popular approach and does the job well but if the only variance in the style is, say, one or two lines, it becomes inefficient.  Why load a 10Kb style sheet when you are literally changing only a few bytes?  This approach is better suited to a complete design change or allow the user a choice of multiple themes, compared with different element styles.

So my answer to this is to have a series of classes which can be changed dynamically by the user.  This displays instantly as the styles have already been loaded by the browser (in my instance there is a small image to load as well).  Of course, there is a default style which is used when no selection has been made.

Firstly, we define the styles:

.bg-purple {
background: #ffffff url(images/bg.png) repeat-x fixed;
}
.bg-blue {
background: #ffffff url(images/bg-blue.png) repeat-x fixed;
}
.bg-red {
background: #ffffff url(images/bg-red.png) repeat-x fixed;
}

You can have as few or as many styles as you like.  You can see that we are only declaring the background here but you can potentially change any style you wish.

Next we assign the body of the document the default (bg-purple) class and we put in our select box with colour choices:

<select onchange=”body.className = value;”>
<option value=”bg-purple”>Purple</option>
<option value=”bg-blue”>Blue</option>
<option value=”bg-red”>Red</option>
</select>

Notice here that the onchange attribute has the javascript ‘body.className = value;’.  This is the most efficient way of changing the class for the body but if, for example, you wanted to change the class of a div you would need to use getElementsByID.  Also note that the value of the options match exactly the class name which will be used.

There is still one drawback - the users will have to choose their background preference each time they load the page.  So, lets get a little more complicated.

By writing a cookie when a selection is made, we can then see if the user has made a selection in the past and then use that selection instead of the default.  So we would have:

<select onchange=”body.className = value;var d = new Date(); d.setDate(+60); document.cookie = ‘bgColor=’ +value+ ‘; expires=’ +d+ ‘; path=/; domain=mydomain.com;’”>

instead of:

<select onchange=”body.className = value;”>

This will write a cookie bgColor with the class name selected as the value.  Make sure that you adjust the domain attribute to your domain and you can change the setDate() function to extend/shorten the expiry date of the cookie.

The last thing we will need to do is to include a function that reads our cookie and uses it’s value instead of the default.  From my research, this is inefficient to do in javascript - whereas in php it takes a lot less code.  It is still possible to do in javascript so if you don’t use php then you aren’t lost.  Please do share if you come up with a solution.

So we use:

<body class=”<?php if (isset($_COOKIE['bgColor'])){echo $_COOKIE['bgColor'];} else { echo “bg-purple”;}?>”>

As you can see it’s a neat bit of code which checks if our cookie exists and uses it if it does or uses the default if it doesn’t.  Now, when the page is refreshed, the users colour choice stays.  The cookie will however expire but if you wished you could rewrite the cookie on each page load, extending the expiry date.  Or you could just be lazy!

Hopefully this helps someone and if you have any ideas, improvements or alterations please do share them.