Hi Pixel
Welcome to the forum and what a great first post !
Thank you for your links, I am just going to read through them now and I will come back.
Again thank you for the offer of your brute force tables, that's very kind of you. At the moment I only have A ...ha ha !!
They may be useful to members here if we can't convince atom to make this a feature in hashcat-plus. It does seem a little "old fashioned" storing huge lists like that for a specific attack when they could be generated on the fly.
Its a very kind offer of you and I still might take you up on it. Perhaps see if others here ask for them also. I would feel guilty you uploading all that just for me !
I am pleased you are interested in this approach and I will get back to you later today.
Update
--------------
Those links were great Pixel !
I think I better clarify what I personally believe we should be aiming for. (Open to suggestions obviously).
Ideally this filtering should be performed on the fly (at time of cracking) using the GPU as it is massively superior to CPU. I remember atom telling me some time ago now that I should try to include as many rules as possible whilst using hashcat-plus as it ensures I am using the GPU to its maximum, so this is a good opportunity to do that.
I think “on the fly†filtering is the only sensible way to go as storing many TB’s doesn’t make sense.
There are 2 methods of filtering I think we should be interested in. These should be available independently or as a combination.
1 Limit the amount of adjacent characters in any line to a user specified amount.
2 Limit the amount of times a character appears (in any position) in a given line.
Does everyone agree with those 2 ?
Welcome to the forum and what a great first post !
Thank you for your links, I am just going to read through them now and I will come back.
Again thank you for the offer of your brute force tables, that's very kind of you. At the moment I only have A ...ha ha !!
They may be useful to members here if we can't convince atom to make this a feature in hashcat-plus. It does seem a little "old fashioned" storing huge lists like that for a specific attack when they could be generated on the fly.
Its a very kind offer of you and I still might take you up on it. Perhaps see if others here ask for them also. I would feel guilty you uploading all that just for me !
I am pleased you are interested in this approach and I will get back to you later today.
Update
--------------
Those links were great Pixel !
I think I better clarify what I personally believe we should be aiming for. (Open to suggestions obviously).
Ideally this filtering should be performed on the fly (at time of cracking) using the GPU as it is massively superior to CPU. I remember atom telling me some time ago now that I should try to include as many rules as possible whilst using hashcat-plus as it ensures I am using the GPU to its maximum, so this is a good opportunity to do that.
I think “on the fly†filtering is the only sensible way to go as storing many TB’s doesn’t make sense.
There are 2 methods of filtering I think we should be interested in. These should be available independently or as a combination.
1 Limit the amount of adjacent characters in any line to a user specified amount.
2 Limit the amount of times a character appears (in any position) in a given line.
Does everyone agree with those 2 ?