03-29-2016, 08:09 AM
(03-28-2016, 08:45 PM)bigblacknose Wrote: According to the technical team at Passware, hashcat checks the ASCII string "TRUE" field during the decryption process. Passware and TC itself checks the CRC-32 checksum. In this case it seems like they differ.
I assume, Passware checks both, the magic bytes "TRUE" and the crc-32 checksum.
IIRC, hashcat checks some other fields, too. So a false positive is not too likely.
(03-28-2016, 08:45 PM)bigblacknose Wrote: I'll be happy to share the hash/password or some MB from the beginning of the disk with someone involved in development.
Send me the first 32256 bytes of the disk (63 sectors) together with the password and i will try to check what's going on here.
Additionally, tell me the keyboard layout of the computer used.
(03-28-2016, 08:45 PM)bigblacknose Wrote: What are the odds of getting the ASCII string "TRUE" with a password/key that also makes sense?
The odds for TRUE or the correct crc-32 checksum is 1:2^32 (i.e. one false positive in about 4 billion tries).
Most of the time the false positives do not fit a simple password scheme.
Nevertheless, that's only true when testing "randomly generated" candidates.
While testing password lists from e.g. rockyou, most of the candidates look "reasonable" somehow (they had been valid passwords for someone else!).