VortexJS is designed based on the principle of Security by Complexity and Virtualization. Unlike traditional obfuscators that rely on lexical transformations (renaming variables), VortexJS relies on semantical transformations.
By compiling JavaScript into a custom bytecode format and executing it within a stackless virtual machine, we aim to maximize the time and resource cost required for reverse engineering, rather than claiming mathematical impossibility.
Important
Obfuscation ≠ Encryption. While VortexJS employs Hyperwave Encryption for string literals and Polymorphic Dispatchers for control flow, the client-side execution environment (the browser) ultimately possesses the keys required to run the code. VortexJS is designed to protect Intellectual Property (IP) and deter tampering, not to secure secrets (API keys, passwords) on the client side.
VortexJS is engineered to defend against specific classes of reverse engineering attacks.
| Attack Vector | Vulnerability | VortexJS Defense Mechanism |
|---|---|---|
| Static Analysis | Analysis of source code without execution. | Control Flow Flattening (CFG): Linearizes logic into a single while(true) loop.Opaque Predicates: Injects mathematically complex dead branches. Chaos Dispatcher: Splits state variables ( S = K1^K2^K3) to break taint analysis. |
| Dynamic Analysis | Debugging and stepping through code at runtime. | Stackless Architecture: Logic does not appear in the native call stack. Anti-Debug Predicates: Measures execution timing to detect breakpoints/stepping. Honey Pots: Deceptive code paths that corrupt memory if forced by a debugger. |
| Automated Deobfuscators | Tools that pattern-match generic obfuscators. | Polymorphism: The dispatcher structure (Switch/BST/Cluster) varies per build. Custom VM Instruction Set: Logic is data-driven, not syntax-driven. Hyperwave Encryption: N-dimensional geometric string transformation. |
We take the security of the compiler itself (e.g., code injection risks during compilation, insecure dependencies) seriously.
| Version | Supported |
|---|---|
3.x.x |
✅ |
2.x.x |
❌ |
1.x.x |
❌ |
< 1.0 |
❌ |
If you discover a vulnerability in the VortexJS compiler or runtime:
- Do NOT open a public issue.
- Email the core maintainer at:
seuriin@gmail.com. - Include a Proof of Concept (PoC) demonstrating the vulnerability.
We aim to acknowledge reports as soon as we can.
VortexJS prioritizes protection depth over performance. Users should be aware of the following security/performance trade-offs:
- Performance Overhead: The Stackless Virtual Machine introduces a simplified instruction cycle overhead. This is unavoidable in virtualization-based obfuscation.
- Browser DevTools: While VortexJS obscures the logic, the side effects (Network requests, DOM manipulation) are always visible to the browser.
- Malware Usage: VortexJS contains safeguards to prevent its use in malicious contexts, but we explicitly disclaim responsibility for any code processed by this engine.
This tool is released for Educational and IP Protection purposes only.
- Do not use VortexJS to hide malicious payloads.
- Do not use VortexJS to bypass anti-virus or EDR solutions.
- Do use VortexJS to protect proprietary algorithms, game logic, or sensitive client-side business rules.
VortexJS relies on a minimal set of dependencies (@babel/parser, @babel/types, terser, esbuild) to reduce surface area.
- We utilize Level 3 IR Optimization to ensure that dead code introduced by dependencies is stripped before the virtualization phase.
- Dependencies are audited via
npm auditon every release cycle.