bkcrack
bkcrack copied to clipboard
kimci86
Is it possible to use the recovered key in Hashcat?
Just wondering if we can leverage the speed of Hashcat / GPU to recover the password faster when we know the key we got from bkcrack?
Sure, use mode 20500 or 20510. https://hashcat.net/wiki/doku.php?id=example_hashes
That's right, thank you @magnumripper. @jlory You simply need to concatenate the three key components to give it to hashcat. Use mode 20510 if you have a single key to recover, or mode 20500 if you have many.
That reminds me of this: hashcat implements the original password recovery algorithm described in Biham and Kocher's paper. At least that is what I remember from the last time I looked at hashcat. I implemented essentially the same algorithm in bkcrack but with an additional optimization I came up with: a small computation is done before starting to test password candidates which then allows to discard password candidates early. As a result, last time I checked with some very unscientific measurements, hashcat and bkcrack were about as fast. I hope to contribute my optimization to hashcat someday to make it faster. I need to learn some OpenCL first!
My memories were a little off, so I edited the message above to fix mistakes. Also, the performance comparison with hashcat was mentioned in this other issue https://github.com/kimci86/bkcrack/issues/52#issuecomment-1011300640
So, to recap, you can use hashcat, but the speed improvement might not be spectacular. If you try it, could you share some time measurements to compare with bkcrack? That would potentially be a great motivation for me towards contributing my optimization to hashcat.
Hashcat's mode 20510 has what they call "6 bytes optimization". Somehow it "knows" the 6 first characters of a longer candidate. That is, if you specify mask ?a it will actually try/crack ?a?a?a?a?a?a?a. I have no idea how that works and I can't recall reading any paper on the subject. Does bkcrack have this feature? If not, you should definitely try to implement it.
@magnumripper
I can't recall reading any paper on the subject.
The original algorithm is described in Biham and Kocher's paper A known plaintext attack on the PKZIP stream cipher in section 3.6. I admit it is hard to follow though. It is also described in Improved Forensic Recovery of PKZIP Stream Cipher Passwords with more details and a diagram (section 3). This paper describes what was implemented in hashcat .The first author of the paper Sein Coray (hello @s3inlc :wave:) contributed the implementation to hashcat.
Does bkcrack have this feature?
Yes, the so-called "6 bytes optimization" is implemented in bkcrack. The recovery algorithm for 6 characters is a special case. For more characters, bkcrack bruteforces the n-6 first characters then applies the algorithm for the last 6 characters. hashcat does it the other way around: it bruteforces (in bruteforce mode) the n-6 last characters and applies the special algorithm for the remaining first 6 bytes.
Hi. I'm having a hard time trying to use the recovered key in Hashcat. Can anyone assist me on which command to use in order to pass the key to Hashcat? Thanks
You just drop the spaces: If key was listed as abcd0123 fedc7890 4567baff it will be abcd0123fedc78904567baff.
A single key can be given as command line argument to hashcat (as opposed to putting it in a file) so a command line for that key could be:
hashcat -m20500 abcd0123fedc78904567baff -i -a3 ?a?a?a?a?a?a
Hi @mindked, here is what happened: The example hashcat command provided above (thank you @magnumripper!) tries to bruteforce a password made of up to 6 printable ASCII characters. After a little while (30 seconds for your configuration), the search space is exhausted and for the given example hash, no solution was found. If you try to recover a password longer than 6 characters with a similar command, the same will happen. So nothing to worry about, that was expected.
If you have a single key to feed to hashcat and if it is longer than 6 characters, I recommend hash type 20510 instead of 20500 because it takes advantage of the zip cipher weakness (the so-called 6 bytes optimization mentioned earlier in this discussion), so you can recover a long password faster.
Here is a hashcat command to recover the password from bkcrack's tutorial, with the assumption that the password is made of more than 6 lowercase letters, uppercase letters or decimal digits. It goes up to length 12 (that is 6 from zip cipher weakness and 6 bruteforced).
hashcat -m 20510 c4490e28b414a23d91404b31 -a 3 -1 ?l?u?d -i ?1?1?1?1?1?1
Doing the same with bkcrack is:
bkcrack -k c4490e28 b414a23d 91404b31 -r 12 ?l?u?d
Regarding performance, I just tested the two commands above on a laptop and measured execution time with time command.
- CPU: Intel Core i5-8350U
- GPU: Intel UHD Graphics 620
Results:
- 6.5 s for bkcrack (CPU)
- 25 s for hashcat (GPU)
- 3 min for bkcrack (CPU) without my custom optimization
So the original algorithm (b. and c.) is faster on GPU (even not a dedicated one, that might also be due to hashcat being smart about which password are tried first) and my optimization (a.) speeds up the computation a lot (especially when the character set is small). I am really curious to see how my optimization would behave on a GPU :) It is yet to be implemented.
@kimci86 Thank you for your very details explanation. That is very helpful. I'm currently running recovery password with -r 14 ?p on bkcrack. If it still can't find it, I will try Hashcat
Not sure if I can post this question in here but yesterday I tried recovery password of bkcrack with -r 14 ?a It found the password after 12 hours of running but there is a strange character. The password didn't work
as bytes: **32 69 93 69 as text: *****iôiU
This is a little off-topic for this present discussion. Let me open another issue for that.
First of all, I'd like to say thank you! A friend and I had a lot of fun yesterday evening poking a ZIP archive with some images in it and bkcrack did the trick!
I, too, was wondering whether I can use hashcat to recover the original password, and found this issue. Thought I'd share my experience (for privacy reasons, I won't share the hash/password here). Originally I had both bkcrack and hashcat running at the same time (which works quite well, since hashcat utilizes mostly the GPU, and bkcrack utilizes the CPU). hashcat found the password first. I then timed both programs separately.
bkcrack.exe -k xxxxxxxx xxxxxxxx xxxxxxxx -r 64 ?p took 1 hour and 47 minutes.
hashcat.exe -m20510 xxxxxxxxxxxxxxxxxxxxxxxx -i -a3 ?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a -w 3 took 6 minutes and 55 seconds
That's quite a stark difference!
In hashcat I see speeds around 18188.8 MH/s on device 1 and 290.1 MH/s on device 2:
OpenCL API (OpenCL 3.0 CUDA 12.0.89) - Platform #1 [NVIDIA Corporation]
=======================================================================
* Device #1: NVIDIA GeForce RTX 3070 Laptop GPU, 7488/8191 MB (2047 MB allocatable), 40MCU
OpenCL API (OpenCL 3.0 ) - Platform #2 [Intel(R) Corporation]
=============================================================
* Device #2: Intel(R) UHD Graphics, 6464/13034 MB (2047 MB allocatable), 24MCU
In case it's relevant: The CPU is an Intel i7-10870H. I'm using 2x16GB DDR4 RAM at 2933 MHz.
@Niko-O Thank you for sharing those measurements! It confirms adding GPU password recovery would be a great improvement.
Closing as question has been answered. Thank you for the feedback and suggestions.