YARA-X Rule Workbench

## Write a rule and test it against the actual sample The slow part of writing YARA rules is not the syntax, it is the loop: edit, compile, scan, look at what matched, adjust. The workbench runs that loop locally with YARA-X, the Rust rewrite of the YARA engine, compiled to WebAssembly and served from this site. Your rules and your samples both stay in the browser. ## The editing loop Type a rule and it compiles as you go. Errors and warnings point at the line and the construct that caused them, so a bad hex wildcard or an unreferenced string surfaces before you scan anything. Rule metadata is parsed and shown alongside, which matters when you are writing a family of rules that share tags and author fields. Scanning runs against whichever artifact is open in the Binary Lab session, or a file you drop in directly. Every match reports the rule that fired, the string identifier, the exact byte offset, and the matched bytes. Click an offset to open it in the Hex Editor at that position, which is how you confirm that a match landed where you meant it to and not inside a resource blob or a certificate. ## Generating a starting point Writing the first draft from a blank editor is tedious. The workbench generates starter rules two ways: from strings the String Extractor pulled out of the current sample, and from a byte range you select in the Hex Editor. Both produce a compilable rule with the strings already escaped correctly, which you then tighten by hand. Generated rules are a starting point and never a finished detection. They will overfit to one sample. The work is deciding which strings are structural to the family and which are incidental to the build you happen to have. ## Writing rules that survive contact with real data A few habits separate rules that hold up from rules that page someone at 3am: - **Anchor on structure, not on strings alone.** A PE check plus two strings beats five strings. - **Avoid strings a compiler chose for you.** Build paths, timestamps and RTTI names change between builds of the same family. - **Prefer hex patterns with wildcards over exact byte runs** when you are matching code, so a recompile does not break the rule. - **Use a condition that counts.** `3 of ($s*)` tolerates variation in a way that `all of them` does not. - **Test against goodware.** A rule you have only tested against one malicious sample has an unmeasured false positive rate, and that is the number that determines whether anyone keeps your rule enabled. The workbench helps with the first four. The fifth needs a corpus, and that is the honest limit of a browser tool. ## Reading a match that fired somewhere unhelpful The most common surprise is a rule that matches, but not where you intended. A string that looks distinctive frequently lives inside a resource section, an embedded certificate, a compressed blob, or the copy of the sample sitting in an overlay. The rule fired honestly; the string was simply present somewhere you were not thinking about. Offsets are what settle this. Jump to the match in the Hex Editor, then check that offset against the section table from the Executable & Object Inspector. If the match landed inside a resource directory or past the last section, the string is not where your rule assumed, and the condition needs an anchor rather than another string. The reverse case is worth checking too. A rule that fails on a sample you are certain it should catch usually means the strings are encoded, compressed or built at runtime. The Entropy Analyzer will say whether the region is packed, and the Shellcode Emulator will show a decode loop producing the plaintext you were trying to match. Rules written against decoded output belong on the decoded artifact, not the packed one. ## Limits and safety File size, rule size and scan time all have hard ceilings, and the engine has a timeout so a pathological regex cannot lock the tab. Scanning is pure pattern matching against bytes at rest, so nothing in the sample executes. No third-party rule feed ships with this release, which means everything you compile here is code you wrote or pasted deliberately. ## Getting rules out Rules are plain text, so copy them into your repository, your detection pipeline, or whatever the rest of your stack expects. Matches attach to the Binary Lab session as findings with their offsets, so the evidence report shows which rule fired on which bytes of which hash. That is usually the artifact a reviewer actually wants, rather than a screenshot of the editor.