0.15 and problems

[falcon111]

Also, the speed you are getting for the "Strange" examples are not accurate because you are already finished the attacks (100%). In your normal example, you are far from the end.

You mean here? :
Time.Started...: Fri Oct 04 00:09:47 2013 (27 secs)
Time.Estimated.: Fri Oct 04 00:13:28 2013 (3 mins, 13 secs)
Speed.GPU.#1...: 2737 H/s
Speed.GPU.#2...: 73075 H/s
Speed.GPU.#*...: 75812 H/s
Recovered......: 0/1 (0.00%) Digests, 0/1 (0.00%) Salts
Progress.......: 7606079/22110625 (34.40%)
Rejected.......: 5515387/7606079 (72.51%)

Or here? :
Time.Started...: Fri Oct 04 00:07:57 2013 (17 secs)
Time.Estimated.: Fri Oct 04 00:11:48 2013 (3 mins, 33 secs)
Speed.GPU.#1...: 2738 H/s
Speed.GPU.#2...: 72782 H/s
Speed.GPU.#*...: 75520 H/s
Recovered......: 0/1 (0.00%) Digests, 0/1 (0.00%) Salts
Progress.......: 2949710/18750000 (15.73%)
Rejected.......: 1657290/2949710 (56.18%)

PS: Besides, 7970's speed is accurate, and 6670's - is not ?

[hannhimhe]

With the rate of rejection you present I would take care of that before hunting for other sources of errors.

Just put together a WPA-friendly wordlist, sort by word length for maximum optimization, and try again.

[falcon111]

With the rate of rejection you present I would take care of that before hunting for other sources of errors.

Just put together a WPA-friendly wordlist, sort by word length for maximum optimization, and try again.

Session.Name...: eharmony
Status.........: Running
Input.Base.....: File (J:\WiFi\Dict\Names\birthdays.txt)
Input.Mod......: File (J:\WiFi\Dict\English_big.txt)
Hash.Target....: File (T:\wifi\md5\eharmony.txt)
Hash.Type......: MD5
Time.Started...: Sun Oct 06 15:50:38 2013 (1 min, 23 secs)
Time.Estimated.: Sun Oct 06 15:53:01 2013 (58 secs)
Speed.GPU.#1...: 391.0 MH/s
Speed.GPU.#2...: 0 H/s
Speed.GPU.#*...: 391.0 MH/s
Recovered......: 40/230014 (0.02%) Digests, 0/1 (0.00%) Salts
Progress.......: 79289564528/135226668600 (58.63%)
Rejected.......: 0/79289564528 (0.00%)
HWMon.GPU.#1...: 2% Util, 67c Temp, 42% Fan
HWMon.GPU.#2...: 92% Util, 60c Temp, N/A Fan

PS: Speed shows devices as 1:6670, 2:7970
And HWMon shows them as 1:7970, 2:6670
Is this supposed to be like this?

[atom]

This is correct, because you did not create enough workload.

J:\WiFi\Dict\Names\birthdays.txt

Sounds like it will have only a few entries. If you switch English_big.txt and birthdays.txt it should run at full speed, or at least much better one.

[falcon111]

This is correct, because you did not create enough workload.

J:\WiFi\Dict\Names\birthdays.txt

Sounds like it will have only a few entries. If you switch English_big.txt and birthdays.txt it should run at full speed, or at least much better one.

There are 27900 records in J:\WiFi\Dict\Names\birthdays.txt

And i've checked hashcat on single GPU with --gpu-devices=1 and --gpu-devices=2 parameters. HWMon shows wrong data:

Status.........: Running
Input.Mode.....: Mask ((067)?d?d?d?d?d?d?d) [12]
Hash.Target....: Dasha (00:26:5a:00:2a:56 <-> f8:d1:11:52:95:b4)
Hash.Type......: WPA/WPA2
Time.Started...: Mon Oct 07 06:16:34 2013 (14 mins, 12 secs)
Time.Estimated.: Mon Oct 07 11:45:58 2013 (2 mins, 3 secs)
Speed.GPU.#1...: 26975 H/s
Recovered......: 0/1 (0.00%) Digests, 0/1 (0.00%) Salts
Progress.......: 6795264/10000000 (67.95%)
Rejected.......: 0/6795264 (0.00%)
HWMon.GPU.#1...: 0% Util, 68c Temp, 53% Fan

Speed 26975 H/s shows that hashcat works with 6670 GPU, but HWMon shows idle 7970 GPU. 6670 has no fan on it.

Status.........: Running
Input.Mode.....: Mask (?d?d?d-?d?d?d?d) [8]
Hash.Target....: TP-LINK_8 (1c:65:9d:25:a9:d6 <-> a0:f3:c1:7d:c9:f0)
Hash.Type......: WPA/WPA2
Time.Started...: Mon Oct 07 11:46:50 2013 (7 secs)
Time.Estimated.: Mon Oct 07 11:49:11 2013 (2 mins, 13 secs)
Speed.GPU.#1...: 73849 H/s
Recovered......: 0/1 (0.00%) Digests, 0/1 (0.00%) Salts
Progress.......: 540672/10000000 (5.41%)
Rejected.......: 0/540672 (0.00%)
HWMon.GPU.#1...: 0% Util, 64c Temp, N/A Fan

In this case, active GPU is 7970: 73849 H/s, and HWMon shows data for 6670 GPU

[atom]

OK, so is the first problem solved?

Now, the second one, it's not a oclHashcat-plus problem. See here, from http://hashcat.net/wiki/doku.php?id=oclh..._forceware:

There is no unique identifier that can be used to map between CAL/OpenCL devices and ADL device type. oclHashcat* is forced to use a fuzzy logic on the device names!

So there's no guarantee to work (but it does most of the time).

[falcon111]

OK, so is the first problem solved?

Not exactly. Yes, i've put dictionaries in other order(long dictionary first), and number of h/s increased. But i decide in what order to place dictionaries to get required passwords combinations. Dictionaries with changed places result in the other password combinations.
Mod dictionaries are usually small, and i try them before and after main dictionary. Now you telling me, that i should always put mod dictionary last?

Now, the second one, it's not a oclHashcat-plus problem. See here, from http://hashcat.net/wiki/doku.php?id=oclh..._forceware:

There is no unique identifier that can be used to map between CAL/OpenCL devices and ADL device type. oclHashcat* is forced to use a fuzzy logic on the device names!

So there's no guarantee to work (but it does most of the time).

I see. Is it possible to make some parameter to map HWMon to GPUs explicitly? For the case when autodetection fails?

[mastercracker]

Just a tip to improve performance. When you want to do a combination attack that uses a small dictionary as the starting one, convert that dictionary to prepending rules (don't forget to reverse the order) and do a regular dictionary attack with the big dictionary as input and the rules as modifiers.

[falcon111]

Just a tip to improve performance. When you want to do a combination attack that uses a small dictionary as the starting one, convert that dictionary to prepending rules (don't forget to reverse the order) and do a regular dictionary attack with the big dictionary as input and the rules as modifiers.

I've already thinked about it. I guess i'm gonna have to make a simple program dictionary-to-rules converter...

Meanwhile, another bug. I'm unable to restore session.
Here's example how to reproduce it:
Creating bat-file:

Code:

C:\Programs\oclHashCat\oclHashcat-plus\oclHashcat-plus64.exe -a 3 -m 2500 -p : --session=temp --username -o temp.out --outfile-format=3 --markov-disable -u 256 --gpu-devices=1,2 T:TP-LINK_8.hccap ?d?d?d?d?d?d?d?d
C:\Programs\oclHashCat\oclHashcat-plus\oclHashcat-plus64.exe --restore --session=temp

Launching OHC, pressing 'q' to abort it. Second line from the bat-file should restore sission and continue calculation, but...
Here's console output:

Code:

T:\WiFi>C:\Programs\oclHashCat\oclHashcat-plus\oclHashcat-plus64.exe -a 3 -m 2500 -p : --session=temp --username -o temp.out --outfile-format=3 --markov-disable -u 256 --gpu-devices=1,2 T:TP-LINK_8.hccap ?d?d?d?d?d?d?d?d
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: 256 loops, 8 accel
Watchdog: Temperature abort trigger set to 90c
Watchdog: Temperature retain trigger set to 80c
Device #1: Turks, 1024MB, 600Mhz, 6MCU
Device #2: Tahiti, 2048MB, 600Mhz, 32MCU
Device #1: Kernel C:\Programs\oclHashCat\oclHashcat-plus/kernels/4098/m2500.Turks_1124.2_1124.2 (VM).kernel (588132 bytes)
Device #1: Kernel C:\Programs\oclHashCat\oclHashcat-plus/kernels/4098/markov_le_plus_v2.Turks_1124.2_1124.2 (VM).kernel (186304 bytes)
Device #1: Kernel C:\Programs\oclHashCat\oclHashcat-plus/kernels/4098/bzero.Turks_1124.2_1124.2 (VM).kernel (33864 bytes)
Device #2: Kernel C:\Programs\oclHashCat\oclHashcat-plus/kernels/4098/m2500.Tahiti_1124.2_1124.2 (VM).kernel (313116 bytes)
Device #2: Kernel C:\Programs\oclHashCat\oclHashcat-plus/kernels/4098/markov_le_plus_v1.Tahiti_1124.2_1124.2 (VM).kernel (88664 bytes)
Device #2: Kernel C:\Programs\oclHashCat\oclHashcat-plus/kernels/4098/bzero.Tahiti_1124.2_1124.2 (VM).kernel (30456 bytes)

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

Session.Name...: temp
Status.........: Aborted
Input.Mode.....: Mask (?d?d?d?d?d?d?d?d) [8]
Hash.Target....: TP-LINK_8 (1c:65:9d:25:a9:d6 <-> a0:f3:c1:7d:c9:f0)
Hash.Type......: WPA/WPA2
Time.Started...: Tue Oct 08 20:32:11 2013 (7 secs)
Time.Estimated.: Tue Oct 08 20:49:55 2013 (17 mins, 36 secs)
Speed.GPU.#1...:    26927 H/s
Speed.GPU.#2...:    76215 H/s
Speed.GPU.#*...:   103.1 kH/s
Recovered......: 0/1 (0.00%) Digests, 0/1 (0.00%) Salts
Progress.......: 663552/100000000 (0.66%)
Rejected.......: 0/663552 (0.00%)
HWMon.GPU.#1...: 94% Util, 70c Temp, 55% Fan
HWMon.GPU.#2...: 95% Util, 58c Temp, N/A Fan

Started: Tue Oct 08 20:32:11 2013
Stopped: Tue Oct 08 20:32:19 2013

T:\WiFi>C:\Programs\oclHashCat\oclHashcat-plus\oclHashcat-plus64.exe --restore --session=temp --gpu-devices=1,2
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: 256 loops, 8 accel
Watchdog: Temperature abort trigger set to 90c
Watchdog: Temperature retain trigger set to 80c
Device #1: Turks, 1024MB, 600Mhz, 6MCU
Device #2: skipped by user
ERROR: Loaded number of devices is async to data in restore file

T:\WiFi>

[mastercracker]

Atom, this is a real bug. I never been able to restore my sessions because of the same error message. Works for single GPU but not with multi-gpu. Just in case it's related, notice this that was in his posting:

HWMon.GPU.#2...: 95% Util, 58c Temp, N/A Fan

In my case, I have to use --gpu-temp-disable not to get the warnings at the start of the attack. I am wondering if this failed detection throws off also the restore file. Also, if I try to open the restore file in a notepad2, It seems to have stored only device1. I could provide restore file if needed.