YARA syntax: anatomy of a rule

A YARA rule is a small, declarative program. Once you know its five building blocks — the header, meta, strings, condition and imports — you can read almost any public rule. This guide covers each of them with a complete example you can paste into the online editor.

The rule header

Every rule starts with the rule keyword and an identifier:

rule MAL_Example_Stealer : windows stealer
{
    condition:
        false
}

• Identifier. Letters, digits and underscores, not starting with a digit, at most 128 characters, and not a keyword (rule, and, them, filesize…). Identifiers are case-sensitive. Public rule sets usually follow a PREFIX_Family_Detail convention described in the style guide.
• Tags. Optional words after a colon. They do not affect matching; scanners use them to filter or label results (yr scan can print them).
• Body. Everything between braces.

The meta section

meta stores documentation as key/value pairs. Values can be strings, integers or booleans. Keys may repeat — many rules list several hash entries.

rule Meta_Example
{
    meta:
        description = "Shows the three meta value types"
        author = "yararules.org"
        date = "2026-09-29"
        score = 70
        experimental = true
    condition:
        true
}

Meta values cannot be used in the condition, but they travel with every match: scanners print them, and the Detection Rule License asks that the author field stays visible when you report matches.

The strings section

Patterns are declared as $identifier = value, optionally followed by modifiers. There are three kinds: text strings in double quotes, hexadecimal strings in braces, and regular expressions between slashes.

rule Strings_Example
{
    strings:
        $text = "cmd.exe /c" ascii wide nocase
        $hex = { 4D 5A 90 00 ?? 00 00 00 }
        $re = /https?:\/\/[a-z0-9.\-]{4,64}\/gate\.php/
    condition:
        any of them
}

Identifiers may be reused as prefixes to build sets ($x1, $x2 → $x*). A bare $ declares an anonymous string, useful in large lists. The strings guide covers escapes and modifiers; every declared string must be used by the condition, directly or through a set such as them — otherwise YARA reports an error.

The condition section

The condition is a boolean expression. It can reference patterns ($a), counts (#a), offsets (@a[1]), file properties (filesize), integers read from the data (uint16(0)), module fields (pe.number_of_sections) and other rules. The conditions guide goes through each operator.

Imports and modules

Modules extend the condition language with parsed file formats and helper functions. They must be imported at the top of the file:

import "pe"

rule PE_Small_Dll
{
    condition:
        pe.is_pe and pe.is_dll() and filesize < 200KB
}

The browser build of YARA-X used on this site supports pe, elf, macho, dotnet, lnk, math, hash, time, console, string, dex, crx, cuckoo and vt. See the modules guide.

Comments

YARA accepts // line comments and /* … */ block comments anywhere whitespace is allowed. Use them for the reasoning behind a tricky condition; use meta for anything a scanner should report.

Private and global rules

Two modifiers change how a rule behaves:

• private rule — the rule is evaluated and can be referenced by other rules, but it is never reported as a match on its own. Useful for shared building blocks such as "is a small PE file".
• global rule — the rule acts as a filter: if it is false, no other rule in the same namespace can match. Use it sparingly; it silently hides every other rule.

private rule Is_Small_PE
{
    condition:
        uint16(0) == 0x5A4D and filesize < 3MB
}

rule MAL_Example_Uses_Helper
{
    strings:
        $a = "EvilConfigMarker" ascii
    condition:
        Is_Small_PE and $a
}

A rule can reference another rule only if that rule is declared before it.

Namespaces and includes

When several files are compiled together, each can live in its own namespace so that two packs may reuse a rule name. The include "other.yar" directive pulls another file in at compile time; support depends on the front-end (the command-line tools resolve relative paths, the browser tools on this site compile each file separately instead).

External variables

Rules can read values supplied at scan time instead of hard-coding them. The variable is defined when rules are compiled or scanned (for example yara -d env=prod rules.yar target with YARA 4, or --define with the YARA-X command line) and used like any identifier in the condition. This lets one rule file behave differently per environment without editing it.

Common syntax errors

YARA-X reports errors with a code, a message and the exact line and column. The most frequent ones are an undeclared string in the condition, a declared but unused string, a missing condition: section, and an invalid escape sequence.

rule Broken_Example
{
    strings:
        $a = "one"
        $b = "two"
    condition:
        $a and $c    // does not compile: $c is not declared, $b is unused
}

Paste this rule into the editor to see YARA-X point at $c. For style and performance issues that are not errors, run the linter.

Putting it together

A rule is a header, optional documentation, optional patterns and a mandatory condition — in that order. Next, learn how to choose patterns that are both specific and fast in YARA strings, then keep the cheat sheet at hand.