09-08-2016, 02:09 PM
(This post was last modified: 09-08-2016, 08:53 PM by henpemaz.
Edit Reason: taking back something I said
)
(09-07-2016, 09:37 PM)jodler303 Wrote: https://hashcat.net/forum/thread-5744.ht...t=pre.rule
It works ! Thanks a bunch !
Now it raises the weird question that is why the heck does this work...
So, the inline rule takes precedence over length check, but normal rules don't...
I don't care what atom says for this matter, it's not a feature if you have to take an extra step to fill your input with garbage just to get past a test that is in the wrong place.
I think I can get around the problem I've found by now. There are only some minor questions left open, but these are more like suggestions for improvements...
- As stated above, why the heck do inline rule takes precedence over length check, but normal rules do not ?
- Why, just WHY are > and < the ONLY rules that take a two-digit numeric input (10, 11, 12) for stuff above 9 ??? ALL other rules expect you to use A, B, C for, the doc would say, 11, 12, 13, but I presume it's wrong since how the fuck do you put in the 10 like that ? I know it's nicer this way but can't you just also accept the other way for CONSISTENCY ?
- Why do Combination attacks take no rules, forcing you to pipe it to another hashcat command and therefore not giving any information about completion percentage and stuff ? I know I can do these by hand, and I do already, but just why ?
- Piping 2 hashcats to --stdout to make a 3-hashcat workline gives me that weird error. Why, and how to avoid it, since some of the methods I want to use (say, combination) REQUIRE me to pipe ?! ?
Code:
[/rant]Well, @jodler303, thanks again for your working workaround, and thanks @atom for that, and for hashcat, it's a great tool, even if there are still some points to improve :^)