previous article:Virtual Interpreter Component Design

As illustrated in the diagram below, the '.c' file contains the core logic and corresponding components of the virtual interpreter. We utilize the Emscripten compiler to compile the target C file into a WebAssembly (WASM) module. This compiler, based on LLVM, initially compiles C/C++ source code into abstract LLVM bytecode. Subsequently, using the Emscripten backend compiler, this abstract bytecode is transformed into asm.js format files. Finally, employing the 'WASM=1' flag, it can be further encoded into WebAssembly binary files with the '.wasm' extension.

The compiler supports the automatic generation of glue code that loads '.wasm' files during the compilation process. This can be achieved by setting the '.js' extension for the target file in the compilation command using the 'WASM=1' flag. This compilation results in two crucial files: a '.wasm' file containing the core scheduling module 'Dispatcher' of the virtual interpreter, essential virtual data structures like 'VMdata' and 'VMarray', and the main logic of 'Handler'. The second file is a '.js' file, which primarily includes the necessary glue code for loading and communicating with the WebAssembly module, as well as code fragments from the 'Handler' and 'VMcontext' interpreters, inline through the 'EM_ASM' macro. To invoke the virtual interpreter at runtime, the protected JavaScript program requires an additional JavaScript script that loads the '.js' file containing the glue code. This file facilitates the runtime loading of the '.wasm' file containing the virtual interpreter into the browser. Additionally, the entry function of the virtual interpreter needs to be instantiated as the original target code's function name. Key portions of the code are extracted and replaced with calls to the interpreter's entry function. This approach enables direct entry into the virtual interpreter to restore the functionality of the original target code when executing critical functions.

JS一键VMP加密 jsvmp.com