Please note, this is a STATIC archive of website hashcat.net from October 2020, cach3.com does not collect or store any user information, there is no "phishing" involved.

hashcat Forum

Full Version: cudaHC stops at Kernel exec timeout
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Hello community.

I am trying to decrypt a hash using cudahashcat+.
I am using a 9600 GT, decrypting WPA2 works perfectely.
But I get problems decrypting SHA512 hashes.

Quote:cudahashcat+ -m 1800 /root/test.hash /usr/share/wordlists/rockyou.txt
cudaHashcat-plus v0.15 by atom starting...

Hashes: 8 total, 8 unique salts, 8 unique digests
Bitmaps: 8 bits, 256 entries, 0x000000ff mask, 1024 bytes
Rules: 1
Workload: 4 loops, 8 accel
Watchdog: Temperature abort trigger set to 90c
Watchdog: Temperature retain trigger set to 80c
Device #1: 9600 GT, 255MB, 950Mhz, 4MCU
Device #1: WARNING! Kernel exec timeout is not disabled, it might cause you errors of code 702
^C^X^C

Then it just stops. I have to kill it manually, no status with s is working. Same command with normal hashcat works fine.

Here is some output with WPA2:

Quote:cudahashcat+ -m 2500 -a3 /root/test.hccap ?l?l?l?l?l?l?l?l
cudaHashcat-plus v0.15 by atom starting...

Hashes: 1 total, 1 unique salts, 1 unique digests
Bitmaps: 8 bits, 256 entries, 0x000000ff mask, 1024 bytes
Workload: 8 loops, 8 accel
Watchdog: Temperature abort trigger set to 90c
Watchdog: Temperature retain trigger set to 80c
Device #1: 9600 GT, 255MB, 950Mhz, 4MCU
Device #1: WARNING! Kernel exec timeout is not disabled, it might cause you errors of code 702
Device #1: Kernel ./kernels/4318/m2500.sm_11.64.ptx
Device #1: Kernel ./kernels/4318/markov_le_plus_v1.64.ptx
Device #1: Kernel ./kernels/4318/bzero.64.ptx

[s]tatus [p]ause [r]esume [b]ypass [q]uit => q

I read there are a few more devices, Kernel. Does this have something to do with it?
The problem is that you probably use the same GPU as main device for your xserver and it is also configured in xorg.conf.

That way, there is a - very restrict and few seconds - timeout during which the program must respond.

For some (slow) kernels + GPU etc setup this is just not possible. In windows we know of a reg patch hack, see https://hashcat.net/wiki/doku.php?id=timeout_patch .

In linux you can avoid that X11 uses this specific card (you may need to somehow modify xorg.conf) or (I think) just simply stopping the lightdm etc also solves the problem, without hacking w/ config files.

Maybe someone else can tell us if there is a nicer hack to set the timeout in a similar way as we can do with the windows registry patch?
Maybe a timeout option of xorg.conf itself?