All,
I am looking for help with getting HC to run against some keys and salts extracted from .bfa files encrypted by Blowfish Advanced CS 2.57 (on sourceforge).
I read through their manual and found the following excerpt:
"Let our password be "helloworld". We want to create a key of 128 bits (16 bytes). The SHA-1 allows us to input as much data bytes as we want to, and puts out a hash of 160 bits (20 bytes). A hash (also called digest) is the same like a CRC32 checksum, but secure for encryption purposes.
To resize the 20 bytes of the hash to the required 16 bytes for the key we take the first 16 bytes of the hash and XOR the rest of 4 bytes over the beginning of these 16 bytes. By this we don't ignore any part of the hash:
password: "helloworld"
|
SHA-1
|
a3d4ff09e22710946702eab2cc382596a8e3197322
a3d4ff09e22710946702eab2cc382596a8
||||||||
XOR e3197322
||||||||
key: 40cd8c2be22710946702eab2cc382596a8
In the second example we assume that our password is still "helloworld" but we need a key for Blowfish which has the required length of 56 bytes.
As already mentioned SHA-1 only returns 20 bytes. So we have to create 36 additional bytes from the password by the following way: we hash the password with SHA-1 and get 20 bytes. Then we add those 20 bytes to the original password and hash the modified password again. The result is a new hash which means 20 new bytes for our key. Due to the modified password this new hash is completely different from the first one. Now we append this second hash to the modified password again and rehash it to get the last 20 bytes. Of course now we have 4 bytes too much, so we XOR them over the first hash as we did in the first example. Now we have the needed 56 bytes for the Blowfish encryption algorithm.
Please remember that your password is always combined with 11 bytes of salt."
Any help is appreciated.
<-Romeo3442->
What exactly do you need help with? If it's interpreting the algorithm description, if I'm reading the description correctly, in pseudocode, what they're describing looks something like this:
b1 = SHA1(password)
b2 = SHA1(password + b1)
b3 = SHA1(password + b2)
xor_source = last_four_bytes_of(b3)
key = first_56_bytes_of(b1 + b2 + b3)
first_four_bytes_of(key) = first_four_bytes_of(key) XOR xor_chunk
Since the source is (presumably) up on SourceForge, though, you could skip their textual description and just Use The Source, Luke (possibly with the help of a debugger).
If you're wanting help actually running that algorithm in Hashcat, you'll absolutely 100% need to write a module. There's nothing at the moment that implements the algorithm you've described (unless someone's snuck in a new module in the last few weeks). As a base, 18600 would probably work best, as it's using SHA-1 and Blowfish (though in a different construction), and of course the comparison kernel would presumably need to be somewhat different.
(05-08-2020, 03:43 AM)womble Wrote: [ -> ]What exactly do you need help with? If it's interpreting the algorithm description, if I'm reading the description correctly, in pseudocode, what they're describing looks something like this:
b1 = SHA1(password)
b2 = SHA1(password + b1)
b3 = SHA1(password + b2)
xor_source = last_four_bytes_of(b3)
key = first_56_bytes_of(b1 + b2 + b3)
first_four_bytes_of(key) = first_four_bytes_of(key) XOR xor_chunk
Since the source is (presumably) up on SourceForge, though, you could skip their textual description and just Use The Source, Luke (possibly with the help of a debugger).
If you're wanting help actually running that algorithm in Hashcat, you'll absolutely 100% need to write a module. There's nothing at the moment that implements the algorithm you've described (unless someone's snuck in a new module in the last few weeks). As a base, 18600 would probably work best, as it's using SHA-1 and Blowfish (though in a different construction), and of course the comparison kernel would presumably need to be somewhat different.
Correct, I am looking for help developing a module to attack this particular implementation. Is this a good place to request or on Github? I am not savvy enough to create the module and thus seeking help from the community. Thanks,
<-Romeo3442->
The algorithm is also not complete. One of the important steps is missing... how does a password cracking tool know if the password is correct ? the verification code i.e. checking the decrypted bytes against some string or similar is completely missing from your description.
Just generating a key is not enough to know if the password is correct.
(05-09-2020, 11:32 PM)Romeo3442 Wrote: [ -> ]Correct, I am looking for help developing a module to attack this particular implementation. Is this a good place to request or on Github? I am not savvy enough to create the module and thus seeking help from the community.
By "help", do you mean you want someone to write the whole module for you? If so, you might be waiting a while. You could, certainly, drop a "new-algorithm" issue on GitHub, but if you peruse the existing list of open "new-algorithm" issues, you'll note that there's a lot of them sitting there. Also, as philsmd says, without knowing exactly how to decide if the key is correct, it's not a lot of use to know how to generate a key. For hash cracking, it's easy -- "does the generated hash match the original?" -- but for encryption key generation, you need to decrypt the data and then look to see if it "seems OK". That's a tricky problem, and requires knowing a lot more about how the data is stored.
Because I have too much curiosity, I took a gander at the source code for BFACS. It's... really something. Mostly Object Pascal code, which is a real throwback to the good ol' days. Certainly, it's not going to be a two hour task to write a module, if for no other reason than BFACS supports more than just Blowfish -- the "Technical Reference" page suggests that it also supports CAST5, ARCFOUR, Serpent, AES, 3DES, and Twofish. If you want something that supports all those, it's going to be more of an adventure.
Do you have a specific data file that you're looking to decrypt -- perhaps the long-lost wallet of Satoshi? If so, that's a bit easier, because there'll only be one cipher to deal with.
(Also, I can't go without quoting this gem from the TechRef: "SHA-1 is the most secure hash algorithm available today.")
(05-10-2020, 03:45 PM)womble Wrote: [ -> ] (05-09-2020, 11:32 PM)Romeo3442 Wrote: [ -> ]Correct, I am looking for help developing a module to attack this particular implementation. Is this a good place to request or on Github? I am not savvy enough to create the module and thus seeking help from the community.
By "help", do you mean you want someone to write the whole module for you? If so, you might be waiting a while. You could, certainly, drop a "new-algorithm" issue on GitHub, but if you peruse the existing list of open "new-algorithm" issues, you'll note that there's a lot of them sitting there. Also, as philsmd says, without knowing exactly how to decide if the key is correct, it's not a lot of use to know how to generate a key. For hash cracking, it's easy -- "does the generated hash match the original?" -- but for encryption key generation, you need to decrypt the data and then look to see if it "seems OK". That's a tricky problem, and requires knowing a lot more about how the data is stored.
Because I have too much curiosity, I took a gander at the source code for BFACS. It's... really something. Mostly Object Pascal code, which is a real throwback to the good ol' days. Certainly, it's not going to be a two hour task to write a module, if for no other reason than BFACS supports more than just Blowfish -- the "Technical Reference" page suggests that it also supports CAST5, ARCFOUR, Serpent, AES, 3DES, and Twofish. If you want something that supports all those, it's going to be more of an adventure.
Do you have a specific data file that you're looking to decrypt -- perhaps the long-lost wallet of Satoshi? If so, that's a bit easier, because there'll only be one cipher to deal with.
(Also, I can't go without quoting this gem from the TechRef: "SHA-1 is the most secure hash algorithm available today.")
"long-lost wallet of Satoshi" --
Not bitcons here for me but still very important to crack.
I have a specific data file which I am interested in. If I was to examine the hex of this file at what offset would I be able to find out if it was blowfish or something not the default of BFACS?
<-Romeo3442->
A friend helped me with parsing the first few bytes of a test file.
That decoding is really helpful -- if the "Folded MD5 of salt+key" is what it sounds like, that'd be the ticket be able to detect whether you've got the correct passphrase -- or at least a good candidate to try. Also, it's independent of the cipher, which is good from a cracking speed perspective, because a few SHA-1s and an MD5 is *hella* fast.
(time passes)
OK, I broke down a downloaded a copy of BFACS, and created a test encrypted file. Turns out, it's even worse (or better, if you're looking to crack the passphrase) than I thought: the "key" in "folded MD5 of salt+key" is not *actually* the key generated by all that SHA-1 shenanigans -- it's actually just:
u32 *h = MD5(salt + key)
h[0] ^ h[1] ^ h[2] ^ h[3]
Of course, you'll get (on average) an FP every 2^32 tries, and the hash rate will be *phenomenal*, being a single round of MD5, so you'll get candidates spewing out fairly regularly, but if you can keep up the rate of copy-paste, you'll probably have an answer pretty quickly.
Also, as far as I can tell, this is all independent of the cipher suite being used. I kinda want to hunt down the guy who wrote this and make sure he isn't running with scissors or anything...
Hello all!
My name is Jorge. I am the one who helped Romeo with parsing out the header of the file generated by the encryption software.
Womble, you are correct about the algorithm, this is a key derivation algorithm. From what I gather from looking at the source code, the password goes through 3 rounds of SHA1 to generate a 60 byte string. Obviously, since we need 56 bytes for the key, the last 4 byte get XORed with the first 4 bytes. After that, the salt is added and the result is md5 hashed. The digest is then folded to fit the last 4 bytes of the header.
We know that a simple script could automate the task, however I advised Romeo to reach out to the forum since implementing this could be helpful for other in the future and also it takes advantage of hashcat efficiency.