Posts: 134
Threads: 27
Joined: May 2010
07-06-2013, 02:17 PM
(This post was last modified: 07-06-2013, 02:17 PM by proinside.)
I may be wrong, and I might be using the command line in a non correct way. Can anyone confirm this:
- using -a 6
oclHashcat-plus64.exe -a 6 -n 80 -m0 --force --status --markov-disable --disable-potfile --gpu-temp-disable --remove MD5.txt -o pass.found rockyou.txt -1 ?l?d?s ?1?1
After a short run the program crash. I think this used to work well (or I might wrong as well and don't remember this with precision)...
Also, it seems that -i option here doesn't make any difference.
Note: if already posted somewhere, point me to where is the topic. Tks.
Posts: 2,936
Threads: 12
Joined: May 2012
ouch, that command line is a mess.
so, first things first: why are you using --force? if you are using --force because you are using an unsupported driver, then that is likely your problem. please do not submit bug reports when using an unsupported driver.
if you are using a supported driver (beta requires catalyst 13.4), and are simply using --force gratuitously, then have you tried running hashcat with a much simpler command line? one that is properly structured, and doesn't include every possible switch?
Code:
oclHashcat-plus64 -o pass.found --remove -a 6 -1 ?l?d?s MD5.txt rockyou.txt ?1?1
lastly, -i only works with mask attacks, and does not work with hybrid attacks.
Posts: 134
Threads: 27
Joined: May 2010
07-07-2013, 08:59 PM
(This post was last modified: 07-07-2013, 09:07 PM by proinside.)
Ok, thanks for your reply epixoip !
Driver installed: 13.4. Windows X64.
Following your suggestion, I did some runs with your clean command line, always using rockyou
dictionaire.
The program crash not ending the dictionaire. Replaced the dictionaire by the same dictionaire,
but from a fresh download (and hopefully in good condition). No change, still crashes.
This with plus b45.
With the exactly same command line, same dictionaire, but using plus b20, no crash, no problems.
Something related to recent builds supporting more than 15 characters ?!
No idea. I'll run using a couple of diferent dictionaires and I'll see what I get.
The options used in my command line (apart from the -i option which, like you said, is to use
with mask) never gave any problem.
Update:
- now did a run using a larger dictionaire (insidepro) and again b45 had a crash, this time
with "The instruction at 0xf9c51736 referenced memory at 0x00000000. The memory could not be read."
- went to b20 and, again, using the same command line, same dictionaire, no problem.
Posts: 621
Threads: 57
Joined: May 2010
I have the same behavior (crashes on dictionary attacks) in a Nvidia multi-GPU setup under windows 7 64-bit. I do think that there is a bug. I just don't know what is the exact cause.
Posts: 5,185
Threads: 230
Joined: Apr 2010
null pointer dereferences mostly point to a bug, thats true. but i cant reproduce it and thats what makes it hard. can you try to find a very small dictionary that makes it possible to reproduce it and then send me that dictionary and hash? hopefully it will crash on linux too then
Posts: 134
Threads: 27
Joined: May 2010
07-14-2013, 12:32 AM
(This post was last modified: 07-14-2013, 01:12 AM by proinside.)
While testing, using a 18 md5 hashes file, running -a 6 and -1 ?l?d?u?s ?1?1:
Test using john.dic and then example.dic.
First with only ?1, then with ?1?1. Will get a crash with ?1?1 or ?1?1?1.
Didn't need to test more than that to crash.
Sent the hash list.
Updated: this can be random, to make things harder. In fact I did a run using
John.dic from ?1 to ?1?1?1 and now no crash !
Ok, switch to example.dic, ?1 no crash. ?1?1 crash immediately.
After example.dic crash, running immediately john.dic with ?1 crash immediately as well.
Eventually, something still fresh from the example.dic crash...
Updated again: using latest build (b53) didn't crash using these options. Looks like not happening anymore.
Posts: 5,185
Threads: 230
Joined: Apr 2010
cool thanks yeah that was actually a fixed bug
