@nebuloss/re-dyn-mcp

A dynamic-analysis MCP server for the GT-BE98 / Broadcom BCM6726b0 WiFi-driver reverse-engineering effort. It drives gdb-multiarch over GDB/MI against the QEMU dhd harness gdbstub, and manages the harness lifecycle (run / stop / logs).

This is the runtime/dynamic counterpart to the static stack:

Topology — this is a DIRECT MCP entry, not behind mcpproxy

re-dyn-mcp runs on dev-build (10.0.50.21), because that is where QEMU, gdb-multiarch, the kernel symbols (vmlinux.harness), and the harness scripts live. The build never leaves dev-build.

Unlike the static servers (re/utils/files/ghidra), which are aggregated behind mcpproxy on the RE container, dyn is registered directly in the client's .mcp.json as:

{ "dyn": "http://10.0.50.21:8781/mcp" }

It is not a mcpproxy upstream. Dynamic debugging is stateful and latency- sensitive (a live gdb session, breakpoints, single-stepping) — fronting it behind the proxy's retrieve_tools / call_tool indirection added latency and an approval gate for no benefit. The client talks to it straight over VLAN 50, so it binds 0.0.0.0 (not loopback).

Related MCP server: gdb-multiarch-mcp

Tools (18)

Harness lifecycle

gdb session

Typical workflow

harness_run                      # boot the dhd harness, gdbstub :1234 (GDB=1 set internally)
gdb_connect                      # attach gdb-multiarch, load vmlinux.harness symbols
gdb_break  brcmf_pcie_probe      # set a breakpoint on the probe path
gdb_continue                     # run to it
gdb_bt ; gdb_regs ; gdb_mem ...  # inspect
gdb_disconnect
harness_stop                     # tear the harness down

Config (environment)

The MCP endpoint is POST /mcp; GET /health returns {"status":"ok"}.

Build & run

npm install
npm run build        # tsc -> dist/
npm start            # node dist/server.js

Deploy (dev-build)

sudo cp systemd/re-dyn-mcp.service /etc/systemd/system/
sudo systemctl daemon-reload && sudo systemctl enable --now re-dyn-mcp
# expects the built server at /opt/re-dyn-mcp/dist/server.js

The service runs as guillaume (not root) so harness_run behaves like a manual run and doesn't litter root-owned files in the user tree. MemoryMax=512M.

Prerequisite — harness artifacts

gdb_connect can only attach once the harness actually boots. That needs two build artifacts present on dev-build:

• rootfs/initramfs-dhd.cpio.gz (initrd)

• vmlinux.harness (kernel image + symbols, path from HARNESS_VMLINUX)

Rebuild them on dev-build (via rtk) before expecting live attach to work. The server itself runs fine without them — harness_run will just fail to boot until they exist.

CI

Typecheck-only (tsc). The runtime drives gdb-multiarch against QEMU, neither of which exists on GitHub runners — the real exercise happens on dev-build.

License

MIT