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
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.
if you want to do real toggle-case attack you can use hashcat in --stdout mode. you would not need rules then.
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.
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 !!!