v62 is up
#41
(09-03-2012, 01:37 PM)atom Wrote: b70 is up !

@mastercracker:

- fix > 100% progress bug
- fix -m 3200 clEnqueueNDRangeKernel() -54 bug
On b68 for Nvidia. Everything was perfect besides the perentage bug. Will test b71 later.
#42
Windows7 64-bit, nVidia, 304,79 beta, oclHashcat-plus-0.09b70.

Starting with previous bugs:
-m3100: Fixed! Great job as always!

-m3000:
.... -a0: This is weird, when I tried to stdin a single plain it cracked the pass, stding the whole dict did NOT work.
Please try with a dict at the end of your command OR with a "< dict".
Here's an example:
Code:
44EFCE164AB921CA:123456
echo 123456 > dict

hc64p -m3000 44EFCE164AB921CA dict
NOT FOUND!

hc64p -m3000 44EFCE164AB921CA < dict
NOT FOUND!

echo -n 123456 | hc64p -m3000 44EFCE164AB921CA
FOUND!

.... -a6: My theory says: Whenever the FULL 7 character long plain is present in your -a6 dictionary, hashcat wouldn't mind adding ANY char at the end of the cracked plain. E.g.:
Code:
E3493F9DD1EB6F82:______7

echo ______7 > dict    // notice the full plain

hc64p -m3000 -a6 E3493F9DD1EB6F82 dict 0
e3493f9dd1eb6f82:______70
Status.......: Cracked

hc64p -m3000 -a6 E3493F9DD1EB6F82 dict X
e3493f9dd1eb6f82:______7X
Status.......: Cracked

hc64p -m3000 -a6 E3493F9DD1EB6F82 dict ~
e3493f9dd1eb6f82:______7~
Status.......: Cracked

Testing this in deep raised another bug, I believe it's closely related to the one mentioned above:
Code:
E3493F9DD1EB6F82:______7

echo ______ > dict    // missing the last char only

hc64p -m3000 -a6 E3493F9DD1EB6F82 dict ?d
Status.......: Exhausted
Input.Base...: File (dict)
Input.Mod....: Mask (?d)

Exhausted!

Going to post about speed in a short time.

atom Wrote: how many hashes did you use for testing?
1mfakemd5.hash = 1 million.

atom Wrote: I am back at 304.x and CUDA 5.0 RC but still it has not the speed of 0.081 on high number of hashes. On low number of hashes, new version is faster. Can you verify?
I can verify, see below:

10 MD5 and 10 vBulletin 4:

oclHashcat-plus-0.08
hc64p -n320 --gpu-loops=512 -a3 -1 ?l?u?d?s --runtime=60 10md5.hash ?1?1?1?1?1?1?1?1
Speed........: 227.6M c/s Real, 227.7M c/s GPU
hc64p -n320 -m2711 -a3 -1 ?l?u?d?s --runtime=60 10vbu4.hash ?1?1?1?1?1?1?1?1
Speed........: 53132.3k c/s Real, 53142.0k c/s GPU


oclHashcat-plus-0.09b71
hc64p -n320 --gpu-loops=512 -a3 --bf-min=8 --runtime=60 10md5.hash ?a?a?a?a?a?a?a?a
Speed........: 263.5M c/s Real, 264.0M c/s GPU
hc64p -n320 -m2711 -a3 --bf-min=8 --runtime=60 10vbu4.hash ?a?a?a?a?a?a?a?a
Speed........: 63604.3k c/s Real, 63728.1k c/s GPU

Already tried 5k IPB hashes, the results were in favor of the new version.
#43
New version b72 is up.

This version should fix the performance loss on AMD and NVidia for higher number of hashes.

On low number of hashes (less than 100000) it should be faster and it should be extreme much faster if you do -a 3 in -m 0, -m 900 and -m 1000 mode due to partial reversal as long the mask length is less than 9. The less hashes the faster.

Please verify.
#44
b73 is up
#45
OK run tests and attached graph of the results. Good news Smile speeds are better than v0.081 now but there is a performance drop on the smallers lists now, 500 and 50000 hashes.

Have included Excel for RAW data. Mask was len 8 ?a?a?a?a?a?a?a?a

Interestingly, when using len 9, the 50000 hashes was faster than len 8, (that's the blank column on the Excel file), and on 5 hashes, len 9 was slower.


Attached Files Thumbnail(s)
   

.xlsx   oclhc-plus_graph.xlsx (Size: 10.47 KB / Downloads: 1)
#46
OK, that looks fine. In every case its faster than 0.081
#47
(09-03-2012, 03:48 PM)M@LIK Wrote: Windows7 64-bit, nVidia, 304,79 beta, oclHashcat-plus-0.09b70.

Starting with previous bugs:
-m3100: Fixed! Great job as always!

-m3000:
.... -a0: This is weird, when I tried to stdin a single plain it cracked the pass, stding the whole dict did NOT work.
Please try with a dict at the end of your command OR with a "< dict".
Here's an example:
Code:
44EFCE164AB921CA:123456
echo 123456 > dict

hc64p -m3000 44EFCE164AB921CA dict
NOT FOUND!

hc64p -m3000 44EFCE164AB921CA < dict
NOT FOUND!

echo -n 123456 | hc64p -m3000 44EFCE164AB921CA
FOUND!

.... -a6: My theory says: Whenever the FULL 7 character long plain is present in your -a6 dictionary, hashcat wouldn't mind adding ANY char at the end of the cracked plain. E.g.:
Code:
E3493F9DD1EB6F82:______7

echo ______7 > dict    // notice the full plain

hc64p -m3000 -a6 E3493F9DD1EB6F82 dict 0
e3493f9dd1eb6f82:______70
Status.......: Cracked

hc64p -m3000 -a6 E3493F9DD1EB6F82 dict X
e3493f9dd1eb6f82:______7X
Status.......: Cracked

hc64p -m3000 -a6 E3493F9DD1EB6F82 dict ~
e3493f9dd1eb6f82:______7~
Status.......: Cracked

Testing this in deep raised another bug, I believe it's closely related to the one mentioned above:
Code:
E3493F9DD1EB6F82:______7

echo ______ > dict    // missing the last char only

hc64p -m3000 -a6 E3493F9DD1EB6F82 dict ?d
Status.......: Exhausted
Input.Base...: File (dict)
Input.Mod....: Mask (?d)

Exhausted!

Going to post about speed in a short time.

atom Wrote: how many hashes did you use for testing?
1mfakemd5.hash = 1 million.

atom Wrote: I am back at 304.x and CUDA 5.0 RC but still it has not the speed of 0.081 on high number of hashes. On low number of hashes, new version is faster. Can you verify?
I can verify, see below:

10 MD5 and 10 vBulletin 4:

oclHashcat-plus-0.08
hc64p -n320 --gpu-loops=512 -a3 -1 ?l?u?d?s --runtime=60 10md5.hash ?1?1?1?1?1?1?1?1
Speed........: 227.6M c/s Real, 227.7M c/s GPU
hc64p -n320 -m2711 -a3 -1 ?l?u?d?s --runtime=60 10vbu4.hash ?1?1?1?1?1?1?1?1
Speed........: 53132.3k c/s Real, 53142.0k c/s GPU


oclHashcat-plus-0.09b71
hc64p -n320 --gpu-loops=512 -a3 --bf-min=8 --runtime=60 10md5.hash ?a?a?a?a?a?a?a?a
Speed........: 263.5M c/s Real, 264.0M c/s GPU
hc64p -n320 -m2711 -a3 --bf-min=8 --runtime=60 10vbu4.hash ?a?a?a?a?a?a?a?a
Speed........: 63604.3k c/s Real, 63728.1k c/s GPU

Already tried 5k IPB hashes, the results were in favor of the new version.

This all can be explained by windows, which adds a space to each word. Thats why it can not you password.

Moral of this: DO NOT USE ECHO ON WINDOWS

Try again with real text editor pls
#48
Code:
1 Million MD5s:
0.08:.............165.1M
0.09b73:..........170.9M
0.09b73(len_9):...170.9M

25k MD5s:
0.08:.............203.1M
0.09b73:..........141.9M
0.09b73(len_9):...203.1M

10 MD5s:
0.08:.............227.5M
0.09b73:..........192.4M
0.09b73(len_9):...228.1M

All tests were ran with the same arguments.
nV...

atom Wrote: This all can be explained by windows, which adds a space to each word. Thats why it can not you password.

Moral of this: DO NOT USE ECHO ON WINDOWS

Try again with real text editor pls

This needs to be replied using the "One Two Three" rule:
1- I'm a noob... BUT not that noob!
2- I actually use linux's echo (Notice the -n is not available in Windows's echo)
3- I only used echo to make the picture clear for you. All texts were manually added\written.
#49
Atom fixed a non cutting 8 chars novum on v6x
Effect of the old bug: dictionary or rule attack on Des(unix) dont accepted chars like
"AhmedenR3" 9 chars now hc 7x use "AhmedenR" -3
"Yilderimibo" 11 chars now hc 7x use "Yilderim" -ibo
"Hammudiilallah" 14 chars now hc 7x use "Hammudii" -allah
short words , i works perfect on des..... we checked many times the reject rate on some attacks but it works the way it should , thanks atom for great work on a masterpiece of programm :-)
#50
Morning Guys!

b74 is up!

@mastercracker: i guess all passwords were found, right?
@blandy: pls update performance graph
@malik: pls update performance table
@malik: will try -m 3000 anomalies later
@proinside: did the driver update help?
@ati6990: WTH does that all mean. do i need to do any additional change to DES?

@all: are we good for release?