Ugh. This whole blog post is giving me the heebie-jeebies. Replacing all static accesses with dynamic ones, and with endless function calls everywhere has to destroy performance. You're intentionally making it hard for the JIT compiler to do its work.<p>And for what? Obfuscating your code so that people don't steal it or whatever? This kind of obfuscation can be easily and programmatically reversed engineered if someone really wants to, so... why do it? Just to screw with people trying to look at the source code of a web page?<p>People complain about JavaScript minifiers and WebAssembly that they're making the web less open and hackable, but at least those things have a point to them. There's a performance upside! This is just "naah, lets make the web slower, more closed and less hackable, for... you know... reasons."
If I were to be making a JavaScript obfuscator, I would simply start by rewriting the AST so that Exceptions would become the driver behind the code. That way, it would make it really hard to reverse the code without executing it.<p>Also sprinkle some parts of the code that check how much time it takes to execute it and then takes a different code path if it was interrupted.<p>What is done here is child's play, the author is clearly not familiar with old-school assembly obfuscation - this code is one script away from being de-obfuscated.
In my (extremely limited) experience with reversing JS, I'm pretty sure I've already seen these obfuscation techniques before, and common deobfuscators of the time had no problem reversing the transformation. It doesn't stop anyone except the most easily discouraged.<p>(The JS that's used to detect adblockers and/or coerce you into viewing ads is often obfuscated. Those of you who have played around with this stuff may recognise this keyword: DtsBlkVFQx.)
The proposed scheme trashes the performance while providing a primitive protection that is statically observable (e.g. distinguishable) and thus easily reversible.<p>Looks insane, in a bad way.
I would like to see the performance differences between the original and obfuscated. Most of the compiler optimizations are being made impossible by removing static access. Plus, a reverse-obfuscator is trivial for all those static-to-dynamic and base64 encoding.
Code obfuscation is idiotic and pointless no matter what form it takes, but this example is particularly egregious. This accomplishes little more than degrading performance across the board for the <i>very real</i> end user (bye bye JIT optimizations) while requiring some <i>purely hypothetical</i> reverse engineer to write one additional script before (<i>gasp</i>) reading the code.<p>I'm genuinely curious how much time and money was wasted on this imbecilic venture.
When I reviewed different obfuscator products, it was based on the idea it was only a "speedbump," for our threat actors, and imposed the cost of someone having both the motive and means to reverse it.<p>If you would prefer that a summer student at an enterprise customer doesn't replace your product with an in-house work-alike, it's useful. Similar if it's cheaper to buy your product than spending several hours reversing it.<p>If your business model relies on the integrity of a secret (key, derivation component, method, etc), it probably has a single, catastrophic failure mode and obfuscation isn't your solution.