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

Hashcat does not recognize correct password from the list #1695

Open
testersz opened this Issue Sep 18, 2018 · 3 comments

Comments

Projects
None yet
3 participants
@testersz

testersz commented Sep 18, 2018

I posted this issue before under Issue #1582, but I'm unable to reopen it.
#1582
So I'm creating new issue

When cracking IPMI and RAdmin v2.2 hashes I observed following:

If dictionary does not contain correct password - nothing found, that is ok;
If dictionary contain correct password - Hashcat display first password from the list as correct password.
I'm using:
Linux kali 4.15.0-kali3-686-pae #1 SMP Debian 4.15.17-1kali1 (2018-04-25) i686 GNU/Linux
hashcat (v4.1.0)
haschat (v4.2.1)
Is there some explanation or solution?

Here is hashes used in test
Admin:f5e6da01af01000097a42cf27356aef866ef545ac4b9a762aaef010ca29c37ae40f69ebb3a74ecdf00000000000000000000000000000000140541646d696e:aa42b3a4cccc9ed949c94794dd0cc046e10128ce
password: pentest
admin:c5a53db2d854061a5ae8c28acc2a077b85859ede6ea952be1d2a00005a0b0000a74800008247000035383339313447423830333334354a44140561646d696e:d82a44aa893b842ca9659f6877f3c5c46374d607
password: 12345678

Wordlist:
123
1234
test
pentest
12345678
123456
qwerty

2)executing hashcat
hashcat -m 7300 -o crack.txt --username hashes/IPMI.list lists/passwords.list

Results:

using this dictionary, I can get result cracked, and shows "123" (Always show first line in wordlist - if wordlist contain correct word) is suitable for the hashes
if we change "pentest" to "pentest1" in dictionary, and set --potfiles-disable
answer cracked only for one hash, and also "123"
if we change "12345678" to "112345678" (No correct passwords in the list for hashes given)
result is Exhausted Recovered (0/2)

How can I troubleshoot this problem? Is there any option to launch it in debug mode to find the reason of this issue?

@testersz

This comment has been minimized.

Show comment
Hide comment
@testersz

testersz Sep 18, 2018

Also tested on:
Linux kali 4.17.0-kali1-686-pae #1 SMP Debian 4.17.8-1kali1 (2018-07-24) i686 GNU/Linux

testersz commented Sep 18, 2018

Also tested on:
Linux kali 4.17.0-kali1-686-pae #1 SMP Debian 4.17.8-1kali1 (2018-07-24) i686 GNU/Linux

@scaery

This comment has been minimized.

Show comment
Hide comment
@scaery

scaery Sep 23, 2018

Could this be somehow related to #1683 ???

I got the same issue. Can you try Kali 2018.2 live iso (Kernel: Linux kali 4.15.0-kali2-686-pae) and confirm. Then we can address this issue back to the right direction. Also, try a x64 machine as well.

scaery commented Sep 23, 2018

Could this be somehow related to #1683 ???

I got the same issue. Can you try Kali 2018.2 live iso (Kernel: Linux kali 4.15.0-kali2-686-pae) and confirm. Then we can address this issue back to the right direction. Also, try a x64 machine as well.

@deargle

This comment has been minimized.

Show comment
Hide comment
@deargle

deargle Oct 3, 2018

I found this same problem yesterday, #1709 replicated on live iso (in virtualized environment).

In my case, it isnt the first word per se, but rather, the first word from the current block of candidates being tested.

PS -- issue not present on x64

deargle commented Oct 3, 2018

I found this same problem yesterday, #1709 replicated on live iso (in virtualized environment).

In my case, it isnt the first word per se, but rather, the first word from the current block of candidates being tested.

PS -- issue not present on x64

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment