Hello
When i run this :
Quote:./oclHashcat-lite64.bin E4DACA7666B28D9CD4C32649F6E66BE868EB29EF:FFEEDD -m110 ?d?d?d?d?d?d?d?a?d?a?d?d --pw-min=10 --pw-max=12 --hex-salt --outfile-format=7 -ourban.txt
And hashcat use a corrupted hash instead.
Hash.Target....: 76cadae49c8db2664926c3d4e86be6f6ef29eb68:ffeedd
I don't think that this is normal.
can reproduce
Code:
../oclHashcat-lite-0.14/oclHashcat-lite64.bin deadbeefdeadbeefdeadbeefdeadbeefdeadbeef:abcdef -m110 "?d?d?d?d?d?d?d?a?d?a?d?d" --pw-min=10 --pw-max=12 --hex-salt
oclHashcat-lite v0.14 by atom starting...
Password lengths: 10 - 12
Watchdog: Temperature abort trigger set to 90c
Watchdog: Temperature retain trigger set to 80c
Device #1: Cypress, 512MB, 725Mhz, 18MCU
[s]tatus [p]ause [r]esume [q]uit => s
Session.Name...: oclHashcat-lite
Status.........: Running
Hash.Target....: efbeaddeefbeaddeefbeaddeefbeaddeefbeadde:abcdef
Hash.Type......: sha1($pass.$salt)
Time.Started...: 0 secs
Time.Estimated.: Tue Feb 5 11:09:22 2013 (10 mins, 25 secs)
Plain.Mask.....: ?d?d?d?d?d?d?d?a?d?a
Plain.Text.....: ****140012
Plain.Length...: 10
Progress.......: 1216512000/902500000000 (0.13%)
Speed.GPU.#1...: 1440.4M/s
HWMon.GPU.#1...: 0% Util, 50c Temp, 35% Fan
(02-05-2013, 11:46 AM)undeath Wrote: [ -> ]deadbeefdeadbeefdeadbeefdeadbeefdeadbeef:abcd
I think in this example, we witness a disturbing insight into the mind of undeath.
Most people would write something like testtesttest:abcd.
Any professional psychologists care to comment ?
I think i found another bug. When i use a mask with for example "?d?d?d?d?d?d?d" , hashcat test random value instead of straight incremental [000001,000002,000003,....].
Plain.Text.....: ****000410
Plain.Text.....: ****400120
Plain.Text.....: ****340043
Plain.Text.....: ****271712
Note : [I disabled Markov] with the same effect
this is not related to this bug and should therefore be in a new thread. Also hashcat works heavily multithreaded, unless you run on cpu with -n1 it will always "mix" the results.
Sorry i meant to say "oclHashcat-lite".
what i said applies to every version of oclhashcat-* too.
This is a visual bug only, it still finds the correct password. What you are seeing is not a "corrupt" hash, but rather the byte-swapped hash (SHA1 is big endian, x86 is little endian.) This is actually what the hash looks like internally. Normally it is then byte-swapped back for display purposes, and that is what's not being done.
Here's some code to illustrate what is happening inside Hashcat:
Code:
#include <stdio.h>
#include <stdint.h>
int main(int argc, char **argv)
{
uint32_t hash[5];
uint32_t bswap_hash[5];
sscanf(argv[1], "%08x%08x%08x%08x%08x", &hash[0], &hash[1], &hash[2], &hash[3], &hash[4]);
int i;
for (i=0; i < 5; i++) bswap_hash[i] = __builtin_bswap32(hash[i]);
printf("%08x%08x%08x%08x%08x\n", bswap_hash[0], bswap_hash[1], bswap_hash[2], bswap_hash[3], bswap_hash[4]);
}
And when we run it...
Code:
epixoip@butters:~$ cc -o bswap bswap.c
epixoip@butters:~$ echo -n 'foobar' | sha1sum
8843d7f92416211de9ebb963ff4ce28125932878 -
epixoip@butters:~$ ./bswap 8843d7f92416211de9ebb963ff4ce28125932878
f9d743881d21162463b9ebe981e24cff78289325
Verify it against hashcat...
Code:
epixoip@butters:~/oclHashcat-lite-0.14$ echo -n 'bar' | xxd -g 0 -ps
626172
epixoip@butters:~/oclHashcat-lite-0.14$ ./oclHashcat-lite64.bin -d 1 -m 110 --hex-salt 8843d7f92416211de9ebb963ff4ce28125932878:626172 ?l?l?l
oclHashcat-lite v0.14 by atom starting...
Password lengths: 1 - 54
Watchdog: Temperature abort trigger set to 90c
Watchdog: Temperature retain trigger set to 80c
Device #1: Tahiti, 2048MB, 925Mhz, 32MCU
Device #2: skipped by user
Device #3: skipped by user
f9d743881d21162463b9ebe981e24cff78289325:626172:foo
Session.Name...: oclHashcat-lite
Status.........: Cracked
Hash.Target....: f9d743881d21162463b9ebe981e24cff78289325:626172
Hash.Type......: sha1($pass.$salt)
See?
You right! However also in the Outfile, the hash is bswapped.
Quote:f9d743881d21162463b9ebe981e24cff78289325:626172:foo