AntiDebug_Breaker: 34 hooks for reading and unblocking front-end JavaScript

What the extension patches, and who reaches for it

Every site you reverse engineer eventually fights back. The page calls debugger in a loop, redefines console.clear, checks innerHeight to see whether you opened devtools, and closes the tab the moment it decides you are looking. AntiDebug_Breaker is a Chrome extension that installs counter-hooks for those defences, and the README describes its purpose as helping with front-end JavaScript reversing and with information gathering during penetration tests. It is built on the author's own Hook_JS library, and the repository layout shows the usual extension shape: a manifest.json, a background.js, a content.js, a popup directory, an i18n directory plus a _locales directory for translated strings, and a scripts directory holding the payloads. The README lists 34 script entries in four groups, and the interesting part is not the count but the granularity. Each script is a single file in scripts/, named after what it intercepts, and a wiki page exists for submitting your own.

Bypass Debugger hijacks three ways of calling code

The infinite debugger is the reason most people install this. The README names the three core ways a page triggers it, and the script hooks all three: `eval`, `Function` and `Function.prototype.constructor`. That covers the overwhelming majority of front-end infinite debugger loops, according to the README, and the honest caveat is in the same paragraph. Because eval runs in its own scope, some sites break when the hook is in place, and the suggested response is to switch to Firefox and debug there instead, where a debugger statement is harmless. The README also states that a small number of sites use targeted countermeasures, such as deliberately causing the eval scoping problem, which can produce a front-end error or leave the debugger loop running. So this is a high-coverage fix with a known failure mode, not a guarantee. The script's principle is explained in an external article linked from the README rather than in the repository itself.

Five of the AntiDebug scripts fight the console, not the debugger

The rest of the AntiDebug group is a set of small arguments with page behaviour. hook clear forbids the page from wiping console data, and it was written by an author named Yosan. hook log, also by Yosan, defends against the page rewriting console.log itself. hook close overrides close so a detection routine cannot shut the tab, and hook history stops the history.back() style trick that throws you off a page you were reading. Fixed window size is the plainest of them, freezing the reported geometry to the constants the README prints: `innerHeight` 660, `innerWidth` 1366, `outerHeight` 760 and `outerWidth` 1400. The reason is that front-end code infers devtools is open from the gap between inner and outer dimensions. Hook table is the cleverest and the most heuristic, going after sites that detect human reaction time: it targets pages that call console.clear frequently, then flood the console with output, and then immediately navigate with location.href, often to a github.io address. If your target shows those three signs, that script is worth loading. If it does not, enabling it changes nothing except your own noise level.

The Hook group reads cookies, storage and requests from inside the page

This is the plain instrumentation half of the extension, and it covers the browser APIs a front-end app leans on: `document.cookie`, `XMLHttpRequest.setRequestHeader`, `XMLHttpRequest.open`, `fetch`, `JSON.parse`, `JSON.stringify`, `Promise`, `Math.random`, `Date.now` and `performance.now`, plus `setItem`, `getItem`, `removeItem` and `clear` on both `localStorage` and `sessionStorage`. Why it matters: request headers and `XMLHttpRequest.open` tell you what the app sends and where, the storage hooks catch the token or the encrypted blob that later gets posted, and `JSON.parse` is where you often see the shape of a response for the first time. Promise and the three timing sources give you a view of ordering and of any fingerprint the app is building from `Math.random` or `performance.now`. The limit of the approach is structural. These hooks replace methods on the objects the page has already loaded, so anything the app runs in a worker, in an iframe the extension cannot reach, or inside a bundled WebAssembly module stays invisible.

Hook CryptoJS, JSEncrypt and SM-crypto print what you came for

This is where the extension earns its keep for anyone reverse engineering a web app's own request signing. Hook CryptoJS intercepts all symmetric, hash and HMAC algorithms inside CryptoJS, with AES, DES, MD5 and SHA named in the README, and a companion tutorial video is titled around extracting the key, iv, mode and padding. Hook JSEncrypt does the same for RSA: on encryption it prints the public key, the original data and the resulting ciphertext, and on decryption the private key, the original data and the recovered plaintext. Hook SM-crypto targets the Chinese national standard algorithms, contributed to the project. Every one of these scripts carries the same troubleshooting note, and it is the most useful sentence in the README for a newcomer: if nothing prints, check whether the target site cleared console.log, or whether it is using a different algorithm from the same library. If you have confirmed the library and the algorithm and still get nothing, the README asks you to contact the author. That is an admission that coverage is empirical rather than guaranteed.

Vue routes and route guards, plus React routes

The framework group is small and does one thing well. For Vue it lists four actions: retrieve the router's routes, clear navigation, clear the route guards, and activate Vue Devtools through a script the README calls detectorExec. Clearing the guards is the useful one for analysis, since an app that blocks navigation on a debug flag stops being able to stop you. React gets one entry, retrieving routes, which is consistent with how much less the extension does there: the React group has a single item against Vue's four. The README links tutorial videos for both frameworks on bilibili, along with a video on locating encryption code inside JavaScript, and it points at a practice site, SpiderDemo, for exercises. The framework hooks are also the scripts most likely to break on a site, because they reach into framework internals whose names change between versions, and the README gives no version compatibility table.

Install from the Web Store, then fetch the MCP bundle

There are two documented routes, and both are short. The Chrome Web Store listing is the supported one, and the manual route starts from the extensions page. Those two addresses are the whole install story:

https://chromewebstore.google.com/detail/antidebug-breaker/opkclndfcbafdaecbbaklefnaadopcln
chrome://extensions/

For the manual route the README says to download the source locally, open Chrome, visit that extensions page, click the load unpacked control in the top left corner and then select the source folder. Load unpacked is a developer mode action, and the README shows a screenshot of it rather than describing the toggle, so expect to enable developer mode first. The interface language is not a build decision: the README says it is chosen under the auxiliary configuration menu, with automatic, which follows the browser, Simplified Chinese and English as the options. Documentation exists in both languages, with README.en.md alongside the Chinese README.md, an English install page at docs/agent-install.en.md and an English MCP page at mcp/README.en.md, so an English-only reader is not blocked. The newest feature is the MCP and Skills bundle: the extension has an MCP page with a button labelled 下载 MCP + Skills that sends you to the GitHub release page for the matching package, with installation written up in docs/agent-install.md. The repository keeps a dedicated mcp directory, a skills directory holding an antidebug-breaker-skills folder, and an agent-release.json at the root. Neither the README nor the installation page names the exposed tools or which scripts the agent may call, so read the bundle before wiring it into an agent loop.

No licence file, three releases in September, scripts you can read

The repository root contains no LICENSE file, so the project states no licence identifier anywhere in the documentation. That is a real constraint for commercial use and for anything you intend to redistribute, and it is different from most of the tooling in this space, which usually ships an MIT or Apache header. On maintenance the picture is healthy: v3.1.0 shipped on 2026-09-12, v3.1.1 on 2026-09-17 and v3.1.2 on 2026-09-21, which is also the date of the last push to main. The scripts are individual files under scripts/ rather than one bundle, indexed by scripts.json, and the README credits the original authors of hook log, the location_href script and the SM-crypto hook, with links to the upstream repositories. That per-script provenance is what makes this project safe to read, and it also means a script you did not write may behave differently from the note next to it.

Editorial conclusion

Adopt AntiDebug_Breaker if you read other people's front-end code for a living and keep losing the console to anti-debug loops, window size checks and CryptoJS parameters hidden behind a hook. Do not adopt it for automating attacks on a site, and remember that the hook targets are one level above the browser API, so a site that reimplements fetch in a worker or bundles its crypto in a WebAssembly module is outside what any of these 34 scripts can see. Verify three things before you rely on it: that Bypass_Debugger does not break the target page through its eval scoping, that the licence question is settled by whoever owns the work you do with it, since no LICENSE file sits at the repository root, and that the manual install path still matches your Chrome build, because the README documents only load unpacked from chrome://extensions/ and the Web Store listing.

Frequently asked questions

Official sources

1. 0xsdeo/AntiDebug_Breaker on GitHub
2. Issues
3. Project website
4. README
5. Releases