Hashcat has got a feature which consists of updating a restore point periodically so that we can quit the task and then restore it at that point in the future, it is working with most of the hash types but specifically I can't get it to work with bcrypt hashes. The output I can see in this case is like the following. Restore point is always 0, it does never get updated, neither even when the task has been already finished, so with bigger dictionaries it is a serious problem, because when I restore a previously stopped task, its progress always starts from the beginning, regardless of the task having a very big progress when it was stoppped.
Code:
Session..........: test
Status...........: Exhausted
Hash.Type........: bcrypt, Blowfish(OpenBSD)
Hash.Target......: [there was a hash here]
Time.Started.....: Mon Feb 13 12:57:57 2017 (7 mins, 46 secs)
Time.Estimated...: Mon Feb 13 13:05:43 2017 (0 secs)
Input.Base.......: File ([a dictionary file path])
Input.Mod........: Rules ([a rule file path])
Input.Queue......: 1/1 (100.00%)
Speed.Dev.#2.....: 425 H/s (0.54ms)
Speed.Dev.#3.....: 0 H/s (0.00ms)
Speed.Dev.#*.....: 425 H/s
Recovered........: 0/1 (0.00%) Digests, 0/1 (0.00%) Salts
Progress.........: 198172/198172 (100.00%)
Rejected.........: 0/198172 (0.00%)
Restore.Point....: 0/2 (0.00%)
Candidates.#2....: [password] -> [password]
Candidates.#3....: [Copying]
HWMon.Dev.#2.....: N/A
HWMon.Dev.#3.....: N/A
[s]tatus [p]ause [r]esume [b]ypass [c]heckpoint [q]uit => Started: Mon Feb 13 12:57:55 2017
So, what's the matter with this? Is it a Hashcat bug? In that case, is it planned to be corrected at any specific release in the future?
Not a bug, your wordlist is too small (198172 candidates), there's simply no restore checkpoint possible with it.
(02-13-2017, 02:59 PM)atom Wrote: [ -> ]Not a bug, your wordlist is too small (198172 candidates), there's simply no restore checkpoint possible with it.
I don't understand. Here is an example with a task using a large word list which had been executing for 4 days:
Code:
Session..........: 72ebf0e8-2c0e-4476-b0b4-96a34395f4eb
Status...........: Running
Hash.Type........: bcrypt, Blowfish(OpenBSD)
Hash.Target......: [hashes file path]
Time.Started.....: Wed Feb 8 13:52:23 2017 (4 days, 19 hours)
Time.Estimated...: Wed Apr 15 20:36:54 2020 (54278016 years, 273 days)
Input.Base.......: File ([dictionary file path])
Input.Mod........: Rules ([rule file path])
Input.Queue......: 1/1 (100.00%)
Speed.Dev.#1.....: 34 H/s (4.48ms)
Speed.Dev.#2.....: 34 H/s (4.47ms)
Speed.Dev.#*.....: 69 H/s
Recovered........: 0/82563 (0.00%) Digests, 0/82563 (0.00%) Salts
Recovered/Time...: CUR:0,0,0 AVG:0,0,0 (Min,Hour,Day)
Progress.........: 28780880/117340172614249728 (0.00%)
Rejected.........: 0/28780880 (0.00%)
Restore.Point....: 0/14343296 (0.00%)
Candidates.#1....: 2622234521 -> ayaaamilaf
Candidates.#2....: ojnathan -> advid
HWMon.Dev.#1.....: Temp: 51c Fan: 42% Util: 98% Core:1124Mhz Mem:2505Mhz Lanes:16
HWMon.Dev.#2.....: Temp: 44c Fan: 42% Util: 98% Core:1124Mhz Mem:2505Mhz Lanes:16
[s]tatus [p]ause [r]esume [b]ypass [c]heckpoint [q]uit =>
In those 4 days, progress had advanced up to more than 28 millions of combinations. There wasn't still any restore point. What could be the reason for that?
That's because you did check only 348 words yet (28780880 / 82563). You threads alone do 256, not even counted the shader or the -n multiplicator. For sure you didn't reach a checkpoint for restore. Problem is not hashcat here, problem is cracking 82563 at once is braindead
(02-13-2017, 11:53 PM)atom Wrote: [ -> ]That's because you did check only 348 words yet (28780880 / 82563). You threads alone do 256, not even counted the shader or the -n multiplicator. For sure you didn't reach a checkpoint for restore. Problem is not hashcat here, problem is cracking 82563 at once is braindead
Thank you, I have noticed that only when current candidates change in the Hashcat output, a restore point is created. The problem with me was that the algorithm was so slow that I had never watched the candidates change even waiting for four days.
Even with only one Bcrypt hash I checked that Hashcat takes too much time to create the first restore point. The reason for that is that the algorithm is too slow. Instead of that I would suggest that Hashcat created restore points more frequently when the algorithm is slower, so that we could stop a task without losing all the done work. With MD5 for example Hashcat creates too many restore points in my computer, almost every second I could say. But with BCrypt it takes four hours to create the first restore point. I think that those times should be more homogeneus bearing in mind the algorithm speed.
(02-13-2017, 11:53 PM)atom Wrote: [ -> ]That's because you did check only 348 words yet (28780880 / 82563). You threads alone do 256, not even counted the shader or the -n multiplicator. For sure you didn't reach a checkpoint for restore. Problem is not hashcat here, problem is cracking 82563 at once is braindead
There is still a problem. I tried with a task with a ten thousand words dictionary, waited for 18 hours, and then, when progress was at 27%, I saw that still there was not any restore point:
Code:
Session..........: 647c1801-f925-4e85-8af1-b68e161d4ba1
Status...........: Running
Hash.Type........: sha512crypt, SHA512(Unix)
Hash.Target......: [hashes file]
Time.Started.....: Tue Feb 7 15:17:38 2017 (18 hours, 9 mins)
Time.Estimated...: Fri Feb 10 08:40:42 2017 (1 day, 23 hours)
Input.Base.......: File ([dictionary file])
Input.Mod........: Rules ([rule file])
Input.Queue......: 1/1 (100.00%)
Speed.Dev.#1.....: 17139 H/s (1.30ms)
Speed.Dev.#2.....: 17490 H/s (1.25ms)
Speed.Dev.#*.....: 34628 H/s
Recovered........: 6/10615 (0.06%) Digests, 6/10615 (0.06%) Salts
Recovered/Time...: CUR:0,0,N/A AVG:0,0,7 (Min,Hour,Day)
Progress.........: 2286481455/8173550000 (27.97%)
Rejected.........: 817355/2286481455 (0.04%)
Restore.Point....: 0/10000 (0.00%)
Candidates.#1....: kangaro -> boeing74
Candidates.#2....: 1234 -> weltmeist
HWMon.Dev.#1.....: Temp: 78c Fan: 66% Util: 95% Core:1124Mhz Mem:2505Mhz Lanes:16
HWMon.Dev.#2.....: Temp: 71c Fan: 58% Util: 94% Core:1124Mhz Mem:2505Mhz Lanes:16
I know that Hashcat does not create a restore point until it finishes checking the current dictionary blocks. This time if we look at the candidates, we can know that the ten thousand words dictionary was divided into two blocks of five thousand words and then the two blocks got executed simultaneously. That's because the 1st word of the dictionary was "123456", the number 5000 was "weltmeister", the number 5001 was "kangaroo", while the last, number 10000 was "boeing747". I work out that this time Hashcat won't create a restore point until the whole dictionary is checked. Isn't that a little kind of nonsense?
As I said already not if you use a single hash. Since bcrypt is salted, there's not benefit (from a time perspective) then to run them all in a single mode in a sequence.