oclHashcat v0.20 vBulletin multihash mode
#1
Question 
Code:
Threads...: 1
Speed.GPU1:       0/s (running)
Speed.GPU*:       0/s
Recovered.: 38/341185 Digests, 23/275278 Salts
Progress..: 0/98948190 (0.00%)
Running...: 3 mins, 42 secs
Estimated.: 0 secs

Hmm, strange - incorrect speed-display again ?!?
#2
it is still on position 0/98948190, wait until it increases. then it should show a value.
#3
So what`s the difference from the previous version ? Wink

Recovered.: 38
Progress..: 0/98948190
#4
made speed display more user-friendly with dynamic suffixes means M/s, k/s or just /s depending on the speed value. old version shows M/s only which means on very low speed it would show 0M/s even it it is 10/s. in your case it is just slower than 1/s.
#5
(06-18-2010, 02:44 PM)atom Wrote: in your case it is just slower than 1/s.

This can`t be true !

Code:
Threads...: 1
Speed.GPU1:       0/s (running)
Speed.GPU*:       0/s
Recovered.: 843/341185 Digests, 567/275278 Salts
Progress..: 131072/344011 (38.10%)
Running...: 50 mins, 4 secs
Estimated.: 0 secs

50 mins x 60 sec = 3000 sec

131072/3000 = ~43 p/s
#6
Quote:This can`t be true !

uhm, moment! you changed the attack. initial post showed:

Progress..: 0/98948190 (0.00%)

now its is:

Progress..: 131072/344011 (38.10%)

Quote:
Code:
Threads...: 1
Speed.GPU1:       0/s (running)
Speed.GPU*:       0/s
Recovered.: 843/341185 Digests, 567/275278 Salts
Progress..: 131072/344011 (38.10%)
Running...: 50 mins, 4 secs
Estimated.: 0 secs

50 mins x 60 sec = 3000 sec

131072/3000 = ~43 p/s

so this is a completly new problem. it is because you have a to little number of combinations in your attack (344011) which is done in blocks (forced by opencl) with a size of 131072 (see progress) but you have 275278 salts. so if you devide 131072 with 275278 it is < 1. since this is a integer operation the result is 0. so you can call this a problem but it will only happen if the number of salts is bigger than the number of blocks.
#7
If you think that this is normal - OK, you know better, I just want to help ...
Anyway the multihash Vbulletin attack with oclHashcat doesn`t seem really useful for the moment,at least for me. The HashCat is faster with dual core CPU than oclHashcat and OC GTX9800+ ...
Here the reslt with the same hash and word lists:

Code:
Index.....: 1/1 (segment), 344549 (words), 3131493 (bytes)
Recovered.: 1761/341183 hashes, 1165/275276 salts
Speed/sec.: 13.75M plains, 50 words
Progress..: 37144/344549 (10.78%)
Running...: 00:00:12:21
Estimated.: 00:01:42:28
50p/s vs 43p/s ...
#8
Quote:If you think that this is normal - OK, you know better, I just want to help ...

yes, please continue doing that! critic is very welcome here. just in case you understood me wrong.

Quote:Anyway the multihash Vbulletin attack with oclHashcat doesn`t seem really useful for the moment,at least for me. The HashCat is faster with dual core CPU than oclHashcat and OC GTX9800+ ...
Here the reslt with the same hash and word lists:

50p/s vs 43p/s ...

yeah well, this is however related to the to small number combinations (344549). i am sure the program printed a line like this: WARNING: words in wordlist_left < XXX
take a look into docs/performance.txt on how to avoid it.

if you use a bigger workload it is ways faster than cpu. on my hd4850 i have about 28k on 10k salted hashes. which is about 280M/s.

little hand-formula: if you want to know your speed, just try a single vb hash and then divide it by the number of unique salts (not hashes). i am sure it is much faster than cpu, much faster than 43p/s.
#9
fixed with oclHashcat v0.25 :-)