The problem with JavaScript Obfuscators and Minification – Tracking down errors

JavaScript obfuscators and minifiers do their job well. In fact, some obfuscators have anti-debugging features. However, if you are a legitimate developer building applications against one of these libraries, chances are you’ve gotten an indecipherable error such as “z=null line 14300″ and it brings your development efforts to a halt. Error messages like this provide no useful information on what the problem really is, or give any hints on how you might be able solve it. You’ve probably even looked at the jumbled source code in a last ditch attempt to make some sense out of the error. And, whether it’s your own library or a mainstream ones as jQuery or Dojo, it doesn’t matter. The amount of productivity lost because of these errors in probably very large, not to mention the frustration it causes.

I hope the the developers of these obfuscators are reading this…because I have a proposed solution to the problem.

Now, I want to start out by mentioning that I fully understand why obfuscators exist for reasons such as source code protection and decreasing download size. What I propose takes this fully into account, yet makes your library developer friendly in a secure way:

During the obfuscation process create an index file that maps each variable, function and class to a real line number and store this file in a web folder.  Then create a small html file that lets you search the index and return the real line number. Provide an option for return the variable, function or class name, too.

The concept is that if there is an error, like the  “z=null line 14300″ I mentioned above, developers can then at least have some hope of narrowing down the general area of the code where it might be occurring.

The bonus is, if you own an obfuscated commercial library, now your tech support people can also look up the general area where a customer might be having a problem. For security reasons you don’t have to share the index file, But, even then, there isn’t enough information in it to de-compile the library. Now, if I post my error to the forum:  What is “z=null line 14300″? Tech support will be able to tell me that I’m missing a custom property on a widget’s HTML DIV element. It’s a win-win situation.

What do you think?

Tags: , , , , , , , , , , , , , , , ,

4 Responses to “The problem with JavaScript Obfuscators and Minification – Tracking down errors”

  1. Sam says:

    This is a nice idea but I don’t think it’s really needed.

    Most JavaScript libraries like jQuery recommend you use the non-minified version for development for exactly this reason.

    Commercial JS libraries should really provide the source for development at least as minification and obfuscation don’t stop people stealing their code. True it just makes it slightly (and only slightly) harder for people to steal their code but it makes it a lot harder honest developers to debug.

  2. agup says:

    True, however you would agree that not all software vendors are willing to publish developer versions of their JavaScript libraries for a variety of reasons. Therefore, under those use cases my proposal offers a debugging middle-ground between developers consuming their API and vendors still doing their best to protect their source code.

  3. Sam says:

    That is sadly true, but would the ones that won’t provide developer versions be willing to provide extra debug information which could be used in reversing their “protection”. I don’t think they would be any more willing to do that unless all the helpful debug information was removed. In which case you’re then back to square one trying to debug anything using their library.

    Just run most minified code through jsbeautifier or any similar tool and you are already a large part of the way to reversing their “protection”. If you then had debug information which gives the correct line numbers and/or class/variable/function names you could reverse it even more accurately.

    At that point they might as well just give the source code away and help the honest developers. All the protection does is hurt the honest developers and provide a false sense of security as the people that don’t want to pay will still be able to reverse it.

  4. agup says:

    Good call on jsbeautifier – as long as there isn’t any meaningful obfuscation. While it can be somewhat slow, it does an amazing job.