Hacker News Reader

Comment by ollyfg | Hacker News Reader

I probably deserve to get downvoted to oblivion for this but... I've deployed JSFuck in production!

We wanted to obfuscate this bit of code, to make life just a little bit harder for reverse engineers. We made this huge function where we pretty much passed in all our application state, and it would run this JSFuck code, and spit out a token. We even made a few tweaks to the code so that you couldn't just reverse it back into JS with something like https://enkhee-osiris.github.io/Decoder-JSFuck/.

Performance was surprisingly alright, and it has never hit an environment where it couldn't execute. All in all, a fun few hours setting it up, and I haven't had to touch it since!

View on HN

makes me sad to hear that :( I will say, as a reverse engineer, that javascript minifiers like closure compiler will optimize almost all obfuscation out, and the rest you can usually translate to a form which it can understand and then it will do the rest.

The effect of obfuscation is not what you expect. It seems like it moves the whole difficulty up, but it only moves up the floor. By doing so it tends to remove all the signals that would warn non-experts of security issues. Remove the obfuscation and then you have all the catastrophic security issues that have accumulated in there like treasures in an egyptian king's tomb https://zemnmez.medium.com/how-to-hack-the-uk-tax-system-i-g...

I'm curious: can you can undo the obfuscation of JScrambler and Obfuscator.io easily? Some time ago I tried to run both through Closure Compiler, but it was way harder than I thought would be.

JScrambler I actually did de-obfuscate to bypass some very significant bot detection a few years ago, but it took a bit more doing -- it uses ES6 features IIRC so I had to transpile it down to ES5 via babel first, but it worked OK after that.

has a pretty good crack at obfuscator.io, too: https://closure-compiler.appspot.com/home#code%3D%252F%252F%...

That's the example from the site. "console.log('Hello world')" gets deobfuscated to "console[a(482)]("Hello World!");"

> That's the example from the site. "console.log('Hello world')" gets deobfuscated to "console[a(482)]("Hello World!");"

That does not look deobfuscated to me.

Anyone familiar with JS is going to have some really good guesses at what a(482) is in this case.

And, even if you don't, you can always call a(482)

Yes, but "obfuscated" means "To make so confused or opaque as to be difficult to perceive or understand". That's obfuscated, not deobfuscated.

Is that difficult? Harder, but still quite easy.

My point was that the GP seems to have mixed the words "obfuscate" and "deobfuscate".

To clarify, that's what happens once you pass it through the obfuscation and THEN closure compiler. If you click the link you will see the obfuscation is much more complex

Oh, then I misunderstood and everyone should ignore this whole thread :P

Do you consider Google Closure sufficiently good obfuscation?

I think closure compiler's 'obfuscation' is an incidental part of its minification passes.

Got it. Thank you.

I've been using the Google Closure compiler for many years with advanced and every time I look at the code output I'm like "there's no way in a 100 years I would be able to de-obfuscate back to my own code to a great extent". But I don't specialize in reverse engineering, so I might be missing something big.

Expecting obfuscation to increase security is a fool's errand. However expecting it to cut down on re-use of your code then it will no doubt work.

personally, I find the code it outputs to be easier to understand often than the source because it simplifies a lot of stuff into the most abstract logic. I think it takes some getting used to for your brain to connect those pieces, though

Fair enough, thank you.

I guess ultra-shortening the names into a,b,c,d,e, etc makes it superficially hard to understand what's going on but I agree on your point about abstract logic.

Makes me think of what might deter a reverse engineer and then this most awesome youtube talk on psychological warfare by Chris Domas

https://youtu.be/HlUe0TUHOIc

It's so good.

Thanks for the link to that blog post, really interesting!

While I think itcs bad to use obfuscation to hide security holes, I do think obfuscation has it's uses. If there's reasons to make data private, then there's reasons to make execution private as well. Not to mention, it was recently proved that indistinguishable obfuscation is possible, so I'm not sure how useful de-obfuscation tools will be in the future

But you don't make data private by obfuscating it and then passing it to people you don't trust.

You make data private by not giving it to people you don't trust, or by encrypting it and not giving the key to people you don't trust.

By "making data private" I meant encryption

Really enjoyed that blog post, thanks for linking it! How long would you say actually finding those two issues took? The attack surface must've been fairly large, but I guess intuition helps.

If I recall, the whole thing took about 6 hours

Obfuscation is like locking your front door. It won't stop anyone who is dedicated, but it might stop someone who isn't.

I understand the frustration, but as someone having to debug browser bugs with JavaScript edge cases, minified (and in this case ultra-obfuscated) JS is hell on earth to untangle and I wish people wouldn't.

Just making sure - you're using js source maps, right? The minifaction should be adding significant pain in your debugging process.

IME, code on prod rarely ships with a sourcemap. and as far as i can tell, GP is talking about other people's minified code, not something where they control the build process

Source maps are used for anti-debugging: https://www.perimeterx.com/tech-blog/2019/javascript-anti-de...

That blog is horrific on mobile

I think I might've actually analysed the code you're describing.

We even made a few tweaks to the code so that you couldn't just reverse it back into JS

This is why a lot of us keep our tools private... an old tradition of the cracking scene going back decades to the 80s. Think of things like IDA/Hexrays and Ghidra, then realise the most prolific crackers had similar private tools they had written many years before those appeared.

>This is why a lot of us keep our tools private

How ironic, that you want to open up other peoples code but keep your own hidden.

Not really ironic or related. The privacy here is, well, keeping the tools entirely private -- no distribution or highly limited distribution, not obscuring their function.

Irony would be applying obfuscation or other DRM protection techniques to tools intended to de-obfuscate/reverse engineer which are then distributed/sold. This is fairly common in commercial reverse engineering solutions, although I don't think the irony of the cat and mouse game is lost on the authors in that case...

why not - after all, none of the open source licenses say that you must actually distribute the program, they only say that you should also include the source code if doing so.

Different motives. Think of it like encryption: when someone finds a weakness in a cypher people will generally move onto a new cypher that’s harder to crack. The difference here is the purpose of writing those tools isn’t to improve security, it’s to break code open. So keeping these tools hidden keeps them effective.

The world is a complex place. It's not just open source vs closed source.

But once better tools have been published, why not show what you did?

Did you have a legitimate reason to make things harder for reverse engineers?

Why are you reverse engineering my code in the first place?

To figure out what it's doing, obviously.

Please STOP that.

I'll make you a promise: if your code never ends up on my machine, I will never try to reverse it.

Otherwise, all bets are off.

Why would I put it on YOUR machine? It's my code. Don't hack my servers, or all bets are off. /s

JS is often (but not always) transmitted from the server to execute on the client machine

You've never heard of NodeJS?

(but not always) <~ this includes nodejs

Friend, I'd love to come to an agreement that your code won't end up on my machine. I'm buying beers when we get together.

Don't request it then :p

If it's not part of any service that's marketed to me, I won't. However, if some vendor wants to run code on my machine, I _will_ be inspecting it.

No thanks. Anything you submit to run on my machine is fair play :-)

This code should never run on your machine. :P

Then why are you obfuscating it or even worried about people deobfuscating it? This thread is about Javascript.

Dude, I write financial applications in Node. Node IS javascript.

These applications run on the back end. Some of the API facing VMs have been attacked and so to be honest I've configured them so that if someone did get access to them, they wouldn't find much. Maybe just some API keys I can invalidate. Although I probably won't do it -- an obfuscator like this could be very handy here.

Did you give a try of Deno. This is a JavaScript runtime but it produce a single binary. This would make sense in your case because it can be harder to inspect it.

Because it's broken for my usecase, and I need to do something slightly different on the webpage

You shouldn't have access to it -- it's on my private servers doing stuff for me. How did you get it?

I think the problem with this thread is people think I am writing browser code, or code that is going to be shared on GitHub.

I am not.

Also I'm only half joking as I've indicated with the "/s" below.

> You shouldn't have access to it -- it's on my private servers doing stuff for me. How did you get it?

Well thanks for chiming in about a completely unrelated topic from website javascript. My comment wasn't getting downvoted until your slapfight with oauea blew up.

Specifically from the web page:

"It does not depend on a browser, so you can even run it on Node.js."

That wasn't a top level question though, it was a question to a commenter saying "We wanted to obfuscate this bit of code, to make life just a little bit harder for reverse engineers." That you obfuscate code nobody other than you can even access is completely irrelevant as a reply to that question.

So then you should ignore the entire thread and move on. Why are you wasting time on this?

> You shouldn't have access to it -- it's on my private servers doing stuff for me. How did you get it?

Seems like the logical solution would be to restrict access to it then, rather than obfuscate it making it harder for yourself to maintain. But hey, you do you.

At the bottom of the thread I explain the intention is to protect against unauthorized access.

I also wouldn't obviously edit the obfuscated production code, so it wouldn't really be a problem.

Because you gave it to me to run it. I want to know what is it exactly that I'm running.

Also, why do you mind me doing that?

No, I didn't give it to you to run. It's explained below if you read the whole thread.

You must have changed it a lot, this seems to produces 100s of kb of obfuscate code for with just a tiny input.

I think you ultimately need to do something like Function(code)() in JSFuck, so it is always possible to remove the final function call and get the `code` directly.

Interesting. I can definitely relate. As an author of a proprietary application written in web technologies, it's easy to be envious of compiled languages.

This is my recipe for minification:

1. Apply a convention where all class properties and methods have to end with a trailing underscore (it's trivial to make an Eslint rule to enforce it)

2. Use 2 minification tools in following order: Closure Compiler (simple optimizations mode), then Terser for best output.

3. Configure Terser mangle.properties.regex: /_$/

4. If it's a desktop app, use Bytenode for Node.js processes (cannot be used for the renderer)

A further obfuscation you could also compress it and have the app unpack itself.

eJztVUESwyAIfAs3GJ60w/+/UZKiUUwzztT20OZiwgIbWJXAwARTmMAX02qRr0o9Vu02xRmwgKUPTzHv0weu8bGtZFhKyKSnTK0Z/parAJ/VI5WyXp7Uo/HYNc3qNchzKWBACnpCK3uj3N1Quvs6qCSJ4Gvah+++VT9/q3AlWLH5Pg3/cRqO94lR5SM5T6rDKSelDOUKC0+EzQ36l5N/zR7lDqti9Xjsj3U71f4AduQBlR9rUg==

Talk about security by obscurity!

If you can use the decoder, the reverse engineers will use the same, no?

For someone to reverse your code, all they need to do is run it through this.

  https://enkhee-osiris.github.io/Decoder-JSFuck/

I think you missed this sentence from the comment you're replying to:

> We even made a few tweaks to the code so that you couldn't just reverse it back into JS with something like https://enkhee-osiris.github.io/Decoder-JSFuck/.

Reply on news.ycombinator.com