Session issue

[Mem5]

I want to use sessions, but does not work, what am I doing wrong ??

using oclHashcat-plus-0.15\oclHashcat-plus64.exe

Code:

oclplus.exe -a 3 -m 2500  --session=wpa_10digits  --restore-timer=1800 --increment-min=10  --increment-max=10 --gpu-temp-abort=90 "wpa.hccap" ?d?d?d?d?d?d?d?d?d?d

I stop it after 5 min.

Then I launch :

Code:

oclplus.exe  --restore --session=wpa_10digits

But this command restart the task from scratch (0 sec), and not from 5 min ! Why ?

Thanks.

[epixoip]

don't look at the time, look at the progress.

[Mem5]

I've just checked, I left the progress at 0.16%, I launch the restore, it begun at 0.00%.

[Mem5]

Any idea ?

[radix]

Code:

radix@katana:~/hashcat/oclHashcat-plus-0.15$ ./oclHashcat-plus64.bin -a 3 -m 2500  --session=wpa_10digits  --restore-timer=1800 --increment-min=10  --increment-max=10 --gpu-temp-abort=90 test.hccap ?d?d?d?d?d?d?d?d?d?d -d 2

Session.Name...: wpa_10digits
Status.........: Aborted
Input.Mode.....: Mask (?d?d?d?d?d?d?d?d?d?d) [10]
Hash.Target....: X
Hash.Type......: WPA/WPA2
Time.Started...:  2013 (4 mins, 16 secs)
Time.Estimated.:  2013 (1 day, 9 hours)
Speed.GPU.#1...:    85953 H/s
Recovered......: 0/1 (0.00%) Digests, 0/1 (0.00%) Salts
Progress.......: 21495808/10000000000 (0.21%)
Rejected.......: 0/21495808 (0.00%)
HWMon.GPU.#1...: 66% Util, 65c Temp, 63% Fan

radix@katana:~/hashcat/oclHashcat-plus-0.15$ ./oclHashcat-plus64.bin --restore --session=wpa_10digits
oclHashcat-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: 16 loops, 8 accel
Watchdog: Temperature abort trigger set to 90c
Watchdog: Temperature retain trigger set to 80c
Device #1: skipped by user
Device #2: Tahiti, 2942MB, 1000Mhz, 32MCU
Device #1: Kernel ./kernels/4098/m2500.Tahiti_1311.2_1311.2 (VM).kernel (312340 bytes)
Device #1: Kernel ./kernels/4098/markov_le_plus_v1.Tahiti_1311.2_1311.2 (VM).kernel (84408 bytes)
Device #1: Kernel ./kernels/4098/bzero.Tahiti_1311.2_1311.2 (VM).kernel (30480 bytes)

[s]tatus [p]ause [r]esume [b]ypass [q]uit => s
Session.Name...: wpa_10digits
Status.........: Running
Input.Mode.....: Mask (?d?d?d?d?d?d?d?d?d?d) [10]
Hash.Target....: X
Hash.Type......: WPA/WPA2
Time.Started...:  2013 (4 mins, 17 secs)
Time.Estimated.:  2013 (1 day, 9 hours)
Speed.GPU.#1...:    84344 H/s
Recovered......: 0/1 (0.00%) Digests, 0/1 (0.00%) Salts
Progress.......: 21577728/10000000000 (0.22%)
Rejected.......: 0/21577728 (0.00%)
HWMon.GPU.#1...: 51% Util, 60c Temp, 56% Fan

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

Seems to be working, but I did abort the run early. Can you drop your runtimer down to say 5 mins and see if it still happens? Also, increment-min/max isn't needed if you aren't incrementing in the first place.

[radix]

Just your luck, someone else came into IRC and had the same issue with cudaHashcat-plus64 not working with sessions. Please file a ticket on trac so that it can be worked.

[Mem5]

OK.
But why is it working with you ?

[atom]

remember that the .restore file is written only at specific times. it might not be an issue, you maybe stopped to early and it did not had a chance to write the file. especially when you increase the -n value and in combination with a slow hash, the runtime for a single complete kernel run can take a lot of time.

the background therefore is the gpu kernels that are running. the restore progress can only be written when a full kernel run is finished. if it wouldn't do it that way parts of the keyspace that wasn't tested would be lost (the parts that did not have been calculated). so it has to wait for kernel run finish, then update progress count, then it can write .restore file.

[Mem5]

I understand.

So the switch "--restore-timer=NUM Save restore file each NUM seconds" is not properly what it means ?

[radix]

remember that the .restore file is written only at specific times. it might not be an issue, you maybe stopped to early and it did not had a chance to write the file. especially when you increase the -n value and in combination with a slow hash, the runtime for a single complete kernel run can take a lot of time.

the background therefore is the gpu kernels that are running. the restore progress can only be written when a full kernel run is finished. if it wouldn't do it that way parts of the keyspace that wasn't tested would be lost (the parts that did not have been calculated). so it has to wait for kernel run finish, then update progress count, then it can write .restore file.

While this is quite possible, I ran his command line on linux and got a proper session file even after quitting after just 4 minutes. Per yesterdays conversation with someone else using windows with cudaHashcat-plus, the might be a bug in the windows version. He had the same problem with the restore file being empty.