11-19-2011, 07:40 PM
Thanks again for your reply atom.
Wow !! oclHashcat-plus around 1 million rules is hardly a limitation !!
I am grateful you took the time to explain that as I was concerned about performance when reading through large or very large rule lists.
When I wrote this
I was referring to the fact you have taught me that running rules in the GPU is faster and more efficient than reading directly from a word list or mask-processor. As the GPU is so much faster this technique is used to utilise the GPU to its maximum. See I do pay attention !
I understand the responsibility is now on the user to check for duplicate rules in their lists. I think this is a better idea as the user should check their lists first. This only has to be done once and this prevents hashcat having to do it every time. Good idea !
I understand that having some rules “built in†would not improve performance in any way. My post or request was to help tidy things up a little for the user. The ability to insert one small user defined list with “:,l,c,u†in it as the first primer list and a secondary list with $1 - $1$0$0†etc would be so much easier to manage from a users point of view, also offering the possibility of interesting combinations.
Your answer explained the limitations (or rather, lack of limitation ) of a large single list from a speed / performance point of view but as a list management technique it would have positive benefits to an end user. So would it cause problems to have a list 1 and 2 in hashcatplus ?
The default supplied rule lists in the hashcatplus directory could be much smaller and cover more ground. As I have mentioned before there are problems with those lists which I have fixed. I am about to make new ones to share for new users and I thought it would be good to find out if I could interest you in this feature before I start making them as it would affect their size greatly.
Thanks.
Wow !! oclHashcat-plus around 1 million rules is hardly a limitation !!
I am grateful you took the time to explain that as I was concerned about performance when reading through large or very large rule lists.
When I wrote this
Quote:Better rules and rule management mean more rules for the GPU thus (hopefully) optimising it. !!
I was referring to the fact you have taught me that running rules in the GPU is faster and more efficient than reading directly from a word list or mask-processor. As the GPU is so much faster this technique is used to utilise the GPU to its maximum. See I do pay attention !
I understand the responsibility is now on the user to check for duplicate rules in their lists. I think this is a better idea as the user should check their lists first. This only has to be done once and this prevents hashcat having to do it every time. Good idea !
I understand that having some rules “built in†would not improve performance in any way. My post or request was to help tidy things up a little for the user. The ability to insert one small user defined list with “:,l,c,u†in it as the first primer list and a secondary list with $1 - $1$0$0†etc would be so much easier to manage from a users point of view, also offering the possibility of interesting combinations.
Your answer explained the limitations (or rather, lack of limitation ) of a large single list from a speed / performance point of view but as a list management technique it would have positive benefits to an end user. So would it cause problems to have a list 1 and 2 in hashcatplus ?
The default supplied rule lists in the hashcatplus directory could be much smaller and cover more ground. As I have mentioned before there are problems with those lists which I have fixed. I am about to make new ones to share for new users and I thought it would be good to find out if I could interest you in this feature before I start making them as it would affect their size greatly.
Thanks.