In this article, we’ll explore how the code protection capabilities of the JXCore project can help solve these problems, along with built-in packaging features, for any Node.js 10+ project.
JXcore encrypts all files during the compilation of a JX package. Once compiled, only JXcore can process your application. You can consider your application completely protected, when both the
extract properties (see the next section for more details) are set to
false. Since it is not included as a library, your code cannot be easily reverse engineered using any of the reflection techniques.
It is important to note that the encryption is not obfuscation. JXcore protects your source code beyond the concept of obfuscation.
When you create a JX package and expose some of its methods to public, you can hide them by embedding a small comment anywhere inside its body:
We have patched the internal V8 engine to handle this part efficiently.
Now, when your package is compiled as a library, if you call:
…the body of this function is no longer available. Instead, you will see the following:
Don’t worry since the function itself can still be invoked:
Creating a JX package is simple and handled with a single command. The only requirement is obviously having JXcore installed.
jx package searches all sub directories for assets and source codes and creates a JXP file, which is a JX project file. For better results, the command needs to be executed under the main folder of your solution. It recursively scans the whole directory structure and puts all the supported file types into the JX file.
The JX package is not just a container for all those files. It is a completely valid application binary format for JXcore, which can be executed.
Even when executed, the JX package stays as a single file and its contents are never unpacked by default. If you are not interested in source code protection and only want JX packaging to pack your solution file then you have an option to create the package as extractable. This way, the package will be extracted on the target system whenever you call the above command line.
When the JX project file (jxp) is created, it includes all necessary information regarding to jx binary file. Turning back to
extract property inside this file, when it is set to
true, the package will be unpacked at its first run.
Once you have the JXP project file, you can simply update it instead of creating the project file again and again. In the case of updating a JXP file (JX project file), you simply compile it instead of creating the whole package from scratch. In order to compile a JXP file into a JX binary, use this simple command:
You can also limit a JX binary file as executable or allow it to be embedded in other solutions (i.e.
require('./my_package.jx');) By default, a JX file can be embedded in any third party solution since the
library option is set to
If you are developing a commercial application and want to prevent other developers from
require()-ing or embedding your package, you just need to set
library option to
In addition to the packaging feature, JXcore also offers another related tool: the Package Manager. It allows you to install npm modules in an easy and convenient way. It does not require the npm tool itself to be installed. Also, several popular Node modules are available as JX packages. The process to install a module is extremely simple. The command below will download the
express.jx package is in fact the Express module packed into JX package and kept in JXcore’s repository. The above command takes it from there and writes it to the current folder.
You can also install it globally. But then it will not be installed as jx package anymore. Instead, it will be installed like any regular npm module:
Code protection and packaging are just two of the key features in JXcore, but there are other features like multi-threading and messaging API already included in our latest release.
JXcore is free to use and redistribute and available from here.
Brian has published in a variety of technical publications over the years, has presented at numerous conferences and events and has served as a technical editor on a number of books.
You can read Brian’s blog archive with 9+ years of content at remotesynthesis.com (he still posts, infrequently). You can find a full list of Brian’s past publications and presentations. Follow Brian on Twitter @remotesynth.