0.6 What the Seven Modules Build

You have the tool installed, specimens to work on, a corpus to test against, and a clear position on what a result from a scan is worth. This section sets out what the seven modules do with that, and it is worth reading rather than skipping, because the order the course takes is a claim about how the skill is actually acquired and it is not the order most YARA material uses.

Why syntax comes first and stops early

Module 1 covers the language: strings, hex patterns, regular expressions, modifiers, conditions and metadata. It is one module out of seven, and that ratio is deliberate.

The syntax is genuinely small. A week of practice gets you fluent in it, and fluency feels like competence because every rule you write compiles and matches its sample. The trap is that nothing in the syntax tells you whether a rule is any good, and the feedback that would tell you does not arrive until the rule has been deployed for months and quietly stopped working.

The feedback delay is the mechanism worth understanding, because it explains why this skill does not accumulate on its own. In most technical work you learn from consequences: the code fails, the query returns nonsense, the build breaks, and you adjust. A badly chosen pattern produces none of that. The rule compiles, deploys, and returns nothing, which is indistinguishable from success, so there is nothing to learn from and the habit that produced it survives intact. Deliberate measurement against a corpus is the substitute for feedback that never arrives, which is why it appears in every module rather than only in Module 6.

So Module 1 teaches the language and, more importantly, teaches you to run yr check and yr fmt as part of writing rather than afterwards. The linter catches a class of problem the syntax cannot express, and meeting it while typing rather than during a fleet hunt is most of its value.

There is a boundary to what the linter can do for you and it is worth knowing before you lean on it. It reports whether a pattern will make a scan slow. It has no opinion at all about whether a pattern will make a scan useful, which is Module 3's territory, so a rule can pass yr check cleanly and still be one of the forty in the scenario above.

The two modules that decide whether a rule is worth anything

Module 2 is running scans properly and Module 3 is choosing what to match, and between them they are the course core.

Module 2 takes yr scan seriously: targets and scan lists, output formats, counts and negation, timeouts, threads and size bounds, and reading results at a scale where you cannot read every line. Much of it is about what a scan does not tell you, which Section 0.1 introduced and which recurs constantly once you are working across an estate rather than a directory.

Giving scanning its own module is a departure from how YARA is usually taught, where running the tool is assumed to be obvious and the material is all language. It is not obvious. The options that matter at scale are the ones nobody mentions, the failure modes are silent, and the difference between a hunt that answers a question and a hunt that produces a second triage problem is mostly in how the scan was scoped rather than in how the rule was written.

Module 3 is pattern selection, and it is the module that separates a rule set worth maintaining from forty rules nobody trusts. The question it teaches is not which pattern looks most distinctive but what it would cost the author to change it, and the answer reorders your instincts substantially. Section 0.2's family already showed you the shape of it: two correct rules, completely different coverage, nothing in the rule text predicting which.

Its position in the course is itself an argument. Plenty of YARA material treats pattern choice as something you pick up along the way and spends its length on syntax instead. Pattern judgment is the part that takes real practice and the part that is invisible in a rule's text, so it gets a module of its own and it comes before the modules that extend reach, because reaching further with the wrong patterns is not progress.

Where the tool does the work for you

Module 4 is the modules that parse a file's structure, and it starts somewhere people do not expect. Before any rule, yr dump prints everything a module extracted from a file, with constants resolved and flags decoded, which turns the pe module from a reference you look things up in into something you can read directly.

That matters most on files that resist the techniques from Modules 2 and 3. A packed sample gives you almost no strings and a great deal of structure, because the loader has to be able to parse the headers whatever happened to the payload.

Module 5 handles files where "the binary" is the wrong mental model entirely: documents that are archives, scripts carrying encoded commands, webshells that are forty characters inside a legitimate page. Each defeats a naive rule in its own particular way, and the ways are properties of the formats rather than anybody's cleverness.

That last clause changes how you prepare for it. Obfuscation varies with an adversary's skill and effort, so you cannot plan for it in general. A container format applies uniformly to every file of that type, including every benign one, so you learn it once and it holds. Most of what makes documents and scripts hard is the second kind, which means it is learnable rather than a permanent arms race.

Proving it and shipping it

Module 6 is testing, tuning and performance, and it is where the corpus from Section 0.3 does its work. Measuring a rule against a population, reading the linter's performance warnings properly, finding which rule in a set dominates a scan, and the arithmetic of what a false-positive rate actually costs across an estate of a given size.

Module 7 is deployment: compiled rules, images, endpoints and fleets, the platforms that consume rules, and maintaining a set over time so you can answer which of your rules still work. It also carries the compatibility material, which is not a footnote. YARA-X reached 1.0.0 in June 2025 and the original engine went into maintenance the same day, but the scanners most organizations run still embed 4.x, so you author on one engine and deploy to another and the differences between them decide whether a rule survives the trip.

Maintenance gets more attention in that module than deployment does, and the ratio is deliberate. Getting a rule running somewhere is a one-off task with a clear finish; keeping forty rules honest over two years is continuous, and it is the part that decides whether the set is an asset or a liability. Rules expire silently, as this module has said several times, so a set with no maintenance practice degrades into a repository of confident-looking files nobody trusts.

What is deliberately not here

Reverse engineering. Rules in this course are written from properties you can observe without disassembling anything. Where the only good pattern would require reading disassembly to find, the course says so and stops, rather than pretending a shortcut exists.

That boundary is drawn deliberately rather than apologetically. Reverse engineering is a separate discipline with its own long training, and a YARA course that gestured at it would teach neither well. What this course does instead is name the moments where you have reached the edge of what static properties can give you, so you know you are handing off rather than failing.

Sample acquisition. Section 0.2 covered the position: possession is a question of jurisdiction and employer policy, the specimens are built rather than downloaded, and the course does not recommend a source.

What the course does cover is what to do once a sample is legitimately in front of you, which is the situation most practitioners are actually in: it arrived from a quarantine, a collection, or a colleague, and the question is what to do next rather than where to get one.

Sigma and log-based detection. YARA describes files; Sigma describes log events. They are complementary rather than competing, and most real coverage uses both, but they are different disciplines and this course is one of them.

The division is cleaner than it first appears and worth holding onto, because it tells you which tool a question belongs to. A file sitting in a temp directory is a YARA question. The same file's hash appearing in process-creation telemetry is a Sigma question. If you find yourself trying to express activity in a YARA rule, or trying to describe file contents in a Sigma rule, the question has been given to the wrong tool.

How to work through it

The modules build, so the order matters more than in a reference. Two habits will make the difference.

Run everything. Every command in this course was executed and its output pasted rather than composed, and the material is written so you can reproduce each result on the specimens you built. A section you read is worth considerably less than a section you ran, particularly where the point is a tool behavior that surprises you.

That is not a general exhortation about learning by doing; it is specific to this tool. A large share of what this course teaches is behavior you would not predict from the documentation: that a bad path exits zero, that a modifier can silently stop a rule matching anything, that the linter has opinions about your logic. Reading those is information. Running them and being surprised is what makes them stick, and the surprise is not available second-hand.

Keep what you build. The specimens, the corpus, the rules and the scan results accumulate into a working environment, and several later modules ask you to compare a result against one you took earlier. Starting Module 6 with no record of what your rules scored in Module 3 means measuring everything twice.

The scan results are the part people discard and the part worth most. A false-positive count is uninteresting on its own and highly interesting compared to the same rule's count last week, or to the previous version of the rule. Saving the output alongside the rule turns Module 6's tuning from a fresh measurement each time into a comparison, which is both faster and considerably more informative.

Course guide: confirm you are ready for Module 1

Step 1, confirm the tool runs. yr --version reports 1.x, and python3 -c "import yara" reports 4.5.x.

Step 2, confirm the specimens exist. Three family builds with three different hashes, and the packed pair if you built it.

Step 3, confirm the corpus exists and holds at least several hundred files.

Step 4, run one rule end to end. Check it, scan the family with it, scan the corpus with it, and run the negation.

Step 5, write down which surface your rules are for, from Section 0.4. Every decision in Modules 3, 6 and 7 depends on that answer, and deciding it now costs nothing.

Module 1 begins with the language itself, and with the two commands that turn writing a rule from a guess into a checked operation.