[Bug 0.14] Wrong hash target [Visual Bug]

[themask]

Hello

When i run this :

./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.

[undeath]

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

[Hash-IT]

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 ?

[themask]

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

[undeath]

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.

[themask]

Sorry i meant to say "oclHashcat-lite".

[undeath]

what i said applies to every version of oclhashcat-* too.

[epixoip]

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.

[epixoip]

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?

[themask]

You right! However also in the Outfile, the hash is bswapped.

f9d743881d21162463b9ebe981e24cff78289325:626172:foo