Posts: 17
	Threads: 4
	Joined: May 2010
	
	
 
	
		
		
 06-18-2010, 01:16 PM
 
		06-18-2010, 01:16 PM 
		
	 
	
		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 ?!?
	
 
	
	
	
	
 
 
	
	
	
		
	Posts: 5,232
	Threads: 233
	Joined: Apr 2010
	
	
 
	
	
		it is still on position 0/98948190, wait until it increases. then it should show a value.
	
	
	
	
	
 
 
	
	
	
		
	Posts: 17
	Threads: 4
	Joined: May 2010
	
	
 
	
	
		So what`s the difference from the previous version ? 
 
Recovered.: 
38
Progress..: 
0/98948190
	
 
 
	
	
	
		
	Posts: 5,232
	Threads: 233
	Joined: Apr 2010
	
	
 
	
	
		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.
	
	
	
	
	
 
 
	
	
	
		
	Posts: 17
	Threads: 4
	Joined: May 2010
	
	
 
	
	
		 (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
	
 
	
	
	
	
 
 
	
	
	
		
	Posts: 5,232
	Threads: 233
	Joined: Apr 2010
	
	
 
	
	
		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.
	
 
	
	
	
	
 
 
	
	
	
		
	Posts: 17
	Threads: 4
	Joined: May 2010
	
	
 
	
		
		
		06-18-2010, 05:05 PM 
(This post was last modified: 06-18-2010, 05:06 PM by vector.)
		
	 
	
		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 ...
	
 
 
	
	
	
		
	Posts: 5,232
	Threads: 233
	Joined: Apr 2010
	
	
 
	
	
		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.
	
 
	
	
	
	
 
 
	
	
	
		
	Posts: 5,232
	Threads: 233
	Joined: Apr 2010
	
	
 
	
	
		fixed with oclHashcat v0.25 :-)