7

I am looking for the currently hardest-to-reverse JavaScript obfuscator. Bonus points if it can be run on one's own server. Performance hit and code bloat are fine.

cmc
  • 4,294
  • 2
  • 35
  • 34
  • 3
    run the code through multiple obfuscators one after another. Extra fun! – Gabi Purcaru Jul 14 '11 at 17:05
  • 16
    better yet - accept the fact that client-side code is out of your control. – digitalbath Jul 14 '11 at 17:08
  • You can also have javascript files importing other javascript files, which can make the whole process a lot harder to piece together, if copying is an issue for you. – Griffin Jul 14 '11 at 17:11
  • @digitalbath: That's not necessarily good advice. Perhaps cmc is trying to protect trade secrets (eg. an algorithm) for as long as possible. Obfuscation would be very helpful for that. – Cam Jul 14 '11 at 17:20
  • @Griffin: How does a JS file import another JS file? – Gabe Jul 14 '11 at 17:27
  • @Gabe, you can create a script element on the fly: `document.createElement("SCRIPT");` – Griffin Jul 14 '11 at 17:38
  • 4
    @Cam: If someone's determined, they'll beat any obfuscator in relatively short time. If they're just fiddling around out of curiosity, even stripping whitespace could scare them off. If you have secrets and want to protect them, you don't put them in JS or anything else that the client every gets his hands on. If doing it is like giving a crook a loaded gun, adding an obfuscator "for protection" is like still giving the crook the gun but kindly ask them not to use it. –  Jul 14 '11 at 17:39
  • 2
    @delnan: I disagree. Without any obfuscation, it could take just a few minutes to decipher. But even for an expert it could take up to a few days depending on the obfuscation and the complexity of what the js code is doing. All I'm saying is that in some cases this few days might be vital if you want to gain a short time advantage before competitors/adversaries are able to take your JS. I think a better metaphor is that you're giving a crook the gun, but it's not loaded and the gun store is 5-6 miles away. They do not have a car. – Cam Jul 15 '11 at 01:47
  • @Cam: Of course it will take *some* time, but is there a real situation where a few days really count? Especially if it's just as possible to put the vital portions on the server, where nobody will ever get it unless they break into the system (which is considerably harder than if your have any security at all, and may have a much higher inhibition)? –  Jul 15 '11 at 12:43
  • @delnan: Sure - there are tons of examples. Suppose you're running some kind of time-limited service and you want to limit the amount of spam/abuse. For example say there's a sports game coming up and you release a service on your sports website that's relevant to the game. Once it's over it doesn't matter but unti then you want to make it harder for your competitors to steal the JS.Your same argument could be made for a lot of multiplayer videogames that attempt to detect cheating, but they all still do it. So maybe you want to obfuscate some anti-cheat code for an html5 or flash game. – Cam Jul 15 '11 at 16:15
  • I just don't understand what people have against obfuscation. It's a very small amount of extra protection, but it's there. Why not take advantage? It's like how we lock our doors at night - it's not very helpful but we still do it. – Cam Jul 15 '11 at 16:16
  • @Cam: I'm not against obfuscation per se. But when used to protect client-side code and a server is involved anyway, there is an infinitely more efficient protection method available that has little to no extra cost (putting the parts to be protected onto the server) available - I don't understand why it is ignored. That's my main point, and your examples don't seem to cover it - or do they? –  Jul 15 '11 at 17:52
  • @delnan: Ok so it turns out we actually agree. What I believe is that for maximum security you should move all code possible to the serverside, and then whatever remains you should obfuscate. For example with the flash/html5 game example, you'd put as much cheat detection as possible on the server, bu you'd need some JS so you'd obfuscate that – Cam Jul 15 '11 at 20:17
  • @pimvdb all I had to do is put a break point on `eval(S)` an look at the value of `S`. not that hard. – Erdogan Kurtur Feb 28 '13 at 09:04
  • I will give you another example. I am running trials on my web site and attackers are cloning my website and replicating API calls from their proxy API and selling my trials. The only solution seems to be to sign the request with domain and timestamp included and obfuscate the JS so that the attacker couldn't replicate the request signature – Toolkit May 23 '22 at 08:01

3 Answers3

5

Write it in Java, then run the bytecode in JavaScript with an obfuscated orto. That'll require two layers of decompilation in order to make any sense of it.

tadman
  • 208,517
  • 23
  • 234
  • 262
  • Woops, I liked the answer but here is a report that [orto is dead](http://stackoverflow.com/questions/1444681/does-anyone-know-where-i-can-find-the-orto-javascript-jvm/1444861) – cmc Jul 22 '11 at 15:22
  • 1
    That would probably make it even harder to reverse engineer. I'd call that a feature. The truth is, even Java bytecode can be "decompiled" so you'll never have true source code protection. The best you can hope for is to make it really hard, more trouble than it's worth. I answered [a related question](http://stackoverflow.com/questions/2862470/javascript-library-to-obfuscate-or-not-to-obfuscate-that-is-the-question/2863059#2863059) about how to achieve that sort of thing. – tadman Jul 22 '11 at 17:35
  • excellent architecture discussion, tadman! When I get enough info for a final answer I'll see if I can edit a summary of your answer in. – cmc Jul 24 '11 at 09:30
3

I'd be curious as to why you want to do this. Obfuscation offers no real protection. If you have something to protect, move it to the server-side, otherwise, why bother. If you're doing as you should and minifying/combining your JS that should be more than enough to scare away anyone not serious about knowing what your code is doing, and has performance benefits to boot. If they are serious, obfuscation isn't going to help you.

aepheus
  • 7,827
  • 7
  • 36
  • 51
  • 6
    Obfuscation is certainly not real protection. Anyone who seriously wants to know what obfuscated code is doing can figure it out. But, that doesn't make it completely value-less as long as the one using it knows what they're getting. Obfuscation adds a level of complexity to reverse-engineering or re-using the code. That level of complexity raises the bar for who would go to the trouble of figuring out how to reverse-engineer the code or steal/borrow the code. A really motivated thief can still get it (with more work), but others won't see it as not worth the trouble and will skip it. – jfriend00 Jul 14 '11 at 18:40
  • 3
    To remove enough information from the source code to push it beyond the point where it is easier to just repogram it from scratch. – cmc Dec 17 '11 at 01:22
3

The JavaScript Code Encrypter And Obfuscator looked nice, until I actually tried to attack it. Took me about two minutes. The trivial solution:

for (i in window) { console.log(window[i]) }

That churned out a bunch of gibberish, but also the original code neatly boinked into one variable.

Note to self: Never, ever, ever, ever use anything you don't fully understand when it comes to security.

cmc
  • 4,294
  • 2
  • 35
  • 34