I'd like to know more about how it picks variable names. Running it on non-obfuscated code is amusing. It occasionally comes up with better names for my variables than the ones I had picked.
I'm a big fan of JSNice - it's easily the best JS beautifier I've used. It's twice saved my bacon, really helping to make sense of some horrible, buggy third-party code.
I tried to de-obfuscate some HTML5 games that I made and the result was bad, marginally better than some naive JS beautifiers.
Yes, we all know that it's pointless to obfuscate client side code, but this serves as a simple deterrent. I've had games copied/pasted on some Chinese website and this seems to avoid that.
I used this [0] to obfuscate, which is free and open-source. You can also try it online here [1] if you don't feel like installing the Node.js package just for playing with it.
disclosure: I built the web interface [1] to the obfuscator, which is also open source.
I used JScrambler before and I really liked. If you don't mind the monthly fee, I'd say go for it.
They do nice stuff, like hiding some of your strings, other literals and random predicates inside an encrypted string. This is decrypted and eval'd at runtime using the text of the decrypt function as a parameter i.e, you can't beautify it otherwise it stop working. The random predicates are merged within your code for instance: it appends a `&& somePredicateThatReturnsTrue(someOtherRandomValue)` to ifs conditions. It makes it really hard to figure out what is happening.
They're SaaS and I believe they do have a webpack plugin (I used their grunt plugin). The plugin will send your code to their servers and wait for it to come back.
Not sure what exactly they're promising wrt. the quality of obfuscation, but if it actually works "well enough" you'd imagine they should be happy for you to run an obfuscated version of their code[1] rather than shipping your JS to their servers. Hmm... :)
[1] I'm assuming it's written in JS. It might not, of course.
That didn't work on JScrambler. The function that does the decryption checks to see if the `eval` has been tampered. (IIRC it checks for a `prototype` property). And you can't modify the body of this function otherwise the decryption fails.
24 comments
[ 5.3 ms ] story [ 63.9 ms ] threadYes, we all know that it's pointless to obfuscate client side code, but this serves as a simple deterrent. I've had games copied/pasted on some Chinese website and this seems to avoid that.
I used this [0] to obfuscate, which is free and open-source. You can also try it online here [1] if you don't feel like installing the Node.js package just for playing with it.
disclosure: I built the web interface [1] to the obfuscator, which is also open source.
[0]: https://github.com/javascript-obfuscator/javascript-obfuscat... [1]: https://javascriptobfuscator.herokuapp.com/
They do nice stuff, like hiding some of your strings, other literals and random predicates inside an encrypted string. This is decrypted and eval'd at runtime using the text of the decrypt function as a parameter i.e, you can't beautify it otherwise it stop working. The random predicates are merged within your code for instance: it appends a `&& somePredicateThatReturnsTrue(someOtherRandomValue)` to ifs conditions. It makes it really hard to figure out what is happening.
So no webpack plugin, I guess :)
[1] I'm assuming it's written in JS. It might not, of course.
This is decrypted and eval'd at runtime
Most(all?) string-based obfuscators can be bypassed by simply replacing eval with a logging eval implementation.
A similar patch to the Function constructor can bypass the other easy dynamic code generation code path.If at some point, a string needs to be evaluated as code, then it's possible to intercept that code and output it.