YARA Rule Formatter

Rules arrive from everywhere — a blog post, a pull request, a colleague's paste — and none of them agree on indentation. This normalises the layout so a rule reads the same as the rest of your rule set, and changes nothing else.

It will not touch what the rule matches

That is the whole constraint. Identifiers, string literals, hex patterns, regular expressions, modifiers and the condition are reproduced byte for byte; only leading whitespace and runs of blank lines change. A formatter that "tidied" { 4D 5A 90 00 } or rewrote a regular expression would be editing a detection, and a detection that silently stops matching is worse than one that never existed.

Multi-line hex strings

A hex string is written in braces and long ones are usually split across lines. Those braces belong to the string, not to the rule body, so treating them as blocks would push everything after them one level too deep and then bring it back out again. They are tracked separately and their contents are left where they are.

Whitespace inside a line is left alone

Only the indentation at the start of a line is rewritten. Aligning the = across a strings section is a matter of taste that differs between rule sets, and enforcing one would produce a diff on every rule the tool ever touched. Running it twice gives the same result as running it once.

The sample is a rule with every line flush left and three blank lines in the middle of it — the state a rule usually arrives in after a copy out of a web page. Formatting it indents the sections one level and their contents two, and collapses the blank run to a single line. Comparing the two panes shows what did not change: every literal is character-identical.