# js-reverse-automation: a skill pack for browser-side JavaScript analysis

> This project packages the work of reversing a site's client side cryptography into a repeatable pipeline for an assistant: connect to a real browser through a protocol for browser control, find the function that encrypts or signs a request, verify it against real samples, and then generate the artefacts that let you replay the algorithm, namely a remote call stub, a local proxy service, and a proxy configuration for an intercepting tool. It is written for authorised testing work.

**Fausto-404/js-reverse-automation--skill** — 结合chrome-devtools-mcp的能力并加上Skill的规范，实现JSRPC+Flask+autoDecoder方案的前端JS逆向自动化分析，提升JS逆向的效率

- Repository: https://github.com/Fausto-404/js-reverse-automation--skill
- Stars: 605 · Forks: 85
- Language: Python
- License: Apache-2.0
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/fausto-404-js-reverse-automation-skill

## What the project is

The repository describes itself as a full workflow automation skill for front end JavaScript reverse engineering, combining the capabilities of a browser control protocol with the specification of a skill, to implement an analysis approach based on remote JavaScript calls, a local service, and an automatic decoder, in order to raise the efficiency of the reverse engineering work.

The scenarios it is aimed at are listed explicitly, and they are the ones that come up constantly in authorised testing. Login parameters that are encrypted, with a list of the algorithms involved including RSA, AES, the Chinese SM2 and SM4 standards, message digests, and custom encodings. Response content that is encrypted when data is scraped. Request signatures in the form of a sign, token, or encrypted parameter. The need to package the reverse engineering logic as reusable code. And the need to work together with an intercepting proxy to capture and modify traffic.

The interesting thing about the list is that every one of them is a problem of the form: the browser already knows the answer, and the difficulty is getting at it.

That is where the remote call idea comes in, and the readme describes the shift in the first of its four pain points. Rather than asking an assistant to reconstruct a complete browser environment so that a piece of obfuscated code will run, the approach is to guide it into establishing a remote call from outside, so that the real browser is used as the algorithm interpreter. The obfuscation logic is bypassed rather than solved, and the encrypted result is obtained at no cost.

So the general shape is: the browser is the oracle, a local service is the bridge, the intercepting proxy is the delivery mechanism, and the skill is the procedure that connects them. That is a coherent answer to a real problem, and the rest of the document is the detail of how it is put into practice.

The project is Apache 2.0 licensed, the last push was on 2026-10-10, and the release history is three whole-number versions across 2026, with the second one in July and the third in September.

## The four problems it sets out to solve

The readme frames the project as solving four problems with what it calls a practical engineering focus, and each of the four is a design decision rather than a feature.

The first is the move from grinding through environment reconstruction to dynamic extraction through the remote call, which is the idea described above. The point of the framing is that the hard part of breaking a site's cryptography is usually not the algorithm, it is getting the code to run at all, and the approach removes that problem from the scope rather than attacking it.

The second is the move from isolated output to delivery across the whole chain. The rejection is of stopping at understanding the code. What the assistant delivers is not an analysis but a runnable local service in Python, together with the configuration that links it to the intercepting proxy, so the result drops into a testing workflow rather than sitting in a document.

The third is the move from running blind in a single stage to validating at each stage against a contract. The phases are numbered from zero to nine, and there is an intermediate artefact with a defined format that acts as the contract between phases. After the code is generated, a local validator is triggered, which the readme says substantially reduces the hallucination and syntax errors that an assistant produces when it is working through long complex text.

That third point is the one that makes the difference between a prompt and a system. A contract artefact means a later phase can check that what it was given is well formed, rather than discovering the problem three steps later in a stack trace.

The fourth is the move from a blank page in every conversation to experience that accumulates. The tool keeps a memory file, described as an evolution matrix, and the readme's claim is that it lets the assistant carry experience across tasks, so the skill pack can keep improving against new kinds of obfuscation and new anti-debugging techniques.

So the four problems map onto four mechanisms: remote call instead of environment reconstruction, generated artefacts instead of analysis, a phase contract with validation instead of a single run, and a memory file instead of a fresh session each time. It is an unusually well argued case for why an assistant needs more than a good prompt.

## The phase pipeline and the contract

The workflow directory holds a single file describing the detailed pipeline from phase zero to phase nine, and the references directory holds the output contract among the knowledge files that are loaded on demand.

The idea of a contract is worth spelling out, because it is the mechanism that makes the phases composable. The readme names a specific artefact, a file with a defined format that holds the analysis result, and it is the thing that one phase writes and the next phase reads. The schemas directory then holds the definitions of the formats involved, one per artefact: the analysis result, the candidates, the runtime probe dump, and the adversarial trace.

So the pipeline is not a chain of prompts but a chain of typed artefacts. Each phase produces a file whose shape is declared, and the next phase is given that file rather than a transcript. That is a much better shape for long work, because it means a phase can be re-run, and it means the validation of the output is a separate concern from the generation of it.

The scripts directory shows the same discipline in the tooling. There is a shared utility library, an input validation script, a script that emits a runtime hook probe, one that emits an adversarial runtime probe, a source level instrumenter, a differential analyser comparing the original and the intervened run, a module probe generator, an evidence graph builder, a candidate scoring script for encryption functions, a differential verifier, and generators for the JSRPC stub, the Flask proxy, and the intercepting proxy documentation.

There is also a service management script that starts and stops the two services, a four layer artefact validator, a browser evidence validator, a quarantine report, a dependency check, an environment patcher, a classifier for anti-scraping defences, an identifier for the encryption algorithm, a library of hook templates, a static analyser that works on the abstract syntax tree, and a small WebSocket client library.

That last pair is the one worth noting. The static analyser works on the parsed syntax tree of the source, and the hook templates are the runtime counterpart, and the two are used together: the static side narrows the field, the runtime side confirms it. The generated directory then holds what the assistant produced, and the artifacts directory holds what a run produced, with one file per stage, from the validated input through the probe dump and the module dump to the evidence graph, the candidate scores, the validation report, the quarantine report, and the two service status files.

## The capability table

The core capability section is a table with two columns, a direction and the highlight of that direction, and the six rows are worth reading closely because they describe a real reverse engineering process rather than a feature list.

The first is real entry point discovery. The approach is to connect to a real browser through the control protocol, trigger and follow the encryption and signing chain, hook the calls of the network primitives, of the cryptographic ones, of the common JavaScript crypto libraries, and of the Chinese SM2, SM3 and SM4 implementations, capturing the parameters as they flow. It also parses the module system of a bundled application and its module cache.

The second is candidate location and verification, and the methods listed are a scoring scheme with eight dimensions, verification against real samples, active calling of the candidate, and a fingerprint difference on the request fields. The stated goal is to keep converging on a reproducible real entry point, and the artefact that ties it together is an evidence graph keyed by a cryptographic hash that links a producer to a consumer, so the data flow can be followed rather than guessed.

The third is runtime adversarial analysis. The observations listed cover anti-debugging, anti-hook tricks, integrity checks, environment fingerprinting, dynamic code, multiple realms, the response chain, and loader events, and the techniques used to keep the instrumentation working are persistent hooks, a unified orchestration layer, rebuilding after external replacement, and a safe unload.

The fourth covers heavily obfuscated code and virtual machine style protection, and it takes a different approach: a conservative source level property tap that correlates the instrumentation position with the runtime hot spots and the call results, combined with a difference analysis between a baseline run and an intervened run, plus signals from console clearing, history navigation, storage access and page closure.

The fifth is the browser evidence loop, which binds the tab and document session identity, manages the lifecycle of browser actions, and uses a validation script that checks the plaintext, the final request body, the route, the status code and the business response, producing evidence that is traceable to a specific action.

And the sixth is automated delivery, which manages the two services, generates the injection code, performs the browser registration check, and outputs the configuration for the intercepting proxy.

## What the deliverable actually contains

The readme lists the final products, and the list is the best summary of what the tool produces.

They are the plaintext and the ciphertext or signature, the final request and the server response, the injection code for the remote call, the local proxy service, the configuration for the intercepting proxy's automatic decoder, and a validation report.

That is a complete chain of evidence. The plaintext and the signature are what you were trying to obtain, the final request and the response are what they were used for, the injection code and the proxy are how you will use them from now on, and the report is what you hand to somebody else.

The generation of the proxy configuration is described in more detail than the rest, and the details are the ones that make it usable. The output covers the complete HTTP message, the wrapping mode, whether it is the request or the response direction, a port fallback, and a verification command that can be copied. The port fallback in particular is the kind of detail that comes from having run into a port already in use.

The point about the wrapping mode is worth understanding, because it is where these tools usually go wrong. A site may encrypt the whole body, or a field inside a JSON document, or a query string value. A configuration that assumes the first kind will silently fail on the second, and the mode is what tells the tool which shape to expect.

The delivery section of the capability table adds one more thing, which is that the browser registration is verified. That is the step where the generated injection code is actually run in the browser and confirmed to work, rather than the code being emitted and hoped for.

And the whole approach still rests on the remote call idea. The injection code is what turns the real browser into a callable function, and the local service is what the intercepting proxy asks when it needs the algorithm applied to a modified request. That is why the tool needs the browser running at all, and it is why the answer is a workflow rather than a library.

## The repository layout, and the memory file

The top level of the repository holds the licence, the readme, and one directory, which is the skill package itself. The package is laid out so that the expensive documentation is only loaded when it is needed.

```
├── workflow/
│   └── pipeline.md
├── constraints/
│   └── rules.md
├── references/
├── schemas/
├── scripts/
├── generated/
└── artifacts/
```

The entry file is a trimmed version of the skill definition, and the detailed workflow with the numbered phases sits beside it. The constraints directory holds the rules the assistant is held to.

The references directory is the interesting one, because its contents are the knowledge the assistant consults rather than the procedure it follows. There is the input and output contract, a description of the capability boundaries, the architecture, the security model, a catalogue of anti-debugging patterns and how to patch them, the browser session and evidence contract, a page for complicated entry point cases covering the module system, asynchronous code and WebAssembly, a page on how to collect evidence through hooks, source and network, and the evolution matrix, which is the cross task memory file.

That last file is the one that makes the fourth of the four claimed improvements real, and it is the one to think about. A file of accumulated experience, indexed by task, that the assistant reads at the start of a new job and writes to at the end, is a crude but effective form of learning, and unlike a model fine-tune it is inspectable, editable, and versioned with the rest of the skill.

The capability boundaries page and the security model are the other two that deserve attention in a tool that drives a real browser against a real site. A boundaries page tells the assistant what it is not supposed to do, and a security model tells the operator what the tool will and will not touch.

The whole design is a good example of the current practice in assistant tooling: the intelligence is in the procedure, the contracts, and the scripts, and the model is the component that follows them. The four directories, the schemas, and the forty-odd scripts are the substance, and the prompt is the smallest part of it.

## Conclusion

js-reverse-automation fits a tester working on a site they are authorised to assess, who keeps repeating the same sequence of locating an encryption function, capturing its parameters, and wiring the result into a proxy. It does not fit somebody who wants a general purpose deobfuscator, because the tool assumes a real browser is available to call into. Verify first which of the two editions you are reading, since the release numbers are whole numbers and the changes between them are large, that the phase contract is what your assistant will actually follow, since the whole design assumes a disciplined sequence rather than a single prompt, and that the generated artefacts are reviewed before they are used, because the pipeline writes executable code into your environment.

## FAQ

### What does the js-reverse-automation skill pack do?

It automates the workflow of reversing a site's client side cryptography: connecting to a real browser through a control protocol, finding and verifying the function that encrypts or signs a request, and generating the artefacts that let you replay the algorithm, namely an injection stub, a local Python proxy, and a configuration for an intercepting proxy.

### Why does the js-reverse-automation approach use a real browser instead of reconstructing the environment?

Because getting obfuscated code to run outside the browser is usually harder than the algorithm itself. The approach is to establish a remote call so the real browser acts as the algorithm interpreter, which bypasses the obfuscation and yields the encrypted result at no cost.

### What is the phase contract in js-reverse-automation?

The pipeline runs in numbered phases from zero to nine, and each phase writes a typed intermediate artefact, defined in the schemas directory, that the next phase reads. The result is a local validator that checks the generated artefacts, which the project says substantially reduces the syntax errors and hallucinations an assistant produces over long complex text.

### How does js-reverse-automation find the encryption function?

It hooks the network, cryptographic, and common JavaScript crypto library calls in the real browser and follows the parameters as they flow, scores the candidates on eight dimensions, verifies them against real samples by actively calling them, and diffs the request fields. A hash keyed evidence graph links the producer to the consumer so the data flow can be followed rather than guessed.

### What does the js-reverse-automation skill pack deliver at the end?

The plaintext, the ciphertext or signature, the final request, the server response, the injection code for the remote call, the local proxy service, the configuration for the intercepting proxy's automatic decoder, and a validation report. The proxy configuration covers the full HTTP message, the wrapping mode, the request or response direction, a port fallback, and a verification command.

## Sources

- [Fausto-404/js-reverse-automation--skill on GitHub](https://github.com/Fausto-404/js-reverse-automation--skill)
- [Issues](https://github.com/Fausto-404/js-reverse-automation--skill/issues)
- [License: Apache-2.0](https://github.com/Fausto-404/js-reverse-automation--skill/blob/main/LICENSE)
- [README](https://github.com/Fausto-404/js-reverse-automation--skill/blob/main/README.md)
- [Releases](https://github.com/Fausto-404/js-reverse-automation--skill/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/fausto-404-js-reverse-automation-skill