New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wrong candidates generating for masks with few devices, --stdout and -o (hashcat 6.2.6 only bug in Windows) #3944
Comments
Can be caused by #3941 ? |
It's extremely unlikely that #3941 has anything to do with this. More likely there is an issue with your drivers or iGPU or similar. Why are you selecting the devices at all when running --stdout? There's no need to select a computing device as it will not make it faster. I'd suggest letting hashcat select the default device on it's own and see if that changes the results. That said, if that does break things, we may need to determine why and either fix or limit this behavior. |
Could you retest without -o and instead use > to redirect the output? I have some suspicion that this may be related to a bug that was recently worked on. |
It's not likely. As I described above, this bug issued on different hardwares.
I didn't but hashcat chooses 2 devices (discrete and integrated GPUs) by default issuing the bug. So I described the explicit example.
As I told in the "Additional context" section, piping to a file (>) produces the correct result :) So, maybe this bug should be tested after fixing that recent bug :) |
Ahh thank you, I should read more carefully, I missed those notes. I was able to reproduce the issue with the latest master so I don't think this is related to the issue I was guessing initially.
This is a bit strange, perhaps a race condition or other contention on accessing the file? |
Yeah, seems to be. Furthermore, 6.2.6 and Windows only (not sure) |
I just did some version testing, it appears that the minor releases 6.2.5 and 6.2.4 both also contain this bug and produce bad outputs in that specific condition. However 6.2.3 and further back to 6.1.1 at least do not appear to contain this issue and exhibit expected behavior. This will likely have been introduced some time after 6.2.3. |
Describe the bug
There're wrong candidates in output with few devices,
--stdout
and-o
options for some masks (hashcat 6.2.6 only bug in Windows).To Reproduce
Discrete GPU + Integrated Graphics:
hashcat.exe -d 1,3 -a 3 --markov-disable --stdout "02?d?d?d?d?d?d?d" -o "test.txt"
Got result with only a part of candidates range
020000000...029999999
and a lot of wrong candidates like0
,00
,00188350
, a mix of\r
,\n
and\r\n
newline-styles. The result file differs each time you delete the file and run the command again (thread-race while output?).Expected behavior
The result file, containing candidates
020000000...029999999
like with-d 1
:hashcat.exe -d 1 -a 3 --markov-disable --stdout "02?d?d?d?d?d?d?d" -o "test.txt"
Hardware/Compute device (please complete the following information):
Hashcat version (please complete the following information):
Diagnostic output compute devices:
Additional context
The problem doesn't appear when only one device is used, the mask is shorter, when piping to a file is used instead of
-o
,--stdout
isn't used, older or linux-version of hashcat is used.The text was updated successfully, but these errors were encountered: