Loading ToolBench
Argus-rs is an AI-first runtime memory evidence and reverse-tracing tool. It models how experienced reversers work: anchor on runtime send/recv/decrypt/dispatch evidence, resolve imports/IAT/thunks, disassemble exact runtime bytes, walk caller/callee chains, inspect strings/globals/buffers, and only then form hypotheses.
Argus-rs is a specialized reverse-engineering tool with 34 memory analysis and hypothesis-tracking tools. All tools have descriptions (10-80 chars, mostly adequate) and input schemas with typed parameters. However, schemas lack depth: most parameters are minimally described (e.g., 'Process ID', 'Address to read from'), and output schemas are not documented. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels. Naming is verb-forward and clear (mem_read, disasm_at, find_callers), but parameter descriptions often omit constraints, formats, or valid ranges. Error handling and recovery guidance are absent from descriptions. The tool set is well-composed for reverse-engineering workflows, but lacks LLM-optimization patterns like dependency hints, format specifications, and actionable error guidance.
Add evidence to support a hypothesis
Analyze a function including prologue, body, and callees
Analyze packet flow through send/recv anchors
Analyze send/network call evidence including preceding instructions and push values
Correlate an address to module and RVA context
Compare struct layouts at two different addresses
Disassemble instructions at an address
Find all functions called from an address
Output schemas not documented. LLMs cannot plan downstream tool calls or extract structured data without knowing what fields to expect. All 34 tools lack return type documentation.
Parameter descriptions lack format specifications and constraints. E.g., 'address' parameter has no format hint (hex? decimal?), 'encoding' has no enum constraint, 'max_results' has no min/max bounds. LLMs cannot validate inputs.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels. mem_write and record_hypothesis are destructive; most read tools are read-only. Agents cannot reason about side effects.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 53 | 2026-07-28+ | v2 |
Find all call sites that reference a function
Find and analyze dispatch table structures
Find and analyze virtual method tables
Locate a string in memory and find references to it
Attach to a process by name or PID
List loaded modules in a process
Read memory at a specific address
Follow a chain of pointer dereferences in memory
Write memory at a specific address
List memory regions in a process
Find processes by name pattern
List all running processes
Query recorded hypotheses
Read a structured data type from memory
Rate the likelihood of a hypothesis being real
Record a hypothesis about code or data behavior
Resolve API function targets from IAT
Find and resolve IAT thunk stubs
List exported functions from a module
List imported functions from DLLs
Scan memory for a byte pattern (AOB - Array of Bytes)
Scan for numeric values in memory
Find all pointers that reference a specific address
Scan memory for text strings
Trace a call chain up or down from a function
Verify or refute a hypothesis
No error handling or recovery guidance in descriptions. Tools like mem_read, locate, and scan_text can fail (invalid PID, no matches, access denied) but descriptions do not hint at recovery steps or error categories.
Parameter descriptions are minimal (10-30 chars). E.g., 'Process ID', 'Address to read from', 'Number of bytes to read' lack context on when to use the tool, what happens on error, or how to obtain required IDs.