Skip to content

Back to the catalog

blog.deeb.charticle

Avred background: Advances in Reversing Defender Signature Format

A blog post building on retooling.io's reverse engineering of Microsoft Defender's WdFilter.sys signature format, explaining how signatures use weighted sub-rules with a score threshold (dominant vs non-dominant matches) and five wildcard opcode types (90 01–90 05) for byte-sequence, placeholder, and regex-like matching, translating each into equivalent YARA rule syntax. It ties these findings back to why certain Avred signature-breaker techniques (like NOP/register wildcarding) fail to evade detection, giving practical insight into how Defender signatures are structured and matched.

TL;DR Explains Windows Defender's weighted sub-rule signature format and wildcard opcodes (translated to YARA), and why it affects Avred's signature-breaking results.
Open original ↗
Document

What it is

A background note by the author of Avred explaining Microsoft Defender's signature format, building on retooling.io's 2024-06-28 post "An unexpected journey into Microsoft Defender's signature World." The relevant component is WdFilter.sys, the kernel-space minifilter driver that scans files. The value beyond the summary is the concrete arithmetic of the scoring model and the exact semantics of each wildcard opcode.

How it works

Signatures are composed of several sub-rules, each carrying matched bytes and a weight. The signature fires when the accumulated weight of matched sub-rules exceeds a threshold. Worked example from the page: threshold 10, eight sub-rules of weight 4 each → any 3 of 8 matching triggers detection. This is the mechanism behind Avred's non-dominant matches. A dominant match is a single sub-rule whose weight alone equals or exceeds the threshold.

Signatures are byte-exact but support wildcards via 90 opcodes, translated here into YARA equivalents:

  • 90 01 XX — match a byte sequence of length XX (single-byte wildcards, e.g. ?? FF FF FF).
  • 90 02 XX — match up to XX bytes at a position (e.g. [0-16]).
  • 90 03 XX YY — two alternative byte sequences of lengths XX/YY; either may match (YARA alternation (43 49 50 41|56 49 50 41)).
  • 90 04 XX YY — regex-like pattern; XX = exact number of bytes to find, YY = pattern length (e.g. [30-39] [30-39]).
  • 90 05 XX YY — same as 90 04 but XX is an upper bound on byte count, and case-insensitive (e.g. "http://[a-zA-Z]{0,64}\\.com/dfrg32\\.exe").

What to do

If you use Avred (or write signature-breaking payloads generally), account for wildcarding: NOP insertion or register substitution in ASM instructions will not break a well-written rule if those bytes fall under a 90-opcode wildcard. The author explicitly attributes his own signature-breaker techniques' poor results to this. Two practical implications:

  • Breaking a signature may require defeating enough weighted sub-rules to drop the score below threshold, not just any one match — target the highest-weight or dominant sub-rules.
  • Byte mutations only help where the rule expects exact bytes, not within wildcarded regions.

Caveats

This is a background/analysis post, not a tool release or advisory — no versions, patches, or reproductions are provided. The opcode semantics and YARA translations are derived from retooling.io's research, not independently formalized here, and the wildcard type list may not be exhaustive.

Technologies named here

Techniques named here

  • Defender sub-rule scoring / weighted signature matching
  • Signature wildcard matching
  • Signature-breaker technique attempts

Related in Malware & RE