Earlier quoted context omitted.
With how mediocre most developers today are, obfuscation is enough.
Can't tell if you mean they can't deobfuscate, or that their code isn't worth the effort of deobfuscating.
Probably both
JavaScript Obfuscation Techniques by Example
31–40 of 75 posts
Re: JavaScript Obfuscation Techniques by Example
#32Sorry for the slightly offtopic question: this page caused Chrome on my mobile phone to freeze completely. I had to reboot my phone, and even after that, I had to figure out a way to close the tab without opening Chrome. Did it happen to someone else?
Damn, I thought I was crazy. I had to reset Chrome to get it working again, could finally read the article after I installed Firefox.
Android 12 with Chrome v103.
Re: JavaScript Obfuscation Techniques by Example
#33Why obfuscating JS when there is WASM?
Business people demand it to protect intellectual property without realizing the ease of reversing it / wanting to say they're doing something to protect IP that their own superior will not realize doesn't help. It is making the best of an impossible situation, the paradox of sending your code to every single customer for them to run it while also wishing nobody could see it. The more aggressive they make patent law…
It's a supply demand thing.
If you publish your code on github, it's more likely to be compromised than if it's just in the webapp, very well obfuscated.
A sufficiently motivated actor will break it, and frankly break almost anything else, so it's a game of probabilities etc..
Obfuscation probably does make sense so long as it's not obviously getting in the way of dev. and, with the key understanding that 'it can be broken'.
Physical security at most companies can be thwarted with enough effort, it doesn't mean we don't do it.
Re: JavaScript Obfuscation Techniques by Example
#34Why obfuscate, when you can just follow modern trends and use webpack (or similar) which gives you completely unreadable shit.
Oh I love this.
Take it one step further: hire sufficiently terrible spaghetti coders that nobody, not you or even they know what the code does, and any hacker trying to make sense of it will feel ill.
Re: JavaScript Obfuscation Techniques by Example
#35This actually gave me some new context on why Web technologies can be slow: fast as the runtime might have become, it spends useless cycles converting hex to ASCII, thrashing the stack, and so on. I wonder if it wouldn't be faster to encrypt the JavaScript code, and use something like the existing Widevine DRM to distribute the keys.
Re: JavaScript Obfuscation Techniques by Example
#36Why obfuscate, when you can just follow modern trends and use webpack (or similar) which gives you completely unreadable shit.
Oh I love this. Take it one step further: hire sufficiently terrible spaghetti coders that nobody, not you or even they know what the code does, and any hacker trying to make sense of it will feel ill.
I'm imagining some state or APT engineers who, having reversed the mess, are then having very fraught discussions about what it could mean and getting the boss to bring in a specialist to figure out what they're missing.
Re: JavaScript Obfuscation Techniques by Example
#37You want to see obfusication? Check out FreeSlots.com. Look at view source on one of the slot machines.[1] Can anyone decode this and figure out the odds generator? [1] view-source: https://www.freeslots.com/slot515.min.js?v=84
I love all the deeply obfuscated junk and weird bitwise stuff... and then `fix_ios6`
Re: JavaScript Obfuscation Techniques by Example
#38You want to see obfusication? Check out FreeSlots.com. Look at view source on one of the slot machines.[1] Can anyone decode this and figure out the odds generator? [1] view-source: https://www.freeslots.com/slot515.min.js?v=84
Why is the odds generator run on the client?
Re: JavaScript Obfuscation Techniques by Example
#39You want to see obfusication? Check out FreeSlots.com. Look at view source on one of the slot machines.[1] Can anyone decode this and figure out the odds generator? [1] view-source: https://www.freeslots.com/slot515.min.js?v=84
I gave it a 10 minute poke just for fun. My main enemy for the first few minutes was the browser trying to tell me I can't do things like eval/etc. Once I got that out of the way with some policy the next issue was the console not really being used to non-printable characters catching me up. In the end those two tricks (both I'm sure being a pain on purpose not by accident) netted me not getting very far as expected, I was only a couple iterations into the first method of obfuscation.
I'm not sure how many levels it was applied but my general strategy on it was the first obfuscation method seemed to be an IIFE that triggers eval on a big string that has had some transformations applied which then calls eval on the next level and so on so I would take the IIFE, turn it into a function definition stuck in a variable like "decodeFunction1" so I could just recursively call directly and change the ending to return the string instead of eval it directly. There is probably something that could be done with debugger breakpoints here but I don't know enough about how that plays out inside eval. Anyways if I were evil I'd make sure at some point in this chain there is a subtle change in what's happening that breaks this approach so I wouldn't be surprised if someone told me that was the case :).
It'd be interesting to see what some real JS devs could get to, both from a "how hard is it" perspective but also just to see what different obfuscations are used in the real world.
Re: JavaScript Obfuscation Techniques by Example
#40A favorite trick of mine is to replace regular length variable names with absolutely massive ones that all share the same first 1024 characters, plays hell with debugger UIs and makes differentiation all but impossible without writing a custom lexer. Add into that a bit of Z̶͚͎̙̭͈͚͚̘͗̑̉̈́͌̆̀̚͝ă̶̡͉̠͍̻͔̯͔͖̪̤̤̫̓̽̏̉̎͌͒̆͘̕ḻ̴̡̡̝̫̠͇̻͎̥̲̜͆͌͑̍ͅg̸͈͒̏̀͂̈͊̂̾̑̈́̑͝o̴̡̙͍͉͓̘̮͗̏̒̂̃̏̓́̕ͅ and you’ve got a stew going, baby!