atom





Administrator Posts: 5,075

Threads: 226

Joined: Apr 2010 #1



This release is again focused on performance increase of the kernels and bugfixes. However, the most code intensive change in this version was the new workload dispatcher as it's part of the the oclHashcat core. The old one wasn't that bad, but the new one is simply faster which adds up to the increased performance of the kernels.



As always, make sure to unpack into a new folder. Never reuse an existing oclHashcat folder (because of the cached kernels).



One important thing for AMD users: You will need to update to the latest beta version of catalyst before updating oclHashcat. We've decided to no longer wait for AMD to ship the latest "stable" catalyst driver simply because they aren't any more stable than beta drivers...



There's also one change made to the binaries itself. We now are using our own toolchain (thanks to crosstool-ng) to create our own binaries with an older glibc. That was required to make the binaries compatible to linux distributions using an older glibc. That means you should be able to run cudaHashcat and oclHashcat now without glibc patching on The-Distribution-Which-Does-Not-Handle-OpenCL-Well (Kali), some (older) Debian systems, CentOS 6.4, etc..



New algorithms

Skype



Peoplesoft



md5($salt.md5($pass))



Mediawiki B type



Kerberos 5 AS-REQ Pre-Auth etype 23 as fast algorithm (reimplementation)



Android FDE



scrypt



Password Safe v2



Lotus Notes/Domino 8



Skype and Peoplesoft are just new parsers as you were already able to crack them with older oclHashcat versions by using the generic hashtypes and by formating the hashes in a way that oclHashcat can load them. By adding parsers we just make it more comfortable for the users to load the hashes as you can use them in their native output.



The md5($salt.md5($pass)) generic algorithm was simply added as it was required for the Mediawiki B type hash-type. It's a simple scheme that does not require any special comment.



The Kerberos 5 algorithm is a reimplementation as fast algorithm type. That is the case if an algorithm is fast enough to require an on-gpu candidate generator. The algorithm actually was fast enough and just by not selecting it as fast hash it lost some performance. By switching it to a fast type we got some speedup for free.



Now it gets interessing. The Android FDE algorithm that was added is the one that is using PBKDF2-HMAC-SHA1 + CBC-ESSIV-AES with 2000 iterations. Only tricky part was the "detection" of a filesystem. Note that this algorithm isn't used anymore in newer android devices. The new one uses scrypt instead of PBKDF2. For details about how the algorithm is working see here:



That's why we've added scrypt to GPU. And what should I tell, it's PITA. The goal of scrypt to run slow on GPU has been fulfilled. Just one note about that. The intention (if I understood currectly) was to make the computuation slow because the memory access is slow. Well that's not what made it slow actually. It's simply the lack of the total memory available on the card. Note that, to run fast with GPGPU, you have to run many tasks in parallel. That means that you have to allocate a huge amount of memory for each parallel task and this is what kills the gpu, not the access time. Also note that this scrypt variant is the real scrypt, not the minimal version that is used for litecoin. The litecoin version uses extreme low settings for N, r and p such that it is not required to work on global memory for all operations. We're using a fully functional scrypt in which you can set N, r and p dynamically. For the benchmark, we're using the defaults of 16k, 8, 1.



The Password Safe v2 was also very interessting. This algorithm actually runs slower than the current one used in Password Safe v3, which is also supported with hash-type 5200. On my AMD hd7970, the v2 version runs with 101 kH/s while the v3 version runs with 506.2 kH/s but I don't think it's too much of a problem. Both run slow enough and are salted.



Last algorithm that was added is Lotus Notes/Domino 8 which was discovered by our own philsmd. Therefore, oclHashcat v1.30 is world's first Lotus Notes/Domino 8 (H-hashes) cracker! For details about how the algorithm is working see here:



Performance increase



We've added some very special GPU type specific instructions that gave the speed boost. This means the increase of the performance depends on the GPU type. Every GPU type required different changes. It's mostly those chipsets that make the differences in cracking speed, after subtracting the effect that the shader count and clock stepping has.



In other words: Lookup your chipset, then you can apply the percentage change on your current speed with oclHashcat v1.21:



For our Test we used (all stock clocked):



VLIW1: R9 290x

VLIW4: hd6990 (only 1st core)

VLIW5: hd5770



sm_50: gtx 750Ti

sm_21: gtx 560Ti

sm_20: gtx 580





AMD VLIW1 (R9 * and hd7* series, state of the art)







AMD VLIW4 (most of the hd6* series)







AMD VLIW5 (most of the hd5* series)







NVidia sm_50 (Maxwell chipset, ex: 750Ti, future state of the art)







NVidia sm_21 (Older vector chipset)







NVidia sm_20 (Older scalar chipset)







some of the algorithms became a bit slower. That is mostly because of driver changes that we were unable to compensate with more efficient code.



Here's the entire performance change table:



Full changelog v1.21 -> v1.30



Quote:

Type: Driver

File: Kernel

Desc: Added support for AMD Catalyst v14.6 and v14.7 (beta) driver



Type: Driver

File: Kernel

Desc: Added support for NV ForceWare 340.24 driver



Type: Driver

File: Host

Desc: added support for AMD ADL 7.0



Type: Reimplementation

File: Host

Desc: Rewrote dispatcher thread from scratch



Type: Reimplementation

File: Kernel

Desc: Rewrote support for algorithm -m 7500 = Kerberos 5 AS-REQ Pre-Auth etype 23 as fast algorithm



Type: Feature

File: Kernel

Desc: Added support for algorithm -m 23 = Skype

Trac: #474



Type: Feature

File: Kernel

Desc: Added support for algorithm -m 133 = PeopleSoft

Trac: #419



Type: Feature

File: Kernel

Desc: Added support for algorithm -m 3710 = md5($salt.md5($pass))



Type: Feature

File: Kernel

Desc: Added support for algorithm -m 3711 = Mediawiki B type

Trac: #410



Type: Feature

File: Kernel

Desc: Added support for algorithm -m 8800 = Android FDE



Type: Feature

File: Host

Desc: Added support for algorithm -m 8900 = scrypt

Trac: #295



Type: Feature

File: Host

Desc: Added support for algorithm -m 9000 = Password Safe v2



Type: Feature

File: Host

Desc: Added support for algorithm -m 9100 = Lotus Notes/Domino 8



Type: Feature

File: Host

Desc: Added support for --increment with attack-mode 6 and attack-mode 7

Trac: #450



Type: Change

File: Kernel

Desc: Renamed -m 112 = Oracle 11g to -m 112 = Oracle 11g/12c



Type: Change

File: Kernel

Desc: Renamed -m 5200 = Password Safe SHA256 to -m 5200 = Password Safe v3



Type: Change

File: Kernel

Desc: Renamed -m 5800 = Samsung Android Password/PIN to -m 5800 = Android PIN



Type: Bug

File: Kernel

Desc: fixed bug in warp kernels were zero-byte leading plains are incorrectly displayed

Trac: #428



Type: Bug

File: Kernel

Desc: fixed bug in SAP CODVN B (BCODE) misses correct password in rare cases

Trac: #495



Type: Bug

File: Kernel

Desc: Enforce maximum password length for -m 8500 = RACF

Trac: #431



Type: Bug

File: Kernel

Desc: Rule iNX = Insert character X at position N didn't allow to insert a character at the very end of the plain

Trac: #457



Type: Bug

File: Host

Desc: fixed bug in bitmap table leading to uncracked 64-bit based hashes if bitmap_size > 0xffff



Type: Bug

File: Host

Desc: Separator for -m 22 = Juniper Netscreen/SSG (ScreenOS) should always be ':', regardless of --separator

Trac: #454



Type: Bug

File: Host

Desc: fixed memory problem of rules_optimize tool

Trac: #456



Type: Bug

File: Host

Desc: fixed crash with --show when using hash types which use "long" salts, e.g. -m 5600

Trac: #489



Type: Bug

File: Host

Desc: fixed output problem when using --attack-mode 1/6/7, sometimes output was truncated

Trac: #494



Type: Bug

File: Rules

Desc: Reduced generated2.rule file to 64k (65536) rules

Trac: #436

Download here: https://hashcat.net/oclhashcat/ This release is again focused on performance increase of the kernels and bugfixes. However, the most code intensive change in this version was the new workload dispatcher as it's part of the the oclHashcat core. The old one wasn't that bad, but the new one is simply faster which adds up to the increased performance of the kernels.As always, make sure to unpack into a new folder. Never reuse an existing oclHashcat folder (because of the cached kernels).One important thing for AMD users: You will need to update to the latest beta version of catalyst before updating oclHashcat. We've decided to no longer wait for AMD to ship the latest "stable" catalyst driver simply because they aren't any more stable than beta drivers...There's also one change made to the binaries itself. We now are using our own toolchain (thanks to crosstool-ng) to create our own binaries with an older glibc. That was required to make the binaries compatible to linux distributions using an older glibc. That means you should be able to run cudaHashcat and oclHashcat now without glibc patching on The-Distribution-Which-Does-Not-Handle-OpenCL-Well (Kali), some (older) Debian systems, CentOS 6.4, etc..andare just new parsers as you were already able to crack them with older oclHashcat versions by using the generic hashtypes and by formating the hashes in a way that oclHashcat can load them. By adding parsers we just make it more comfortable for the users to load the hashes as you can use them in their native output.Thegeneric algorithm was simply added as it was required for thetype hash-type. It's a simple scheme that does not require any special comment.Thealgorithm is a reimplementation as fast algorithm type. That is the case if an algorithm is fast enough to require an on-gpu candidate generator. The algorithm actually was fast enough and just by not selecting it as fast hash it lost some performance. By switching it to a fast type we got some speedup for free.Now it gets interessing. Thealgorithm that was added is the one that is using PBKDF2-HMAC-SHA1 + CBC-ESSIV-AES with 2000 iterations. Only tricky part was the "detection" of a filesystem. Note that this algorithm isn't used anymore in newer android devices. The new one uses scrypt instead of PBKDF2. For details about how the algorithm is working see here: https://hashcat.net/forum/thread-2270.html That's why we've addedto GPU. And what should I tell, it's PITA. The goal of scrypt to run slow on GPU has been fulfilled. Just one note about that. The intention (if I understood currectly) was to make the computuation slow because the memory access is slow. Well that's not what made it slow actually. It's simply the lack of the total memory available on the card. Note that, to run fast with GPGPU, you have to run many tasks in parallel. That means that you have to allocate a huge amount of memory for each parallel task and this is what kills the gpu, not the access time. Also note that this scrypt variant is the real scrypt, not the minimal version that is used for litecoin. The litecoin version uses extreme low settings for N, r and p such that it is not required to work on global memory for all operations. We're using a fully functional scrypt in which you can set N, r and p dynamically. For the benchmark, we're using the defaults of 16k, 8, 1.Thewas also very interessting. This algorithm actually runs slower than the current one used in Password Safe v3, which is also supported with hash-type 5200. On my AMD hd7970, the v2 version runs with 101 kH/s while the v3 version runs with 506.2 kH/s but I don't think it's too much of a problem. Both run slow enough and are salted.Last algorithm that was added iswhich was discovered by our own philsmd. Therefore, oclHashcat v1.30 is world's first Lotus Notes/Domino 8 (H-hashes) cracker! For details about how the algorithm is working see here: https://hashcat.net/forum/thread-3550.html We've added some very special GPU type specific instructions that gave the speed boost. This means the increase of the performance depends on the GPU type. Every GPU type required different changes. It's mostly those chipsets that make the differences in cracking speed, after subtracting the effect that the shader count and clock stepping has.In other words: Lookup your chipset, then you can apply the percentage change on your current speed with oclHashcat v1.21:For our Test we used (all stock clocked):VLIW1: R9 290xVLIW4: hd6990 (only 1st core)VLIW5: hd5770sm_50: gtx 750Tism_21: gtx 560Tism_20: gtx 580some of the algorithms became a bit slower. That is mostly because of driver changes that we were unable to compensate with more efficient code.Here's the entire performance change table: https://hashcat.net/misc/p130_img/changes_v130.png Website Find KT819GM





Senior Member Posts: 347

Threads: 2

Joined: Aug 2011 #2 Version by version it's more interesting to read your release notes as I sometimes learn more here in few min than reading other pages for hours. Thank you very much for your hard work!



p.s. is R9 290X missing 'k' let's say on descrypt? somehow numbers not mach, or I don't know something as I have none of these cards? Find Pixel





Member Posts: 70

Threads: 1

Joined: May 2012 #3 Thank you Find Mem5





Posting Freak Posts: 762

Threads: 135

Joined: Feb 2011 #4 Thanks ! AwesomeThanks ! Find BlowCane





Junior Member Posts: 7

Threads: 2

Joined: Apr 2013 #5 Nice : ) Find vrposter





Junior Member Posts: 48

Threads: 7

Joined: Jun 2013 #6 Wow, thx a lot! Find ewwink





Junior Member Posts: 8

Threads: 2

Joined: Aug 2014 #7 great release, thank you. Find 2die4





Junior Member Posts: 25

Threads: 3

Joined: May 2014 #8 Thank you atom!!! Find jimi





Junior Member Posts: 1

Threads: 0

Joined: Aug 2014 #9 Thanks for your work !

FirePro W5000 with new AMD Beta Driver and OclHashcat v1.30 is working .. Find forumhero





Senior Member Posts: 313

Threads: 44

Joined: Aug 2011 #10 greatly appreciate all the hard work. thank you.



just noticed descrypt on R9 290X is terrible. is that a typo or performance for descrypt really that bad? Find