Bytenode
A minimalist bytecode compiler for Node.js.
This tool truly compiles your JavaScript code into V8 bytecode, so that you can protect your source code. It runs on Node.js and Electron. See examples/ for current runnable projects.
Install
npm install --save bytenode
Or globally:
sudo npm install -g bytenode
Security and Code Protection Note
Bytenode compiles JavaScript into V8 bytecode, which removes original source formatting, comments, and variable names, drastically increasing the barrier to entry for reverse engineering. However, be aware that V8 bytecode is not encryption. Decompilation and analysis tools exist, such as View8 and Ghidra plugins. These tools are valuable for the cybersecurity community to audit applications and analyze malicious code. Some of them extract only abstract pseudo-code from .jsc files, while others can decompiles them back to readable JavaScript.
If your goal is maximum intellectual property protection, Bytenode should not be your only line of defense. We recommend adding an obfuscation step (using tools like javascript-obfuscator) into your build pipeline before compiling the code with Bytenode. This ensures that even if the bytecode is decompiled, the resulting JavaScript remains unreadable and hard to reverse-engineer.
Known Issues and Limitations
-
In Node 10.x, Bytenode does not work in debug mode. See #29.
-
Any code depends on Function.prototype.toString function will break, because Bytenode removes the source code from .jsc files and puts a dummy code instead. See #34. For a workaround, see #163
-
Async Arrow Functions (and Arrow Functions in general) cause crashes in Puppeteer and in Electron apps. See #106, #47. They also cause issues with the ndb debugger. See #135. It seems that whenever there is a context change (or even when called from another file or module), arrow functions break because V8 inspects them internally using Function.prototype.toString in these cases. See #157.
-
Electron ≥ 42 (V8 ≥ 14.8): bytecode compiled via ELECTRON_RUN_AS_NODE crashes the main process with SIGTRAP. V8's serialized bytecode header carries a read-only snapshot checksum (header offset 16). The Electron main/browser process boots V8 from Chromium's v8_context_snapshot, whose read-only heap differs from the Node default snapshot used by ELECTRON_RUN_AS_NODE. So a .jsc produced with compileElectronCode() (run-as-node) carries a checksum that does not match the main process. Starting with V8 14.8 this no longer fails gracefully (cachedDataRejected) but hard-aborts (EXC_BREAKPOINT / SIGTRAP) while deserializing. The fix is to compile in the same process type that will load the .jsc — use compileElectronMainCode() or compileFile({ electronMain: true }), which compile inside an actual Electron main process. (On Electron ≤ 41 / V8 ≤ 14.6 the two checksums happened to be compatible, so electron: true worked there.)
-
Electron renderer bytecode is context-specific. On Electron 43.5.1 and later, the renderer snapshot differs from the Node and main-process snapshots. The project’s reported checks found that bytecode compiled with electron: true or electronMain: true was rejected by renderer preloads/pages, while renderer-compiled bytecode loaded in both. Use compileElectronRendererCode() or compileFile({ electronRenderer: true }) for renderer code. This mode compiles in a hidden window’s preload, so the result is suitable for renderer/preload contexts and should not be used in the main process or worker threads. The reported compatibility checks covered Electron 43.4.1, 43.5.1, 43.7.3, and 44.4.3; verify the mode against the exact Electron versions you ship. See #265.
| Loaded in | Electron 43.4.1 | Electron 43.5.1, 43.7.3, 44.4.3 |
|---|
main, worker_threads | electronMain | electronMain or electron |
utilityProcess | electron | electron or electronMain |
| preload, renderer page | electron or electronRenderer | electronRenderer only |
Resources
Examples
This is the beginning of the README. Read the rest at the original. Read the full README ↗
