747

I want to make a JavaScript application that's not open source, and thus I wish to learn how to can obfuscate my JS code? Is this possible?

Chuck Le Butt
  • 47,570
  • 62
  • 203
  • 289
Teifion
  • 108,121
  • 75
  • 161
  • 195
  • 16
    I'd be interested to hear the reason you are trying to obfuscate the code, it might give some needed context to give a helpful answer. – JohnFx Jan 24 '09 at 00:46
  • 49
    The only way to truly keep something secret is to *not send it to the client*. If they don't have it, they can't read it. Sending it encrypted is just asking for trouble at the hands of the few people who actually care, and everyone else won't poke around even if you send it in the clear (c.f. DRM). – Donal Fellows Jun 08 '10 at 20:42
  • 10
    [This tool is really great you can do it online obfuscation](http://www.javascriptobfuscator.com/default.aspx) [One more link for obfuscation](http://www.daftlogic.com/projects-online-javascript-obfuscator.htm) – RPB Mar 22 '12 at 12:05
  • 2
    You can try this [one](http://compressor.atomproject.net/) its online and have functionality for compression of CSS and JS. – Ivan Baev Jun 06 '12 at 07:47
  • 1
    Or http://utf-8.jp/public/aaencode.html – Jason C Mar 24 '14 at 05:28
  • 1
    here another solution : http://stackoverflow.com/questions/2060984/how-can-i-encrypt-javascript-code-so-that-its-not-decryptable – T.Todua Jun 10 '14 at 17:21
  • @JasonC Haha, I hadn't seen that one before but I'd seen the awesome http://utf-8.jp/public/jjencode.html – TheZ Aug 17 '14 at 05:34
  • 10
    Obfuscating your code __is not a good idea.__ It will only inconvenience legitimate users (eg. when they need to fix a bug), and do nothing to 'protect' it from people who have a (financial) incentive to reverse-engineer it. It is __fundamentally impossible__ to prevent reverse-engineering of Javascript code. – Sven Slootweg Mar 29 '15 at 18:53
  • 2
    Ad been said, your code will never be safe as far as copying goes. It can generate the "ugliest" code but if someone spends enough time, they can decode your code. – Evan Carslake Jul 18 '15 at 22:35
  • 22
    The argument not to obfuscate seems flawed to me. Unless you really think your users might fix/report bugs, then you should do it. It can decrease load times by minifying. It will never stop a really dedicated hacker, but it will slow him/her down and it will stop half-arsed hack attempts. It's very easy to do and there are many tools (see other answers), I'd say certainly do it as there are only advantages most of the time, but don't expect it to bring real security or to stop someone copying your code if they really want to. The only way to do this is to keep code server side and use ajax. – Benjamin Mar 27 '16 at 20:09
  • [The best javascript obfuscator](http://jsobfuscator.byethost7.com/) thats how i make it work. It is even not decoded by js beautifier. ;) – abhishek bagul May 03 '16 at 12:08
  • 1
    Most of the obfuscators mentioned here can be reversed simply by setting `window.eval = console.log.bind(console);` before running the script. At best, the result after running that will be the same as from running a minifier on the original, so I don't see any real advantages of using a dedicated obfuscator over just using a minifier. Especially since obfuscated code is usually more bloated (and slower to load) than minified code. – Hjulle Jun 02 '16 at 11:59
  • 2
    In conclusion: Before choosing an obfuscator, try running an obfuscated example after setting `var oldEval = window.eval; window.eval= function(x){console.log(x); return oldEval(x)}` . Then paste the result into jsbeautifier and see if it still looks obfuscated. If not, choose another obfuscator. – Hjulle Jun 02 '16 at 13:49
  • 3
    Or even simpler: Just paste the example in http://deobfuscatejavascript.com/. The results from "the best javascript obfuscator" (according to @abhishekbagul) after running the deobfuscator is exactly the same as the original source, even including comments! – Hjulle Jun 02 '16 at 13:59
  • 1
    [This online obfuscator](https://javascriptobfuscator.herokuapp.com) is really simple to use, or if you're using Node.js or have it installed, you can use this project: [javascript-obfuscator](https://github.com/javascript-obfuscator/javascript-obfuscator) `npm install --save-dev javascript-obfuscator `which is open source and really good. – Tiago Oct 25 '16 at 01:23
  • Use Encode.js : encodejs.devincity.com – nachshon f Apr 30 '17 at 17:35
  • 1
    I made a solution for this: https://github.com/blackmiaool/decent-messup – blackmiaool Jun 10 '17 at 12:03
  • For every obfuscator a deobfuscator can be made. – Rainb Jul 11 '18 at 12:37
  • Try moving your code to worker threads and using importScripts("yourscript.js");, they will be less easy to see in the debugger as they will be available only when loaded (stepped in to) and are hidden by default. – ejectamenta Dec 04 '18 at 18:02
  • 3
    It's unfortunate that this question is closed. It is a common problem, with a variety of solutions, all of which are quite tractable to explain and compare/contrast without clarifying the question. – Scott Smith Jun 12 '19 at 08:01
  • 1
    @Benjamin: the argument is not flawed, it's just perfectly aligned and politically correct in accordance to current agenda which states 'work for fun and exposure, and let others rake in your money'. – sunny moon Sep 04 '20 at 10:53
  • Somewhat old question but maybe still interesting for some of you: http://obfuscator.io does some decent obfuscating and you really need some effort, to understand the code. – Moldevort May 29 '21 at 20:54
  • One not easy but good method: Do not use JavaScript. – i486 Sep 15 '21 at 09:51

22 Answers22

430

Obfuscation:

Try YUI Compressor. It's a very popular tool, built, enhanced and maintained by the Yahoo UI team.

You may also use:

UPDATE: This question was originally asked on 2008, and The mentioned technologies are deprecated. you can use:

Private String Data:

Keeping string values private is a different concern, and obfuscation won't really be of much benefit. Of course, by packaging up your source into a garbled, minified mess, you have a light version of security through obscurity. Most of the time, it's your user who is viewing the source, and the string values on the client are intended for their use, so that sort of private string value isn't often necessary.

If you really had a value that you never wanted a user to see, you would have a couple of options. First, you could do some kind of encryption, which is decrypted at page load. That would probably be one of the most secure options, but also a lot of work which may be unnecessary. You could probably base64 encode some string values, and that would be easier.. but someone who really wanted those string values could easily decode them. Encryption is the only way to truly prevent anyone from accessing your data, and most people find that to be more security than they need.

Sidenote:

Obfuscation in Javascript has been known to cause some bugs. The obfuscators are getting a little better about it, but many outfits decide that they see enough benefit from minifying and gzipping, and the added savings of obfuscation isn't always worth the trouble. If you're trying to protect your source, maybe you'll decide that it's worth your while, just to make your code harder to read. JSMin is a good alternative.

keparo
  • 33,450
  • 13
  • 60
  • 66
  • 37
    I want to add that doing a base64 encode will be of no benefit to security, since it is a trivially reversable procedure. Even encrypting it won't help if it's decrypted client-side. The only way to ensure security of a string is to have the client ONLY see the encrypted string, and it is passed to – Claudiu Oct 11 '08 at 21:13
  • 18
    the server for further processing. – Claudiu Oct 11 '08 at 21:14
  • 10
    FYI, online YUI compressor may be found here: http://refresh-sf.com/yui/ – mtness Jan 19 '10 at 14:45
  • 9
    Encrypting the string values will be only of marginally more benefit than base64 encoding them, if they have to be decrypted by the browser to use them. The reason is that you'll have to give the browser the encryption key as well, and anything the browser can do the user can too. – Ben Jan 01 '12 at 05:27
  • 9
    When I do my minifying with YUI Compressor I make sure it uses "safe" minification methods, ie it keeps the semi-colons `--preserve-semi`. Rewriting the private variables to a, b, c etc is usually safe. Another thing I do is make the minifier put a line break after each semi-colon in the code `--line-break 0`. Then in production if it errors I least have a valid reference line to work from and can find that code in my development copy. Otherwise you just end up with an error on a massive line of code and no idea where the error is. – zuallauz Feb 15 '13 at 01:36
  • Use Encode.js : encodejs.devincity.com – nachshon f Apr 21 '16 at 15:47
  • 1
    @nachshonf why? How is Encode.js better than the more popular solutions mentioned above? – Redoman May 23 '16 at 12:38
  • Minification offers no protection as a browser's developer tools perfectly recreate minified source code. – Chris Apr 27 '22 at 14:30
  • 1
    @Chris Only if your build tools generate source maps, I believe. – Hashim Aziz Jun 09 '22 at 18:34
  • Created an HTML Obfuscator using JavaScript, it obfucates script quite well. Created this quite a while ago, over 10 years ago, you can use it freely on my archival server. http://vps-net.com/internet-development-tools/html-data-obfuscation-web-tool.php – DoctorLouie Jul 03 '22 at 07:29
142

I'm surprised no one has mentioned Google's Closure Compiler. It doesn't just minify/compress, it analyzes to find and remove unused code, and rewrites for maximum minification. It can also do type checking and will warn about syntax errors.

JQuery recently switched from YUI Compresser to Closure Compiler, and saw a "solid improvement"

Jason Hall
  • 20,632
  • 4
  • 50
  • 57
  • 65
    yes, but recently they left Closure compiler and are using UglifyJS now. The JQuery code was buggy after compressing with closure compiler – Chielus May 24 '11 at 07:32
  • I would like to note that, if your working with angular. this tool won't really work because of the dependency injection and the renaming of arguments, unless there is a checkbox I can't see. – iConnor Aug 16 '13 at 23:41
  • 1
    Useful tool, but it doesn't do obfuscation which is probably why nobody else had mentioned it. – Madbreaks Mar 25 '14 at 23:18
  • 1
    @Madbreaks with Advanced Optimizations (https://developers.google.com/closure/compiler/docs/api-tutorial3) it will minify the code to the point of obfuscation. Variables can be renamed for brevity, for instance. – Jason Hall Mar 26 '14 at 22:43
  • Google is not an option for security either – Fillipo Sniper Oct 17 '18 at 00:44
128

Obfuscation can never really work. For anyone who really wants to get at your code, it's just a speed bump. Worse, it keeps your users from fixing bugs (and shipping the fixes back to you), and makes it harder for you to diagnose problems in the field. Its a waste of your time and money.

Talk to a lawyer about intellectual property law and what your legal options are. "Open Source" does not mean "people can read the source". Instead, Open Source is a particular licensing model granting permission to freely use and modify your code. If you don't grant such a license then people copying your code are in violation and (in most of the world) you have legal options to stop them.

The only way you can really protect your code is to not ship it. Move the important code server-side and have your public Javascript code do Ajax calls to it.

See my full answer about obfuscators here.

Community
  • 1
  • 1
Schwern
  • 153,029
  • 25
  • 195
  • 336
  • 24
    Lawyers probably create more costs/issues than the lost code, think very carefully and arrange lots of money to engage lawyers!! – andora Mar 10 '11 at 13:14
  • 14
    -1: I believe that finding a lawyer that understand JavaScript would be hard... Not to the mention the fees and the amount of time needed to find "violators". Can someone really be violating a license that is buried in the HTML/JavaScript files if he never signed anything? +1 for the AJAX calls. – Alerty Oct 30 '11 at 17:14
  • 16
    @Alerty 1) Licenses fundamentally are about *granting* use of copyrighted material. You have little right to use it without the license. You don't have to sign it to get the rights. A license is different from a contract. 2a) Since the question is about people copying and using the HTML/Javascript without permission, the license is not "buried", it's right there on the thing being taken. 2b) You have little right to use someone else's copyrighted material without a license. 3) The lawyer does not need to understand Javascript, just intellectual property law. – Schwern Oct 31 '11 at 19:06
  • 1
    @Schwern: I would logically assume that there had to be some kind of license software agreement in order to validate the conditions of the usage of the copyrighted material. There is no way to see those conditions without loading the page that contains the license within the JavaScript file. So for example, if the license says that the end user must give $100 for each use there would be no way for the end user to accept before using the copyrighted material. In other words, it would not be fair and could be seen has fraudulent. – Alerty Nov 01 '11 at 04:19
  • 6
    @Alerty Don't be obtuse. This is about punishing those who copy the file for use on their own site without permission. What you're talking about is a contract, not a license. Contracts require mutual assent and are a give and take. Licenses grant you right to use intellectual property. Licenses are one way (the owner is granting you things), you are not required to sign because you are not giving anything away. Many "Software License Agreements" are actually contracts because they go beyond licensing the property and into sometimes ridiculous things like right to sue. – Schwern Nov 02 '11 at 00:01
  • lets say you wanted to make a photoshop out of canvas, there is no way sending data back and forth would work. Untill everyone gets 1gb/s internet. So yea, some programs can't be made money of in javascript. Therefore, they need to have different business structure. Provide Cloud only storage, make it open source, innovate so fast that leave all copiers behind. Etc. – Muhammad Umer Jul 26 '13 at 05:29
  • 2
    Free online obfuscator vs complicated expensive lawyer...I wonder which I will choose – markasoftware Aug 09 '13 at 19:42
  • 1
    It is almost as if the people seeking this have not given that much thought to how much benefit and how much effort it would be to "protect" their work... – Casey Feb 13 '14 at 17:48
  • 3
    Down-voted for saying 'hire a lawyer'. What an obnoxious statement. You cannot copyright Javascript that is ran on the WWW.That's like the same logic as copyrighting a custom CSS class. Good luck. – NiCk Newman May 18 '15 at 05:20
  • 2
    @NiCkNewman While copyright law is different from country to country, in most countries you (or the company you have assigned your copyright to) have copyright over the code you write including HTML, Javascript and CSS. In many countries you automatically have copyright over your work. Putting it on the web does not change that. You might want to talk to a lawyer or do some research if you're in the publishing field (and if you're a programmer, you are) and don't understand copyright and licensing, your rights over your works, and the rights of others. – Schwern May 18 '15 at 16:47
  • 3
    Door locks can never really work. For anyone who really wants to get at your property, it's just a speed bump. Worse, it keeps your friends from fixing problems in your house, and makes it harder for you to diagnose problems in the field. Its a waste of your time and money. – user626528 Oct 02 '18 at 20:14
  • 2
    @user626528 Anyone in the world can try to break these door locks. They can try to break them as many times as they like. You can't know if people are trying to break your lock. If they break in you will never know. High quality automatic picks (decompilers/deobfuscators) are freely available. These are the essential differences between physical security and online security. – Schwern Oct 02 '18 at 20:38
  • And nonetheless, any physical lock on your house, car, office, etc is just a speed bump for someone really determined and well equipped. Quit using them, they are just a waste of your time and money. – user626528 Oct 02 '18 at 21:06
  • `The only way you can really protect your code is to not ship it. Move the important code server-side and have your public Javascript code do Ajax calls to it.` nosense if are talking about speed bump, taking the code from ajax calls will take less time than reverse ing. Proper obfuscation will make the work,"speed bump" is part of the game, so let's the crackers take their time and us make the job – jamesjara Jan 05 '19 at 14:45
  • All good and ponies in rainbows, but are there any lawyers out there who defend their clients for free, giving away their knowledge to educate those just for the sake of high etics and love for sharing? – sunny moon Sep 04 '20 at 10:40
  • I totally disagree whenever I hear "talk to layer". Leave the door in your house opened and talk to your layer how to protect your property. If that approach would worked, Google, Facebook and Microsoft would have relied on that long time ago. – Max Sep 16 '21 at 14:46
  • 1
    @Max Just how obfuscation is nothing more than a speed bump if you know what you're doing, it's the same with locks. You don't need to be an expert, just [watch some YouTube videos](https://www.youtube.com/c/lockpickinglawyer). A door lock protects you because a limited number of people can pick the lock and they need to expose themselves to do it. If 7 billion people could invisibly and extralegally try to pick the lock on your door you'd think differently about the security afforded to you by your door lock. Sleep tight. Google, Facebook, and Microsoft bother with obfuscation for security. – Schwern Sep 16 '21 at 14:51
49

You can obfuscate the javascript source all you want, but it will always be reverse-engineerable just by virtue of requiring all the source code to actually run on the client machine... the best option I can think of is having all your processing done with server-side code, and all the client code javascript does is send requests for processing to the server itself. Otherwise, anyone will always be able to keep track of all operations that the code is doing.

Someone mentioned base64 to keep strings safe. This is a terrible idea. Base64 is immediately recognizable by the types of people who would want to reverse engineer your code. The first thing they'll do is unencode it and see what it is.

El Ronnoco
  • 11,753
  • 5
  • 38
  • 65
Claudiu
  • 224,032
  • 165
  • 485
  • 680
  • 1
    @Claudiu Please explain what you mean by server-side javascript. I didn't understand. – Vivek Kodira Oct 12 '08 at 04:10
  • 66
    Wherever I go, the most common answer to "how can I obfuscate my Javascript?" is "you shouldn't worry about that because someone could un-obfuscate it." This is not really an answer. – Travis Wilson Jul 31 '09 at 16:00
  • 2
    @Vivek: A bit late, but what I really meant is "server-side code". It is possible to run javascript not in a browser, just on a server, but I don't know how common that is. – Claudiu Oct 06 '10 at 22:00
  • 8
    @Travis: I didn't say "you shouldn't worry about it." I just said that if you want a closed-source program, you're not going to want to write it in client-side javascript, because any obfuscation you do will not prevent it from being (pretty easily) reverse-engineered. – Claudiu Oct 06 '10 at 22:01
  • 9
    Right. Which in no way answers "how can I obfuscate my JavaScript". Obfuscation isn't an abstract concept, it's a technical one. The op simply asked "how?" – Madbreaks Mar 19 '14 at 06:10
  • 2
    @Madbreaks: The question was in the context of not making his code open source. The immediate technical answer is the accepted one, but the better in-context answer (as in, what are you really trying to do?) is, IMO, that you cannot have client-side javascript that isn't open-source, because everybody has the source, regardless of how you obfuscate it. Either way both answers are here and people can read and benefit from both. – Claudiu Mar 19 '14 at 06:58
  • 1
    The answer is "You can't. And here's why...". It may not be the answer the OP was looking for but it is the answer to his question, provided with a rationale. I think Claudiu and the other responders have done a good job of actually answering the question. – U007D Mar 29 '15 at 22:47
  • The answer is: `wasm`! Write code in C then translate to `wasm`. IT WILL BE SUPPORTED IN THE NEXT 5 YEARS. WAIT. OR INSTALL Chrome Canary to try it. –  Oct 02 '16 at 03:07
45

There are a number of JavaScript obfuscation tools that are freely available; however, I think it's important to note that it is difficult to obfuscate JavaScript to the point where it cannot be reverse-engineered.

To that end, there are several options that I've used to some degree overtime:

  • YUI Compressor. Yahoo!'s JavaScript compressor does a good job of condensing the code that will improve its load time. There is a small level of obfuscation that works relatively well. Essentially, Compressor will change function names, remove white space, and modify local variables. This is what I use most often. This is an open-source Java-based tool.

  • JSMin is a tool written by Douglas Crockford that seeks to minify your JavaScript source. In Crockford's own words, "JSMin does not obfuscate, but it does uglify." It's primary goal is to minify the size of your source for faster loading in browsers.

  • Free JavaScript Obfuscator. This is a web-based tool that attempts to obfuscate your code by actually encoding it. I think that the trade-offs of its form of encoding (or obfuscation) could come at the cost of filesize; however, that's a matter of personal preference.

Tom
  • 15,527
  • 5
  • 48
  • 62
  • 20
    Since the Javascript code must run on the client's machine it is not just difficult to obfuscate to the point where code can not be reversed-engineered but *impossible*. – Schwern Oct 25 '08 at 23:27
  • 23
    it's about statistics. what's the threshold that someone is going to get access to your code at with obfuscation and without? they can still get access, but the higher the threshold, the fewer the people. the fewer people know about something, the safer that something. standard security classification practice. – Cris Stringfellow Feb 22 '12 at 11:45
  • Have you tried http://www.zeroify.com obfuscator? It uses Minification and Compression but also renames classes and IDs to make it harder to understand the intent of classes and objects – SED May 20 '17 at 02:02
  • @SED Is that a joke, they seem to just replace variable/function names with `ZER0O00OIFY ` using different combinations of [o,O,0]. If I really wanted to read that code I could, and a search/replace in a text editor would take a few mins. If people want to read your JS they will. Any client side JS that someone really wants to use, will get used. Either run it server side, or get over it. Chances are your code is not unique, or novel. Stick a license on it if you really want to. – Peter R Aug 21 '17 at 21:45
  • 1
    @PeterR search/replace in a text editor is going to make your life that much more difficult trying to read it or reverse engineer it. it's not perfect, but does add an extra layer of annoyance/difficulty by removing context clues. most programmers aren't as smart as you, which is what makes this such a great deterrent. – SED Aug 22 '17 at 23:06
  • 1
    @SED I don't know a single programmer that couldn't find/replace a bunch of `[ZER0O00OIFY, ZER0000OIFY, ZEROO00OIFY, ZEROOO0OIFY]` vars into at least `[var1, var2,..]` within a single minute. I can literally de-uglify, re-indent, and search/replace var names within two minutes. And no, I'm any smarter than an average Jr. Dev. The simple fact is, there is NO way to obscure client side JS. You can buy yourself 5 minutes, MAX, but that's of no use. This stuff is really just to sell someone who doesn't know code on added "Security". No one who has ever written a line of JS would buy that crap. – Peter R Aug 23 '17 at 07:11
  • 4
    @PeterR _"I can literally de-uglify, re-indent, and search/replace var names within two minutes"_ -- sure, go ahead and try that on a multi-pass minified, obfuscated, 20MB codebase bundle with a structure that takes weeks to understand even with the original, commented source code. And to make it even harder, obfuscation tools exist that deliberately make your code broken if indentation, lines, etc. change. – John Weisz Apr 01 '19 at 20:53
29

What i would do:

A. Troll the hacker!

This is will be in the second part my fake/obfuscated secret javascript code LAUNCHER. The one you see in the source code.

What does this code?

  1. loads the real code
  2. sets a custom header
  3. posts a custom variable

var ajax=function(a,b,d,c,e,f){
 e=new FormData();
 for(f in d){e.append(f,d[f]);};
 c=new XMLHttpRequest();
 c.open('POST',a);
 c.setRequestHeader("Troll1","lol");
 c.onload=b;
 c.send(e);
};
window.onload=function(){
 ajax('Troll.php',function(){
  (new Function(atob(this.response)))()
 },{'Troll2':'lol'});
}

B. Obfuscate the code a little

What is that?

  1. thats the same code as above in base64
  2. this is not the SECRET javascript code

(new Function(atob('dmFyIGFqYXg9ZnVuY3Rpb24oYSxiLGQsYyxlLGYpe2U9bmV3IEZvcm1EYXRhKCk7Zm9yKGYgaW4gZCl7ZS5hcHBlbmQoZixkW2ZdKTt9O2M9bmV3IFhNTEh0dHBSZXF1ZXN0KCk7Yy5vcGVuKCdQT1NUJyxhKTtjLnNldFJlcXVlc3RIZWFkZXIoIlRyb2xsMSIsImxvbCIpO2Mub25sb2FkPWI7Yy5zZW5kKGUpO307d2luZG93Lm9ubG9hZD1mdW5jdGlvbigpe2FqYXgoJ1Ryb2xsLnBocCcsZnVuY3Rpb24oKXsgKG5ldyBGdW5jdGlvbihhdG9iKHRoaXMucmVzcG9uc2UpKSkoKX0seydUcm9sbDInOidsb2wnfSk7fQ==')))()

C Create a hard to display php file with the real code inside

What does this php code?

  1. Checks for the right referrer (domain/dir/code of your launcher)
  2. Checks for the custom HEADER
  3. Checks for the custom POST variable

If everything is ok it will show you the right code else a fake code or ban ip, close page.. whatever.

<?php
$t1=apache_request_headers();
if(base64_encode($_SERVER['HTTP_REFERER'])=='aHR0cDovL2hlcmUuaXMvbXkvbGF1bmNoZXIuaHRtbA=='&&$_POST['Troll2']=='lol'&&$t1['Troll1']='lol'){
 echo 'ZG9jdW1lbnQuYm9keS5hcHBlbmRDaGlsZChkb2N1bWVudC5jcmVhdGVFbGVtZW50KCdkaXYnKSkuaW5uZXJUZXh0PSdBd2Vzb21lJzsNCg==';//here is the SECRET javascript code
}else{
 echo 'd2luZG93Lm9wZW4oJycsICdfc2VsZicsICcnKTt3aW5kb3cuY2xvc2UoKTs=';
};
?>

base64 referrer = http://here.is/my/launcher.html

SECRET javascript = document.body.appendChild(document.createElement('div')).innerText='Awesome';

FAKE = window.open('', '_self', '');window.close();

Now .. if you define event handlers in the SECRET javascript it's probably accessible.. you need to define them outside with the launchcode and pointing to a nested SECRET function.

SO... is there a easy wayto get the code? document.body.appendChild(document.createElement('div')).innerText='Awesome';

I'm not sure if this works but i'm using chrome and checked Elements,Resources,Network,Sources,Timeline,Profiles,Audits but i didn't find the line above.

note1: if u open the Troll.php url from Inspect element->network in chrome you get the fake code.

note2: the whole code is written for modern browsers. polyfill needs alot more code.

EDIT

launcher.html

<!doctype html><html><head><meta charset="utf-8"><title></title><script src="data:application/javascript;base64,KG5ldyBGdW5jdGlvbihhdG9iKCdkbUZ5SUdGcVlYZzlablZ1WTNScGIyNG9ZU3hpTEdRc1l5eGxMR1lwZTJVOWJtVjNJRVp2Y20xRVlYUmhLQ2s3Wm05eUtHWWdhVzRnWkNsN1pTNWhjSEJsYm1Rb1ppeGtXMlpkS1R0OU8yTTlibVYzSUZoTlRFaDBkSEJTWlhGMVpYTjBLQ2s3WXk1dmNHVnVLQ2RRVDFOVUp5eGhLVHRqTG5ObGRGSmxjWFZsYzNSSVpXRmtaWElvSWxSeWIyeHNNU0lzSW14dmJDSXBPMk11YjI1c2IyRmtQV0k3WXk1elpXNWtLR1VwTzMwN2QybHVaRzkzTG05dWJHOWhaRDFtZFc1amRHbHZiaWdwZTJGcVlYZ29KMVJ5YjJ4c0xuQm9jQ2NzWm5WdVkzUnBiMjRvS1hzZ0tHNWxkeUJHZFc1amRHbHZiaWhoZEc5aUtIUm9hWE11Y21WemNHOXVjMlVwS1Nrb0tYMHNleWRVY205c2JESW5PaWRzYjJ3bmZTazdmUT09JykpKSgp"></script></head><body></body></html>

Troll.php

<?php $t1=apache_request_headers();if(/*base64_encode($_SERVER['HTTP_REFERER'])=='PUT THE LAUNCHER REFERER HERE'&&*/$_POST['Troll2']=='lol'&&$t1['Troll1']='lol'){echo 'ZG9jdW1lbnQuYm9keS5hcHBlbmRDaGlsZChkb2N1bWVudC5jcmVhdGVFbGVtZW50KCdkaXYnKSkuaW5uZXJUZXh0PSdBd2Vzb21lJzsNCg==';}else{echo 'd2luZG93Lm9wZW4oJycsICdfc2VsZicsICcnKTt3aW5kb3cuY2xvc2UoKTs=';}; ?>
cocco
  • 16,442
  • 7
  • 62
  • 77
  • 2
    oh and yes i would also obfuscate the javascript code. – cocco Jul 04 '13 at 11:14
  • 1
    This is something I was just thinking about, trolling the cracker. I would like to see something like this without having to use PHP :) – pgarciacamou May 19 '15 at 17:33
  • 9
    Even if this is funny, a web developer who is able to properly inspect the site, can somehow get the source code. I really think that there is no way to hide any type of data at the moment you put it online. – cocco May 19 '15 at 17:38
  • It is not any kind of obfuscation i think. however knows how to open console, he might also know about base64 encoding/decoding, very simple. – T.Todua Dec 14 '17 at 11:44
20

The problem with interpreted languages, is that you send the source to get them working (unless you have a compiler to bytecode, but then again, it is quite trivial to decompile).

So, if you don't want to sacrifice performance, you can only act on variable and function names, eg. replacing them with a, b... aa, ab... or a101, a102, etc. And, of course, remove as much space/newlines as you can (that's what so called JS compressors do).
Obfuscating strings will have a performance hit, if you have to encrypt them and decrypt them in real time. Plus a JS debugger can show the final values...

PhiLho
  • 40,535
  • 6
  • 96
  • 134
20

Try JScrambler. I gave it a spin recently and was impressed by it. It provides a set of templates for obfuscation with predefined settings for those who don't care much about the details and just want to get it done quickly. You can also create custom obfuscation by choosing whatever transformations/techniques you want.

Chad Hedgcock
  • 11,125
  • 3
  • 36
  • 44
Anthony
  • 225
  • 2
  • 2
  • 8
    JScrambler subscription is very very expensive... Cheapest subscription require minimum 3 month price $145 - it's crazy. – barbushin Aug 11 '13 at 11:16
  • 1
    They now have a free plan. The other subscription plans are still that pricy. – user7610 Sep 01 '13 at 21:30
  • 2
    The free plan only includes optimization and minification. – Jean Hominal Oct 24 '14 at 15:49
  • 1
    'The free plan includes optimization and minification', yeah no. Obfuscation and optimization don't go together, sorry. – NiCk Newman May 18 '15 at 05:17
  • 2
    Looking at JScrambler's website today and more-so pricing plans I can't see a free option. Only a free trial.. – KDT Jan 30 '16 at 17:54
  • I was pretty frustrated with JScrambler because there's no good c# client for it and the API docs don't tell you enough to be able to make the rest calls from scratch, but their customer support makes it worth my boss' money. – Chad Hedgcock Mar 31 '16 at 01:20
18

Contrary to most of the other answers I suggest against YUI Compressor; you should use Google Closure.

Not much because it compresses more, but mostly because it will catch javascript errors such as a = [1,2,3,]; which make IE go haywire.

jball
  • 24,791
  • 9
  • 70
  • 92
Andreas Bonini
  • 44,018
  • 30
  • 122
  • 156
  • 5
    shouldn't checking your code against errors and incompatibility be done either way *before* obfuscating?? has nothing to do with obfuscating actually – phil294 Nov 29 '15 at 13:35
12

I can recommend JavaScript Utility by Patrick J. O'Neil. It can obfuscate/compact and compress and it seems to be pretty good at these. That said, I never tried integrating it in a build script of any kind.

As for obfuscating vs. minifying - I am not a big fan of the former. It makes debugging impossible (Error at line 1... "wait, there is only one line") and they always take time to unpack. But if you need to... well.

ʍǝɥʇɐɯ
  • 4,012
  • 7
  • 32
  • 53
Tsvetomir Tsonev
  • 105,726
  • 5
  • 27
  • 34
  • 1
    But obfuscating doesn't necessarily compress it to one line, it could be as simple as changing the function and variable names or converting strings to base64. Minifying puts all the code on one line. – rw-nandemo Jun 18 '14 at 16:19
  • Nowadays UglifyJS seems to be the best choice. The author is a cool guy too! :) – Tsvetomir Tsonev Feb 17 '16 at 13:47
  • Regarding debugging, you can mostly generate sourcemaps which you can include when testing so you can see on which line an error occurred, even if it's minified. – Luca Steeb Aug 04 '16 at 12:26
11

A non-open-source Javascript-based application is fairly silly. Javascript is a client-side interpreted language.. Obfuscation isn't much protection..

JS obfuscation is usually done to reduce the size of the script, rather than "protect" it. If you are in a situation where you don't want your code to be public, Javascript isn't the right language..

There are plenty of tools around, but most have the word "compressor" (or "minifier") in its name for a reason..

dbr
  • 165,801
  • 69
  • 278
  • 343
10

You can't secure client side code: just press F12 on Google Chrome, pause javascript execution and you will get all strings, even those encrypted. Beautify it and rename variables and you will get almost the original code.

If you're writing server side javascript (i.e. NodeJS) is afraid of someone hacking into your server and want to make the hacker work more difficult, giving you more time to get your access back, then use javacript compilers:

You need to use Closure Compiler on Advanced Compilation, as it's the only tool that renames all your variables, even if those are used in multiple files/modules. But it just have a problem: it only work if you write in it's coding style.

Gustavo Rodrigues
  • 3,517
  • 1
  • 25
  • 21
  • Closure compilng is not obfuscating code :P – NiCk Newman May 18 '15 at 05:15
  • 1
    It's not made for it, but works well doing it: it doesn't add extra code like some compilers ( which usually can be reversed which the tools I cited ) but changes it to uncommon ways, some even hard to undo, and remove unused code, which in comparison to real obfuscation is good for performance. – Gustavo Rodrigues May 18 '15 at 10:28
  • 1
    Not a good idea. Minifying/compiling code server-side might may introduce security issues if the minifier has a bug: https://zyan.scripts.mit.edu/blog/backdooring-js/ – mgol Aug 24 '15 at 17:13
  • The bug you cited applies only to UglifyJS: it don't apply to Closure Compiler. – Gustavo Rodrigues Aug 29 '15 at 14:26
  • For all those who care about minifying javascript files, there is also a javascript un-minifier. so I don,t think that is a layer of security at all – Fillipo Sniper Oct 17 '18 at 00:35
  • Minifiers already existed when I answered that, but minifiers don't get the original source code, but one with renamed variables and properties. There's statistical renaming but isn't that great. In the other hand one thing makes minification less efficient today is debugging, which got a lot better in those four years. – Gustavo Rodrigues Oct 18 '18 at 02:36
5

I would suggest first minify with something like YUI Compressor, and then convert all string and numbers to HEX Values using something like http://www.javascriptobfuscator.com/

With this, the code would be rendered near impossible to understand and I think at this Stage it will take more time for a Hacker to re-enact your code than actually if he re-wrote from scratch. Rewriting and Cloning is what you cant actually stop. After all we are free-people !

5

Dean Edward's Packer is an excellent obfuscator, though it primarily obfuscates the code, not any string elements you may have within your code.

See: Online Javascript Compression Tool and select Packer (Dean Edwards) from the dropdown

smdrager
  • 7,327
  • 6
  • 39
  • 49
5

Try this tool Javascript Obfuscator

I used it on my HTML5 game not only it reduced it size from 950KB to 150 but also made the source code unreadable closure compilers and minifiers are reversable I personally dont know how to reverse this obfuscation.

Jerczu
  • 75
  • 1
  • 1
4

Have you tried Bananascript? It produces highly compressed and completely unreadable code.

niutech
  • 28,923
  • 15
  • 96
  • 106
  • 21
    it compresses the code nicely, but just change the `eval()` in the last line to `console.log()` and your console will spit out the whole thing – LobsterMan Mar 20 '13 at 18:48
4

I'm under the impression that some enterprises (e.g.: JackBe) put encrypted JavaScript code inside *.gif files, rather than JS files, as an additional measure of obfuscation.

xgMz
  • 3,334
  • 2
  • 30
  • 23
4

I am using Closure-Compiler utility for the java-script obfuscation. It minifies the code and has more options for obfuscation. This utility is available at Google code at below URL:
Closure Tools

But now a days I am hearing much of UglifyJS. You can find various comparison between Closure Compiler and UglifyJS in which Uglify seems to be a winner.
UglifyJS: A Fast New JavaScript Compressor For Node.js That’s On Par With Closure

Soon I would give chance to UglifyJS.

shaILU
  • 2,050
  • 3
  • 21
  • 40
4

I've been using Jasob for years and it is hands down the best obfuscator out there.
It has an advanced UI but is still intuitive and easy to use.
It will also handle HTML and CSS files.

The best way to use it is to prefix all of your private variables with something like an underscore, then use the sort feature to group them all together and check them off as targets for obfuscation.

Users can still view your source, but it's much more difficult to decipher when your private variables are converted from something like _sUserPreferredNickName to a.

The engine will automatically tally up the number of targeted variables and prioritize them to get the maximum compression.

I don't work for Jasob and I get nothing out of promoting them, just offering some friendly advice.
The downside is that it's not free and is a little pricey, but still worth it when stacked against alternatives - the 'free' options don't even come close.

Shadow The GPT Wizard
  • 66,030
  • 26
  • 140
  • 208
Matt
  • 41
  • 1
3

As a JavaScript/HTML/CSS obfuscator/compressor you can also try Patu Digua.

Adrian
  • 41
  • 1
2

I've used this in the past, and it does a good job. It's not free, but you should definitely take a look.
JavaScript Obfuscator & Encoder

Henry
  • 2,870
  • 1
  • 25
  • 17
2

You definitely should consider taking a look at Obfuscriptor.

I goes beyond the typical Javascript minifying tricks we've seen from other tools such as YUI Compressor or Google Closure.

The obfuscated code looks more like encrypted. Unlike anything I've seen before.

Mike
  • 1,296
  • 2
  • 15
  • 40