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.

4 Comments

Leave a Comment

Username (required) :
Email (required) :
Web Site :
Comment :

Cancel