mdxfind documentation
mdxfind has a Windows build (x86-64, 32-bit, ARM64), but Windows treats password-recovery tools defensively. This page is about getting it running without doing anything you'll regret.
Three layers will fight you. Pick one of these and stop reading the others:
| Path | Best for | Effort |
|---|---|---|
| A. Dedicated cracking rig | Anyone with hardware whose main job is cracking | Set Windows up once with SAC off; one Defender exclusion |
| B. WSL2 with the Linux build | Mixed-use desktop, casual / occasional cracking | 5 min, no Windows defenses to fight |
| C. Native .exe on consumer Windows | Need native GPU on a daily-driver Windows machine | 15 min, ongoing maintenance, two layers to manage |
Three independent defense layers, in the order you encounter them:
Edge and the Defender SmartScreen filter check downloads against Microsoft's cloud reputation. A fresh mdxfind release nobody has downloaded yet has no reputation and gets warned about ("Windows protected your PC"). Click More info → Run anyway, or Unblock-File it from PowerShell. This one is harmless and goes away once enough people have downloaded the same file.
SAC is what actually stops the .exe from running on Windows 11. It allows a binary if either:
An unsigned, freshly-built mdxfind has neither. You'll see Event IDs 3077 / 3118 ("Smart App Control Block") in the Event Viewer under Microsoft-Windows-CodeIntegrity/Operational. The launch silently fails — no error dialog, just nothing happens, and a CodeIntegrity event in the log.
SAC is enabled by default on new Windows 11 installs in VerifiedAndReputable enforcement mode, and once it's enforced you can't turn it off without reinstalling Windows. So the time to opt out is during initial setup.
This is the layer most people don't expect. Even after a binary is signed and SAC lets it through, Defender's behavioral engine watches what it does — and what mdxfind does (mass cryptographic hashing, mask-based keyspace enumeration, hex-fingerprint lookups against a hash table) is exactly the on-disk and runtime fingerprint that Microsoft trains as Hacktool:Win32/*. There is no signature you can apply that will change this — code-signing solves SAC, not Defender. Defender will quarantine the binary mid-run, sometimes hours into a job, sometimes during the next Windows Update reboot scan.
The good news: Defender's exclusion list overrides this for any path or process you specify. The exclusion is the actual fix.
If you have a rig whose main job is cracking, this is the realistic path.
At Windows install time, during OOBE: decline Smart App Control. SAC's VerifiedAndReputable mode is one-way; you can't reverse it later without reinstalling. Pick wisely on the first boot.
Install mdxfind in a path you control, e.g., C:\Tools\mdxfind\.
Add a Defender exclusion, in an elevated PowerShell:
Add-MpPreference -ExclusionPath 'C:\Tools\mdxfind'
Add-MpPreference -ExclusionProcess 'mdxfind.exe'
Done. The path exclusion stops Defender from scanning hash files (which can themselves trigger flags depending on contents). The process exclusion stops behavioral monitoring of the running binary. No reboot needed.
This is the same approach hashcat and John the Ripper users take. mdxfind isn't doing anything different from those tools as far as Windows is concerned.
If your Windows machine is also your daily driver, the cleanest answer is to run the Linux build under WSL2. WSL2 runs Linux in a managed VM; Defender doesn't behavioral-scan inside WSL2's filesystem, and SAC doesn't apply to ELF binaries.
wsl --install -d Ubuntu-24.04
Inside the resulting Ubuntu shell:
sudo apt install libjudy-dev libssl-dev libpcre3-dev libmhash-dev librhash-dev zlib1g-dev
# Then build mdxfind from source, or fetch a Linux release tarball.
Your Windows-side hash files are visible from WSL at /mnt/c/....
GPU caveats: - NVIDIA: works fine. Install the NVIDIA WSL CUDA driver on the Windows host (one .exe from NVIDIA's site); WSL gets full CUDA access. - AMD: limited. ROCm-on-WSL is partial and not all GPUs are supported. - Intel/integrated: not supported in WSL.
If you have AMD or Intel GPUs and you need GPU dispatch, Path A or C is the better answer.
You need GPU dispatch, and you're not willing or able to dedicate the machine. Here's the path.
Releases on the GitHub project (when shipped signed) carry an Authenticode signature. Verify before trusting:
Get-AuthenticodeSignature .\mdxfind.exe | Format-List
Status should be Valid. NotSigned means it's an unsigned dev build (use Path A or B). HashMismatch means the file has been altered after signing — don't run it.
First download will trigger a SmartScreen warning. Either More info → Run anyway, or:
Unblock-File .\mdxfind.exe
This clears the Mark-of-the-Web zone identifier so SmartScreen treats the file as locally-sourced.
A signed release with reasonable distribution should pass SAC. If it doesn't, the publisher's cert hasn't built up Microsoft ISG reputation yet — you have a few options:
Signing doesn't help with Defender's behavioral classifier. You still need:
Add-MpPreference -ExclusionPath 'C:\path\to\mdxfind\directory'
Add-MpPreference -ExclusionProcess 'mdxfind.exe'
Without this, Defender will quarantine the binary the first time its behavioral scan fires on a running mdxfind process — usually within minutes-to-hours of first launch, sometimes during a routine Windows Update.
Get-MpThreat # see what was quarantined
Get-MpThreatDetection | Format-List # detail per detection
To restore from quarantine:
$mp = "$env:ProgramData\Microsoft\Windows Defender\Platform"
$exe = Get-ChildItem $mp -Recurse -Filter MpCmdRun.exe | Sort-Object LastWriteTime -Descending | Select-Object -First 1
& $exe.FullName -Restore -Name "Hacktool:Win32/<exact-name-from-Get-MpThreat>"
Then immediately add the exclusions above so it doesn't happen again.
We've seen people try to "fix" the Windows defense layers in ways that brick the machine. Each of these has bitten somebody we know:
HKLM\SYSTEM\CurrentControlSet\Control\CI\Policy:VerifiedAndReputablePolicyState). It's one-way. You will be reinstalling Windows.mdxfind.exe implicitly blocks everything else, including the per-session sshd handler. If you've reached the box over SSH, you've just locked yourself out and recovery requires console / KVM / Windows Recovery Environment access.Set-MpPreference -DisableRealtimeMonitoring $true). Modern Windows resets this on update or reboot, and Tamper Protection on Windows 11 will simply refuse the change. Use exclusions instead — they're the supported mechanism.The exclusion-based approach is reversible, supported, and what every legitimate recovery-tool operator on Windows uses.
Remove exclusions:
Remove-MpPreference -ExclusionPath 'C:\Tools\mdxfind'
Remove-MpPreference -ExclusionProcess 'mdxfind.exe'
If you imported a self-signed publisher cert (see below), remove it from both stores:
Get-ChildItem Cert:\LocalMachine\TrustedPublisher\ |
Where-Object Subject -match "mdxfind" | Remove-Item
Get-ChildItem Cert:\LocalMachine\Root\ |
Where-Object Subject -match "mdxfind" | Remove-Item
Verify the exclusions are gone:
Get-MpPreference | Select-Object ExclusionPath, ExclusionProcess
If you're cross-compiling mdxfind yourself (mingw on Linux, MSYS2 on Windows, etc.), the resulting binary is unsigned. The realistic answer is Path A or Path B for running it.
If you specifically need SAC to accept a self-built binary on a SAC-enforced machine that isn't your dedicated rig, you can sign with your own cert and import that cert as a trusted publisher on the target machine. The signature won't be trusted on anyone else's machine — it's only good on the machines where you've explicitly imported your cert.
The basics:
codeSigning, valid 5 years). OpenSSL works fine for this.osslsigncode (Linux/macOS) or signtool.exe (Windows). Include a free Authenticode timestamp (e.g. http://timestamp.sectigo.com) so the signature outlives the cert's expiry..cer (DER format)..cer into both Cert:\LocalMachine\Root (so the chain validates) and Cert:\LocalMachine\TrustedPublisher (so SAC trusts the publisher).The full cross-build + signing recipe lives in the project's build documentation; this page is about running mdxfind, not building it.
mdxfind shows up on VirusTotal with a few hits, typically classified as Hacktool, Riskware, or occasionally Coinminer. None of these are malicious behavior — mdxfind doesn't mine, doesn't phone home, doesn't escalate privileges, and doesn't touch anything on the system besides what you explicitly point it at. The classifications fire on the same on-disk pattern that triggers Defender's behavioral scan: extensive cryptographic code, hash-table lookup machinery, and mask-based candidate enumeration. That pattern overlaps with how a credential-recovery tool legitimately works.
If your environment is regulated or your security team triages VT hits, the practical answer is the same as on the running-it side: an exclusion / allowlist for the path or hash, applied through your normal endpoint management process.