Detection engineering without live malware

Generate benign files that match YARA rules.

Aray parses supported detection logic deterministically, uses LLM assistance only when needed, and constructs inspectable Linux ELF, Windows PE, and format-specific artifacts with conventional engineering backends.

Black Hat USA 2026 Selected for Arsenal

Get started Explore the architecture

416

Selected public source entries

97.6%

Positive-fixture yield in full-compile mode

406

YARA matches in the current baseline

3

Artifact families: ELF, PE, generic

Why Aray

Testing security controls with live malware creates avoidable risk, operational overhead, and handling requirements. Aray generates non-malicious artifacts that satisfy static YARA conditions without reproducing the malicious behavior of the samples those rules describe.

Use the artifacts to exercise:

• scanner and alert pipelines;
• incident-response and recovery automation;
• detection-rule validation;
• controlled false-positive and alert-volume experiments;
• research into YARA normalization and autonomous cyber defense.

Research prototype

Aray implements a useful subset of YARA and uses probabilistic models for rule interpretation. Always verify generated output with YARA and use it only in authorized testing environments.

A Narrow Trust Boundary

Aray interprets

Complex rules may be normalized and judged by an LLM. Deterministic canonicalization restores retained fixed values, constructibility preflight rejects known terminal constraints, and supported strings, modifiers, placements, counts, and endian-aware integer checks are extracted directly into Pydantic models. Extraction uses a model only for syntax outside that subset.

Conventional code constructs

Python, assemblers, linkers, and direct binary writers own byte encoding, offset placement, header construction, constant patching, and filesize constraints.

YARA verifies

The batch evaluator invokes the real YARA CLI. A valid model response or a successful build does not count as success unless the resulting artifact matches.

read + select rule -> optional LLM normalize/judge
                  -> deterministic constructibility preflight
                  -> deterministic fixed-evidence extraction
                  -> PE / ELF / generic construction
                  -> YARA verification

Read the architecture details

Quick Start

The shortest path uses scan-only mode. It writes a minimal scanner artifact directly, without GCC or MinGW.

$ git clone https://github.com/c2dc/aray.git
$ cd aray
$ uv sync
$ cp .env_example .env
$ uv run aray data/rules/rule0.yar --scan-only
$ yara data/rules/rule0.yar build/linux/app
rule0 build/linux/app

Requirements are Linux, Python 3.12+, uv, and the YARA CLI. Rules that require normalization or extraction fallback also need access to an OpenAI-compatible model; Aray supports fully local model execution through Ollama.

Configure models and providers Browse focused examples

Deterministic Backends

Target	Construction strategy	Output
Linux ELF	GNU assembler sections and a linker script, or a direct minimal ELF64 writer	build/linux/app
Windows PE	MinGW with offset-aware two-pass placement, or a direct minimal PE64 writer	build/windows/app.exe
Generic	Direct byte-blob writer preserving format magic at offset zero	build/generic/output{ext}

Generated sources and normalized rules remain available in the build directory for inspection. The model never emits C, assembly, linker scripts, PE headers, or complete binary data.

Published Evaluation

Aray was evaluated end to end in two stages over 416 selected source entries from the Yara-Rules community repository. The first stage used Aray's own normalization workflow; the second froze those accepted outputs before deterministic realization and YARA scanning.

Aray stage	Result	Model-dependent path
Normalization	416 / 416 accepted	234 normalized; 182 pass-through
Full-compile-mode realization, 1 worker	406 / 416 matches (97.6%), 10 preflight dispositions	0

Every frozen input bypassed normalization in the second stage because Aray had already performed it in the first. The 406 constructible entries used deterministic string and constant extraction, while seven unsupported pe.* rules, two infeasible whole-file hash preimages, and one unsatisfiable integer value stopped at capability preflight before extraction. There were zero unexplained mismatches and zero construction failures, giving 406/406 conditional realization.

The extraction role was configured in separate realization-stage controls as GLM-5.2, Qwen 3.5, Phi-4, and GPT-4.1, but none of those models was invoked. End-to-end acceptance is an identifier-restricted YARA match against each associated upstream original rule. The result measures workflow completion, not provider quality or universal implication between predicates.

Review the methodology and collection breakdown Download the validation summary

Research Team

Aray is a project of Lab-C2DC - Laboratory of Command and Control and Cyber-security at the Aeronautics Institute of Technology (ITA). It is part of a research collaboration among ITA, the University of Sao Paulo (USP), iFood, and Texas A&M University (TAMU).

View the source on GitHub