WAC 2.0.2

WAC 2.0.2 — bugfix release

Fixed: wrong NT and LM hashes for every account of a SAM using the RC4 scheme

The SAM's hashed boot key is derived, in the RC4 scheme (revision 1 of the F value of SAM\Domains\Account), with a constant string holding twelve Q. WAC 2.0.0 and 2.0.1 had thirteen. The hashed boot key came out wrong, and so did the NT and LM hashes of every account. They were values of a valid look, written without any error.

The AES scheme of Windows 10 and 11 does not use that constant, and it was the only one confronted before. A SAM still using the RC4 scheme is affected: Windows 8.1 and earlier, and any machine whose SAM was not rewritten to AES.

The constant was settled on the real F value of a Windows 8.1 machine, not guessed: only twelve Q satisfy the checksum the structure carries.

Also fixed: the hash history in the RC4 scheme is decrypted with its own salts (NTPASSWORDHISTORY, LMPASSWORDHISTORY).

That checksum is now verified. A wrong boot key or constant gives no hash at all, rather than wrong ones.

The exhibit store is not affected: it holds the SAM and SYSTEM hives as collected. Converting it again with 2.0.2 (--convert=<folder>) gives the right hashes.

How it is checked

• On a Windows 8.1 machine, with this binary, three hashes are confronted with MD4 of known passwords. A test account's current hash and the previous one in its history match. So does an account created with a known password, and so does the empty-password constant.
• On Windows 11 (AES), the VM test cycle confronts the witness account's hash and history at every run.
• A new test program, sam_secrets_test, builds an F value encrypted and checksummed by an independent computation. It runs 5 checks, the first of which fails with thirteen Q.

Files

Same as 2.0.1: WAC.exe (Windows 10 and 11, x64, standalone), wac.yml, verify-exhibits.ps1|.sh, verifier-consigne.ps1|.sh, raw_hive_test.exe, SHA256SUMS.