Links
Why AgentRE-Bench Matters
AgentRE-Bench evaluates LLM agents on long-horizon reverse-engineering tasks. The benchmark gives an agent a compiled binary and a static-analysis tool set. There is no source code and no hand-written hint. The agent has to decide which tools to call, interpret raw output, and submit a structured answer.
The benchmark is built around several design choices that shaped XREF-8B:
- Synthetic C/C++ binaries with known ground truth, so scoring is deterministic and reproducible.
- Coverage across Linux ELF x86-64 and Windows PE32+ x86-64 binaries.
- Static tool use:
file, strings, readelf, objdump, nm, hex dumps, entropy checks, and PE-aware MinGW binutils.
- Long-horizon reasoning: hard tasks require chains of 10-25 tool calls where each output should inform the next decision.
- Weighted scoring over concrete fields such as C2, protocol, encoded strings, file type, and technique set overlap.
- Hallucination penalties for fabricated techniques, which rewards calibrated answers over guessing.
XREF-8B was tuned for this style of work: evidence gathering, tool selection, taxonomy discipline, and JSON submission.
What It Was Trained To Do
XREF-8B is not a general malware generator or exploit assistant. It is a reverse-engineering assistant trained to inspect binaries and report what is present.
It is intended to help with:
- identifying file format, architecture, linkage, and stripped/symbol status
- recovering C2 indicators when present
- recognizing encoded or encrypted strings
- mapping imports and disassembly evidence to behavior
- identifying anti-debugging, anti-VM, injection, persistence, evasion, and encryption behavior
- distinguishing benign utilities, suspicious/hackware tools, and malware samples
- producing compact machine-readable JSON for downstream automation
Benchmark Coverage
The AgentRE-Bench task family spans progressively harder reverse-engineering problems across Linux ELF and Windows PE binaries. The benchmark stresses behavior families such as C2 discovery, encoded-string recovery, anti-analysis checks, covert channels, process injection, runtime code generation, PE loading behavior, direct syscall usage, persistence, encryption, and worm-like propagation in synthetic samples with known ground truth.
The PE support in XREF-8B is real, but still younger than the ELF path. It performs best when the PE spec and canonical PE taxonomy are injected into context.
Repository Contents
adapter_model.safetensors and adapter_config.json: PEFT adapter weights for Qwen/Qwen3-8B
tokenizer.json, tokenizer_config.json, and chat_template.jinja: tokenizer and chat-template assets
spec.md: top-level reverse-engineering context contract
reverse_engineering_spec.md: ELF analysis guidance and output rules
reverse_engineering_spec_pe.md: Windows PE analysis guidance, MinGW tool preferences, PE taxonomy, and output rules
example_json.md: example final JSON outputs
- : package manifest
Training-only files are intentionally excluded: optimizer state, scheduler state, RNG state, trainer state, local checkpoint metadata, and internal handoff notes are not part of this package.
Loading With PEFT
from peft import AutoPeftModelForCausalLM
from transformers import AutoTokenizer
model_id = "AgentreBench/xref-8b"
tokenizer = AutoTokenizer.from_pretrained(model_id, trust_remote_code=True)
model = AutoPeftModelForCausalLM.from_pretrained(
model_id,
device_map="auto",
torch_dtype="auto",
)
Serving With vLLM
vllm serve Qwen/Qwen3-8B \
--enable-lora \
--lora-modules xref-8b=AgentreBench/xref-8b
Use xref-8b as the model name in the client request.
Context Injection
For best results, inject the included specs before each binary-analysis task. Recommended prompt order:
spec.md
reverse_engineering_spec.md for ELF tasks, or reverse_engineering_spec_pe.md for Windows PE tasks
- The binary path and task instructions
- Static-analysis tool schemas
- A final instruction requiring exactly one valid JSON object
The model should not rely on prior chat memory. A fresh session should receive the spec, tool definitions, and current binary path.
Expected tools include format-specific static RE utilities such as:
file
strings
readelf
- GNU
objdump
- MinGW
x86_64-w64-mingw32-objdump for PE files when available
nm or x86_64-w64-mingw32-nm
hexdump / xxd
- entropy or section-inspection helpers
- a final JSON submission tool
For Windows PE tasks, the spec prefers MinGW-aware tools and canonical PE vocabulary to reduce output-contract drift.
Training Summary
- Base model:
Qwen/Qwen3-8B
- Initial supervised fine-tuning: balanced benign/malware reverse-engineering traces
- Preference tuning: IPO over the supervised fine-tuned line
- Adapter format: PEFT adapter
- Adapter rank: 16
- Adapter alpha: 32
- Adapter dropout: 0.05
- Target modules:
q_proj, k_proj, v_proj, o_proj
- Training coverage: ELF/Linux and Windows PE analysis traces
Training emphasized the same loop used by AgentRE-Bench: inspect, form hypotheses, verify with tools, avoid unsupported claims, and submit one structured answer.
AgentRE-Bench Results
XREF-8B was evaluated with the AgentRE-Bench tool-using harness. In the recorded Linux/ELF run, XREF-8B completed the benchmark and scored in the ~0.40 range (0.3805 in the archived full run), outperforming the GPT-5.5 result published on the AgentRE-Bench site (0.255) under the same benchmark family.
For Windows PE validation, XREF-8B performed substantially better after PE-specific context, canonical PE taxonomy, and MinGW-aware tooling were added. Completed standard PE tasks averaged 66.55% under the AgentRE-Bench scorer. The PE run was partial, so treat this as validation rather than a final official benchmark submission.
The stronger PE validation may suggest that current LLM reverse-engineering agents map Windows malware APIs, imports, and named injection/evasion techniques more directly than some ELF workflows, where success often depends on lower-level control-flow, data-flow, and encoded-configuration recovery. This is an early observation, not a general claim about all malware or all models.
XREF-8B is optimized for structured final answers. Generic triage output should look like this shape:
{
"file_type": "PE64",
"classification": "malicious",
"encoded_strings": true,
"decoded_c2": null,
"c2_protocol": null,
"techniques": [],
"encryption_details": {},
"decoded_strings": {},
"anti_analysis": [],
"important_functions": [],
"evidence": [],
"confidence": "medium"
}
Use JSON null, booleans, lists, and objects directly. Do not emit stringified nulls or explanatory prose outside the final JSON object when a machine-readable answer is required.
Practical Guidance
- Give the model tool access. It is strongest when it can inspect the binary rather than answer from the filename or strings alone.
- Force a single JSON final answer when using it in automation.
- Keep the evidence field. It is useful for review and for catching unsupported claims.
- For PE files, preserve the canonical technique vocabulary in
reverse_engineering_spec_pe.md.
- Prefer static analysis by default. If dynamic analysis is allowed, run it only under an explicit sandbox policy.
Safety and Scope
XREF-8B is a dual-use reverse-engineering model. Use it for defensive analysis, education, research, and authorized security work.
Do not use it to:
- deploy or operate malware
- execute unknown samples outside a safe sandbox
- generate malware or offensive payloads
- provide instructions for abuse, persistence, evasion, or unauthorized access
Known Limitations
- The model performs best with tool access and the included specs.
- It can over-trust strings if the controller does not encourage corroborating imports/disassembly.
- PE performance depends heavily on canonical taxonomy and output normalization.
- It may classify suspicious utilities as hackware when malicious intent is ambiguous.
- The PE validation run was partial; more PE-specific trace generation and evaluation are recommended.
- Results should be reviewed by a human analyst before operational decisions.
License
XREF-8B is released under Apache-2.0, matching the Qwen/Qwen3-8B base model license.