By Krzysztof Trzeciak
“How can I protect my JavaScript code?” This question has probably been asked millions of times and the answer is always the same. You can use obfuscation, but it will, in reality, not protect your source code. That’s why it is always recommended that you shift critical code to the server side. But in Node.js, server side code is also in JavaScript and hence is open to curious eyes unless you develop a C++ add-on, which defeats the purpose of using JavaScript in the first place. What if you are developing commercial software using Node.js? What if you are an enterprise, bound by data protection regulations wherein information cannot be left in text format?
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.
Code Protection
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 library and 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.
Curious developers may wonder about the outcomes when someone converts one of the interface methods to string? Interface methods are the ones exported by the interface JavaScript file. If you have ever tried to call a function’s toString() method in JavaScript, you already know that it will give you the function’s source code. JXcore helps you hide any function body from curious eyes by allowing you to choose any function to be hidden without affecting its functionality.
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:
Packaging
One of the problems with current processes of deploying a Node.js project on the server is that they require copying a large number of files including JavaScript files, dependencies, assets, etc. A missing file or module on the server can cause the application to crash or become unstable.
JXcore’s packaging feature can solve many of these problems encountered during a regular server deployment. However, it is not only meant to simplify an application’s deployment process but to also solve other problems related to the deployment of any JavaScript server-side application with all its dependencies. JXcore packages all third-party modules together with their assets along with all of your application’s files and resources. This simplifies the deployment process.
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 true.
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 false and recompile the package again. JXcore will not allow the package to be called from other JavaScript files or JX packages.
Package Manager
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:
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:
What’s Next
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.
We are also working on some very exciting features, one of which is to replace the V8 engine with LLVM. This feature alone would enable JavaScript programmers to develop native apps. This is going to take some time to complete but we have many other features coming soon, so stay tuned.
JXcore is free to use and redistribute and available from here.