Cracked-hash import rejects hashcat $HEX[...] plaintexts

Summary

POST /v1/hashes/import/<type> rejects legitimate hashcat output when the recovered plaintext is wrapped in hashcat's $HEX[...] encoding.

Details

hashcat emits $HEX[...] for any recovered password containing bytes that are ambiguous in the plain outfile — leading/trailing whitespace, delimiters, or non-UTF-8 bytes. The crack-import verifiers (hashview/utils/utils.py, e.g. _verify_ntlm) hash the submitted plaintext literally, so they compute the digest of the string "$HEX[2057...]" instead of the bytes it encodes. The digest never matches, and because the import is atomic, a single such line rolls back the whole batch with:

Plaintext for hash <hash>, was found to be invalid.

Reproduction

Import an NTLM (1000) crack whose password has a trailing space, e.g. a hash whose real plaintext is "%032023RC$ "; hashcat writes it as <hash>:$HEX[2530333230323352432420]. The import fails with the error above even though the plaintext is correct.

Expected

The verifiers should decode $HEX[...] to the raw candidate bytes and hash those, per hash family (raw bytes for MD5/SHA*/MD4-900/MySQL; zero-extended → UTF-16LE for the NTLM/MSSQL2012 families), matching hashcat exactly.

Fix

PR incoming against v0.8.3-dev.

Start in hashview/utils/utils.py with the crack-import verifiers, including _verify_ntlm, and trace the POST /v1/hashes/import/ path. Reproduce the NTLM case using the supplied $HEX[...] plaintext, then check each listed hash family against hashcat's byte and UTF-16LE rules. Done means encoded plaintexts import successfully without breaking ordinary plaintext validation or atomic batch behavior.