Whats next going on in the Hashcat development? Well, I am working on multiple battlefields 
- I was working on a new attack method that is a mix of markov attack and jtr-stylish increment mode. While doing this I found out that, using this algorithm, it is possible to "morph" substrings from any dictionary into an other dictionary by creating rules with "i" and "o" functions in combination with some statistics. I just added this morph rule generator to the hashcat-utils v0.06 which will be released when I am think its worth it.
- CPU version of hashcat has not been developed yet (just some bugfixes), but I bought myself a AMD Bulldozer CPU. When I am bored with GPGPU I will start adding some special XOP instructions to CPU hashcat but there is also a small thought that says I should start adding CPU support for oclHashcat-plus. This way I can deprecate CPU hashcat, too, without loosing any features. But maybe I will change my mind on this again. There is still this specific problem that CPU hashcat is extreme fast in quick checking huge hashlists in simple dictionary mode. I am not sure if its possible with OpenCL to hold this speed. Also I have no idea how I could port table-attack to GPGPU because of the vector datatypes. Its incompatible. This however is no longer a problem with the new GCN architecture in the new hd7xxx since its a scalar architecture.
- The Wiki pages are nearly complete. They already proven as a worthy investment of time. But the latest changes from oclHashcat-plus for example require some updates on some wiki pages that still have to be done.
- The AMD APP SDK v2.6! The first impression was much better than with AMD APP SDK v2.5. First thing I noticed that they added a lot of new c++ code which broke my offline compiler for the kernels. As a result I had to write a new offline compiler from scratch. Then I tested some long awaited features. First one was the support for mapping between bitselect and BFI_INT. Well, its still not done. OK, I dont care, I will continue to patch the binary kernel. Another thing I noticed is that they added support for the 7xxx series cards. The kernels compiled cleanly, but for some reason my binary patch for BFI_INT failed on them (changed opcodes?). So i did some more research on them to find out that bitselect finally has been mapped to BFI_INT but only on these cards. So i quickly added some macros for GCN and now fully support mapped BFI_INT for GCN But the SDK 2.6 also has some disadvanges. It looks like it produces slower code on the same codebase. But maybe i just have to rewrite some stuff to get back the old speed. We will see..
- Catalyst 12.1 will be release soon. I am not sure if this might break all preview oclHashcat* versions. At least it did on this specific preview driver. That will be a nightmare! Also it requires SDK 2.6 since it segfaults when trying to compile kernels with SDK 2.4. This means: If catalyst 12.1 breaks kernels -> need upgrade to SDK 2.6 -> produces slower code. And there is nothing i can do against it
- Some days ago I found out an optimized way for the binary digest -> ascii password candidate generation which is used in many PHP based apps which have an own hashing algorithm like VBULL, IPB, MYBB, etc. Instead of using the binary result of the md5 transformation they convert it to ascii HEX and then transform it. This new optimized functions is used in the -m 5 and -m 15 kernels and increased the performance by ~5% on both AMD and NV and on both oclHashcat-lite and oclHashcat-plus
- My latest experiment succeeded in an 2% on-nearly-all-algorithms improvement on AMD cards. To make it short again: my hd5970 with stock clock settings reach 9950M/s (before 9780M/s) on MD5. Just 50M/s more needed to finally break the 10B mark! Another nice results is the one from NTLM which has broken the 18000M mark (on the same system). Yay!
- I was working on a new attack method that is a mix of markov attack and jtr-stylish increment mode. While doing this I found out that, using this algorithm, it is possible to "morph" substrings from any dictionary into an other dictionary by creating rules with "i" and "o" functions in combination with some statistics. I just added this morph rule generator to the hashcat-utils v0.06 which will be released when I am think its worth it.
- CPU version of hashcat has not been developed yet (just some bugfixes), but I bought myself a AMD Bulldozer CPU. When I am bored with GPGPU I will start adding some special XOP instructions to CPU hashcat but there is also a small thought that says I should start adding CPU support for oclHashcat-plus. This way I can deprecate CPU hashcat, too, without loosing any features. But maybe I will change my mind on this again. There is still this specific problem that CPU hashcat is extreme fast in quick checking huge hashlists in simple dictionary mode. I am not sure if its possible with OpenCL to hold this speed. Also I have no idea how I could port table-attack to GPGPU because of the vector datatypes. Its incompatible. This however is no longer a problem with the new GCN architecture in the new hd7xxx since its a scalar architecture.
- The Wiki pages are nearly complete. They already proven as a worthy investment of time. But the latest changes from oclHashcat-plus for example require some updates on some wiki pages that still have to be done.
- The AMD APP SDK v2.6! The first impression was much better than with AMD APP SDK v2.5. First thing I noticed that they added a lot of new c++ code which broke my offline compiler for the kernels. As a result I had to write a new offline compiler from scratch. Then I tested some long awaited features. First one was the support for mapping between bitselect and BFI_INT. Well, its still not done. OK, I dont care, I will continue to patch the binary kernel. Another thing I noticed is that they added support for the 7xxx series cards. The kernels compiled cleanly, but for some reason my binary patch for BFI_INT failed on them (changed opcodes?). So i did some more research on them to find out that bitselect finally has been mapped to BFI_INT but only on these cards. So i quickly added some macros for GCN and now fully support mapped BFI_INT for GCN
But the SDK 2.6 also has some disadvanges. It looks like it produces slower code on the same codebase. But maybe i just have to rewrite some stuff to get back the old speed. We will see..- Catalyst 12.1 will be release soon. I am not sure if this might break all preview oclHashcat* versions. At least it did on this specific preview driver. That will be a nightmare! Also it requires SDK 2.6 since it segfaults when trying to compile kernels with SDK 2.4. This means: If catalyst 12.1 breaks kernels -> need upgrade to SDK 2.6 -> produces slower code. And there is nothing i can do against it
- Some days ago I found out an optimized way for the binary digest -> ascii password candidate generation which is used in many PHP based apps which have an own hashing algorithm like VBULL, IPB, MYBB, etc. Instead of using the binary result of the md5 transformation they convert it to ascii HEX and then transform it. This new optimized functions is used in the -m 5 and -m 15 kernels and increased the performance by ~5% on both AMD and NV and on both oclHashcat-lite and oclHashcat-plus
- My latest experiment succeeded in an 2% on-nearly-all-algorithms improvement on AMD cards. To make it short again: my hd5970 with stock clock settings reach 9950M/s (before 9780M/s) on MD5. Just 50M/s more needed to finally break the 10B mark! Another nice results is the one from NTLM which has broken the 18000M mark (on the same system). Yay!