⚠️⚠️⚠️ WIP - DON'T USE. YOUR JS MIGHT (99% chance) BREAK. CODEBASE IS A HOT-PIECE OF SHIT.

JS Deobsfucator

A JS deobsfucator built in Rust using SWC.

TODOs

• Including array and object literals in constant folding.
• Proxy arrow functions.
• Proxy objects (yes, I know, I didn't even know they existed).
  • PROBLEM: Each individual pass is quite easy but there are a lot of moving parts (object mutation check, property mutation check, literal proxies and function proxies).
  • Maybe, we can use 'composition' and reuse code from already implemented stuff.
• Do something about IIFEs.
  • Noramlizing IIFEs is quite unsafe because they can't be direcly convert into block statments. Reasons - presence of arguments & this, scoping of var, let and const, default parameters, closures etc.
  • But I think, with some complex logic, we can still convert all IIFEs expect closures into block statements (by providing things like arguments, this, and parameters as block-scoped let variables).
• Proxy varialbes
  • Aliases (ex - var x = a)
  • Constants
  • Inderiect aliases (ex - var x = a.b)
• IMPORTANT: ProxyArrayMutationAnalyzer can't detect mutations through aliases or function return values!
• IMPORTANT: Do something about the string array rotator + memoized string array generator pattern used by most of the obsfucators.
  • Properly detect the memoized string array generator and convert it into a proxy function so that other modifications can handle that.
  • Maybe: A strict/hardcoded detection of the string array rotator followed by a static analysis which writes the final string array directly.
  • NOTE: This is quite important since, this is stopping a lot of other modifications like proxies, property simpilication etc.
  • NOTE: Best way is to copy-paste relevant code and run it using a JS runtime, obtain final static value of array, copy-paste the value into the actual script & remove rotation logic and voila!
• Some code in-between is AI-generated; clean it, refactor it to match other things, verify it, resolve edge cases.
• Error handling.
• Remove unecessary leftover parantheses.
• Document each modification module and name each one correctly.
• Implmement visit_mut_module_items for all modification which require it and explicitly document which don't.
• Maybe: Merge visit_mut_stmts and visit_mut_module_items logic; it's very similar except 1 extra layer of pattern matching in visit_mut_module_items.
• Final boss: AI-based variable naming.