Argus MCP server

Argus

English · 繁體中文 · 简体中文 · 日本語 · 한국어

An MCP server that gives AI agents evidence from a running process.

Every reverse-engineering MCP server so far bridges a static analyzer — Ghidra, IDA, apktool. They hand your agent the file on disk. None of them can tell the agent what the program is actually doing right now: what got decrypted into that buffer, which address the vtable slot resolved to at runtime, which call site sent that packet.

Argus is the other half. It attaches to a live Windows process and returns runtime evidence: real bytes at real addresses, disassembly of the code that actually executed, resolved IAT thunks, caller chains walked from live memory, and a hypothesis ledger that tracks what has been proven versus what is still a guess.

It does not draw conclusions for the model. It returns addresses, module/RVA context, instructions, callers, callees, and local evidence, then gets out of the way.

Why this exists

Games die. The publisher shuts the servers down, the studio folds, the genre moves on. What survives is a client sitting on somebody's hard drive that can no longer connect to anything — no source, no protocol documentation, no server left to talk to. Just an executable that still remembers how to speak a language nobody is listening to anymore.

Argus was built to bring those back.

Reconstructing a server for a dead game means recovering its protocol: packet layouts, encryption, opcode dispatch, the state machine on the other side of the wire. The only surviving specification is the client binary itself. Nobody wrote the document you need, and the people who knew have long since moved on.

Static analysis gets you partway. But a twenty-year-old client is packed, its strings are encrypted, its handlers dispatch through tables that only exist once the process is up. So you run it, and you watch it work — which is where the next section comes in.

That is what this tool is for: not breaking into something alive, but getting something dead to speak again.

Why go to the running process at all

A CPU cannot execute ciphertext.

Whatever a program does to protect itself on disk — packing, string encryption, virtualized instructions, imports resolved at load time — all of it has to be undone before the processor can run the code. At the instant of execution, the real instructions and the real data are sitting in memory in the clear. They have to be. That is not a flaw in any particular protector; it is a consequence of how processors work, and no amount of obfuscation gets around it.

So the two approaches are reading different things:

• Static analysis reads the file. What the author shipped.
• Runtime analysis reads what the file turned into. What the machine is actually running.

When those two differ, the second one is the truth.

Where static analysis wins

The trade runs the other way too, and it is worth being blunt about it: a static analyzer sees every path, including the ones that never execute. Argus only sees what actually ran. A branch that was never taken leaves no runtime evidence at all, and a function nobody called may as well not exist.

Shortened. The full README is on GitHub.