Jscrambler allows you to lock your code to specific domains, browsers, dates and operating systems. This functionality is great when coupled with anti-tampering and anti-debugging capabilities since it ensures the code is running how it was designed to and in the correct environment.
Jscrambler also allows you to choose behaviors which are triggered whenever someone breaks the locks in the code or tries to debug the application and tamper with it. The following section describes each of the behaviors you can select regarding Jscrambler's Code Locks and Self-Defending transformations. Countermeasures can also be explicitly triggered using code annotations.
This is the default behavior and is enabled by default. Whenever someone breaks a lock in your code or tries to tamper with the application the application will stop working.
Note that removing this capability is only possible on Jscrambler's Code Locks, not on the Self-Defending transformation or Self-Healing transformation.
This functionality was previously known as warningFunction
.
This option allows supplying the transformation with a name of a function which will be called when someone breaks any lock or tries to debug or tamper with the application. The function should be inside of the code which is being protected and its functionality is totally up to the user. It could, for example, contact a server informing that someone is trying to run the code after it has expired (date lock) or trigger a pop-up message.
This option will delete all the cookies which do not have a path
property set neither have been created with the HttpOnly
flag.
This option will trigger a redirect to a specified URL.
Our current redirect approach as a countermeasure currently is not supported on browsers that came out prior to Internet Explorer 9 as it would require extra logic only for a small amount of use cases.
If the user wants to add this behaviour for Internet Explorer 8 (the oldest version Jscrambler supports) it can be done using the Custom Callback countermeasure.
The function invoqued should be similar to the following:
function redirect (url) {
var ua = navigator.userAgent.toLowerCase();
var isIE = ua.indexOf('msie') !== -1;
var version = parseInt(ua.substr(4, 2), 10);
if (isIE && version < 9) {
var link = document.createElement('a');
link.href = url;
document.body.appendChild(link);
link.click();
}
}
This countermeasure will block the application from sending data to external services as soon as the countermeasure is triggered. Take into consideration that any ongoing requests will not be aborted and only subsequently will be blocked. When triggered, this countermeasure might also cause your application to not work as expected since some assets might not be loaded afterward.
This countermeasure works for Browser, Node.js and Hybrid applications (React Native, NativeScript, etc).
This option will send a notification to an external service as soon as a violation occurs.
Those notifications can be seen on the Application Live Feed Or Application Reports.
Countermeasure's Compatibility list (may work with other platforms):
Attempts to damage the state and behavior of the application and/or the environment where the application is running. By default, when triggered, self-destruct prevents even basic JavaScript code from functioning, and makes the process/tab that is running the code unusable, often to the point of crashing. However, the precise behavior of self-destruct can be fined-tuned using configuration files (see below) with several sub-options:
{
"countermeasures": {
"selfDestruct": {
"destroyObjectFull": "myObject",
"crashWithMemory": true
}
}
}
The following self-destruct options are available:
destroyObject
: Damages basic JavaScript objects and APIs (including the DOM, when executed in a web context). Internet Explorer 8 and older versions are not supported.destroyObjectFull
: Significantly damages JavaScript objects and APIs (including the DOM, when executed in a web context). Incurs a more significant performance/code size overhead than destroyObject
. Instead of a boolean, destroyObjectFull
can also be parameterized with a custom object name, in which case only objects and APIs contained in that object are damaged. Internet Explorer 8 and older versions are not supported.crashWithMemory
: Crashes the process/tab by consuming excessive amounts of memory.crashTimeout
: Crashes the process/tab by overloading the event loop.crashStack
: Crashes the stack of the running process/tab.By default, destroyObject
and a random between crashTimeout
or crashWithMemory
are used. Multiple types of crash
should not be combined in a single destruction. When destroyObject
is selected along side with destroyObjectFull
, only destroyObjectFull
is included.
If an incompatible version of Internet Explorer is used, then self-destruct is less effective and may be disabled altogether, but only use-cases that trigger countermeasures are impacted (i.e., Internet Explorer 8 users that do not trigger countermeasures can still use protected applications normally).
These behaviors can be selected for each of Jscrambler's locks and for the Self-Defending transformations as well.
To enable any countermeasure, select the checkboxes relative to each of the behaviors and fill the extra parameterization if needed. Below is an example of the attack response options:
Our CLI and our other packages such as webpack and gulp allow for specifying the attack response options through the configuration:
{
"keys": {
"accessKey": "myAccessKey",
"secretKey": "mySecretKey"
},
"applicationId": "myApplicationID",
"params": [
{
"name": "browserLock",
"options": {
"browsers": [
"firefox"
],
"countermeasures": {
"customCallback": "callbackFunction",
"deleteCookies": true,
"redirect": "https://www.example.com",
"realTimeNotifications": true,
"selfDestruct": true,
"breakApplication": true
}
}
}
],
"areSubscribersOrdered": false
}