hashcat
hashcat copied to clipboard
hashcat
inaccurate error 'empty file' using -a 1 and -j with a space
Version: v6.2.6-439-g9b9664967 (and others)
These combinator attack commands that use a single -j rule that appends a space:
hashcat -a 1 /path/to/file1 /path/to/file2 -j '$ ' --outfile /otherfilename [etc]
hashcat -a 1 /path/to/file1 /path/to/file2 -j '$\ ' --outfile /otherfilename [etc]
... die with this error:
/path/to/file1: empty file.
This may be a shell issue, but the error should be more specific to a problem with -j.
I've seen it from a few people recently but I think the "root cause" may not be exact here. I think it may not be this specific rule($ ) but rather some "invalid" rule that causes it.
I can't reproduce that on master.
@justpretending Don't know what to tell you - I can reproduce it on three different systems at or near master, and so can three other people (two of which stumbled upon it totally independently).
Also, your commands are incomplete.
They weren't intended to be complete - just enough to provide the context around the problematic flag. I've updated the post to clarify.
hashcat -a 1 /path/to/file1 /path/to/file2 -j '$ ' --outfile /otherfilename [etc]
You aren't going to tell us you put the hashlist after the left and right wordlists?
@justpretending
You aren't going to tell us you put the hashlist after the left and right wordlists?
No. And your comments seem slightly aggressive, and/or seem to imply that this is my first time using hashcat or reporting a hashcat issue. Why is that?
I mean, don't get me wrong - I could still be the problem. :grin: I'm totally prepared to find out that my shell / script stuff might be causing some kind of mis-escaping or quoting problem. Other very similar attacks that don't try to inject a space between two wordlists, but are otherwise identical (for example, injecting a non-space character), work just fine. (This is how I know the files are not empty). So it could totally be a shell thing. And using -j '$\x20' works fine. so that's another strong indicator of a shell or quoting problem.
So it could be an error on my side. But even if so, then the error message would still be inaccurate - because the file is not empty.
The fix for this bug should be for whatever is going wrong - even if it's user error - to no not be directly inaccurate. Even if the "fixed" error is vague or generic, that will be an improvement. :grin:
And your comments seem slightly aggressive
Sorry for that. Must be a language barrier.
and/or seem to imply that this is my first time using hashcat or reporting a hashcat issue. Why is that?
I'd expect a seasoned reporter to provide a complete command along with the contents of file1 and file2 so that anyone could reproduce the issue. Also, you keep talking of shells, but still haven't told us what shell you are using.
I'd expect a seasoned reporter to provide a complete command along with the contents of file1 and file2 so that anyone could reproduce the issue. Also, you keep talking of shells, but still haven't told us what shell you are using.
I'm not sure who the "us" is in this context, but to be transparent, you are not the target audience of this issue. Instead, you've stepped into the middle of an existing discussion for which this bug is just a public artifact. The issue is already in front of the people who need to see it. If they need more information, they will be happy to ask, and I'll be happy to provide it.
Reproduced this error in Windows Terminal using the following commands:
hashcat -m 0 -a 1 <MD5 Hash> <wordlist.txt> <wordlist.txt> -j '$-'
hashcat -m 0 -a 1 <MD5 Hash> <wordlist.txt> <wordlist.txt> --rule-left='$-'
hashcat -m 0 -a 1 <hash.txt> <wordlist.txt> <wordlist.txt> -j '$-'
hashcat -m 0 -a 1 <MD5 Hash> <wordlist.txt> <wordlist_different_file.txt> -j '$-'
hashcat -m 0 -a 1 <MD5 Hash> <wordlist_different_file.txt> <wordlist_different_file.txt> -j '$-'
All had the same issue. Further, it persisted into cmd.exe. HOWEVER, it did not follow me into Powershell. This leads me to believe that there is an issue escaping one of the characters following -j. I couldn't tell you what the issue was, but I am inclined to report it as a hashcat issue, since the rule specifier does not rightly have anything to do with the text file passed as the first argument, and as OP already posted, the text file is not empty.
No problems on a Linux command line isolate this to Windows users, but for those of us who are cracking on host hardware with a decent GPU, this does make a significant issue. Thanks much to the devs for taking a look, and I hope this helps some.
Reproduced this error in Windows Terminal using the following commands:
hashcat -m 0 -a 1 <MD5 Hash> <wordlist.txt> <wordlist.txt> -j '$-'hashcat -m 0 -a 1 <MD5 Hash> <wordlist.txt> <wordlist.txt> --rule-left='$-'hashcat -m 0 -a 1 <hash.txt> <wordlist.txt> <wordlist.txt> -j '$-'hashcat -m 0 -a 1 <MD5 Hash> <wordlist.txt> <wordlist_different_file.txt> -j '$-'hashcat -m 0 -a 1 <MD5 Hash> <wordlist_different_file.txt> <wordlist_different_file.txt> -j '$-'All had the same issue. Further, it persisted into cmd.exe. HOWEVER, it did not follow me into Powershell. This leads me to believe that there is an issue escaping one of the characters following
-j. I couldn't tell you what the issue was, but I am inclined to report it as a hashcat issue, since the rule specifier does not rightly have anything to do with the text file passed as the first argument, and as OP already posted, the text file is not empty.No problems on a Linux command line isolate this to Windows users, but for those of us who are cracking on host hardware with a decent GPU, this does make a significant issue. Thanks much to the devs for taking a look, and I hope this helps some.
Also, for reference, I'm using version 6.2.6, so this may already be resolved...
Can reproduce in zsh (hashcat v6.2.6)
hashcat hash.txt -m 1700 -a 1 rockyou.txt rockyou.txt -j "$_"
This produces the same confusing error: rockyou.txt: empty file.
However, escaping the $ with a forward slash ( \ ) :
hashcat hash.txt -m 1700 -a 1 rockyou.txt rockyou.txt -j "\$_"
solves the problem, and runs as expected.
