Filter When Using Toggles ?

[Hash-IT]

atom can you please tell me what word list filtering goes on when a user selects toggle5 rule and no other rules.

I assumed there wouldn't be any list filtering as I wouldn't be adding or subtracting characters so why does hashcatplus perform a very, very long scan ?

Also I noticed that hashcatplus disregarded an awful lot of my words in my list after this long scan, which surprised me.

I am wondering if hashcatplus ignores words that have less than5 alpha characters when toggle5 rule is applied ?

If so can this be changed so that if a user selects toggle5 or any toggle that any lines with just numbers, alpha less than 5 are still passed on ? If there are indeed less than 5 alpha characters then toggle whats there.

I may be wrong but it seems that this has happened.

Thanks.

[atom]

if you have word "test1234" in your dict, and a rule which contain T4, it wants to toggle the case of "1", which is not possible, so it gets rejected.

[Hash-IT]

Would it be possible to change this behaviour ? If the character that hashcatplus see’s is not an alpha character, can it just ignore the rule on that character ?

So in your example test1234

We would at least get test1234, Test1234, TEst1234, TESt1234,tEst1234 ..etc ?

At the moment I think people may misunderstand this rule.

[atom]

no it was hard enough to add it. i did this on purpose

[Hash-IT]

OK

Its a shame as you had convinced me to use toggles instead of a full upper lower case permutation. I had just got round to the idea that this was best !! ha ha !

I have looked on the wiki on the toggle attack with rules and there is no mention of this filter or behavior and I wonder if there should be ? I don't think new people like myself will think it works in the way it does.

Can I ask why you did that on purpose ?

[atom]

well, thats how all the rules work. if any of the functions report an negative return, the whole rule is skipped. an other example would be '8 but the plain has only length 6 -> plaintext is skipped.

[Hash-IT]

I completely understand why you would filter when a rule affects a password in such a way as to make it less than 8 characters and therefore unsuitable for WPA. I am very impressed with the fact you thought about that so carefully on your first release of a WPA tester to be honest. I also understand why you would filter if it exceeded hashcatplus’s 15 character limit.

What I am unsure about and I am only guessing that others would be also, is that when it comes to something that doesn’t affect the length or validity of a password (such as case) why is it filtered ?

I understand you cannot toggle the number “123” but can hashcatplus just apply the toggle rule to the characters it can in a given password and ignore the rest ?

With the filtering as it is now the password candidate “password123” using toggle2 would never produce a very common password “PassWord123”, as it would have been rejected due to the “123”,which seems like a shame.

I am very impressed with the filtering in general its just that I can’t work out why case changes to passwords (using toggles) would need to be filtered.

This isn’t a criticism, I am just interested as I don’t understand this. Could case toggling please be treated separately as a rule for the reasons above and not be filtered ?

Thank you.

[atom]

no because if i do this, there is no way in doing the opposite again. if some user want exactly the feature as it is implemented right now he can not do this any longer. however, by carefully preparing your rules / by adding additional rules, you can. that makes the difference and thats why i choosed this implementation because it gives the biggest flexibility. in other words, if you know your word in the dictionary is incompatible to a rule X, then dont use rule X. btw, rejected rules do not generate any overhead in time. so they can be seen as something good not as something bad.

[Hash-IT]

no because if i do this, there is no way in doing the opposite again.

OK, I was just thinking there might be a way for a user to switch off filtering easily. Perhaps filtering on by default and a simple –f 0 to turn it off for example. I didn’t realise it would be so complicated.

I am not clever enough to work out why case manipulation (toggle rule) is filtered out or how it affects a given words WPA suitability. I understand you cannot toggle a number but I guessed the rest of the alpha in the word could be. I will try to think about this on my own and not bother you with it again, I clearly have much to learn.

Here you say..

if any of the functions report an negative return, the whole rule is skipped

then here…

rejected rules

However during use it seemed to me that hashcatplus was rejecting my “words” from the list not the rule. As the status update on the screen said “rejected xxx / xxx”. I couldn’t work it out.

I have tried to experiment on my own so as not to take up your time on this but I have been unable to see the output from hashcatplus. I can do this no problem with maskprocessor and hashcat but not with hashcatplus as I understand it doesn’t have –stdout. Unfortunately hashcatplus is the one that does the rule filtering so I can’t print to a text file to see how my rules are being rejected and on which words.

Is there a technique I could use to test my rules against the filter in hashcatplus before running them on my list ?

Thank you.

[atom]

i see, that was my mistake. when i wrote "rejected rule" i actually mean "rejected word". sorry for that!

yes, you can test your rules with hashcat (cpu) and --stdout. both programs share the same rule engine code so hashcats rule engine will react the same way.