Toggle Rule
#1
I have read your wiki here...
http://hashcat.net/wiki/toggle_attack_with_rules

I basically understand what is happening and the way you have managed to avoid duplicate toggles. However I don't understand why there are letters in there.

T1 T2 T3 etc I understand
TA TB TC TD TE I am not sure why they are there when T defines a position ?

Can anyone help me please ?
#2
T is the function, means "toggle-case". This function requires exactly one single parameter.

T0: 0 is the parameter = change case of position 0
T1: 1 is the parameter = change case of position 1
T9: 9 is the parameter = change case of position 9
T10: 1 is the parameter = change case of position 1

Thats why you have to encode everything > position 9.

A = position 10
B = position 11
C = position 12

and so on..

TA: A is the parameter = change case of position 10
TB: B is the parameter = change case of position 11
#3
(11-05-2011, 05:18 PM)atom Wrote: A = position 10
B = position 11

etc... Smile

Oh...thank you. Smile

I feel a little embarrassed now !

To further humiliate myself I have another thing I am stuck with.

Quote: Depending on the rule-name they include all possible toggle-case switches of the plaintext positions 1 to 15 of either 1, 2, 3, 4 or five 5 charecters at once.

Here it says that all possible toggle-case switches of the plaintext positions 1 to 15. Can I (very humbly) suggest that this is perhaps not as beginners like myself my think ? Looking at it I cannot image all possible combinations from Aaaaaaaaaaaaaaaa to AAAAAAAAAAAAAAAA as to achieve all possible toggle combinations would need toggle 16 wouldn't they ?

Thank you.

#4
Yes, but that is EXACTLY the optimization in it and what makes the toggle case that efficient. if you have upper case chars in your password you do it to make it harder to crack the pass. that also means you would not use ONLY upper case characters. You would try to equalize the number of lower and upper chars. if you have a lenght 8 password, maybe 4 upper and 4 lower. or 5 upper and 3 lower. something like this. so it makes no sense to have all 16 set upper if you have a length 16 password.
#5
(11-05-2011, 05:35 PM)atom Wrote: Yes, but that is EXACTLY the optimization in it and what makes the toggle case that efficient. if you have upper case chars in your password you do it to make it harder to crack the pass. that also means you would not use ONLY upper case characters. You would try to equalize the number of lower and upper chars. if you have a lenght 8 password, maybe 4 upper and 4 lower. or 5 upper and 3 lower. something like this. so it makes no sense to have all 16 set upper if you have a length 16 password.

I see what you mean now the key word was "optimization". I understand what you are doing here now. My view on this is that I tailor some very small passwords lists to each target, this way I have the luxury of being able to change every bit of my list rather than intelligently guessing changes made to a large list.

If I was prepared to miss out on optimisation of a large list and instead choose to opt for a full toggle mutation of a small list then I would need to make toggle 15.rule then wouldn't I ?
#6
if you want to do real toggle-case attack you can use hashcat in --stdout mode. you would not need rules then.
#7
(11-05-2011, 05:44 PM)atom Wrote: if you want to do real toggle-case attack you can use hashcat in --stdout mode. you would not need rules then.

As I am testing WPA I need to use HashcatPlus, I guess I run Hashcat into HashcatPlus to achieve this ?

I will take a look for some instructions how to do it.

Are there any plans to make a "real toggle-case attack" feature available in HashcatPlus ? .... please Smile

Great support by the way, much better than paid for software !
#8
there is no reason to implement it in oclHashcat-plus since there is no improvement (neither in speed nor in flexibility) in comparisation to piped attack.
#9
(11-05-2011, 11:32 PM)atom Wrote: there is no reason to implement it in oclHashcat-plus since there is no improvement (neither in speed nor in flexibility) in comparisation to piped attack.

OK I understand. I have managed to make a rule file that crashes HC+ every time I use it so as soon as I sort it out I'll give the piped thing a try.

I have no doubt the rule crash is entirely my own fault so please don't think this is a bug report ! ha ha !

Thanks.
#10
Sorry to dig this topic up again but I have to say how impressed I am with I think it was "legion" who came up with this idea and also managed to work out how not to duplicate toggles (cancelling each other out).

I was going to make some more of these toggle rules (7,8,9 etc) and share them here by way of a small contribution to the project but I immediately saw that my chosen method to make these toggle rules was not going to omit duplications.

I wonder if anyone here is clever enough to understand this and could explain how these rules were produced in such a way to optimise them ?

I suspect they were generated in the same way I was going to make them and then manually picked through to remove duplications. If so I can see why you stopped at toggle 5 !!!