deathshotxd/0xcr0sscrushWindows BYOVD research on DCRCVDrv.sys and Alinubx.sys, reverse engineering their kernel primitives, IOCTL surfaces, and detection opportunities.
Two signed drivers. One dangerous kernel primitive. 0xCr0ssCrush is a Windows BYOVD research project covering the DCRCVDrv.sys and Alinubx.sys drivers abused by the Cruciferra malware-as-a-service loader: their interfaces, their kernel primitives, their provenance, and how to detect and defend against their abuse.
A research harness and analysis package for two vulnerable signed drivers:
The repository reproduces the operators' own redundancy tactic: if one driver is refused by the host, the harness falls back to the other.
Both drivers were documented by eSentire's Threat Response Unit in August 2026 as components of the Cruciferra malware-as-a-service loader, which terminates AV/EDR processes before payload delivery. These are not hypothetical primitives - they are abused in the wild, they are signed, and neither file was present in Microsoft's enforced vulnerable-driver blocklist at the time of this research.
Controlled-lab run: driver selection, hash validation, target resolution, and the termination IOCTL path on a Windows 11 lab host. See docs/reproduction.md for the exact procedure.
0xCr0ssCrush does not claim discovery of the underlying vulnerable drivers. Its contribution is a reproducible comparative research implementation covering two recently abused signed Windows drivers, their exposed interfaces, kernel primitives, provenance, environmental behavior, and defensive detection opportunities.
No publicly indexed implementation matching both driver interfaces was identified during our research.
The independent support for the findings:
Full matrix and IOCTL surface in docs/ioctl-reference.md.
Signed driver from MOCOMSYS (DCRC) carrying WFP callout strings and a
child-process monitor. The exposed device \\.\DCRCVDRV_U accepts a
termination IOCTL from user mode. Analysis:
\\.\DCRCVDRV_U0x2205C0Details in docs/dcrcv-analysis.md.
Signed driver from CnCrypt with WFP/ALE callout strings. The exposed
device \\.\Alinubx accepts a termination IOCTL taking a PID and an
exit status.
\\.\Alinubx0x222024{ pid: DWORD, exit_status: DWORD }Details in docs/alinubx-analysis.md.
Both drivers expose the same primitive family:
primitive_family: PROCESS_CONTROL
primitive: PROCESS_TERMINATION
The machine-readable classification lives in metadata/drivers.json so additional drivers can be added without restructuring the repository.
Complete dispatch analysis (including the observed additional DCRCVDrv.sys surface) is in docs/ioctl-reference.md.
Every claim in the writeup carries an evidence label:
[CONFIRMED] directly established from code/disassembly
[CORROBORATED] observed here and independently supported
[INFERRED] likely but not fully proven
[UNRESOLVED] current evidence insufficient
Annotated disassembly excerpts (import capture, IOCTL dispatch, termination helper, strings) are included under analysis/ so the analysis can be re-walked.
Build, then never load a driver without hash validation - the harness itself enforces this:
cargo build --release --target x86_64-pc-windows-gnu
crosscrush.exe -d -n "notepad.exe" # dry run, no IOCTLs
crosscrush.exe -n "notepad.exe" -k dcrc # single driver
Step-by-step procedure and lab hygiene in docs/reproduction.md.
IOCTL-accepted and process-stopped are two distinct observations; the reproduction guide makes this explicit.
Sigma, YARA, and telemetry guidance:
detection/
|-- sigma/driver_load_win_cruciferra_byovd.yml
|-- yara/cruciferra_drivers.yar
+-- telemetry/README.md
Detection strategy in docs/detection.md.
Observed state is recorded per build in lab/test-matrix and marked as Verified / Not tested / Blocked / Unknown. Currently verified on Windows 11 24H2 (build 26100) with HVCI disabled. No blanket compatibility claims are made.
Snapshot-specific and reproducible: docs/blocklist-status.md.
Hash-specific provenance for every sample in the repository:
metadata/
|-- drivers.json # driver registry
+-- samples.json # sample registry (acquisition, verification)
Validated against the documentation by scripts/validate_metadata.py. Details in docs/driver-provenance.md.
|-- README.md / WRITEUP.md / THREAT_MODEL.md / RESEARCH_NOTES.md
|-- CHANGELOG.md / SECURITY.md / LICENSE
|-- docs/ analysis, IOCTL reference, provenance, detection
|-- src/ research harness
|-- analysis/ annotated disassembly artifacts
|-- detection/ sigma / yara / telemetry
|-- lab/ test matrix and manifests
|-- metadata/ machine-readable driver and sample registry
|-- scripts/ metadata validation
+-- .github/ CI and release workflows
This project exists for research and defense. Load these drivers only on systems you own or are authorized to test; loading them elsewhere is illegal in most jurisdictions. See SECURITY.md and THREAT_MODEL.md.