HydraDragonAntivirus is a three-year independent open-source antivirus/EDR project for x86-64 Windows, combining YARA, ClamAV, and custom kernel components for research and authorized malware analysis experimentation.
| Tool | HydraDragonAntivirus/HydraDragonAntivirus — experimental local antivirus/EDR combining static and dynamic analysis for Windows, GPL-2.0, primary language YARA |
| Category | Open-source antivirus / EDR / malware research framework |
| Primary Use | Running a local, self-contained detection stack — YARA signatures, ClamAV rules, OpenEDR, Sanctum kernel monitoring, MBRFilter, and firewall components — in lab VMs for malware analysis experimentation |
| Safe Use | Strictly for expert malware analysts and security researchers in isolated virtual machines and clean test environments; the README explicitly states it is not production-ready and not a replacement for a daily antivirus |
| Telemetry Note | Installs low-level components — an MBRFilter boot-start driver, an ELAM driver, Sanctum kernel monitor, a local HydraDragon Firewall CA certificate for its TLS inspector, Npcap, ClamAV, and Suricata — all visible in service lists, driver stores, and certificate stores, giving defenders clear artifacts of deployment |
HydraDragonAntivirus occupies an unusual niche in the open-source security ecosystem: a full local antivirus and EDR stack, built almost entirely by one developer over three years, and published under GPL-2.0 on GitHub with roughly 243 stars. The repository's primary language is listed as YARA, which tells you immediately where the detection heart of the project lives — hand-written analyst signatures, ClamAV rules, and YARA rules maintained on the VirusKov / Multron server side. The README opens with unusually blunt self-assessment, warning that documentation is outdated and that most directories besides OpenEDR, MBRFilter, and Sanctum are deprecated for performance reasons. That candor is characteristic of the whole document, and it matters: this is a research artifact, not a product.
Architecturally, the project is a composition exercise rather than a from-scratch engine. The author assembles OpenEDR for endpoint telemetry, Sanctum for kernel-level syscall interception and monitoring, MBRFilter for boot-sector protection, ClamAV and YARA for signature scanning, Suricata and Npcap for network visibility, an Owlyshield-derived dynamic analysis component, and a custom firewall with a transparent TLS inspection proxy. What the author contributes on top is the integration glue, the signature corpus, the detection philosophy, and the kernel-side pieces. For researchers studying how an open detection stack hangs together, the composition itself is the interesting object of study.
The Sanctum component deserves particular attention because it is the most fragile piece. Its Alt Syscalls implementation and kernel monitor rely on hardcoded offsets into internal Windows kernel structures — the README cites 0x1d8, 0x7d0, 0x77, and PspServiceDescriptorGroupTable — that are strictly pinned to Windows 11 24H2 (Build 26100+). Running it on Windows 10 or Windows 11 23H2/22H2 will produce unsupported errors or outright kernel crashes. This is a textbook example of why syscall-based monitoring tools that parse unexported kernel structures break on every OS build: the offsets move, and the tool must be re-derived per build. Anyone evaluating Sanctum's approach in a lab should treat the 24H2 requirement as a hard boundary.
MBRFilter illustrates the opposite design philosophy: instead of chasing volatile internals, it sits as a SERVICE_BOOT_START (0) UpperFilter, meaning it initializes at the very start of the disk stack during boot. The stated goal is hardware-adjacent resistance against bootkits and Petya-style ransomware that tamper with the Master Boot Record before user-mode defenses load. For defenders studying bootkit tradecraft from the protective side, this is a well-known pattern — early-boot filter drivers — implemented openly, and the repository effectively documents the mechanism a defender would look for when auditing driver stacks.
The detection philosophy section is the most intellectually interesting part of the README. The author's stated rule is that near-zero false positives come first: when a detection cannot be made without false positives, the detection rate is deliberately lowered, because a clean file flagged as malware is treated as a worse failure than a missed sample. The README openly contradicts itself across updates — an earlier note about using nearly every new signature, then a pivot to preferring 90% instant detection over 99% very slow detection — which reads like an honest log of a solo developer discovering the classic precision-versus-coverage tension that commercial AV vendors spend entire teams on. As an educational artifact about detection engineering trade-offs, this section alone justifies a read.
The signature pipeline has a research-relevant twist: the analyst signatures in analyst_signatures/ — HydraDragonSig, YARA, and ClamAV rules written during manual analysis — are deliberately not published, because they churn constantly as samples are reviewed. The author will send snapshots on request, with the explicit caveat that any copy is already stale. This is operationally honest: signature corpora that lag reality give a false impression of detection capability, and the author refuses to publish a fossil. It also means anyone reproducing results from this repo is working with the public engine components, not the live analyst-curated rules.
Deployment constraints are significant and well documented. The installer expects a clean or freshly formatted x86-64 Windows machine, and the README asks users not to install if Python 3.12, Node.js, Npcap, ClamAV, Suricata, or OpenEDR components are already present, due to version and service conflicts. Cloning requires enabling long paths with git config --global core.longpaths true because OpenEDR's nested directory tree exceeds Windows' 260-character limit. Installation is not fully automated — drivers, Npcap, and firewall components may need manual approval — and if driver installation fails, the README's suggested workaround is disabling Secure Boot, which should only ever be done in a disposable VM.
Driver signing receives careful treatment. The README notes that all drivers must be signed, that WDK test signing is acceptable for general development but insufficient for ELAM drivers, and that since ELAM cannot auto-start in test-signing mode, the antivirus uses a delayed start to prevent the driver from being abused. It also explicitly warns that the Sanctum cert.ps1 / sign.bat / build.rs self-signing hash loop is a development and CI artifact process only — in production, sanctum.sys must never ship with the local self-signed sanctum.pfx and its sample password. For anyone studying secure driver development lifecycle practices, these notes are a compact case study in the gap between dev signing and legitimate production attestation.
Known limitations are refreshingly specific. Files larger than 2 GB are skipped by the scanner and must not be treated as clean. The transparent TLS Proxy/Inspector installs a local HydraDragon Firewall CA certificate when consent is enabled — a detail defenders should note, because any inspection CA is a high-value trust anchor; the firewall GUI can add and remove it, and the uninstaller removes it on a best-effort basis. On the detection side, very old malware samples may be missed due to signature retirement, and samples with a stripped PE header can evade engines that rely on PE parsing, though YARA rules that don't verify file type may still fire. The README even links VirusTotal comparisons of a header-stripped sample versus the original — a practical lesson in evasion via format ambiguity.
The project's trajectory, as narrated in the README, is moving in two directions: a mobile sibling at HydraDragonAntivirus/HydraDragonAV-Mobile intended to be the first open-source antivirus to join professional AV-Test evaluations, and a desktop-side simplification toward real-time protection built on Owlyshield + OpenEDR + Firewall, shedding heavy signature loads. A TODO item plans to replace Npcap — which the author notes is not really open source — with a custom Suricata build, and to add a HydraDragonIDE static analyzer. The default branch is development-version, the repo carries an 'active development in progress' banner, and the GitHub Pages demo is acknowledged as broken while the Multron server backend and WebSocket protocols churn.
As an evaluation target, HydraDragonAntivirus should be approached exactly as its README demands: by expert malware analysts and security researchers, in virtual machines, expecting breakage. It is not a product to install on a workstation, and it will not stop an administrator from running destructive commands like rd C: /s /q — the author is explicit that intentional administrative actions are out of scope, as are boot failures caused by manual driver or registry misconfiguration. What it offers the community is transparency: a readable, self-critical, end-to-end antivirus architecture covering signature scanning, kernel monitoring, boot protection, and network inspection, with every wart documented. For studying how detection stacks actually get built — and how their philosophies evolve under real-world pressure — few repositories are this instructive.
To explore it, clone the repository after setting core.longpaths true, and read the project Wiki for architecture diagrams and component guides before attempting any build. There is a POC video demonstrating the engine in action, and the author points to Multron Win Cleaner, a separate utility that scans using the VirusKov / Multron engine, as a lightweight way to observe HydraDragon-family detections without installing the full stack. Both are documentation-grade entry points appropriate for authorized research use in isolated lab environments only.
HydraDragonAntivirus/HydraDragonAntivirus.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.