Welcome back to Jscrambler 101! A collection of tutorials on how to use Jscrambler to protect your JavaScript. These tutorials cover Jscrambler version 6.1.

Introduction

Last time, on Jscrambler 101 - Control Flow Flattening, we talked about Control Flow Flattening and its properties against reverse engineering.

This time, we’re going to explore Code Locks.

If you develop and sell JavaScript applications — whether they are standard JavaScript, mobile web applications, or HTML5 — you’ll want to prevent someone who didn’t pay or whose license has expired from executing your code. This is where our Code Locks come into play.

Code Locks

Jscrambler allows you to lock your code to a predefined list of domains, browsers, and operating systems and set expiration dates. By using them, you can limit the execution of your code to a given set of browsers, a time frame (useful for demos that shouldn't be runnable after the preview period is over), on a given domain (usually yours), or a particular operating system.

This means that you can deliver expirable demos to your clients without incurring the fear of code or client-loss.

Code Locks can also trigger a function when someone tries to execute the code outside of the set parameters. This function has to be defined inside the unprotected code and can be used to warn you when such an unwanted behavior occurs.

Application Locks

As the name suggests, Date Locks lock the code to a period of time. The code can be locked to run until a certain date, after a certain date, or between two dates.

These are done by setting the startDate , the endDate , or both, respectively. This can be useful to enforce license expiration or send out demos of your code.

If we observe the following API parameters, we can see that the protected code will run from 01-09-2018 to 10-09-2018. If someone were to run the code outside of these dates, then the warningFunc function would be triggered.

{ // keys "params": [ { "name": "dateLock", "options": { "startDate": "2018-09-01", "endDate": "2018-09-10", "warningFunction": "warningFunc" } } ] }

Domain Lock locks code to a domain name or IP address. This is helpful if you want to stop someone from copying your code and running it on another domain or locally. Once again, it’s another great option if you want to enforce license agreements.

Some accepted examples are:

mysite.com - code breaks outside of mysite.com

mysite.com, www.mysite.com - code breaks outside of mysite.com or www.mysite.com

*.mysite.com - code breaks outside of mysite.com and its sub-domains

192.168.* - code breaks if it runs on an IP outside of the 192.168 network

file://Users/you/* - code breaks outside of your user directory

As for the API, several domains can be inserted in a list, like this:

{ // keys "params": [ { "name": "domainLock", "options": { "domains": [ "Domain1", "Domain2" ], "warningFunction": "VALUE" } } ] }

Platform Locks

Browser Locks lock the code to a list of Browsers. If you want to enforce license agreements, this is a transformation you should consider using. The list of browsers works as a whitelist, meaning that the selected browsers are the ones where the code can run.

As an example, if we observe the following API Parameters, the protected code will only run on Firefox and Chrome:

{ "keys": { "accessKey": "XXXXXX", "secretKey": "YYYYYY" }, "applicationId": "ZZZZZZ", "params": [ { "name": "browserLock", "options": { "browsers": [ "firefox", "chrome" ] } } ] }

This locks the code to a list of operating systems. It’s useful when you want to enforce apps to run on a specific platform. As happens with Domain locks and Browser locks, this can be applied for license enforcement.

Once again, the OSes can be defined in a list inside the API parameters:

{ // keys "params": [ { "name": "osLock", "options": { "oses": [ "linux", "windows", "osx", "tizen", "android", "ios" ], "warningFunction": "VALUE" } } ] }

Conclusion

Summing up, using Code Locks helps you to protect your code by enforcing licenses and preventing it from running outside of your set parameters — whether it's a Browser, Date, Domain, or Operating System.

Remember that you can test all of these locks in our Playground App. Simply select one or more locks and use your domain, the current date, your browser or operating system — depending on which locks you’ve selected — in order to have the app running properly. After that, you can select a domain you don’t own, previous or later dates, a different browser, and a different operating system from the ones you have, and you’ll see that the protected code won’t run properly.

Feel free to proceed to one of our other 101 Tutorials:

Enjoy your testing and start protecting your Applications ASAP!