Anything Analyzer: An Electron Workbench That Feeds Captured Traffic to an LLM

The gap Anything Analyzer targets: five capture sources, five separate tools

The README opens with a complaint rather than a feature list. DevTools sees only the browser. Fiddler and Charles do proxy work but nothing else. Wireshark cannot read HTTPS. After capture, the operator still scrolls through hundreds of requests by hand. Anything Analyzer's answer is to funnel browser traffic, desktop app traffic, curl and wget calls, Python and Node scripts, and phone or IoT device traffic into a single session, then hand that session to a language model. The intended user is someone doing protocol reverse engineering or API analysis who would otherwise run a proxy, a browser inspector and a notes file side by side. It is not a general network monitoring tool, and the README never claims to be one. The scope is HTTP and HTTPS request and response inspection with an analysis layer on top.

Two capture channels merging into one SQLite-backed session

The architecture diagram shows two entry points. The first is an embedded browser driven through the Chrome DevTools Protocol, using CDP Fetch interception to record every HTTP request and response including headers and bodies. The second is a built-in MITM proxy listening on port 8888 by default, which signs TLS certificates on the fly with node-forge and caches them per domain using an LRU policy. Both channels write into the same session, and each request is tagged with its origin so you can tell CDP traffic from proxy traffic. Persistence is better-sqlite3, a local SQLite database, which is why sessions survive restarts. The main process is split into directories that map onto these concerns: src/main/capture for the CDP Fetch engine, JS hooks and storage snapshots, src/main/proxy for CA management and certificate issuance, src/main/ai for the two-phase orchestration, src/main/mcp for both the MCP client and the built-in server, and src/main/session for lifecycle. That separation is worth noting because it means the proxy can run without the browser, which is what makes the terminal and phone scenarios work at all.

The two-phase analysis pipeline and what the JS hooks actually intercept

Analysis is not a single prompt over a raw dump. Phase 1 filters noise requests, and Phase 2 performs the focused analysis, with the model able to pull request details on demand rather than receiving everything up front. The README lists five modes: automatic detection, API reverse engineering, security audit, performance analysis, and JS encryption reverse engineering. There is also a manual path where you tick specific requests and skip pre-filtering entirely, which is the escape hatch when the automatic filter discards something you needed. On the browser side, JS hook injection targets fetch, XHR, crypto.subtle, CryptoJS, and the Chinese SM2, SM3 and SM4 primitives, and the tool can extract encryption-related code fragments out of JS files. Output streams into the report view and supports follow-up questions. The honest caveat is that the quality of Phase 1 filtering determines everything downstream, and the README gives no detail on how the filter decides what counts as noise. Manual multi-select exists precisely because that filter will sometimes be wrong.

Getting it running: LLM key, CA certificate, port 8888

The README describes two installation paths. Prebuilt packages come from the Releases page: Anything-Analyzer-Setup-x.x.x.exe for Windows, arm64 and x64 dmg files for macOS, and an AppImage for Linux. From source, the sequence is git clone, cd anything-analyzer, pnpm install, then pnpm dev for development mode, pnpm test for tests, and pnpm build && npx electron-builder --win for a Windows installer. Node.js 18 or newer is required, along with pnpm and Visual Studio Build Tools on Windows. Before any analysis works you configure an LLM under Settings then LLM with an API key; OpenAI, Anthropic and any compatible API are supported through Chat Completions and the Responses API. For browser capture you create a session with a name and target URL, click Start Capture, operate the embedded browser, stop, then click Analyze. For everything else you install the CA certificate from Settings then MITM proxy, enable the proxy, and point the client at it. The README gives concrete examples: curl -x http://127.0.0.1:8888 https://api.example.com/data, a Python proxies dict with http and https keys pointing at the same address, and HTTP_PROXY and HTTPS_PROXY environment variables for Node. Phones use the Wi-Fi settings HTTP proxy field with the host machine's IP and port 8888, then download and install the CA certificate by browsing to the proxy address on the device. Certificates live in %APPDATA%/anything-analyzer/certs/ on Windows and ~/Library/Application Support/anything-analyzer/certs/ on macOS. The root CA is valid for 10 years and leaf certificates for 825 days, which the README ties to Apple's requirement. First-time certificate installation needs administrator rights on both platforms.

What the proxy deliberately does not do, and where that bites

The CA certificate section states the limits plainly: the MITM proxy is read-only capture and does not modify requests or responses, WebSocket traffic is tunnelled rather than decrypted, individual bodies are capped at 1MB, and binary content is skipped automatically. Each of those is a real boundary. If you are debugging a WebSocket protocol, this tool records the upgrade request and then stops being useful. If you are analysing a gRPC service or anything carrying protobuf or image payloads, the binary skip means the interesting bytes never reach the analysis stage. If a response body exceeds 1MB, you get a truncated view and the AI reasons over the truncated version without necessarily knowing it is truncated. There is also a structural limitation: the CA certificate has to be installed and trusted on every device you capture from, and on iOS that means navigating to the proxy address in the device browser, which is the step people most often get wrong. The project is also Electron, so the install is a desktop application with a graphical interface. Anyone hoping to run this in a headless CI container or on a remote server is looking at the wrong shape of tool.

MCP in both directions, and how it differs from proxying into Burp Suite

The MCP support runs two ways. As a client, Anything Analyzer can attach to external MCP servers over stdio or StreamableHTTP, which extends what the analysis stage can reach. As a server, it exposes its own capture and analysis capabilities as MCP tools that Claude Desktop or Cursor can call directly. That second direction is the more interesting design decision. Instead of you driving a proxy and then pasting results into a chat window, the editor or agent calls into the capture layer as a tool. Compare that to Burp Suite, which is the obvious alternative for HTTP interception. Burp's model is manual: you configure the proxy, browse, and inspect requests in an interface built around a security tester's workflow, with extensions in Java or Python through the Montoya API and BApp store. Burp does not send your traffic to a language model, and it does not inject JS hooks to catch crypto.subtle or SM4 calls. Anything Analyzer trades Burp's depth in request manipulation (repeater, intruder, scanner) for automated interpretation and agent integration. If your job is finding injection flaws through careful manual tampering, Burp is the better instrument. If your job is producing a written explanation of how an undocumented API authenticates, the pipeline here is aimed at exactly that.

Licence, release cadence and the maintenance bill

The README carries a License MIT badge and links to a LICENSE file, but the repository metadata supplied here lists the licence as unknown. Those two statements cannot both be current, and the difference matters commercially: MIT permits reuse in closed products with attribution, while an unlicensed repository grants no such permission by default. Treat the badge as unverified until you open the LICENSE file yourself. On maintenance, the release history shows a fast cadence: v3.6.59 on 5 August 2026, v3.6.60 on 7 August, then v3.6.61 tagged and referenced as v3.6.62 on 26 August, with the last push to main on 9 September 2026. That is roughly a release every few days, which in an Electron app that bundles its own Chromium means a steady stream of dependency churn to keep up with. Auto-update runs through electron-updater, and the README warns that macOS auto-update requires signed and notarised builds, with CSC_LINK, CSC_KEY_PASSWORD, APPLE_ID, APPLE_APP_SPECIFIC_PASSWORD and APPLE_TEAM_ID configured in GitHub Actions secrets, otherwise ShipIt cannot install updates. If you fork this for internal use, that notarisation setup is a cost you inherit, not one the project absorbs for you. The tool also sends captured request and response data to whichever LLM provider you configure, so the data handling question is really a question about your provider contract, not about this repository.

Editorial conclusion

Adopt it if you already have an LLM API key and your work is reverse engineering web APIs, mobile app endpoints or JS encryption flows, because the CDP plus MITM merge into one session is the part that is genuinely hard to assemble yourself. Do not adopt it if you need full-fidelity packet capture, because the README states bodies are capped at 1MB, binary content is skipped, and WebSocket traffic is tunnelled without decryption. Before installing, resolve the licence discrepancy: the README badge says MIT while the repository metadata reports no licence, and that difference determines whether you can ship it inside a commercial product.

Official sources

1. Issues
2. Mouseww/anything-analyzer on GitHub
3. README
4. Releases