A technique for hiding your JavaScript code | Hacker News Reader

A technique for hiding your JavaScript code

patrick-wied.at

62 pointspa735 comments

I can't help but feel saddened that we learned how to code using View Source (indeed, it's a big factor in the web's success) and now we're trying to prevent others doing the same.

Also, this seems like a surprisingly naive generalisation to me: "... a first measurement for preventing evil business guys from stealing your code – developers who can figure the code out are (mostly) kind enough not to steal it."

"Developer tools" is the new View Source. Browsers should really just redirect View Source to the live DOM view of their developer tools, that's what most people want from it.

Maybe, but there's still a lot of value in being able to see pre-rendered code so I wouldn't go as far as a redirect. Somehow combining the two could be a good option.

I like having them both personally. I'll normally use the page inspector for most things, but I like to see the raw HTML I'm producing from a web app too, along with the CSS and JS tags, etc.

Developer Tools would've scared the crap out've me when I was 11 years old trying to figure out how web pages worked.

The classic view source showing just text is a very powerful message: websites are just text[1]. As a young wannabe, it was very empowering for me to realize that all I had to do to accomplish my dreams was to open up Notepad and type some special text.

[1]: And images and videos and so on. That's not the point.

They do very different things. View source will show the document as delivered to the browser; developer tools show the page as rendered. You really need both.

The former already exists in your browser's Network panel of the developer tools. It's the response for /Foo from the server.

It should be demoted from "View Source" though; how the DOM got into its current state is not that important; only the current state really matters.

The author has replied with the edit:

ADD: Jeez, don’t get me wrong, I’m not really trying to hide my code from anyone, I actually love writing open source software, it was just a fun idea to do this experiment :)

This is a really good Idea! I will implement this in my site, where I blocked the right mouse-klick so nobody can steal my images!!11

Dude, you are kidding, right? I hope so.

The "11" at the end indicates that he is indeed kidding.

He meant "PrtScr" instead of "11" xD

Fun solution to a useless problem. Trying to hide your JS/HTML code is silly and pretty 1999-like.

There are poor web designs that are pretty 1999-like, but that doesn't stop people from doing it. To each their own.

>My JS code is an array of characters, a character has an ASCII code which lies in the range from 0 to 255

Your JS code may happen to be ASCII only, but in the context of ECMAScript, a character is actually a Unicode code unit.

Bonus points for not just creating an image, but hiding the code steganographically in an existing image (ie only using the LSB of each pixel to hide code)!

This might be quite effective in preventing people trying to reveal your code as part of their job. You could use some sort of obscene image to hide your code in.

But at some point you need to have the code on client side to get the code in string format, doesn't that give away how you've stored the code in the image?

Comments should make it fairly straightforward to accomplish:

function foo() {

/* ...characters for image data... /

bar();

/ ...more image data... */

The asterisks are not showing up but you get the idea. It checks out with the comments part of the javascript spec as well:

http://ecma-international.org/ecma-262/5.1/#sec-7.4

...as the text inside the comment can be any unicode code unit except for an asterisk (For source Character rules see http://ecma-international.org/ecma-262/5.1/#sec-6).

If you want asterisks to show up, * put a space on both sides.

  If you want to do something *f*a*n*c*y* put two spaces
  at the front of the line, it will show up verbatim
  including line breaks.

bonus points for hiding data in existing image without modifying it.

Here is an interesting application of this idea http://www.p01.org/releases/MATRAKA/matraka.png.html

Sure the beef of your code is hidden in image data but since the extraction method has to be exposed in regular JavaScript code, it's kinda useless.

If you are willing to use HTML5 'magic', could you not stream the JS down via a web socket and then execute it? That would prevent most of the conventional HTTP intercepts from having access to the code.

But won't web developer or similar show you any generated javascript?

As in putting a break point at line 125 and executing String.fromCharCode.apply(String, codes) on the console?

If someone is clever enough to hide their JavaScript like this, then they hopefully know that it isn't foolproof. In other words, don't rely on obfuscating your code for anything related to security (as an example).

Did you read to the bottom? He knows it doesn't really hide the code. He's just having fun and slowing down the lowest level of code-stealers.

Actually, this slows down all levels of code stealers. No longer can we simply copy and paste (or download if it is its of *.js file) into our editor of choice. Now, we have to open the dev console, call getCode(), and deal with any formatting issues that might arise (such as \\n -> \n).

Hm, has anybody thought of QR codes containing javascript already?

This is the exact same process used by http://hid.im to encode a torrent file into a PNG (not for obfuscation, mind you).

This might be useful as a way to reduce your code size using the image's compression algorithm

Maybe, but obviously we would need loss-less compression. And the current web standards like gzip are optimized and perfectly suited for "text-like" loss-less compression, so it seems a little pointless to apply any image-optimized loss-less compression.

Modern servers and browsers support the DEFLATE algorithm for compressing over HTTP, which is the same algorithm as PNG. The only difference is that PNG preprocesses with a predictor to exploit row-to-row correlations in an image. Since the assumptions of that predictor are less likely to be sound with JavaScript code than with practical image data, and since lossless compression is a zero-sum game, PNG will perform worse than plain old DEFLATE on average for JS code.

So after you get the code string, how do we run it? eval()?

Reply on news.ycombinator.com