0.2 How This Course Is Structured

Seven modules, one argument

The course is built around a single progression: you learn what to key a rule on, then how to prove it works, then what it takes to get it running somewhere real. Each module is six sections, a summary, and eight scenario questions.

What each module leaves you able to do

Module 1, The Rule as a Claim. Write a syntactically correct rule and say precisely what a match does and does not establish. Strings, hex patterns with wildcards, regular expressions, the modifiers, and condition logic including counts, offsets and the of and for quantifiers. The module's argument is that the condition is where the thinking happens: the strings section is a list of candidates, and the condition is what turns candidates into a claim.

Most people write the strings section carefully and the condition carelessly, usually as all of them, and that single habit is responsible for a large share of rules that are simultaneously too narrow and too fragile.

Module 2, Patterns That Survive. Choose patterns by what they cost the author to change rather than by how distinctive they look. This is the module that decides whether your rules are worth anything, and it is deliberately early.

Its position is a claim in itself. Plenty of YARA material treats pattern choice as something you pick up along the way and spends its length on syntax instead. Syntax is a week's work; pattern judgment is the part that separates a rule that survives from one that does not, and it needs the room. It covers the durability ordering, the extraction workflow, the patterns that look excellent and are not, and the specific trap of keying on artifacts of the build environment rather than of the program.

Module 3, Structural Detection. Use the pe module to catch what strings cannot: imports, imphash, section characteristics, entry point, the rich header, timestamps. A packed sample gives you almost no strings and a great deal of structure, so this is where you go when Module 2's techniques come back thin.

It is also where imphash lives, which is the closest thing YARA has to a family fingerprint: a hash over the imported function names rather than the file bytes, so it survives recompilation while changing when the program's actual capabilities change.

Module 4, Beyond Executables. Write rules where the file is not a binary. Office documents and their macro storage, PowerShell and its obfuscation, webshells in several languages, and ELF for the Linux estate. Each has a file format with its own structure, and each defeats a naive text rule in its own particular way.

An Office document is a ZIP container, so the macro you want to match is compressed and a text pattern will never see it. PowerShell can be encoded four different ways in a single file. A webshell may be three characters of PHP inside an otherwise legitimate page. Treating any of these as a flat sequence of bytes is the error the module exists to prevent.

Module 5, Testing and the False-Positive Economy. Build a clean corpus, measure a rule against it, and tune for cost rather than elegance. yr check, yr fmt, timing, the three causes of a slow rule, and the arithmetic of what a false-positive rate actually costs across an estate of a given size.

That arithmetic is the part usually left out. A rate that sounds negligible stops being negligible when it is multiplied by the number of files on an endpoint and then by the number of endpoints, and the module works the numbers rather than asserting a threshold.

Module 6, The Compatibility Boundary. Know what breaks between YARA-X and 4.x and write rules that survive the deployment target. The six documented incompatibilities, how to test for them, and what to do when your authoring engine and your scanning engine disagree.

The module is built on rules compiled under both engines rather than on a changelog, so what you see is the actual error each one produces and the actual construct that triggers it.

Module 7, Deployment and the Rule Estate. Run rules on forensic images, endpoint sweeps and fleet hunts, integrate with the surfaces that consume them, and maintain a rule set over time: versioning, retirement, and knowing which of your rules are quietly dead.

That last one closes the loop with Section 0.1. A rule that has stopped matching looks exactly like a rule guarding a clean estate, so the only way to tell them apart is a deliberate check, and Module 7 covers what that check looks like.

Why Module 6 exists

It is the module that would not have been in this course two years ago, and it exists because the ground moved.

In June 2025 YARA-X reached 1.0.0 and the original YARA went into maintenance mode on the same day. Not deprecated, not unsupported, but closed to new features: bug fixes and security patches only, and every new capability from that point lands in YARA-X alone. YARA 4.5.5 in October 2025 was the last release of the 4.x line, and by mid-2026 YARA-X was shipping 1.17 and 1.19.

If that were the whole story it would belong in a footnote in Module 1. What makes it a module is the second half: the switch is not clean, and most estates have not made it.

Rule-level compatibility is around ninety-nine percent rather than complete, and the differences are documented rather than mysterious. Process scanning, which matters for live memory work, is not implemented in YARA-X at all. The language bindings are incompatible, so anything embedding YARA in a tool has to be ported rather than upgraded. And the scanners a lot of organizations actually run, THOR and Velociraptor among them, embed 4.x.

The practical consequence is specific: you will author in one engine and deploy to another, and the rule that compiles cleanly on your laptop may not compile on the thing that has to run it. That is not a hypothetical. It is a Tuesday afternoon, and it is entirely avoidable if you know which constructs sit on the wrong side of the line.

There is a second reason the module earns its place, which is that the incompatibilities are not arbitrary. Each one exists because YARA 4.x accepted something it should not have, and the strictness that breaks your rule is usually catching a real mistake in it. Module 6 treats them that way rather than as obstacles.

What is not here

No capstone module. Seven modules sits under the threshold where the specification requires one, and the end-to-end case is folded into Section 7.6 instead, which is the same shape FOR201, FOR202 and FOR203 use.

No reverse engineering. Rules in this course are written from properties you can observe without disassembling anything, and where a genuinely useful pattern would require RE to find, the course says so and stops rather than pretending otherwise.

No Sigma. That is a different language for a different data source and it has its own course; Section 0.4 says where the line between them falls.

No sample acquisition either. Whether you may hold live malware is a question of jurisdiction and employer policy, and a course is the wrong place to decide that for you. The specimens in Section 0.6 are built from software you already have, which sidesteps the question for everything the course teaches.

The reference layer

Set up somewhere to work before Module 1, because every module adds to it.

mkdir -p ~/yara/{rules,specimens,clean,out}
#
# rules/      one file per family, fmt-ed before commit
# specimens/  the four from Section 0.6
# clean/      files a rule must NOT match
# out/        scan results you keep for comparison
#
tree -L 1 ~/yara

The clean directory is the one people leave empty, and it is the one that makes every later measurement possible.

After Module 7 there are six more directories, and they are not filler.

Cheatsheets are lookup pages for when you know a thing exists and cannot remember its form. Cookbooks are runbooks organized by the situation you are in rather than by technique. Walkthroughs are worked cases, several of which end with a weaker rule than the one first drafted. The playground says where to practice. The operational reference consolidates every command in the course by task, and the references module lists sources with warnings about which of them go stale.

Section 0.3 covers the environment those sections assume, which is two engines rather than one.