Posts: 723
Threads: 85
Joined: Apr 2011
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 ?
Posts: 5,185
Threads: 230
Joined: Apr 2010
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
Posts: 723
Threads: 85
Joined: Apr 2011
(11-05-2011, 05:18 PM)atom Wrote: A = position 10
B = position 11
etc... 
Oh...thank you.
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.
Posts: 5,185
Threads: 230
Joined: Apr 2010
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.
Posts: 723
Threads: 85
Joined: Apr 2011
(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 ?
Posts: 5,185
Threads: 230
Joined: Apr 2010
if you want to do real toggle-case attack you can use hashcat in --stdout mode. you would not need rules then.
Posts: 723
Threads: 85
Joined: Apr 2011
(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
Great support by the way, much better than paid for software !
Posts: 5,185
Threads: 230
Joined: Apr 2010
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.
Posts: 723
Threads: 85
Joined: Apr 2011
(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.
Posts: 723
Threads: 85
Joined: Apr 2011
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 !!!
