Loads Of Requests !

[Hash-IT]

wow man, this post rocks. much thanks for putting this all together. it makes it much more easy for me to keep track of all the requests. i will quote each request next:

Phew, I am glad you have read it in the way you have. I must admit to being a little nervous in posting this as I wondered if it might overwhelm you and put you off !!

I can imagine just how difficult it must be keeping track of my requests as I myself forgot a few !!!

You have given me an idea to help you with this. I'll post back later when its done.

Increment.


ACCEPTED

Thank you.

Allows the user to start from a chosen number of characters.


ACCEPTED

Thank you.

Estimate time to complete on this computer.


for two reasons, i will not do this:

1. piped requests are cached by both the system-os and oclHashcat-plus. the estimation would be completly inaccurate.
2. oclHashcat-lite will get an embedded maskprocessor in a later version. this way, its also possible to calculate an ETA.

OK I understand

Mask-Processor Info

since the previous request is not accepted, this one can not be accepted, too.

OK

Prevent multiple sequential instances of characters.


this is not maskprocessor. you are talking about something that should be called markovprocessor. but such an generator already exists. its in jtr which also has an --stdout mode. so you have an alternative for this

To put this simply .... There is no "alternative" to hashcat !!!

It just isn't the same unless its from the authentic mask-processor.

Mask-processor start at position.


ACCEPTED

Awesome ! This will be very useful for many people.

When S status is pressed it would be nice to see an example of the last or nearest to last password tested.


unfortionally, i cant do this. the reason is that oclHashcat-plus does not know it by itself.

1. see this section for an explanation: http://hashcat.net/wiki/oclhashcat_plus#...ry_loading
2. if the word was processed by a rule only the result is stored in cache. that could lead to completly confusing results.

Ahh, thats a shame but I understand.

Allow 2 rule files


finally i understood this idea. and i have to say its great. really. i will do it. i am just not sure if i will do it exactly the way you suggested, have to think about it. but call it ACCEPTED.

Hurray !! ha ha !! I am sorry I don't explain things very well but I have to tread a fine line. If I think I am not being understood it can appear like I am nagging when you have already given an answer, which would be a bad thing to do. However I can tell by your answers sometimes that I have not explained myself properly so I try again in a different way. I did tell you I was a bit thick !! I'm very grateful you tolerate me long enough to give me the chance to explain.

Really looking forward to this feature request being implemented as I am about to share some rule files I have been making and I need to see the new format before doing it as it would massively help to reduce their size.

Allow multiple .hcap selection to run consecutively.


the bad thing is how to do this. oclHashcat-plus uses the first unparametered commandline argument as its hashlist (or hccap file) while all further parameters are defined to be wordlists. so its more a technical question how to do it. on the other hand, there is an easy alternative solution to build a simple for () loop inside a batchscript and place oclHashcat-plus inside and iterated through all your hashshake files. in other words, no real benefit but easy workaround.

There you go again clever cloggs !! Remember some of us are not as clever as you with stuff like this !! ()Loop ?? Huh ?

It would be nice for users to be able to select a folder instead of a single file in command line then. Is that easier to impliment ?

More algorithms.


more algorithms yes, but currently i am not interessted in the ones you named, especially not file or filesystem decryptions. this is hashcat

OK, I am a little disappointed about this but you're the boss !

Toggle Rule


i already tried to explain this. i will try again shortly. hashcat's rule engine must have some sort of error-checking. if rule is incompatible to an input word from an dictionary it must be able to skip it. this policy affects all functions. i dont see an good explanation why to create a special case for the toggle rule.

Before I start this is not an argument, I am just trying to explain myself better. I think the toggle rule is a good idea as a quick (optimised) version of a full case toggle. Once I understood your reasoning for using it I really got into the idea that it was a smart thing to do but I was disappointed that it was not applied to, well, basically most passwords.

An awful lot of passwords end in a number, if the toggle rule doesn't work on these passwords then we gain little from this otherwise excellent feature. If the hashcatplus user has lowercase names followed by numbers in their list it is very likely that a target would capitlise their name. so...

bobsmith123 (in hashcatplus users dictionary).

Using T2 rule ... would eventually get ....

BobSmith123

As we have no idea where the capitiolisation is in a given word then we cannot simply set a Toggle at a definite position. However we do have the full toggle option which would go through all possibilities of bOBsMITh123 etc which is a phenomenal task when using a huge word list.

Your smart idea that people use "token gesture" capitolisation in their passwords is great. Using the T2 option we don't do all possibilities but the most likely token few capitols. Much quicker.

However the filter at the moment skips all lines or words in a password list that have numbers or special characters in them, this is a massive waste of this brilliant feature.

The rule filter is a good idea but I believe it should only be applied when it adversely affects the password candidate. Such as the (must be greater than 8 characters long) for WPA. Testing words of any less is pointless and the filter is justified in dismissing <8 candidates.

Hashcatplus should be smart enough to only toggle the alpha characters and leave the numbers and / or special characters in place.

I apologise if I am becoming a bore with this but I don't see the logic in dismissing so many good password chances with this option. The likely-hood of someone making a password that is simply alpha with token capitolisation is miniscule compared to that same person who makes the effort to capitolise, making one that also contains numbers / special also.

Title rule


OK, cool thing somehow. ACCEPTED.

Thank you, this will be especially useful for passwords that are names.

Rule list pre sorter


you already can do this with hashcat. just run something like "./hashcat-cli64.bin -r your.rule -o prestorted.dict --stdout your.dict"

Yes ,thank you for the explanation. How do I see what hasn't been tested ?

Word list clean up tool.


partially you can do with hashcat-utils. ulm is ulm and hashcat-utils is not made to replace ulm. i am to busy with hashcat to do this.

Understood, thanks. if you ever get bored and feel like a change in subject please come back to me on this one.

Again, thanks for the merge!

You are very welcome. Thanks for reading it !