DES ECB error

[Phil]

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

[atom]

That's perfectly fine for DES. In DES both keys "haricat1" and "hashcat1" are the same.

[Phil]

That's perfectly fine for DES. In DES both keys "haricat1" and "hashcat1" are the same.

TIL

[epixoip]

haricat is hashcat's lesser known cousin

[royce]

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)

[SebastianG33]

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?

[atom]

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.

[royce]

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.

[undeath]

The high amount of multithreading causes non-determinism regarding the order of candidates processed.

[royce]

Normally, yes. But with --keep-guessing, I would expect all possibilities to be exhausted. In different output order, but all represented.