Need: Fraud & Abuse Prevention

Introduction

About Anti-Debugging

How does Anti-Debugging work?

Benefits of Anti-Debugging

• Enhanced detection – combining nine techniques heightens the ability to identify debugging activity. Each runtime uses a distinct subset of techniques, increasing the overall detection capabilities.
• Stronger resilience – the injection of random checks in the source code reduces single points of failure, resulting in a more resilient defense against debugging activities.
• Broader attack surface coverage – the diverse and independent nature of the techniques addresses various debugging approach strategies.
• Extended defense protection – safeguarding against different types of breakpoints (conditional, exception, event, and XHR/fetch), offline debugging, and offering swift reactions upon detecting debugger activity.
• Smooth and quick reaction – a wide array of countermeasures, such as custom callback, delete cookies, redirect, real-time notifications, data exfiltration prevention, self-destruct, and break application, provide an extensive defense toolkit. The option to stop or break application execution is discretionary.

Popular use cases

• Piracy
• Licence abuse
• Cheating and bypassing restrictions

Conclusion

Updated on July 15, 2025

Welcome back to Jscrambler 101! A collection of tutorials on how to use Jscrambler to protect your JavaScript. This tutorial covers the Code Watermarking feature, included in the Jscrambler version 8.5.

Introduction

In this article, we’ll explore Code Watermarking, a new Jscrambler feature released in version 8.5. Code Watermarking is a self-service feature that empowers customers to verify ownership of JavaScript code using robust, nearly unremovable watermarks, akin to a digital signature. This feature addresses intellectual property (IP) theft and supports forensic tracing for enterprises. 

About the Code Watermarking Protection Feature

How was the feature inspired?

The feature was created to address Jscrambler’s customers’ need for a self-service verification method. Many users are unaware of embedded watermarks, limiting their ability to address IP theft or investigate leaks in web applications. The feature focuses on self-service verification for JavaScript.

How does the Code Watermarking feature work?

The feature enables users to confirm JavaScript code ownership independently, leveraging watermarks’ signature-like persistence to protect frontend logic and trace code origins without manual support. The “Watermark” UI, as shown in the screenshot, provides an intuitive interface for watermark detection:

It allows users to upload JavaScript files (.js, .mjs, .cjs formats) or input a URL. The system checks for robust, embedded watermarks (already included in protected code) and displays results: “Code belongs to [Organization], protected on [Date]” or “No watermark match found.” If the user disagrees with Jscrambler’s assessment that a piece of code is theirs, even if no watermark was found, they can submit the file for analysis by clicking a link that appears after our response. 

Code Watermarking Benefits 

• Ownership Verification: confirms if suspect JavaScript is yours, akin to verifying a signature, streamlining IP dispute resolution.

• IP Theft Deterrence: near-unremovable watermarks discourage copying by ensuring traceability, mirroring a signature’s trust signal.

• Legal Evidence: provides signature-like proof of ownership for legal disputes.

• Forensic Tracing: traces leaked JavaScript to its source, supporting breach investigations, similar to signatures that identify origins.

• Increased Awareness: educate customers about watermarking’s signature-like capabilities.

Conclusion

Code Watermarking offers a robust, signature-like solution to verify JavaScript ownership. By enabling self-service verification within the organization, it delivers immediate value while laying the groundwork for future capabilities, such as automated code scanning, ownership certificates, and AI code attribution. This feature not only strengthens JavaScript security where traditional code signing falls short but also sets Jscrambler apart in a crowded market.

With ongoing customer feedback and planned integrations, Code Watermarking showcases the signature-like robustness of watermarks, emphasizing ownership verification, deterrence, and forensic tracing.

Last updated on April 9th, 2024

Welcome back to Jscrambler 101! A collection of tutorials on how to use Jscrambler to protect your JavaScript. This tutorial covers Jscrambler version 8.3.

Introduction

Last time, on Jscrambler 101 — Source Maps, we detailed how you can leverage Jscrambler’s Source Maps to achieve painless debugging of protected apps.

This time, we’re going to talk about one of Jscrambler’s most valuable capabilities: Client-Side Countermeasures. We will show you how to set up these countermeasures and highlight some common use cases where they help you ensure that your applications remain protected.

Countermeasures

As you’ve read in our previous 101 tutorials, two of Jscrambler’s protection layers are Code Locks and Self-Defending.

By locking your code to specific browsers, domains, OS’es, and date ranges, you can prevent someone from breaking the lock and trigger an action when a lock-breaking attempt is made.

The same goes for the self-defending module. This feature prevents someone from trying to debug the code or tamper with it and also enables you to trigger specific actions when these debugging/tampering attempts occur.

These actions, which we call countermeasures, come in seven flavors: Break Application, Custom Callback Function, Delete Cookies, Redirect, Real-Time Notifications, Self-Destruct, and Data Exfiltration Prevention. Let’s go over each of them.

Break Application

Breaking the application is Jscrambler’s default client-side countermeasure.

The way it works is straightforward: every time that someone tries to break a lock in your code or whenever the self-defending module is triggered, the application will completely stop working.

This behavior is always enabled on the self-defending module.

Custom Callback Function

This countermeasure gives you full control over the desired triggered action.

To get it to work, you need to have a specific function inside your original source code with the desired behavior. Then, you supply the name of that function when setting up the custom callback, and it will be triggered as a countermeasure.

Delete Cookies

The delete cookies functionality immediately deletes all end-user cookies that don’t have a path property set nor have been created with the HttpOnly flag.

We will cover a specific use case for this countermeasure further below.

Redirect

As the name implies, with this option you are able to automatically redirect the user to a specified URL, such as a warning page.

This countermeasure is supported for browser versions that were released after Internet Explorer 9 but can be adapted to earlier versions as described in our docs.

Real-Time Notifications

This countermeasure enables you to receive notifications in the Web App’s Live Feed whenever a violation occurs to the specified lock or self-defending code.

All instances contain details to enable a better understanding of each violation, as seen below:

Self-Destruct

Self-destruct enables going beyond breaking the app. A combination of actions, such as crashing the memory, destroying the session, and destroying objects, destroys your app and its environment for every malicious user – possibly even crashing the attacker’s machine.

Attackers will lose all progress in a reverse engineering attempt, including all data from the app’s memory and from objects.

Data Exfiltration Prevention

This countermeasure will block the application from sending data to external services as soon as it is triggered. It provides another layer for protecting sensitive data and preventing data leakage, which is especially useful when dealing with data protection use cases.

The Data Exfiltration Prevention works for browsers, Node.js, and hybrid applications (React Native, NativeScript, etc).

Setting Up Countermeasures

Specifying Countermeasures Globally

As we mentioned before, client-side countermeasures are triggered when one of two possible scenarios occurs: either when someone breaks a code lock or when the self-defending module is activated (during a tampering or debugging attempt).

You can set up countermeasures easily via the Jscrambler Web App. When you’re on the screen with the application you want to protect, in the Fine-Tuning tab, ensure that you have selected either the self-defending feature or a code lock.

In either case, you’ll see a “Countermeasures” section, where you can specify which countermeasures you wish to apply.

You can also set up countermeasures directly through the Jscrambler CLI and the Jscrambler packages for webpack and gulp. You can specify countermeasures directly in the Jscrambler configuration file, as shown below:

{
  "keys": {
    "accessKey": "myAccessKey",
    "secretKey": "mySecretKey"
  },
  "applicationId": "myApplicationID",
  "params": [
    {
      "name": "browserLock",
      "options": {
        "browsers": [
          "firefox"
        ],
        "countermeasures": {
          "customCallback": "callbackFunction",
          "deleteCookies": true,
          "realTimeNotifications": true,
          "redirect": "https://www.example.com",
          "breakApplication": true
        }
      }
    }
  ],
  "areSubscribersOrdered": false,
  "applicationTypes": {
    "webBrowserApp": true,
    "desktopApp": false,
    "serverApp": false,
    "hybridMobileApp": false,
    "javascriptNativeApp": false,
    "html5GameApp": false
  },
  "languageSpecifications": {
    "es5": true,
    "es6": false,
    "es7": false
  }
}

Specifying Countermeasures Locally

From Jscrambler 6.1 onwards, countermeasures can be specified and triggered for specific portions of the code by using Countermeasure Injection. This gives you additional control over countermeasures which you can tailor to your specific needs.

To set this up, you have to use code annotations like shown below:

// @jscrambler define countermeasureInjection { countermeasures: { breakApplication: 1, deleteCookies: 1 } } as cmi
// @jscrambler enable cmi

Note that, if you don’t specify countermeasures in this code annotation, only Break Application will be applied.

Countermeasures Use Cases

Now that we have covered what countermeasures are and how to set them up, let’s go through some examples of use cases where using Jscrambler’s countermeasures can be vital to ensure the security and integrity of your applications.

Redirect to the Warning Page

Sophisticated attacks like malvertising or adware try to redirect the users of a legitimate website to a malicious copycat page that asks for user credentials.

One such example would be a cryptocurrency exchange under the domain www.exchange.com. If some users have compromised devices (for example with a malicious browser extension), they may be redirected to an external website that is copying the original one (under a similar domain such as www.echange.com, and the same user interface).

The external website can display a warning asking the user to create a new password or to set up 2FA again. Users may be unaware of the malicious intent and insert the requested data, which is sent to attackers.

Now, assuming that this cryptocurrency exchange was using a client-side monitoring solution like Webpage Integrity, it would be possible to set up an automatic redirect when such an attack is detected. So, infected end-users would not reach the malicious website and instead see a warning message such as the one shown below.

Custom Callback to a SIEM

Picking up on the example above, a redirect to a warning page would be one of many viable countermeasures to be applied.

Another possible reaction mechanism would be to set up a custom callback to an SIEM, with the goal of sending an immediate alert to security teams whenever someone tries to run the code outside of the specified environment.

This would be a valid approach for any of the other locks (domain, OS, browser, and date range) and the self-defending feature as well.

Delete Cookies to Prevent Scraping

Several web apps require authentication in order to access user-specific pages. Imagine a social media platform or even a SaaS web app with a trial plan. In both cases, the user has to log in before accessing the platform’s content.

Automated scraping attacks may seek to obtain this (often private) information to feed it to an external platform or exploit the web app itself.

When the attack starts, Jscrambler’s anti-tampering features come into play, detecting the tampering attempt and enabling a countermeasure. In this case, an effective one would be to delete cookies — this would immediately end the user session and deny access to private pages.

Custom Callback to Prevent App Features Abuse

For this last use case, let’s consider an application with a free and premium mode, such as an HTML5 game.

While the “premium” state is often managed on the server-side, there are several cases where this must be done on the client-side, such as with offline apps.

In these cases, an attacker would be able to easily access the app’s core logic, which resides in the JavaScript code. Then, it’s a matter of time until the attacker is able to identify how the premium state is managed and force it to “premium” instead of “free”. This effectively grants the attacker a tampered version of the app with all the premium features, bypassing the need to pay in order to unlock them.

App developers could set up a custom callback when a tampering or debugging attempt is detected by Jscrambler.

A practical example of this scenario is the tampering of the “Space Shooters” game, which we detailed in our Jscrambler 101 — Self-Defending article.

Custom Anti-Cheat Mechanism with Countermeasure Injection

Let’s consider that you have a mobile game that implements a custom anti-cheat mechanism. When a cheater is detected, using a Jscrambler countermeasure injection, you could also set the code to supplement the custom anti-cheat actions with existing countermeasures:

if (detectCheat()) {
    customAntiCheat();
    // @jscrambler define countermeasureInjection { countermeasures: { breakApplication: 0, realTimeNotifications: 1 } } as cmi
    // @jscrambler enable cmi
}

By setting realTimeNotifications: 1, every time this injected countermeasure is triggered, it will also appear in your Jscrambler Live Feed, with details of the incident.

Conclusion

And we’re done! Now you can unleash the full power of using Client-Side Countermeasures to protect your applications.

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

• Jscrambler 101 — First Use

• Jscrambler 101 — Code Annotations (Code Performance)

• Jscrambler 101 — Self Defending

• Jscrambler 101 — Control Flow Flattening

• Jscrambler 101 — Code Locks

• Jscrambler 101 — How to use the CLI

• Jscrambler 101 — Source Maps

• Jscrambler 101 — Self-Healing

• Jscrambler 101 — Profiling (Code Performance)

• Jscrambler 101 — App Classification

• Jscrambler 101 — Memory Protection

• Jscrambler 101 — SIEM Integration

Enjoy your testing and start protecting your Applications ASAP! If you have any additional questions, feel free to contact us.