TC password found, wrong?

[bigblacknose]

Hi,

This is the situation:


I was attacking a TC system disk (boot mode) with hashcat.
After som days hashcat actually found a password that made sense to previous passwords that I had seen.

To confirm (and a simple way to decrypt from E01) I launched Passware against the same TC disk.
No success. Passware didn't find the same password (didn't find any password).

I mounted and booted the TC disk in VMware but unfortunate I can't unlock the disk with the password that hashcat found. I'm aware the TC/boot defaults to US Ascii keyboard layout and if there are special characters (which is the case) in the password, but I have tried this in a lot of various way and still it is not possible to unlock the disk.

I also have tried mounting the disk in *nix in different ways, but no success.


What is happening here? Do you have any thoughts? Passware says that the password that hashcat has found is wrong. I repeated the process of extracting the TC hash and tried different of hashcat installations (also the beta), and every time hashcat is able to find the same password.

Thanks for your thoughts. I'll be happy to share further information with someone involved in development.



/ bigblacknose

[bigblacknose]

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'll be happy to share the hash/password or some MB from the beginning of the disk with someone involved in development.

What are the odds of getting the ASCII string "TRUE" with a password/key that also makes sense?

In either way, I will reply to this thread when someone has shed some light over this strange issue.

[epixoip]

It's possible it's a false positive but the odds are pretty low. Especially if the password it found make sense.

[mkcon]

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.

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.

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!).

[bigblacknose]

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.

Thanks, I will send you a PM with some details. And later we can post the conclusions here.


// BBN

[bigblacknose]

I have been getting help from mkcon regarding this issue, and we have agreed that this is a false positive.

The password is wrong, that is.


Recovered......: 1/1 (100.00%)
// BigBlackNose - still remember that feeling

[atom]

Please send me the first 512 byte and the incorrect password so that we can reproduce and fix the problem

[bigblacknose]

Done. // BBN

[atom]

Thanks for the file you've provided. I've analyzed it.

The first thing I tried to reproduce is why JtR isn't cracking it. It turns out the reason is that JtR doesn't support boot-mode TC cracking. So I've patched the JtR code in a way that it can crack it. However the first 4 byte returned were 0x9f0fc936. We can assume to have used the wrong password (or the wrong algorithm selected).

When oclHashcat used PBKDF2-HMAC-RipeMD160-AES it returned the same number 0x9f0fc936 as JtR. But then why is oclHashcat returns it as being cracked? Well, it then turns out that my new optimization kicked in here. You can read about here: https://hashcat.net/forum/thread-4812.html

To make it short: The cipher used was _not_ AES256. The cipher used was Serpent256. JtR only supports AES cracking for TC, but oclHashcat supports all ciphers. This means we do _not_ have a bug. So I've dumped the serpent output, the first 4 byte is 0x45555254 which means "TRUE". Here's the full 16 byte buffer:

0x45555254
0x00002d18
0xa459c8d1
0xa3fb93c8

So you hit additional 16 bit check for older TC versions. To test for them, a nice way is to check if bytes 7 and 8 (as a short number) are <= 5. Note the buffer isn't swapped here that's why they appear as being bytes 5 and 6. To create a false positive chances are 6:2^48 (6:281474976710656 or 1:46912496118442).

Given a theoretical speed of 1MH/s, which requires you a machine with at least 4 high-end GPU's, this would produce 1 false positive only every 517 days. For that reason I thought it's enough to check only these 6 byte and do not do the crc32.

[bigblacknose]

Thanks for you analysis.

It was only oclHashcat and Passware that I have been given a try (except trying to mount the image in different ways).
Not JtR.

// BBN