Hashcat freezes

[gentl]

Hi! 
I have Ubuntu 16 with installed Cuda 10.2 and Last Nvidia drivers - geforce 440.64 
The system has 16 gb RAM , Core i3  and  7x1080ti
I compiled Hashcat from last github source. And have a strange bug:

CUDA API is using.

- I have dictionary splitted on files by 512mb.
- If i using -m 21700 or -m 21800  - hashcat always  freezes on 70-86% progress in same files (for example always on dict4 and dict9). When i press S for status it just print in cmd line and nothing happend. Then i should use cntrl-c to stop proccess. (look attachment)
- If i use ./hashcat --restore   after abort.  It freezes too.
- I tried to use different hash's - but no results.
- If i using -m 11300  - i haven't any problems.
 

./hashcat -a 0 -m 21700 /mnt/hdd/hash/ehash.txt  /mnt/hdd/pass.txt.004 

How can i catch where the bug ?

[philsmd]

try to pinpoint the problem by testing only the second half of the file... then again the half (subset) of the file that leads to the freeze etc until you find when and why it freezes.

Did you try to use OpenCL instead of CUDA (to show all the backends/devices use: hashcat -I), e.g. with hashcat -d 2 ... (depends on your system and the -I output, of course),

We actually have a similar report here: https://github.com/hashcat/hashcat/issues/2341

but we were still unable to reproduce it.

It would be great if you can generate a new hash (no funds etc attached to that wallet i.e. an empty wallet) for which we know the password and it also leads to the freezes with a specific word list and/or setup (Nvidia GPU only maybe).

[gentl]

sure, will make more deep investigation.
Just tested on win7 x64 with hashcat-5.1.0+1736 build. 
Cuda 10.2  Drivers 440. 5 x 1070  gpu
Same file freeze on 91%
------------------
Just tried to use OpenCl on Ubuntu - freezed on 75%

[gentl]

try to pinpoint the problem by testing only the second half of the file... then again the half (subset) of the file that leads to the freeze etc until you find when and why it freezes.

Did you try to use OpenCL instead of CUDA (to show all the backends/devices use: hashcat -I), e.g. with hashcat -d 2 ... (depends on your system and the -I output, of course),

We actually have a similar report here: https://github.com/hashcat/hashcat/issues/2341

but we were still unable to reproduce it.

It would be great if you can generate a new hash (no funds etc attached to that wallet i.e. an empty wallet) for which we know the password and it also leads to the freezes with a specific word list and/or setup (Nvidia GPU only maybe).

I started to split dict file until i had files with one word.  So here is file with word which makes hashcat freeze ..
I have no ideas how this word can do that...

[philsmd]

Can you please test if this also happens with the example hash from: https://hashcat.net/wiki/example_hashes

I think that it could easily be that if there is some problem it has to do with the combination of hash and word (not just word alone)

That means that we would need to have an example hash that you can provide with known password and which also leads to the same problem (in fact we would always need the combination of hash, word and setup - Nvidia/CUDA/OpenCL etc).

[undeath]

I can confirm something is amiss when using the wordlist provided by gentl above.

Code:

hashcat -m 21700 /tmp/example.21700 /tmp/123.txt

shows the status prompt but does not react on pressing "s" and did not complete after several minutes

Doing the same with "echo test > /tmp/test" completed in less than one minute.

Code:

hashcat (v5.1.0-1736-gb1d5f92c) starting...

OpenCL Info:
============

OpenCL Platform ID #1
  Vendor..: Intel(R) Corporation
  Name....: Intel(R) OpenCL
  Version.: OpenCL 1.2 LINUX

  Backend Device ID #1
    Type...........: CPU
    Vendor.ID......: 8
    Vendor.........: Intel(R) Corporation
    Name...........: AMD Ryzen 5 1600 Six-Core Processor
    Version........: OpenCL 1.2 (Build 117)
    Processor(s)...: 12
    Clock..........: 0
    Memory.Total...: 32121 MB (limited to 8030 MB allocatable in one block)
    Memory.Free....: 32057 MB
    OpenCL.Version.: OpenCL C 1.2
    Driver.Version.: 1.2.0.117

[philsmd]

interesting. good to know how to reproduce this. I think I'm now also able to reproduce this (and therefore also this: https://github.com/hashcat/hashcat/issues/2341) problem...

I'm currently testing a fix like this, which seems promising (rm -rf kernels/ for testing):

Code:

diff --git a/OpenCL/inc_ecc_secp256k1.cl b/OpenCL/inc_ecc_secp256k1.cl
index f9ec3419..9d56d4e9 100644
--- a/OpenCL/inc_ecc_secp256k1.cl
+++ b/OpenCL/inc_ecc_secp256k1.cl
@@ -512,6 +512,23 @@ DECLSPEC void mod_512 (u32 *n)

     // substract (a -= r):

+    if ((r[ 0] == 0) &&
+        (r[ 1] == 0) &&
+        (r[ 2] == 0) &&
+        (r[ 3] == 0) &&
+        (r[ 4] == 0) &&
+        (r[ 5] == 0) &&
+        (r[ 6] == 0) &&
+        (r[ 7] == 0) &&
+        (r[ 8] == 0) &&
+        (r[ 9] == 0) &&
+        (r[10] == 0) &&
+        (r[11] == 0) &&
+        (r[12] == 0) &&
+        (r[13] == 0) &&
+        (r[14] == 0) &&
+        (r[15] == 0)) break;
+
     r[ 0] = a[ 0] - r[ 0];
     r[ 1] = a[ 1] - r[ 1];
     r[ 2] = a[ 2] - r[ 2];

or (only makes sense for constant time):

Code:

diff --git a/OpenCL/inc_ecc_secp256k1.cl b/OpenCL/inc_ecc_secp256k1.cl
index f9ec3419..ff877ca1 100644
--- a/OpenCL/inc_ecc_secp256k1.cl
+++ b/OpenCL/inc_ecc_secp256k1.cl
@@ -512,6 +512,9 @@ DECLSPEC void mod_512 (u32 *n)

     // substract (a -= r):

+    if ((r[ 0] | r[ 1] | r[ 2] | r[ 3] | r[ 4] | r[ 5] | r[ 6] | r[ 7] |
+         r[ 8] | r[ 9] | r[10] | r[11] | r[12] | r[13] | r[14] | r[15]) == 0) break;
+
     r[ 0] = a[ 0] - r[ 0];
     r[ 1] = a[ 1] - r[ 1];
     r[ 2] = a[ 2] - r[ 2];

I will ask atom if this fix is good enough. thank you very much in the meantime

[gentl]

Hey how can i fix it or when u will add commit with fix =)

[philsmd]

in general a patch can be applied by just using

Code:

git apply the_patch.diff

the "patch" utility on linux etc will work the same way.

The pull request was already opened on github: https://github.com/hashcat/hashcat/pull/2350

I think a little bit of patience is always desirable, because developers (amongs others) also need to make sure that a candidate patch/fix doesn't break other things (quality assurance, unit tests etc).

[gentl]

I just git clone fresh hashcat.
Hashcat freezes as usual =(