It looks like hashcat 4.0.1 is slightly off when printing the output for the DES ECB password. Attempting to crack DES ECB I get the following output:
root@ht:~/hashcat# echo hashcat1 | tools/test.pl passthrough 14000
24ac458a29cc3241:5337554801018442
./hashcat64.bin -m 14000 test2.des -a 3 ?a?a?a?a?a?a?a?a --keep-guessing
24ac458a29cc3241:5337554801018442:haricat1
On:
# ./hashcat64.bin -V
v4.0.1
That's perfectly fine for DES. In DES both keys "haricat1" and "hashcat1" are the same.
(02-15-2018, 01:55 PM)atom Wrote: [ -> ]That's perfectly fine for DES. In DES both keys "haricat1" and "hashcat1" are the same.
TIL
haricat is hashcat's lesser known cousin
It's a family reunion!
Code:
$ hashcat --quiet --potfile-path=/dev/null --keep-guessing -m 14000 test.hash -a 3 -1 '`012abcdghirstu' ?1?1?1?1?1?1?1?1
24ac458a29cc3241:5337554801018442:haricat0
24ac458a29cc3241:5337554801018442:haricau0
24ac458a29cc3241:5337554801018442:harhbau1
24ac458a29cc3241:5337554801018442:haricat1
24ac458a29cc3241:5337554801018442:h`ricat0
24ac458a29cc3241:5337554801018442:h`ricau0
24ac458a29cc3241:5337554801018442:h`ricau1
24ac458a29cc3241:5337554801018442:h`ricat1
I think some of them may be Klingon.
I was surprised to see that there's a little variation between --keep-guessing runs; why is that?
Code:
$ hashcat --quiet --potfile-path=/dev/null --keep-guessing -m 14000 test.hash -a 3 -1 '`012abcdghirstu' ?1?1?1?1?1?1?1?1
24ac458a29cc3241:5337554801018442:haricat0
24ac458a29cc3241:5337554801018442:haricau0
24ac458a29cc3241:5337554801018442:haricau1
24ac458a29cc3241:5337554801018442:harhbat1
24ac458a29cc3241:5337554801018442:h`ricat0
24ac458a29cc3241:5337554801018442:h`rhbau0
24ac458a29cc3241:5337554801018442:h`ricau1
24ac458a29cc3241:5337554801018442:h`ricat1
(yeah, it's a lazy charset, either side of the character - so sue me)
(02-16-2018, 06:07 AM)royce Wrote: [ -> ]It's a family reunion!
Code:
$ hashcat --quiet --potfile-path=/dev/null --keep-guessing -m 14000 test.hash -a 3 -1 '`012abcdghirstu' ?1?1?1?1?1?1?1?1
24ac458a29cc3241:5337554801018442:haricat0
24ac458a29cc3241:5337554801018442:haricau0
24ac458a29cc3241:5337554801018442:harhbau1
24ac458a29cc3241:5337554801018442:haricat1
24ac458a29cc3241:5337554801018442:h`ricat0
24ac458a29cc3241:5337554801018442:h`ricau0
24ac458a29cc3241:5337554801018442:h`ricau1
24ac458a29cc3241:5337554801018442:h`ricat1
I think some of them may be Klingon.
I was surprised to see that there's a little variation between --keep-guessing runs; why is that?
Code:
$ hashcat --quiet --potfile-path=/dev/null --keep-guessing -m 14000 test.hash -a 3 -1 '`012abcdghirstu' ?1?1?1?1?1?1?1?1
24ac458a29cc3241:5337554801018442:haricat0
24ac458a29cc3241:5337554801018442:haricau0
24ac458a29cc3241:5337554801018442:haricau1
24ac458a29cc3241:5337554801018442:harhbat1
24ac458a29cc3241:5337554801018442:h`ricat0
24ac458a29cc3241:5337554801018442:h`rhbau0
24ac458a29cc3241:5337554801018442:h`ricau1
24ac458a29cc3241:5337554801018442:h`ricat1
(yeah, it's a lazy charset, either side of the character - so sue me)
Klingon family reunions are the best type, lol
Back on topic, anyone know why this is?
Because in DES it's a 56 bit key, not 64 bit. One bit gets dropped, therefore 0x30 and 0x31 is the same, for example.
But why does the cracking approach sometimes find one first, and sometimes find the other one first? I would expect the attack to be deterministic and reproducible.
The high amount of multithreading causes non-determinism regarding the order of candidates processed.
Normally, yes. But with --keep-guessing, I would expect all possibilities to be exhausted. In different output order, but all represented.