Node.js code obfuscation is generally done to accomplish one or all of the following goals:

• Prevent unauthorized modifications to plain text code
• Watching for code attacks on node.js files
• Permanently retain the ability to sell or share node.js code, without the worry of theft of intellectual property
• Gathering metrics about the usage of protected node.js code once it is shared with the external/outside world
• Regulate how long the commercial node.js files can be used
• Regulate the list of domains authorized to use your node.js code
• Regulate where (on which hosts) the node.js scripts can be used.

In the context of enscrypt.io or atshai.com (we own both sites), node.js obfuscation is the process by which a plain text node.js file (.js) is converted into an illegible, unreadable but executable form, which still qualifies as actual node.js

It isn't just enough to obfuscate a node.js code. It's important to also ensure that when that obfuscated code IS attacked, there are provisions set in place to deal with it.

• So Javascript protection is first obfuscating the node.js code, and ensuring all attempts to get it to do what isn't intended to do, leads to the termination of the node.js execution.
• Additionally, protecting Javascript code means being able to track the frequency of attacks on the protected code.

There are multiple different ways through which an attacker can initiate attacks on an obfuscated code. When you have hard evidence showing the different IPs an attacker is using, the dates/times the attacks are being initiated, and the particular shields which the attacker is trying to circumvent, you now have more than enough information to take action.

Whenever you decide to host a commercial website on the internet, there will be entities seeking to harm you in one way or another.

• The most common way you can be harmed is through hacking the scripts/files on your website, especially the ones visible to just about anybody..i.e. .js node.js files
• What we provide here is total obfuscation of those visible files, with sensitivity checks included.
• The sensitivity checks keeps track of how the node.js files on your site are being used.
• If anyone tries to step through a protected file attempting to figure out how it works, the sensitivity checks will detect it and will cause the script to terminate.
• If the attacker downloads your protected .js code and attempts to run it on his own private host, the sensitivity checks will also detect that and will self destruct.

If you wish to limit the usage of your node.js to specific browsers, you can specify the list of allowed browsers in the commands.javascript.cfg file.

• Whenever your obfuscated code is used on a browser that is not in the list, it will alert the user of the incompatible browser and terminate execution of the node.js code.

Yes, you can expect your obfuscated Node.js files to work as expected in any browser.

Anti-Tampering is one of the features included in every obfuscated node.js file. It is the mechanism that detects when an obfuscated node.js code has been altered. And when such a detection is registered, this feature causes the modified node.js to terminate execution. In other words, this feature prevents modifications to your code AND sends a record to our database to track this attempt.

In other words, with this feature, any modification made to your code will cause it to become inoperable.

AtShai's algorithm obfuscates in such a way that, if any part of that obfuscated body of the script is altered, it in effects alters the path of execution of the code, which in effect ensures the direction of the code away from a successful completion.

Yes. Date Locking and Expiration Date assignments are possible.

What is Date Locking? Dating locking is the process of confining the operability of an obfuscated .js code to within a specific time period. For example, you may wish to allow your protected node.js to function ONLY if executed between two dates...i.e. July 14, 2022 (11:00am) to September 9th, 20202 02:00pm. With this configuration, the obfuscated node.js code will terminate if it is executed BEFORE and AFTER the dates specified.

Setting Expiration Dates - With this type of setting, the obfuscated will only terminate itself IF it is executed AFTER the expiration date.

The satellite feature, when enabled, gives your obfuscated code the permission to send us statistics about the different types of attacks the code is being subjected to, out in the world.

Additionally, if enabled, the satellite feature allows you, the developer, greater control of your node.js files. For instance, all obfuscated scripts configured with the Date Locking/Expiration feature will verify their dates remotely.

• The benefit of this is obvious. In cases where your code is executed systems or browsers that has had their time/clock altered malciously, the satellite feature ensures the obfuscated is not affected. It will use the local clock to validate itself. It will validate the current time with our servers.

After obfuscating a node.js code in its totality, we encase the obfuscated code inside several layers of protection, otherwise known as shields.

Now, these shields aren't ordinary shields. Nope. They are very sensitive. Think of them as artificially intelligent doors. Or bodyguards. There are certain doors we expect to be attacked regularly by both passive and lukewarm attackers.

However, there are other doors that, when breached, reveal to us, without a shadow of a doubt that a determined attack is underway and is being carried out by a serious hacker. It's important to keep track of these so you can know how serious your attackers, the methods of attacks they're using and ways to deal with them.

Yes. If you encounter a system or browser that is unable to execute the obfuscated code, just let us know. We'll update the obfuscator with the capabilities needed to accommodate that system. It's really that simple!

The size of the encrypted script will be negligible, especially if encrypted using Level 1 protection.

Earlier versions of the encrypted scripts were much heavier, but over time, and with the input of several customers, we've been able to trim out the unnecessary parts.

Now, users get to choose specific levels of protection to apply to their scripts, as opposed to us imposing preset configurations.

No. One of the early challenges of protecting source code is developing the appropriate level of protection that does not noticeably impact the execution of the code being protected.

We are very proud to say that, as of June 19, 2021, scripts protected with our obfuscator can be expected to run almost as fast as their original / plain text versions. There will be time added to the execution of the final encrypted script, but this time is negligible.

But what exactly is 'negligible'? What does that mean?

We have quite a few very short, straight to the point videos in the above links available for you to watch to get an idea of what to expect.

Of course. During the duration of your license term, you get to choose when or if each script you protect should expire. If a script is protected without the expiration mandate, that essentially means the script will never expire. Your users will be able to continue using it for as long as they wish.

The online options requires you to upload your scripts to our online portal for them to be encrypted.

The on-prem options allows you to utilize the actual Obfuscator on your own private hosts. With this version, and for the duration of the license period, you will be able to protect an unlimited number of scripts on an unlimited number of servers.

Yes, the scripts you encrypted during the period which the license was valid and current, will continue to work, even after your license expires. We don't control the expiration dates you assign to your scripts. That is up to you. You get to decide whether or not the script(s) you protect have to expire.