Speed isn’t Everything !

[Hash-IT]

nothing to worry dude i am looking forward for your rephrased version

You are probably going to regret saying that !!


I will no doubt be testing the boundaries of your tolerance as I think this is going to be a long one, but you may find some things of interest which I hope inspire you.

I am writing the following under no pretence that I know anything about hash cracking, theory or programming at all. I am just a humble user with little knowledge or understanding but just wants to get the job done so to speak. I think it would be good for you to hear what the hashcat experience is like from the other side ! So if I say something stupid that’s why, well…. there are many other reasons but that’s mainly why !

I personally am only interested in WPA but I guess my requests will also apply to all other hash types. So for now and for simplicities sake I will refer only to hashcat’s WPA feature if that’s ok. Also I mention “hashcat” when it actually applies to all versions.

To me, it seems as if you wish to maintain hashcat as a small, tight and compact executable. I guess this is the fine art of programming, keep it compact and minimalist. I understand this and admire it, I only wish this principle to be extended to dictionaries and rule files, which is why I am writing this.

Hashcat is fast, no question or doubt about it. You have won the speed race decisively and proved you really know how to program the fastest cracker on the internet. Congratulations, it is quite an achievement and most people would sit back and bathe in the glory but you do seem keen on further improvements, which is inspiring to me.

My thread title “Speed isn’t everything” is in no way a criticism, speed is vital when cracking WPA. However my point, although badly explained is, although hashcat’s speed is awesome….make that… totally awesome, lets please not lose the point of hashcat by admiring its outstanding technical achievements only.

Hashcat is surly about cracking hashes and breaking passwords. This is only achieved by 2 methods, brute force and dictionaries. Brute force is the very last resort and is the simpleton’s method of choice. Oh and by the way, I include myself in that category before anyone gets offended !! Brute force does indeed require tremendous speed to compensate for the lack of effort by the user to research possible passwords pertaining to the target in question. Hashcat has more than adequately catered for these types of users and this method of attack by its shear speed, I for one thank you very much for it !

Dictionaries are or should be the first method of attack for any sane penetration tester. In theory this sounds very simple and to be honest when first realising just how alike most users are when it comes to choosing a password one would think that a computer running many thousands if not millions of passwords a second will have no trouble finding a password from a dictionary.

As we know this isn’t as simple as it sounds, a dictionary has to actually contain the password verbatim, which is unlikely when you consider password padding. I call password padding things like prefix / suffixing numbers, other words or special characters etc. That simple trick to pad out a password can render most dictionaries useless and this was my main point. Hashcat running many thousands of the wrong passwords does mean it is fast but I say (humbly) it does not make it fast in the right way. This is where I wonder if you (again this is not a critical statement) have lost sight of what fast is when applied to crackers. Technical brilliance is great but real world results are better.

I suggest and hope you start to look at hashcat in a different way and not judge it on how fast it can try a password but on how fast it can successfully find one ! So looking at hashcat in this way can I suggest the following ?

My wish is that you would extend the principle of keeping code compact and minimalist to dictionaries also. What this means is that dictionary size can be kept to an absolute minimum by only storing words in lower case with no padding whatsoever.

These “base” words can then be mutilated or permutated into a theoretical list many times greater in size but without using up the hard drive space or bandwidth when sharing normally required as hashcat can do this on the fly. I believe this method will also more comprehensively cover most if not all possibilities of padding.

I understand this is where the rule files come in. This is a great idea and very much appreciated. Although this is another area where I hope you will extend your minimalist approach. At the moment if I want to sufix the numbers 0 – 10 (a common pad) to a password as it passes through hashcat I would have to make a rules list like the following.

$1
$2
$3
$4
$5
$6
$7
$8
$9
$10

If I need 0 – 1000….well I think you can see that this list would be huge. Can you please think of a way for users to be able to make smaller rule lists ? Perhaps something like the following ?

$ --increment d (0-10)
Or
$ --increment d (0-100)

Doubtless you are better qualified to suggest ideas for letters and special characters etc, but I am sure you get the idea.

Until recently I knew nothing about the maskprocessor, so I apologise for that. Interestingly this rather proves my point, for the average user like myself seeing it from the other side, hashcat is a confusing place to be ! The user is left not knowing which version they should be using and also not knowing that other programs are required to mutate passwords, such as maskprocessor. It has however given me an idea for hashcat.

As hashcat is just about perfect as it is, apart from the 16 character limit that is !!!! Could I interest you in attracting your attention to perhaps making a simpler (to use) and more comprehensive version of maskprocessor ?

I guess this would keep hashcat small and compact as it would simply test passwords passed to it from this other external program. This new, hopefully GUI could add all the mutations and also provide some sort of much needed resume feature. As I mentioned before, not having some sort of automatic backup and the ability to resume an attack can totally wipe out all speed gains over “other” WPA crackers.

With this separate program, being separate, should allow the hardcore hashcat users to still be able to use hashcat as they do now. I understand from your last post that using this external program will probably have a significant performance hit as it will force hashcat to work in a less efficient way. Well, there is no such thing as a free lunch so I would be more than willing to sacrifice a few thousand keys per second if I could know that all permutations were being catered for and that in the event of a power out I won’t lose everything. I like to think of it as intelligent brute force !

So, my humble requests in list form. I know you have explained some of them but I thought I would list them anyway.

Allow up to 63 character passwords for WPA

Automatically save position every 10 minutes in case of accidental power outs.

Easier to use and more comprehensive version of maskprocessor. Perhaps GUI ?
Brute force with start from.
Password padding.
Many more mutations.

Work on more than one WPA key at once like hashcat does with hashes.

Ability to accept standard .cap files. (I am grateful you made the online form after our last discussion but this would be one less step for the user to make.)

Better documentation. This was a problem on my other projects, it’s the boring bit but very useful.

You mentioned that hashcat with the maskprocessor can mutate passwords like Cain&Able does. Can I ask does maskprocessor do the mutations concurrently or consecutively ? You see with a base word of “pass” using Cain I would also get pAsS100 where I don’t think any other program does this.

Anyway thank you for reading this far down, if my suggestions don’t make any sense or are just plain wrong then I apologise in advance as I said I am a simple user with little knowledge in this subject. I also appreciate you may consider many of my requests beyond the remit of hashcat. You may say hashcat’s goal is to simply hash words provided to it which is fair enough, but I hope you perhaps think about changing how you view hashcat’s speed, more in found passwords rather than tests per second….however totally and utterly awesome that is !!!!

Thanks.

---

Forumhero, thank you very much for the code you took the time to write out, I am going to study it !

oh i had nothing to do with it, it's Atom's tool

P.S
women don't respect men who kiss their ass. so make sure to keep the pimp hand strong

I loved your last post !!! Tears of laughter rolling down my cheeks !!

You gave me the confidence to leave my coffee cup out this morning and not return it to the dishwasher !!

Yeah, you know what I am talking about…..just keeping my bioatch in line !!
.
.
.

Probably should go and clear that up later….