08-21-2014, 05:48 PM
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..
New algorithms
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: https://hashcat.net/forum/thread-2270.html
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: https://hashcat.net/forum/thread-3550.html
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)
![[Image: changes_v130_vliw1.png]](../../misc/p130_img/changes_v130_vliw1.png)
AMD VLIW4 (most of the hd6* series)
![[Image: changes_v130_vliw4.png]](../../misc/p130_img/changes_v130_vliw4.png)
AMD VLIW5 (most of the hd5* series)
![[Image: changes_v130_vliw5.png]](../../misc/p130_img/changes_v130_vliw5.png)
NVidia sm_50 (Maxwell chipset, ex: 750Ti, future state of the art)
![[Image: changes_v130_sm50.png]](../../misc/p130_img/changes_v130_sm50.png)
NVidia sm_21 (Older vector chipset)
![[Image: changes_v130_sm21.png]](../../misc/p130_img/changes_v130_sm21.png)
NVidia sm_20 (Older scalar chipset)
![[Image: changes_v130_sm20.png]](../../misc/p130_img/changes_v130_sm20.png)
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: https://hashcat.net/misc/p130_img/changes_v130.png
Full changelog v1.21 -> v1.30
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: https://hashcat.net/forum/thread-2270.html
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: https://hashcat.net/forum/thread-3550.html
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: https://hashcat.net/misc/p130_img/changes_v130.png
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
