alibi is a read-only Windows forensic kit. Its value depends on three properties: the source is what the reviewer reads, the scan does not modify the system, and the detection logic is honest about what it can and cannot see. If you find a flaw in any of those, this document is how to tell us.

Reports we want to receive:

• Detection bypasses — a cheat / spoofer / DMA artifact / input adapter that the kit should flag but doesn't, with enough specificity that we can reproduce.
• Trust-claim contradictions — copy in the README, scanner/README.txt, alibi-safety-card.html, or one-page-guide.html that says the kit doesn't do X, but the source does X.
• Side effects — anything the kit modifies on the host (registry, files, services) that violates the read-only guarantee. The opt-in LOLDrivers fetch is the one disclosed network call; anything else is a bug.
• Parsing crashes — malformed input (a weird Prefetch entry, a registry value the kit doesn't expect, a non-UTF8 path) that crashes the scanner before it writes a report.
• HTML / JS issues in the visual companion — XSS via untrusted finding metadata, broken offline behavior, anything that calls out to the network.
• PowerShell / Python parity drift — a scenario where the canonical PowerShell kit and the Python parity port produce materially different verdicts on the same machine.

These are documented limitations, not bugs:

• DMA cheats at runtime. No PC-side footprint by design. The kit detects DMA development artifacts (pcileech_top.bin, FPGA build dirs, branded DMA hardware vendor names).
• A user lying about whether they ran the kit, or substituting a report from a clean machine. That requires the kit-self-integrity flow described in docs/for-reviewers.md — verify the kit's hashes against HASHES.txt before trusting any report.
• Kernel-level adversaries on the suspect machine. A rootkit can hide arbitrarily; the kit is keyword + registry + filesystem matching, not anti-rootkit telemetry.
• Sophisticated artifact wiping (Prefetch deletion, BAM key flushing, USB device-history scrubbing). The kit acknowledges this in its own coverage-limitations section; a clean result is necessary but not sufficient.

Preferred: use GitHub's private vulnerability reporting:

→ https://github.com/Sutaigne/alibi/security/advisories/new

This routes the report directly to the maintainers and gives you a private channel to share repro steps, sample artifacts, or sanitized scan output.

Acceptable also: open a public issue if and only if the report does not include active-evasion specifics (e.g. "PowerShell-encoded payload format that slips past $ScriptContent_HighRisk") that would help cheaters more than it would help defenders. When in doubt, use private reporting.

A forensic anti-cheat scanner is, byte-for-byte, hard to tell apart from the things it hunts. alibi deliberately contains:

• a plaintext database of cheat-brand, spoofer, and DMA-hardware names (keywords.py, forensic-common.ps1);
• the literal high-risk command strings it scans a suspect machine for — e.g. powershell -encodedcommand, iex (new-object net.webclient, driver-signing-bypass flags (forensic-common.ps1);
• .bat launchers that self-elevate (-Verb RunAs) and run unsigned PowerShell (-ExecutionPolicy Bypass), because a downloaded, unsigned script won't run otherwise.

Signature and heuristic engines — and especially SmartScreen reputation, which blocks new, unsigned, rarely-downloaded files regardless of content — score those exactly as they'd score the real thing. The result is a false positive at download or extract time.

The detection you're most likely to see is Trojan:Script/Wacatac.B!ml on the GitHub ZIP download. The !ml suffix means it's a cloud machine-learning verdict, not a confirmed signature — Wacatac.B!ml is a well-known generic ML false positive that fires on many legitimate scripts and tools. An offline Defender signature scan of the same files returns clean, which is the tell. This false positive has been reported to Microsoft for reclassification.

None of it is an infection, and you can prove that:

• Hashes. Every shipped file's SHA256 is in HASHES.txt. Compare what you received against it.
• VirusTotal. Upload the ZIP to virustotal.com for a ~70-engine second opinion.
• The source. Everything is plain text. The "suspicious" strings are detection signatures, sitting in readable arrays you can audit line by line.

• Browser says "Virus detected" / blocks the download. Override it in the browser's Downloads list (Edge: ⋯ → Keep → Keep anyway; Chrome: Keep), then verify against HASHES.txt.
• "Access to the compressed (zipped) folder is denied" on extract. That's the Mark of the Web, not a virus — Windows tags all internet downloads (see Microsoft's Attachment Manager note). Clear it with Unblock-File .\alibi-main.zip (or right-click the ZIP → Properties → Unblock), then extract. 7-Zip ignores the tag entirely.

• Report false positives to the vendor. A confirmed false positive should be submitted to Microsoft at the Defender Security Intelligence portal (mark "I believe this file is clean" and note it's an open-source defensive forensic tool). A reclassification there clears the verdict for everyone. If you hit a block on another vendor's engine, tell us via private reporting and we'll submit it there too.
• Keep the trigger surface minimal. We don't commit redundant ZIP archives or compiled blobs; the only thing in the repo is the readable source the tool needs to run.

• We don't obfuscate or encode the keyword database to dodge antivirus. Runtime-decoded string blobs read as more malicious to heuristics, not less — and unreadable detection logic would break the kit's whole "read every line" trust model. The signatures stay in plaintext on purpose.
• We don't Authenticode-sign (see What we don't do). Signing would raise download reputation, but it fights the same plain-source trust model. We trade that reputation cost for auditability and lean on hashes + VirusTotal + vendor submission instead.

We aim for an initial response within 7 days of the report. Substantive fixes target the next minor release (typically within 2–4 weeks). Public disclosure happens after the fix ships, with credit to the reporter unless anonymity is requested.

• We don't sign Authenticode certificates. This is a plain-source kit; binary signing fights the "read every line" trust model.
• We don't ship a binary that can't be audited. Every file in the kit is plain .ps1 / .py / .html / .css / .js / .txt — no compiled binaries, and no opaque archives. Version history lives in git, not in committed ZIPs.
• We don't run a bug bounty. This is an open community kit, not a commercial product. Credit and a CHANGELOG.md entry are what we have to offer.

Author: Bread (@Sutaigne). Contributor: Drownmw.