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