You really helped doing that decode and annotation -- made the whole thing pretty easy. Like you, I got misled by the source, by the use of the word "key" with reference to the MD5 check (in the call to TKeyHashSimple.Create) -- it's not the SHA-1-generated key that gets passed in, it's actually the raw passphrase. So, to check if a password is a valid candidate for decryption, you don't even *need* to do any SHA-1 or key construction -- the MD5 check is sufficient. I nearly hurt myself laughing when I realised how simple (and bad) it is.
I've got the C module code and an -a3 (brute-force) kernel that cracks a test crypted file already written; wordlist and combo kernels are a few lines of copy-paste away. Benchmark on a 3-year-old Intel mobile CPU:
Hashmode: 24300 - BFACS
Speed.#2.........: 176.4 MH/s (47.31ms) @ Accel:1024 Loops:1024 Thr:1 Vec:8
this sounds very interesting
@womble, do you plan on sharing your hashcat module and opening a pull request (PR) on github ?
what is your strategy with avoiding false positive (or can we assume that it's quite rare and the user should use --keep-guessing ?)
btw: also see
https://github.com/hashcat/hashcat/blob/...t-guide.md for our new dev guide, we would appreciate some feedback or help in improving it also. that would be great (but remember, it's a guide... not a tutorial or step-by-step instruction on how to add a module)
It would also be nice to have some standard hash format for it.... lately we tend to use hash formats with signature like:
$BFACS$version*salt*data*hash
or similar, where the start is the signature, then comes a number to indicate an internal hash version (could also be a software version, but in general it's just some "hash format version"), and after that the important data.... the last field is normally the checksum/hash or encrypted data etc
I think it wouldn't be impossible to use the MD5 checksum as a early reject/exit, but later on also do some further verification (only if matched)... not sure if a strategy like this is possible/applicable here (I didn't look at the details)
Thx and really great discovery
(05-15-2020, 08:39 AM)philsmd Wrote: [ -> ]@womble, do you plan on sharing your hashcat module and opening a pull request (PR) on github ?
Yes, although I'm in no hurry given that my other PRs don't seem to have gotten any eyeballs.
(05-15-2020, 08:39 AM)philsmd Wrote: [ -> ]what is your strategy with avoiding false positive (or can we assume that it's quite rare and the user should use --keep-guessing ?)
It'll have to be --keep-guessing. There's not really any other way that'll work.
(05-15-2020, 08:39 AM)philsmd Wrote: [ -> ]btw: also see https://github.com/hashcat/hashcat/blob/...t-guide.md for our new dev guide, we would appreciate some feedback or help in improving it also. that would be great (but remember, it's a guide... not a tutorial or step-by-step instruction on how to add a module)
It's excellent. Helped me immensely when I was writing the PKCS#1 module.
(05-15-2020, 08:39 AM)philsmd Wrote: [ -> ]It would also be nice to have some standard hash format for it.... lately we tend to use hash formats with signature like:
$BFACS$version*salt*data*hash
I've used $bfacs$<salt>$<check>. Not rocket science to change, though, if necessary. I don't think a version is necessary here, as the last release was aaaaaaaaaaaaaages ago.
(05-15-2020, 08:39 AM)philsmd Wrote: [ -> ]I think it wouldn't be impossible to use the MD5 checksum as a early reject/exit, but later on also do some further verification (only if matched)... not sure if a strategy like this is possible/applicable here (I didn't look at the details)
I don't think it's feasible. You can encrypt *anything* with this tool, so there's no known plaintext we can use to decide if we've got the right passphrase, and even an entropy check won't work (because the plaintext could be compressed or another encrypted blob or whatever).
oh... are you mpalmer on github ? yeah, I see that there are some still open PRs, I think atom/jsteube is busy a lot, but I will try to ping him on IRC etc. normally it doesn't take that long (I think one reason could be that we/he saw that some PRs were still incomplete or were updated a lot... so might have decided to wait a little bit etc)...
Actually, what comes to my mind now is that it would be great to find some "collision" (or just another password that would work) and try to decrypt the file with that "wrong" password.... would this be feasible for you to test... it might take some time to find a collision, but you could be lucky. It would be interesting to see if the software is able to reject the collision (wrong password, but still correct "checksum"/quick check)
I think/hope there is some other means to validate the data... but again, you could also be right and this is the only test.
Thx
(05-15-2020, 07:46 AM)womble Wrote: [ -> ]You really helped doing that decode and annotation -- made the whole thing pretty easy. Like you, I got misled by the source, by the use of the word "key" with reference to the MD5 check (in the call to TKeyHashSimple.Create) -- it's not the SHA-1-generated key that gets passed in, it's actually the raw passphrase. So, to check if a password is a valid candidate for decryption, you don't even *need* to do any SHA-1 or key construction -- the MD5 check is sufficient. I nearly hurt myself laughing when I realised how simple (and bad) it is.
I've got the C module code and an -a3 (brute-force) kernel that cracks a test crypted file already written; wordlist and combo kernels are a few lines of copy-paste away. Benchmark on a 3-year-old Intel mobile CPU:
Hashmode: 24300 - BFACS
Speed.#2.........: 176.4 MH/s (47.31ms) @ Accel:1024 Loops:1024 Thr:1 Vec:8
Thank you! When Romeo first contacted me and told me about this and mentioned blowfish, I said "oh hashcat supports that!", after reading the documentation and exploring the source code, I came to find out it was using blowfish to encrypt the data, but they key derivation algorithm was laughable.
Looks like speeds are impressive for the given hardware.
(05-15-2020, 12:59 PM)philsmd Wrote: [ -> ]oh... are you mpalmer on github ? yeah, I see that there are some still open PRs, I think atom/jsteube is busy a lot, but I will try to ping him on IRC etc. normally it doesn't take that long (I think one reason could be that we/he saw that some PRs were still incomplete or were updated a lot... so might have decided to wait a little bit etc)...
The PKCS#1 module I'm still not 100% happy with, but the two small ones should be ready to go.
(05-15-2020, 12:59 PM)philsmd Wrote: [ -> ]Actually, what comes to my mind now is that it would be great to find some "collision" (or just another password that would work) and try to decrypt the file with that "wrong" password.... would this be feasible for you to test... it might take some time to find a collision, but you could be lucky. It would be interesting to see if the software is able to reject the collision (wrong password, but still correct "checksum"/quick check)
Finding a collision, given that it's only a 32-bit check value and the module runs at 170MH/s or so even on my laptop, isn't very hard. I got one already, and lo! it can detect that the file was decrypted incorrectly (it doesn't say "wrong password", but I know what it means). There's a second header inside the ciphertext with a 32-bit magic value, so between the 32-bit initial check and the post-decryption magic value check, the false positive rate should be ~2^(-64). The only problem is that now I've got to implement that unhinged key generation algorithm, and per-cipher suite kernels for the decryption...
(05-15-2020, 04:13 PM)0x4n6 Wrote: [ -> ]Thank you! When Romeo first contacted me and told me about this and mentioned blowfish, I said "oh hashcat supports that!", after reading the documentation and exploring the source code, I came to find out it was using blowfish to encrypt the data, but they key derivation algorithm was laughable.
Looks like speeds are impressive for the given hardware.
Yeah, this should absolutely *scream* on a decent GPU. Doing a single MD5, a few XORs, and a compare is not big work.
Womble,
Romeo passed on your message regarding extraction of the salt and folded md5 formatted for hashcat input.
I got a python script ready to go and it works with my sample file. I know you gave him a template for the output, but I wasnt 100% sure if you need the ouput to be either:
$bfacs$<707af3a5da717fdaa34fd2>$<8f927841>
or
$bfacs$707af3a5da717fdaa34fd2$8f927841
Let me know and I'll release it tomorrow morning to you and Romeo.
Thank you!
I've made your bit of python redundant, I'm afraid -- but on the upside, false positives should be a thing of the past! You'll want to use
https://github.com/mpalmer/bfacs2hashcat to extract the hash data and format it for cracking, and then run the crack using a hashcat built from
https://github.com/mpalmer/hashcat/tree/bfacs (at least until
https://github.com/hashcat/hashcat/pull/2407 gets merged).
Happy cracking!
Aside #1: The password on that test file you screenshotted earlier was `1212`.
Aside #2: On a V100-enabled EC2 instance:
Code:
Speed.#1.........: 15612.1 MH/s (76.58ms) @ Accel:16 Loops:1024 Thr:1024 Vec:1
I feel the need... the need for SPEED!
(05-19-2020, 04:07 PM)womble Wrote: [ -> ]I've made your bit of python redundant, I'm afraid -- but on the upside, false positives should be a thing of the past! You'll want to use https://github.com/mpalmer/bfacs2hashcat to extract the hash data and format it for cracking, and then run the crack using a hashcat built from https://github.com/mpalmer/hashcat/tree/bfacs (at least until https://github.com/hashcat/hashcat/pull/2407 gets merged).
Happy cracking!
Aside #1: The password on that test file you screenshotted earlier was `1212`.
Aside #2: On a V100-enabled EC2 instance:
Code:
Speed.#1.........: 15612.1 MH/s (76.58ms) @ Accel:16 Loops:1024 Thr:1024 Vec:1
I feel the need... the need for SPEED!
Well, I feel irrelevant now 😭!
Thank you for the help. I'll compile it and give it a go. btw the password was 1212 for that test file, so it working as expected.
This has been resolved. Thank you womble!