thoughts on hashcat-plus v0.12 w64 radeon6670

[falcon111]

1. Default session restore file better be placed in temp folder, i don't think writing it onto system volume is such a good idea. I have my system volume on ssd, and writing 22M every couple minutes on it is not good.
2. Default session restore file should include something unique, like pid or something. Thas way i can pause one copy and run another without bothering with session names.
On --restore you can search for the stored sessions, if there is one only session - restore it, if their number!=1 - give error.
3. Being paused, hashcat updates restore file
4. Sometimes console hangs. I can press 's' key and there's no reaction from the program, but calculations seems to go on though.
5. Runs ended with "Exhausted" sometimes showing time estimated > 10 years.
6. Feature request: attack by dictionary, containing bruteforce masks, so i can specify probable masks in one file and check them all in one run. At this moment i have to write bat-files of several hashcat runs.
7. As i understand, hashcat can't process dictionaries with masks on both ends of the words. Hybrid attacks can add bruteforce masks to one side of the password only, making impossible to find something like 12word34 combinations.
The way i see hybrid attack - add new macros (?w for example) for a dictionary word, then specify dictionary and mask something like ?d?d?w?d?d.
8. Sometimes hashcat crashes on start with no console output.
9. Don't really understand why every run hashcat shows something like NOTE: autotuned --gpu-accel from 32 to 24. Numbers mostly different every run. Not sure why it autotunes parameters, i've specified manually, what --gpu-accel switch for then?

PS: 1, 2: Second thought on restore session filename. It can be generated on the base of hash-filename. When cracking hash.md5, session name will be hash.md5.restore. It's even better than placing files in temp folder.

[atom]

Thanks for your thoughts!

1. Default session restore file better be placed in temp folder, i don't think writing it onto system volume is such a good idea. I have my system volume on ssd, and writing 22M every couple minutes on it is not good.

Thats not a good idea. For example on Linux the temp folder is not part of the disc. So If you computer crashes that is the case when you want to restore session but if the data is in a RAM disc its lost. Simple isnt it?

2. Default session restore file should include something unique, like pid or something. Thas way i can pause one copy and run another without bothering with session names.
On --restore you can search for the stored sessions, if there is one only session - restore it, if their number!=1 - give error.

They include the pid. Its required for multiple instances check. Using --restore with some sort of parameter sounds to complex. The program would have to deal with different informations of different session from within one single session about stats it does not know. That would require inter-process communications and and and.

3. Being paused, hashcat updates restore file

Yeah, thats becaise its handled from a different thread. But you have a point here, it should. What I can do is to disable writing of restore file while the tool is in pause mode, but this also means that the last unsaved restore point is not stored as well. But I guess thats a good compromis.

4. Sometimes console hangs. I can press 's' key and there's no reaction from the program, but calculations seems to go on though.

That is related to a very complex problem inside oclHashcat. I can tell you this happens because oclHashcat is already in the last phase of the workload you configured (Either dictionary or mask) - even if it does not look like. So oclHashcat can be in the last phase even if you just started the program. That is related to the -n paramter. See the v0.12 release notes about the technicals details of -n parameter. I dont want to explain this in detail here but maybe you can imagine. I will see if I can do a workaround in a later version for this.

5. Runs ended with "Exhausted" sometimes showing time estimated > 10 years.

Sounds like a bug. You know how to reproduce it?

6. Feature request: attack by dictionary, containing bruteforce masks, so i can specify probable masks in one file and check them all in one run. At this moment i have to write bat-files of several hashcat runs.

You mean for hybrid attack? And the masks can be queued? Yeah I though about the same a while ago. Maybe I will find a simple way to do it but no promisses.

7. As i understand, hashcat can't process dictionaries with masks on both ends of the words. Hybrid attacks can add bruteforce masks to one side of the password only, making impossible to find something like 12word34 combinations.
The way i see hybrid attack - add new macros (?w for example) for a dictionary word, then specify dictionary and mask something like ?d?d?w?d?d.

You can already do that, more or less with multi rules! There is also and hybrid folder in rules/ to do exactly what you want. Do: -r rules/hybrid/prepend_d.rule -r rules/hybrid/append_d.rule

8. Sometimes hashcat crashes on start with no console output.

If there is no console output might be because you wanted to check a to big hashlist. This part is done before it prints anything. Typically I wont go over 15 mil hashes for MD5 or 10 mil for SHA256 or bigger. This is related to so memory structures that allow oclHashcat to do check with high performance but they require more memory.

9. Don't really understand why every run hashcat shows something like NOTE: autotuned --gpu-accel from 32 to 24. Numbers mostly different every run. Not sure why it autotunes parameters, i've specified manually, what --gpu-accel switch for then?

Yeah I've added this because peopl misuse -n value very often. Please read the release notes for more details. Its explained in there very well.

PS: 1, 2: Second thought on restore session filename. It can be generated on the base of hash-filename. When cracking hash.md5, session name will be hash.md5.restore. It's even better than placing files in temp folder.

That sounds interessting. But why have two things that make it unique? There would be session name and hash/filename name.

[falcon111]

1. Default session restore file better be placed in temp folder, i don't think writing it onto system volume is such a good idea. I have my system volume on ssd, and writing 22M every couple minutes on it is not good.

Thats not a good idea. For example on Linux the temp folder is not part of the disc. So If you computer crashes that is the case when you want to restore session but if the data is in a RAM disc its lost. Simple isnt it?

I have my win64 the same way, all TEMPs are on the ram drive.
Still, i'm considering the risc of loosing progress. When i'm doing some long hashcat runs, i'm specifying --session=<otherplace>.
But mostly, restore needed to continue manually aborted run. Computer crash... hmm, i've forgot how it looks like

2. Default session restore file should include something unique, like pid or something. Thas way i can pause one copy and run another without bothering with session names.
On --restore you can search for the stored sessions, if there is one only session - restore it, if their number!=1 - give error.

They include the pid. Its required for multiple instances check. Using --restore with some sort of parameter sounds to complex. The program would have to deal with different informations of different session from within one single session about stats it does not know. That would require inter-process communications and and and.

No, they not. I've meant session filename.
But, that's no longer needed, restore-filename generated by hash-filename seems much better.

3. Being paused, hashcat updates restore file

Yeah, thats becaise its handled from a different thread. But you have a point here, it should. What I can do is to disable writing of restore file while the tool is in pause mode, but this also means that the last unsaved restore point is not stored as well. But I guess thats a good compromis.

Agreed.

5. Runs ended with "Exhausted" sometimes showing time estimated > 10 years.

Sounds like a bug. You know how to reproduce it?

Well, i'm usually do not run the same data more than once, but i'll try to find the way to reproduce. Im my case, it happens in 25-50% of runs.
What i'm afraid of - that's this is just the visible part of some bigger problem with keys sequences.

6. Feature request: attack by dictionary, containing bruteforce masks, so i can specify probable masks in one file and check them all in one run. At this moment i have to write bat-files of several hashcat runs.

You mean for hybrid attack? And the masks can be queued? Yeah I though about the same a while ago. Maybe I will find a simple way to do it but no promisses.

Hybrid and bruteforce. I'm calculating some statistics, it generates file with contents like
?d?d?d-?d?d?d?d
?d?d?d?d?d?d-?d
?d?d?d?d-?d?d?d?d
?l?l?l?l?l?l?l?l?l
?l?l?l?l?l?l?d?d
... and so on.
I want to have possibility to put those masks in one file and check them in one hashcat run. Just like usual dictionary, but containing masks and not words.

7. As i understand, hashcat can't process dictionaries with masks on both ends of the words. Hybrid attacks can add bruteforce masks to one side of the password only, making impossible to find something like 12word34 combinations.
The way i see hybrid attack - add new macros (?w for example) for a dictionary word, then specify dictionary and mask something like ?d?d?w?d?d.

You can already do that, more or less with multi rules! There is also and hybrid folder in rules/ to do exactly what you want. Do: -r rules/hybrid/prepend_d.rule -r rules/hybrid/append_d.rule

Yep, i was not thinking on such possibility.
Still, it's easier to specify --custom-charset1 <somechars> ?1?1?1?w?1?1?1 than to create rules with thousands lines in them.
Besides, markov chains are not working with rules, as I understand.

8. Sometimes hashcat crashes on start with no console output.

If there is no console output might be because you wanted to check a to big hashlist. This part is done before it prints anything. Typically I wont go over 15 mil hashes for MD5 or 10 mil for SHA256 or bigger. This is related to so memory structures that allow oclHashcat to do check with high performance but they require more memory.

That happened when i was running hashcat from hashcatgiu with big dictionaries list. I had to reduce number of dictionaries to successfully launch hashcat.
Right now i don't remember details, if this will happen again, i'll let you know.

PS: 1, 2: Second thought on restore session filename. It can be generated on the base of hash-filename. When cracking hash.md5, session name will be hash.md5.restore. It's even better than placing files in temp folder.

That sounds interessting. But why have two things that make it unique? There would be session name and hash/filename name.

No, no need to do unique modifications. If *.restore will be created by the hash-file name, that's will be just great.
Just don't forget to use path to hash file also, not the path to program itself.
T:\path\hash.md5 -> T:\path\hash.md5.continue
NOT the
T:\path\hash.md5 -> C:\Programs\Hashcat\hash.md5.continue