Subprojects
exav is a workspace of focused pieces rather than one binary. Several are useful even if you never run a virus scan: the extractor opens more container formats than most dedicated tools, the grep searches inside them, and the YARA engine runs without a JIT.
Each is listed below with what it is and who it is for. Architecture covers how they compose and how a scan flows through them.
Standalone tools
Section titled “Standalone tools”| Subproject | What it is |
|---|---|
| exav-unpack | Bounded, memory-safe extraction for the full supported-format list — as a Rust library, a CLI, and a WASM module that runs in a browser |
| exav-grep | grep for the inside of archives: search recursively through zip/rar/7z/tar/iso/OLE/PDF/email members |
| exav-update | Standalone signature-database fetcher, usable without the scanner |
Libraries
Section titled “Libraries”| Subproject | What it is |
|---|---|
| exav-core | The scanning engine: database parsing, pattern/hash matching, file typing, and the verdict model |
| exav-pe-emu | A sandboxed x86-32 emulator that unpacks packed Windows executables by running their stub |
| exav-x86 | A decode-only x86-32 instruction decoder with no dependencies, checked against an independent decoder over 94 million real decode sites |
Why they are separate
Section titled “Why they are separate”- Blast radius. Extraction is the part that touches hostile bytes first and
hardest. Keeping it in its own
#![forbid(unsafe_code)]crate with its own budget and panic containment means a malformed archive cannot reach the engine, let alone the host. - You can take one piece. A build system that needs to look inside archives does not need a virus scanner, and a browser tool that unpacks uploads should not ship a signature database. Both are one crate, not a fork.
- Compile only what you use. Every format is a Cargo feature, so a ZIP-only extractor is a real build target rather than a wish.