# v_jstools: a Chrome extension for debugging reverse-engineered JavaScript

> v_jstools is a Manifest V3 Chrome extension for hooking page APIs, injecting code, generating JS environment stubs and running AST and WASM analysis. It is aimed at people who read and deobfuscate front-end JavaScript, not at general web developers.

**cilame/v_jstools** — 模仿着写一个 chrome 插件，用来快速调试前端 js 代码。

- Repository: https://github.com/cilame/v_jstools
- Stars: 3,014 · Forks: 761
- Language: JavaScript
- License: not declared
- Published: 2026-09-24 · Updated: 2026-09-24 · Language: en
- Canonical page: https://hysenlabs.com/projects/cilame-v-jstools

## Who v_jstools is actually for

The README opens with one line: it is a tool for debugging JavaScript pages during reverse engineering. That framing matters, because it separates v_jstools from the extensions most web developers install. It is not a framework inspector, not a network panel replacement, and not a linter. It assumes you are looking at code someone did not want you to read, and that your problem is getting a handle on a function before it runs.

The intended user is someone doing front-end analysis: pulling apart a signup or signing routine, tracing how a page builds a request, or extracting values that only exist inside a closure. The README also points to a WeChat group for AI reverse engineering and for v_jstools usage and case studies, which tells you the maintainer expects practitioners rather than casual users.

If your task is ordinary application debugging, the browser's own DevTools already cover it, and adding an extension with broad page access buys you nothing.

## The four mechanisms inside v_jstools

The README lists four core capabilities: hooking page APIs, injecting code, generating JavaScript environment code, and a JS analysis toolkit. They are separate features that share the same extension surface.

Hooking page APIs means intercepting calls the page makes, so you can observe arguments and return values at the boundary rather than stepping through the whole bundle. Code injection is described as configurable: you set up the code, it is injected, and closing the debugging state cancels the injection. That last detail is the interesting one, because it implies the injected script is tied to an active debugging session rather than persisting in the page.

Generating JS environment code produces a stub of the browser environment, which is the usual need when you want to run a lifted function outside the page it came from. The toolkit is the deepest part: a text comparison page, a library of packaged scripts, an AST page for analysing JavaScript syntax trees, an AST tool for compression, decompression, obfuscation and deobfuscation, an AST analysis mode that injects a page so it can use the current page's own functions, and a WASM analysis mode that does the same for WebAssembly.

The README is explicit that the AST tool's scope is limited by Manifest V3 permissions, so it can do less than a standalone AST tool would. That is a design constraint, not a bug, and it is worth knowing before you plan a workflow around it.

## Installing v_jstools from GitHub or pip

The README gives two download routes. The first is the repository itself: download it, extract the archive into the current folder, then drag the resulting folder onto Chrome's extensions page. The README's own claim is that this is all the setup required.

```bash
pip install v_jstools
v_jstools unpack vvv
```

According to the README, running that second command extracts the extension and opens the target folder location, so you can drag the folder straight into Chrome's extensions page. The README states that the command-line installation route currently supports only the V3 version. What you should see is a folder containing at least manifest.json, background.js, popup.html, popup.js and the tools directory, which matches the repository's top-level layout.

The README notes that full functionality requires Chrome version 105 or higher. It does not document what degrades on older builds, only that the complete feature set needs 105+.

## Manifest V3 is the constraint, not the feature list

The current code is the Manifest V3 version, and the project keeps the old Manifest V2 build as an archived release labelled as the final V2 snapshot. That release exists because V2 and V3 are not interchangeable: extension APIs changed, and anything built against the old surface will not simply carry over.

The README's own admission that the AST tool is limited by V3 permissions is the clearest limitation in the available documentation. Manifest V3 constrains how extensions execute code in pages, so a tool that wants to transform JavaScript and run it in page context has less room than a V2 build did. The two injection-based analysis modes, AST analysis and WASM analysis, work by injecting a page that can use the current page's functions. That is a reasonable workaround, but it means the analysis surface depends on the page you are sitting on.

Nothing in the README documents rollback, version pinning, or how to move between the V2 and V3 builds beyond the archived release link. If you need a reproducible analysis environment, that gap is real.

## Where v_jstools is the wrong tool

Three cases stand out.

First, if you need analysis that runs outside Chrome, v_jstools is the wrong shape. It is a Chrome extension, and the README describes no CLI analysis mode, no headless operation and no server component. The pip package is a delivery mechanism for the extension files, not a standalone analyser.

Second, if your JavaScript is not obfuscated and you are debugging your own application, the hooking and injection features duplicate what DevTools breakpoints and the console already do, while adding an extension with page-level access.

Third, if you need a documented, stable API, this is not that. The README is organised around download instructions, animated demonstrations and a feature list. It does not document the hook API surface, the injection configuration format, or the environment generator's output. The 2025/12/22 update notes that the AI assistant feature ships with two function-call interfaces configured for testing, and that the maintainer may make function calls configurable later. That is an explicit statement that part of the feature set is provisional.

A related point on maintenance: the last push to the default branch was on 2026-04-27, and the repository is not archived. The most recent release listed is the Manifest V2 archive from 2025-07-15. Anyone evaluating this should read the commit history rather than assume a steady release cadence.

## How v_jstools differs from a standalone deobfuscator

A standalone deobfuscator such as JS Deobfuscator takes a script as input, transforms it, and returns the result. Your work happens on a file, offline, and the output is something you can diff and keep.

v_jstools inverts that. It works on a live page, inside the browser, and its value comes from being present while the code runs. Hooking a page API only makes sense when the page is executing. Generating environment code is about reproducing the runtime a lifted function expects. The AST analysis and WASM analysis modes inject into the current page specifically so they can borrow the page's own functions, which an offline tool cannot do.

The trade-off is reproducibility. An offline deobfuscator gives you a file you can version. v_jstools gives you an interactive session whose state depends on the page, the injection configuration and Chrome's permission model. If your goal is a clean artefact you can hand to someone else, the offline route is the better fit. If your goal is to understand what a page does while it does it, the extension is the better fit, and the two are complementary rather than competing.

## Licence, upgrades and what the repository does not say

The repository listing shows no licence. That is not a statement that the code is unlicensed; it means no licence file is present in the files available, and the README does not mention one. For a tool that gets loaded into a browser with page access, that matters. If you plan to use v_jstools inside a company, the absence of a stated licence is something to resolve with the maintainer before you build a process around it. This is a factual gap, not legal advice.

Upgrade cost is tied to the Manifest V3 migration. The project has already done one full rewrite from V2 to V3, and keeps the V2 build archived rather than maintained. There is no documented deprecation policy, no changelog file in the top-level listing, and no stated Chrome-version policy beyond the note that full functionality needs Chrome 105 or higher. Upgrades are therefore something you verify by reading the README's dated update notes, which are written as bullet points rather than as release documentation.

The practical consequence: pin the build you have tested, keep the extracted folder, and re-read the README update section before replacing it.

## Conclusion

Adopt v_jstools if you already read obfuscated front-end JavaScript and want hooking, injection and AST work in one extension; skip it if you need a stable documented API, a Firefox build, or anything you can run outside Chrome. Before relying on it, check the manifest.json permissions against what you are willing to grant, and confirm the repository's licence, since the listing shows none. The pip route (pip install v_jstools, then v_jstools unpack vvv) is the fastest way to see the actual folder contents before you load it.

## FAQ

### How do I install v_jstools in Chrome?

Either download the repository from GitHub, extract it and drag the folder onto Chrome's extensions page, or run pip install v_jstools followed by v_jstools unpack vvv, which the README says extracts the files and opens the target folder. Full functionality requires Chrome 105 or higher.

### Does v_jstools work without downloading it from GitHub?

Yes. The README lists a pip route as an alternative to downloading from GitHub, and states that the command-line installation currently supports only the V3 version.

### What can the v_jstools AST tools do?

The toolkit includes an AST page for analysing JavaScript syntax trees and an AST tool for compression, decompression, obfuscation and deobfuscation. The README notes that the AST tool's capabilities are limited by Manifest V3 permissions.

### Is there still a Manifest V2 version of v_jstools?

Yes, but only as an archive. The README links to a Manifest V2 release described as the final V2 snapshot, and the current code is the Manifest V3 version.

## Sources

- [cilame/v_jstools on GitHub](https://github.com/cilame/v_jstools)
- [Issues](https://github.com/cilame/v_jstools/issues)
- [README](https://github.com/cilame/v_jstools/blob/main/README.md)
- [Releases](https://github.com/cilame/v_jstools/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/cilame-v-jstools