YARA-X vs YARA: differences and migration

YARA-X is the successor of YARA, rewritten in Rust by VirusTotal. It reads the same rule language, so switching is usually painless, but it is deliberately stricter in places where YARA 4.x was lenient. This guide summarises what changes and how to migrate a rule set.

History and status

YARA was created at VirusTotal and became the standard language for describing malware files. After more than a decade of C code, VirusTotal started YARA-X as a new implementation with three goals: better error reporting, better performance on complex rule sets, and a safer codebase. YARA-X is used in production at VirusTotal (Livehunt and Retrohunt), and YARA 4.x now mainly receives maintenance.

Compatibility

The rule language is the same: meta, strings, condition, text/hex/regex patterns, modifiers, quantifiers, loops and the common modules. Across the thousands of rules in this library, the vast majority compile with YARA-X 1.20 without any change — each rule page shows its status, and the scanner packs only include rules that compile.

Notable differences

• Stricter parsing. Invalid escape sequences in strings and regexes, invalid or duplicated modifiers, and some ambiguous constructs are errors instead of being silently accepted.
• Clearer errors. Every diagnostic has a code, a message and the exact line and column, with the offending source excerpt. The online editor shows them as you type.
• Unknown module fields are errors. Misspelled pe. fields fail at compile time instead of evaluating to undefined at scan time.
• base64 modifier. The pattern must be at least three bytes long.
• Performance. Better behaviour with complex regular expressions and large rule sets; compile-time warnings about patterns likely to be slow.
• New syntax. The with statement defines local variables inside a condition (see conditions). Rules that use it do not compile with YARA 4.
• Modules. Most module names and fields are shared; some were reorganised, new ones were added (for example lnk, dex, crx), and magic is missing from builds without libmagic, such as the WebAssembly build.
• Includes and deprecated features. include handling depends on the front-end, and a few long-deprecated features were dropped.

Command-line comparison

Migration checklist

1. Run yr check on the whole rule set and fix errors file by file. The error codes are stable, so you can grep for them.
2. Fix invalid escapes: in text strings only \" \\ \t \n \r \xNN are valid; in regexes, escape / and avoid escaping ordinary letters.
3. Remove conflicting modifiers (for example nocase with xor, or base64 with fullword).
4. Replace deprecated identifiers such as entrypoint with pe.entry_point or elf.entry_point.
5. Re-check module field names with yr dump -m <module> sample.
6. Re-run your positive samples and goodware corpus (see testing and CI) — matches should be identical.
7. Review new compile-time performance warnings; the performance guide explains most of them.

A rule that needs to compile with both engines should avoid with and other YARA-X-only syntax.

A rule that shows the stricter parsing

rule Escape_Example
{
    strings:
        $ok = "C:\\Windows\\Temp\\"
        $bad = "C:\Windows\Temp"   // does not compile: \W and \T are not valid escapes
    condition:
        any of them
}

YARA-X rejects $bad and points at the exact column; the fix is to double each backslash, as in $ok.

YARA-X in the browser

YARA-X compiles to WebAssembly. The tools on this site use the official @virustotal/yara-x build (version 1.20.0, BSD-3-Clause), loaded from this site and run in a Web Worker:

• The scanner scans files and ZIP archives with library packs or your own rules.
• The editor compiles as you type and tests against a dropped sample.
• The linter adds performance heuristics to YARA-X diagnostics.

Nothing is uploaded: files are read with the browser File API and scanned in memory. See the official YARA-X documentation for the complete language reference.