hello_js_reverse_skill: a Claude Code skill for JavaScript reverse engineering

Installing it means cloning a directory into a tool's skills folder

This is not a package you add to a dependency list. It is a skill: a directory holding `SKILL.md`, a stack of reference documents and a set of templates that an AI coding tool reads when a matching task shows up. The README offers two routes. The first is to ask the assistant in your chat window to install it by name and project address, and let it do the download and configuration. The second is a plain clone into whichever skills directory belongs to your tool.

git clone https://github.com/WhiteNightShadow/hello_js_reverse_skill.git ~/.codex/skills/hello_js_reverse_skill

Cursor and VSCode plugins get the same repository at `~/.cursor/skills/hello_js_reverse_skill` and `~/.vscode/skills/hello_js_reverse_skill`. After installation the README states that the agent reads `SKILL.md` and activates the skill automatically when a conversation touches interface signature analysis, anti-scraping work, dynamic cookies, obfuscated JavaScript, WASM or browser environment debugging.

That activation rule is the whole mechanism. There is no daemon, no service and no library call. If your tool does not load skills from that directory, a correctly cloned copy does nothing at all.

Four template directories map a solution mode to a language

The most useful part of the repository is the `templates/` directory, because the README's quick start table ties each entry to a specific shape of problem: when the encryption is pure logic, use `templates/node-request/`; when the target runs inside a JavaScript virtual machine, use `templates/vm-sandbox/`; when the crypto lives in a `.wasm` module, use `templates/wasm-loader/`; when nothing runs without a browser, use `templates/browser-auto/`.

Starting a Node.js project out of the first template looks like this:

cp -r templates/node-request/ my_project/
cd my_project && npm install
node main.js

The Python equivalent mirrors it with `templates/python-request/`, where the signing logic you would edit lives in `utils/sign.py` rather than `main.js`:

cp -r templates/python-request/ my_project/
cd my_project && pip install -r requirements.txt
python main.py

The `scripts/` directory adds four utilities that sit alongside those templates: `check-deps.sh` for verifying Node.js and Python are present, `sandbox-runner.js` as a command line VM sandbox, `hook-generator.js` with ten hook patterns, and `crypto-identifier.js`, which works from ciphertext features rather than source to guess which algorithm produced a value.

One detail worth flagging early: the repository is filed under Python as its primary language, while the README describes a two-language design where `crypto` and `crypto-js` carry Node.js and `hashlib` and `pycryptodome` carry Python. Both are true at once, since the Python template set and `check-deps.sh` exist alongside Node.js ones, but the language label understates how much of this project is JavaScript work.

Cookie attribution is the feature that genuinely needs the browser

Most reverse engineering tasks divide cleanly into ones you can solve from static source and ones where you have to watch a page run. The `analyze_cookie_sources` helper added in v2.5.0 is the clearest example of the second kind. It combines what arrived in HTTP `Set-Cookie` headers with what was observed in `document.cookie` writes during a session, which answers the question a developer actually has, which cookie did this page set and from where.

Splitting the two sources matters because they behave differently. A header cookie was set by the server responding to your request, and it arrives whether or not any script ran. A `document.cookie` write came from JavaScript executing in the page, which means it depends on timing, on values computed at runtime, and possibly on a fingerprint of the machine doing the reading. When the two disagree about which cookies exist, you have learned something specific rather than something vague.

The rest of the feature list follows the same division. Common algorithms such as MD5, SHA, AES, DES, RSA, HMAC and Base64 are described as pure algorithm reimplementations. Obfuscation work is split into named categories including OB-style obfuscation, control flow flattening, `eval` packing and custom virtual machines. The single workflow named `camoufox-reverse` is what unifies the browser side, covering source search, hook injection, function tracing, network analysis, request interception and anti-detection checks through one MCP server.

The README hedges on JSVMP tracing in a way worth reading closely

The virtual machine tracing feature is described as covering JSVMP style protection with four techniques: hooking, instrumentation, logging, and source-level instrumentation added in v2.5.0. Immediately after that, the README states that the approach provides a general investigation path but that actual effectiveness has to be verified against each target sample.

That caveat is the honest part of the feature, and it changes how you should plan the work. A byte-code virtual machine exists precisely to move the interesting logic out of anything a human or a tool can read directly, so the value of a documented procedure is in the procedure rather than in an outcome. The dedicated references `references/jsvmp-analysis.md` and `references/jsvmp-source-instrumentation.md` are where that procedure lives, alongside `references/anti-debug.md` for the debugger counter-measures that tend to fire alongside this class of protection.

The v3.6.0 and later anti-scraping taxonomy helps here too. The README groups anti-scraping into signature based systems, behaviour based systems, and pure obfuscation, and warns against the trap where your instrumentation changes the fingerprint the signature was computed over. Knowing which of the three you are facing before you start hooking determines whether the signature you recover will even match once your hooks are removed.

Three releases in two days, and no license file

The release history is unusually compressed. v3.7.0 shipped on 2026-09-07, v3.8.0 on 2026-09-08 at 09:39, and v3.9.0 on 2026-09-08 at 12:01. The last push recorded for the repository is 2026-09-08, matching the newest tag, and the default branch is `main`.

The release notes are more informative than the README in one respect: they explain what moved underneath. v3.7.0 added configurable JSON API collection to the Python template with page, offset and cursor pagination, primary key deduplication, JSONL output, per-page checkpoints and resume validation, and made the template tests offline. v3.9.0 aligned the skill with MCP v1.8.0 and added fixed-source case preparation for KProtect, javascript-obfuscator, CryptoJS and FingerprintJS, with download checks and source and licensing retained. That last point is the maintainer being explicit that upstream assets are prepared on demand and stay outside the repository rather than being bundled.

The tree holds `.github/`, `SKILL.md`, `cases/`, `docs/`, `examples/`, `references/`, `scripts/`, `templates/` and `tests/`, and the README calls `cases/` the single experience library. What the tree does not hold is a license file, and the repository carries no license identifier. That is a real constraint rather than a technicality, because the templates and case material are the parts most likely to be copied into someone else's project.

The top-level tree is also broader than a skill strictly needs, with `tests/` sitting next to `references/`. The v3.9.0 notes describe 40 Python template tests, 16 script and local HTTP boundary tests, 12 Node tests and 39 tool contract checks, which explains why a prompt package carries a test suite.

The README hands off before reaching the MCP tool surface

The documentation is layered, and knowing which layer answers your question saves a lot of time. The README itself is the entry point: installation routes, the capability list, the mode-to-template table, and a project structure listing that names every reference file. `SKILL.md` is the file the agent actually reads. Everything else is depth that the README points at rather than repeats.

It does not get as far as documenting the MCP tool surface. The README stops inside the section introducing the `camoufox-reverse` MCP server, so the practical reference for tool names and their migrations lives in `references/mcp-tool-reference.md`, and the cookbook of task-shaped recipes lives in `references/mcp-cookbook.md`. The decision tree that picks between solution modes is `references/workflow-overview.md`, with the per-phase detail in `references/phase-details.md`.

There is a version dependency to keep in view when you read those. v3.9.0 aligns with MCP v1.8.0, and its notes say the new parameters need v1.8.0, while older workflows keep working against the v1.6.x and v1.7.x tool schemas. If a documented argument is rejected, that pairing is the first thing to check.

The last piece worth knowing about is scope. The v3.9.0 notes state plainly that upstream semantic differences and failure records are kept rather than smoothed over, and that no claim is made about passing commercial site risk controls. For a tool whose output is a verified request signature, that framing is the right one to evaluate it against.

Editorial conclusion

The value here is packaged judgement rather than code. Somebody already worked out that a dynamic cookie problem needs the browser and a pure crypto problem does not, and the repository encodes that split in four template directories and a decision tree in references/workflow-overview.md. What it will not do for you is produce a working signature on an unfamiliar target without you verifying the outcome, and the README says so more than once. If your goal is a verified request signer for a known API, start from templates/node-request/ and change the logic in main.js; if the target is a JS virtual machine or a WebAssembly module, expect to read references/jsvmp-analysis.md before touching code. One loose end to settle first: no license file ships with the repository, so check terms before copying any template.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. WhiteNightShadow/hello_js_reverse_skill on GitHub