Hashcat not getting any candidates from maskprocessor

[HomeSen]

Hi hashcats.

I have a weird issue with hashcat in combination with mask processor: When piping mp's output into hashcat on my cracking station, hashcat just initializes and then immediately stops with the message "Exhausted". On my local laptop, the same command works without issues, but it's rather slow due to the mobile GPU

I need to use mp, since I want to break a rather weird SHA1 usage: The vendor truncates the entered password at 16 chars and then copies it into a char[16] that gets initialized with NULL bytes. Since this is different from a normal SHA1, I wrote a rule that mimics the behavior. And since the password is probably just some random letters and digits, and none of my (rather huge) wordlists yielded any results, I have to use a mask/bruteforce attack.
Unfortunately, hashcat doesn't allow combining mask attacks with rules files.

Anyways, here is the used command and output:

Code:

$ mp64 -i 1:8 ?a?a?a?a?a?a?a?a | hashcat -O -m 100 --status --status-timer 30 --stdin-timeout-abort 60 uart_sha1.txt -r pad_null-16.rule
hashcat (v5.1.0-1118-gede3ac9) starting...

CUDA API (CUDA 10.1)
====================
* Device #1: GeForce GTX 1080 Ti, 11178 MB, 28MCU
* Device #2: GeForce GTX 1080 Ti, 11178 MB, 28MCU
* Device #3: GeForce GTX 1070, 8119 MB, 15MCU
* Device #4: GeForce GTX 1070, 8119 MB, 15MCU

OpenCL API (OpenCL 1.2 CUDA 10.1.152) - Platform #1 [NVIDIA Corporation]
========================================================================
* Device #5: GeForce GTX 1080 Ti, skipped
* Device #6: GeForce GTX 1080 Ti, skipped
* Device #7: GeForce GTX 1070, skipped
* Device #8: GeForce GTX 1070, skipped

OpenCL API (OpenCL 2.0 ) - Platform #2 [Intel(R) Corporation]
=============================================================
* Device #9: Intel(R) Xeon(R) CPU E5-2609 v4 @ 1.70GHz, skipped

Hashes: 1 digests; 1 unique digests, 1 unique salts
Bitmaps: 16 bits, 65536 entries, 0x0000ffff mask, 262144 bytes, 5/13 rotates
Rules: 1

Applicable optimizers:
* Optimized-Kernel
* Zero-Byte
* Precompute-Init
* Early-Skip
* Not-Salted
* Not-Iterated
* Single-Hash
* Single-Salt
* Raw-Hash

Minimum password length supported by kernel: 0
Maximum password length supported by kernel: 31

Watchdog: Temperature abort trigger set to 90c

Host memory required for this attack: 4675 MB

Starting attack in stdin mode...

Session..........: hashcat
Status...........: Exhausted
Hash.Name........: SHA1
Hash.Target......: 554beec588aa530c6723ffedb0e34a8778b1b6dd
Time.Started.....: Fri May 31 09:57:12 2019 (1 sec)
Time.Estimated...: Fri May 31 09:57:13 2019 (0 secs)
Guess.Base.......: Pipe
Guess.Mod........: Rules (pad_null-16.rule)
Speed.#1.........:        0 H/s (0.00ms) @ Accel:128 Loops:1 Thr:1024 Vec:1
Speed.#2.........:        0 H/s (0.00ms) @ Accel:128 Loops:1 Thr:1024 Vec:1
Speed.#3.........:        0 H/s (0.00ms) @ Accel:256 Loops:1 Thr:1024 Vec:1
Speed.#4.........:        0 H/s (0.00ms) @ Accel:256 Loops:1 Thr:1024 Vec:1
Speed.#*.........:        0 H/s
Recovered........: 0/1 (0.00%) Digests, 0/1 (0.00%) Salts
Progress.........: 0
Rejected.........: 0
Restore.Point....: 0
Restore.Sub.#1...: Salt:0 Amplifier:0-0 Iteration:0-1
Restore.Sub.#2...: Salt:0 Amplifier:0-0 Iteration:0-1
Restore.Sub.#3...: Salt:0 Amplifier:0-0 Iteration:0-1
Restore.Sub.#4...: Salt:0 Amplifier:0-0 Iteration:0-1
Candidates.#1....: [Copying]
Candidates.#2....: [Copying]
Candidates.#3....: [Copying]
Candidates.#4....: [Copying]
Hardware.Mon.#1..: Temp: 48c Fan: 29% Util: 41% Core:1518MHz Mem:5005MHz Bus:16
Hardware.Mon.#2..: Temp: 57c Fan: 20% Util:  0% Core:1632MHz Mem:5005MHz Bus:16
Hardware.Mon.#3..: Temp: 40c Fan: 32% Util:  0% Core:1582MHz Mem:3802MHz Bus:16
Hardware.Mon.#4..: Temp: 36c Fan: 33% Util:  0% Core:1582MHz Mem:3802MHz Bus:16
Started: Fri May 31 09:56:59 2019
Stopped: Fri May 31 09:57:14 2019

The cracking station is running Ubuntu 16.04.6 LTS with latest updates applied and uses the NVIDIA driver 418.67 with Cuda 10.1.
As mentioned before: On a Windows 10 laptop with GeForce MX150 the same command works without issues

[philsmd]

did you try if the maskprocessor command works at all ? does the left part produce any candidates if used alone:
./mp64.bin -i 1:8 ?a?a?a?a?a?a?a?a

also the start is probably very small with length 1, only lengh 2, only length 3 etc so it might take some while, therefore I would suggest testing something like this (after you made sure that mp64 works as expected, see above):

Code:

mp64 ?a?a?a?a?a | ./hashcat --stdout

just to test if the input/output works (there might be a little bit of startup lag, because hashcat needs a couple of password candidates to start)


I think you could also just use a hashcat mask file (hcmask) for the padding. e.g. something like this:

Code:

00,?a?a?a?a?a?1?1?1?1?1?1?1?1?1?1?1
00,?a?a?a?a?a?a?1?1?1?1?1?1?1?1?1?1
00,?a?a?a?a?1?1?1?1?1?1?1?1?1?1?1?1
00,?a?a?a?1?1?1?1?1?1?1?1?1?1?1?1?1
00,?a?a?a?a?a?a?a?1?1?1?1?1?1?1?1?1
00,?a?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1
00,?a?a?1?1?1?1?1?1?1?1?1?1?1?1?1?1
00,?a?a?a?a?a?a?a?a?1?1?1?1?1?1?1?1

and the command would of course need to include the --hex-charset switch

Code:

hashcat -m 100 -a 3 --hex-charset hash.txt a.hcmask

where a.hcmask is the above hcmask file with all the 8 masks (random order or sorted, however you like ... normally the masks with a lot of ?a?a?a?a... at the beginning can accelerate much much more than others, because of larger keyspace and larger charset at the left side of the mask)

[HomeSen]

did you try if the maskprocessor command works at all ? does the left part produce any candidates if used alone:
./mp64.bin -i 1:8 ?a?a?a?a?a?a?a?a

Yes, this does produce the expected output.

also the start is probably very small with length 1, only lengh 2, only length 3 etc so it might take some while, therefore I would suggest testing something like this (after you made sure that mp64 works as expected, see above):

Code:

mp64 ?a?a?a?a?a | ./hashcat --stdout

just to test if the input/output works (there might be a little bit of startup lag, because hashcat needs a couple of password candidates to start)

For some reason, this doesn't give any output at all, but simply terminates after ~15s.

Using an hcmask seems to work though. So, I'll use that, instead.
Thank you for your help

[philsmd]

maybe whenever you find some free time, you could investigate this stdin problem further... did you try with a different terminal ? are you using linux ?

you could also try if "cat" (or windows "type" command) or echo on the left side work for you... I think this is some very weird stdin problem that may depend on your terminal etc.... but we would need to investigate this further where exactly this fails. The most likely thing is that hashcat receives some "EOF" byte. otherwise it shouldn't stop at all (it should keep waiting for input).

what happens with this command (attention: these commands are "wrong" on purpose ! left side is missing s.t. we see if hashcat is waiting):

Code:

./hashcat --stdout

(hashcat should wait kind of forever with this command)

or

Code:

./hashcat --status --status-timer 1 example0.hash

ATTENTION: both of these commands are kind of wrong, because they expect input from the pipe but there is no left side (this is just a test if hashcat is "waiting" for the input... do NOT use these commands in general)

update: the problem might depend on your OpenCL runtime for your CPU, try to uninstall it and test again. I saw some weird issues like this before and after removing the OpenCL Intel Core/Xeon Runtime, the problem didn't happen anymore... not sure why this is the case sometimes please test

[HomeSen]

maybe whenever you find some free time, you could investigate this stdin problem further... did you try with a different terminal ? are you using linux ?

Hashcat itself is running on Ubuntu Linux 16.04.6 LTS, and I tried connecting to the system via SSH from different OSes with different SSH clients. All show the same behavior.

It is also weird that Hashcat doesn't accept keypresses: [s]tatus [p]ause [b]ypass [c]heckpoint [q]uit
Neither of these works, but that had been the case ever since we got that machine. Unfortunately, I don't have physical access to the system, so I can't check if it's the same when directly accessing the console.

you could also try if "cat" (or windows "type" command) or echo on the left side work for you... I think this is some very weird stdin problem that may depend on your terminal etc.... but we would need to investigate this further where exactly this fails. The most likely thing is that hashcat receives some "EOF" byte. otherwise it shouldn't stop at all (it should keep waiting for input).

There seems to be an issue with stdin, using cat and a relatively large wordlist results in the same weird behavior:

Code:

$ cat /usr/share/wordlists/weakpass_2a | hashcat -m 100 /home/ptwa/uart_sha1.txt
hashcat (v5.1.0-1118-gede3ac9) starting...

CUDA API (CUDA 10.1)
====================
* Device #1: GeForce GTX 1080 Ti, 11178 MB, 28MCU
* Device #2: GeForce GTX 1080 Ti, 11178 MB, 28MCU
* Device #3: GeForce GTX 1070, 8119 MB, 15MCU
* Device #4: GeForce GTX 1070, 8119 MB, 15MCU

OpenCL API (OpenCL 1.2 CUDA 10.1.152) - Platform #1 [NVIDIA Corporation]
========================================================================
* Device #5: GeForce GTX 1080 Ti, skipped
* Device #6: GeForce GTX 1080 Ti, skipped
* Device #7: GeForce GTX 1070, skipped
* Device #8: GeForce GTX 1070, skipped

OpenCL API (OpenCL 2.0 ) - Platform #2 [Intel(R) Corporation]
=============================================================
* Device #9: Intel(R) Xeon(R) CPU E5-2609 v4 @ 1.70GHz, skipped

Hashes: 1 digests; 1 unique digests, 1 unique salts
Bitmaps: 16 bits, 65536 entries, 0x0000ffff mask, 262144 bytes, 5/13 rotates
Rules: 1

Applicable optimizers:
* Zero-Byte
* Early-Skip
* Not-Salted
* Not-Iterated
* Single-Hash
* Single-Salt
* Raw-Hash

Minimum password length supported by kernel: 0
Maximum password length supported by kernel: 256

ATTENTION! Pure (unoptimized) backend kernels selected.
Using pure kernels enables cracking longer passwords but for the price of drastically reduced performance.
If you want to switch to optimized backend kernels, append -O to your commandline.
See the above message to find out about the exact limits.

Watchdog: Temperature abort trigger set to 90c

Host memory required for this attack: 1766 MB

Starting attack in stdin mode...

Session..........: hashcat
Status...........: Exhausted
Hash.Name........: SHA1
Hash.Target......: 554beec588aa530c6723ffedb0e34a8778b1b6dd
Time.Started.....: Mon Jun  3 23:14:39 2019 (0 secs)
Time.Estimated...: Mon Jun  3 23:14:39 2019 (0 secs)
Guess.Base.......: Pipe
Speed.#1.........:        0 H/s (0.00ms) @ Accel:1024 Loops:1 Thr:64 Vec:1
Speed.#2.........:        0 H/s (0.00ms) @ Accel:1024 Loops:1 Thr:64 Vec:1
Speed.#3.........:        0 H/s (0.00ms) @ Accel:1024 Loops:1 Thr:64 Vec:1
Speed.#4.........:        0 H/s (0.00ms) @ Accel:1024 Loops:1 Thr:64 Vec:1
Speed.#*.........:        0 H/s
Recovered........: 0/1 (0.00%) Digests, 0/1 (0.00%) Salts
Progress.........: 0
Rejected.........: 0
Restore.Point....: 0
Restore.Sub.#1...: Salt:0 Amplifier:0-0 Iteration:0-1
Restore.Sub.#2...: Salt:0 Amplifier:0-0 Iteration:0-1
Restore.Sub.#3...: Salt:0 Amplifier:0-0 Iteration:0-1
Restore.Sub.#4...: Salt:0 Amplifier:0-0 Iteration:0-1
Candidates.#1....: [Copying]
Candidates.#2....: [Copying]
Candidates.#3....: [Copying]
Candidates.#4....: [Copying]
Hardware.Mon.#1..: Temp: 60c Fan: 28% Util: 38% Core:1480MHz Mem:5005MHz Bus:16
Hardware.Mon.#2..: Temp: 67c Fan: 32% Util: 40% Core:1518MHz Mem:5005MHz Bus:16
Hardware.Mon.#3..: Temp: 58c Fan: 32% Util: 15% Core:1506MHz Mem:3802MHz Bus:16
Hardware.Mon.#4..: Temp: 54c Fan: 33% Util:  9% Core:1506MHz Mem:3802MHz Bus:16
Started: Mon Jun  3 23:14:19 2019
Stopped: Mon Jun  3 23:14:40 2019

what happens with this command (attention: these commands are "wrong" on purpose ! left side is missing s.t. we see if hashcat is waiting):

Code:

./hashcat --stdout

(hashcat should wait kind of forever with this command)

It only waits for ~9s and then returns:

Code:

$ time hashcat --stdout

real    0m9.081s
user    0m4.048s
sys     0m4.960s

or

Code:

./hashcat --status --status-timer 1 example0.hash

ATTENTION: both of these commands are kind of wrong, because they expect input from the pipe but there is no left side (this is just a test if hashcat is "waiting" for the input... do NOT use these commands in general)

Same for that one:

Code:

$ hashcat --status --status-timer 1 uart_sha1.txt
hashcat (v5.1.0-1118-gede3ac9) starting...

CUDA API (CUDA 10.1)
====================
* Device #1: GeForce GTX 1080 Ti, 11178 MB, 28MCU
* Device #2: GeForce GTX 1080 Ti, 11178 MB, 28MCU
* Device #3: GeForce GTX 1070, 8119 MB, 15MCU
* Device #4: GeForce GTX 1070, 8119 MB, 15MCU

OpenCL API (OpenCL 1.2 CUDA 10.1.152) - Platform #1 [NVIDIA Corporation]
========================================================================
* Device #5: GeForce GTX 1080 Ti, skipped
* Device #6: GeForce GTX 1080 Ti, skipped
* Device #7: GeForce GTX 1070, skipped
* Device #8: GeForce GTX 1070, skipped

OpenCL API (OpenCL 2.0 ) - Platform #2 [Intel(R) Corporation]
=============================================================
* Device #9: Intel(R) Xeon(R) CPU E5-2609 v4 @ 1.70GHz, skipped

Hashfile 'uart_sha1.txt' on line 1 (554beec588aa530c6723ffedb0e34a8778b1b6dd): Token length exception
No hashes loaded.

Started: Mon Jun  3 22:43:13 2019
Stopped: Mon Jun  3 22:43:22 2019

update: the problem might depend on your OpenCL runtime for your CPU, try to uninstall it and test again. I saw some weird issues like this before and after removing the OpenCL Intel Core/Xeon Runtime, the problem didn't happen anymore... not sure why this is the case sometimes  please test

After uninstalling the "intel-opencl" and "intel-opencl-cpu" packages, I can "cat" wordlists into hashcat, again. And I can also request the current status, as well as checkpoints, etc.

Though using cat only yields ~1.3MHashes/s on those 4 GPUs in total for a plain SHA-1:

Code:

Session..........: hashcat
Status...........: Running
Hash.Name........: SHA1
Hash.Target......: 554beec588aa530c6723ffedb0e34a8778b1b6dd
Time.Started.....: Mon Jun  3 23:27:01 2019 (19 secs)
Time.Estimated...: Mon Jun  3 23:27:20 2019 (0 secs)
Guess.Base.......: Pipe
Speed.#1.........:   491.4 kH/s (6.99ms) @ Accel:1024 Loops:1 Thr:64 Vec:1
Speed.#2.........:   372.1 kH/s (7.00ms) @ Accel:1024 Loops:1 Thr:64 Vec:1
Speed.#3.........:   264.5 kH/s (5.50ms) @ Accel:1024 Loops:1 Thr:64 Vec:1
Speed.#4.........:   199.5 kH/s (5.45ms) @ Accel:1024 Loops:1 Thr:64 Vec:1
Speed.#*.........:  1327.5 kH/s

Using the hcmask, I get the ~30.000 fold of that:

Code:

Session..........: hashcat
Status...........: Running
Hash.Name........: SHA1
Hash.Target......: 554beec588aa530c6723ffedb0e34a8778b1b6dd
Time.Started.....: Mon Jun  3 23:09:42 2019 (3 mins, 0 secs)
Time.Estimated...: Mon Jun  3 23:40:41 2019 (27 mins, 59 secs)
Guess.Mask.......: ?a?a?a?a?a?a?a?1?1?1?1?1?1?1?1?1 [16]
Guess.Charset....: -1 00, -2 Undefined, -3 Undefined, -4 Undefined 
Guess.Queue......: 1/3 (33.33%)
Speed.#1.........:  9181.0 MH/s (12.32ms) @ Accel:64 Loops:64 Thr:1024 Vec:1
Speed.#2.........:  9132.5 MH/s (12.54ms) @ Accel:64 Loops:64 Thr:1024 Vec:1
Speed.#3.........:  5917.2 MH/s (10.20ms) @ Accel:8 Loops:512 Thr:1024 Vec:1
Speed.#4.........:  6137.0 MH/s (9.83ms) @ Accel:8 Loops:512 Thr:1024 Vec:1
Speed.#*.........: 30367.5 MH/s

Or when using a wordlist, I still get the ~10.000 fold of what stdin mode gave me:

Code:

Session..........: hashcat
Status...........: Quit
Hash.Name........: SHA1
Hash.Target......: 554beec588aa530c6723ffedb0e34a8778b1b6dd
Time.Started.....: Mon Jun  3 23:34:10 2019 (8 secs)
Time.Estimated...: Mon Jun  3 23:34:21 2019 (3 secs)
Guess.Base.......: File (/usr/share/wordlists/insidepro)
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........:  3513.5 kH/s (6.92ms) @ Accel:1024 Loops:1 Thr:64 Vec:1
Speed.#2.........:  3627.4 kH/s (6.99ms) @ Accel:1024 Loops:1 Thr:64 Vec:1
Speed.#3.........:  3607.3 kH/s (5.46ms) @ Accel:1024 Loops:1 Thr:64 Vec:1
Speed.#4.........:  3597.8 kH/s (5.47ms) @ Accel:1024 Loops:1 Thr:64 Vec:1
Speed.#*.........: 14346.0 kH/s

So, looks like the Intel Open-CL packages have been the culprit. I'm not sure how or why they had such seemingly unrelated impacts, but at least I now got that sorted.
Thank you, once again, for all the help

[philsmd]

oh thanks for the confirmation. so my educated guess was spot on.

I actually saw a similar problem in the past... but it's soo weird why this is happening.
It's most likely a driver problem, but the problem is that it doesn't seem to happen all the time with new installations (not even all the time with a specific ubuntu system/version etc).

It seems that the Intel OpenCL Runtime gets hold of the stdin file descriptor and hashcat can't read from the pipe/stdin anymore after this happens... but this shouldn't happen of course !

We would really need to debug this further and try to see where and why the stdin reading fails exactly, but without an affected installation it's of course very difficult for the devs to troubleshoot this.

Maybe in the future whenever you have some spare minutes and your GPUs are not busy cracking (AND you are still able to get the same problem again), you could contact a dev/mod on #hashcat IRC and we could try to debug/troubleshoot this together. Not sure what else to say here, it's a very, very weird bug and most probably not a hashcat-related problem (but you never know for sure, but it seems to happen to a very small amount of installations that it's not really easy to get hold of such a system/problem. You are lucky !)

[hashserious]

I don't know if it's related or not, but when i try with different example hashes some hashes throw "token length exception". For example -m 400, -m 500, -m 600, -m 1600 and -m 14800(not everything was tested). Also, with -m 2501 example file the minimum password length supported by kernel is 64 and maximum is also same.

System: Arch 2x gtx1080.

[philsmd]

entirely unrelated. has nothing to do with pipe and stdin.

also your problems are PEBCAK as far as I can tell

example hashes are here: https://hashcat.net/wiki/example_hashes you always need to specify -m x (where x is the hash type).

it's definitely PEBCAK, because -m 2501 is using pairwise master key (PMK) and of course this key has fixed length (32 bytes or 64 hexadecimal characters). a fixed size key is of course of fixed size. what else should it be ? 64 (hex chars) min and 64 (hex chars) max is perfectly fine for PMK

[hashserious]

entirely unrelated. has nothing to do with pipe and stdin.

also your problems are PEBCAK as far as I can tell

example hashes are here: https://hashcat.net/wiki/example_hashes you always need to specify -m x (where x is the hash type).

it's definitely PEBCAK, because -m 2501 is using pairwise master key (PMK) and of course this key has fixed length (32 bytes or 64 hexadecimal characters). a fixed size key is of course of fixed size. what else should it be ? 64 (hex chars) min and 64 (hex chars) max is perfectly fine for PMK

Thanks for -m 2501 clarification.

As for other types, i had to escape $ symbols with "\", because otherwise it wouldn't include everything left of that symbol and thus the length was incorrect.

Sorry for interruptions and thanks for insults.

[philsmd]

to me pebcak is not an insult. it's a problem description i.e. what the main cause of the problem could be.

sorry if it sounded like an insult to you, sometimes it's difficult to express oneself (and feelings etc) with just a simple forum post. I didn't meant to be mean at all

It's good that you've found out what is going on and that $ needs to be escape or used within quotes when directly used in the command line. as an alternative you can/should use also hash files, they are sometimes better suited especially with large hashes (and hashes with special characters like $ # ! etc)