Session..........: hashcat
Status...........: Running
Hash.Type........: Bitcoin/Litecoin wallet.dat
Hash.Target......: $bitcoin$96$d011a1b6a8d675b7a36d0cd2efaca32a9f8dc1d...760525
Time.Started.....: Fri Jan 10 16:51:04 2020 (3 secs)
Time.Estimated...: Tue Jan 14 22:19:39 2020 (4 days, 5 hours)
Guess.Base.......: File (rockyou.txt), Left Side
Guess.Mod........: File (rules/best64.rule), Right Side
Speed.#1.........: 4005 H/s (5.91ms) @ Accel:64 Loops:16 Thr:256 Vec:1
Recovered........: 0/1 (0.00%) Digests, 0/1 (0.00%) Salts
Progress.........: 0/1463127168 (0.00%)
Rejected.........: 0/0 (0.00%)
Restore.Point....: 0/14344384 (0.00%)
Restore.Sub.#1...: Salt:0 Amplifier:0-1 Iteration:7136-7152
Candidates.#1....: 123456## nothing, reverse, case... base stuff -> dolphins6## nothing, reverse, case... base stuff
Hardware.Mon.#1..: Temp: 37c Fan: 23% Util: 97% Core:2075MHz Mem:4104MHz Bus:16
That i mark "Candidates....." the sign "->" means frst part most to be equal to the second?
it's just showing you a whole set (a range) of password candidates. The displayed password candidates in the "Candidates.#" line within the status output are neither meant to be complete, nor can they show you each and every mangled password candidate. They are only indicative such that the users see *some* of the passwords (the first password from a huge set and the last password from a huge set).
If you want to see all of them, you could use this:
Code:
hashcat --stdout -a 0 -r rules/best64.rule rockyou.txt
This --stdout feature can be used for troubleshooting / debugging too, it will include the whole set of password candidates (if you use the correct / same parameters as with the command including the cracking, without the --stdout, but with the hash file).
of course the --stdout output can be very large and therefore you might need to either filter ("grep" in linux) it or limit it ("head"/"more"/"tail" in linux) etc
(07-20-2020, 01:46 PM)philsmd Wrote: [ -> ]it's just showing you a whole set (a range) of password candidates. The displayed password candidates in the "Candidates.#" line within the status output are neither meant to be complete, nor can they show you each and every mangled password candidate. They are only indicative such that the users see *some* of the passwords (the first password from a huge set and the last password from a huge set).
If you want to see all of them, you could use this:
Code:
hashcat --stdout -a 0 -r rules/best64.rule rockyou.txt
This --stdout feature can be used for troubleshooting / debugging too, it will include the whole set of password candidates (if you use the correct / same parameters as with the command including the cracking, without the --stdout, but with the hash file).
of course the --stdout output can be very large and therefore you might need to either filter ("grep" in linux) it or limit it ("head"/"more"/"tail" in linux) etc
Thank you for you answer, understand all you say and you advice (im stating using linux, just use VB, for now im using windows, anyway im starting with all very new).
Now ask you something:
When the 2 parts before and after "->" is equal what that mean?
in general, it only happens that both the left and right part of the "->" sign are equal if you are testing with only one password candidate... but it could also happen that by chance several (mangled with rules etc) password candidates are equal and therefore the set of password candidates that you are trying are not unique.
With fast hashes it's not a huge problem if not ALL of the password candidates are unique, but for slow hashing algorithms like bcrypt/scrypt/pbkdf2 with high cost factors/iterations etc, it could matter a lot and therefore the user is responsible to avoid duplicate input by using more clever attack types or better rules that do not produce many duplicates.
(07-20-2020, 02:12 PM)philsmd Wrote: [ -> ]in general, it only happens that both the left and right part of the "->" sign are equal if you are testing with only one password candidate... but it could also happen that by chance several (mangled with rules etc) password candidates are equal and therefore the set of password candidates that you are trying are not unique.
With fast hashes it's not a huge problem if not ALL of the password candidates are unique, but for slow hashing algorithms like bcrypt/scrypt/pbkdf2 with high cost factors/iterations etc, it could matter a lot and therefore the user is responsible to avoid duplicate input by using more clever attack types or better rules that do not produce many duplicates.
Thank you very much for take a time to teach me, i understand all that you say me.