+- hashcat Forum (https://hashcat.net/forum)
+-- Forum: Support (https://hashcat.net/forum/forum-3.html)
+--- Forum: hashcat (https://hashcat.net/forum/forum-45.html)
+--- Thread: Rule generater generates unusable rule (/thread-10631.html)
Rule generater generates unusable rule - Toetje - 02-21-2022
Could someone explain the following issue to me?
I did the following command which completed succesfully:
hashcat-6.2.5/hashcat.bin -m 0 -a 0 hashes.md5 wordlist.dic --generate-rules=6000000 --generate-rules-func-min=1 --generate-rules-func-max=30 --debug-mode=1 --debug-file=stats.txt --potfile-disable -o found.txt
The stats.txt file now contains all rules that succesfully found a password.
However a few rules in the stats.txt are unsupported when I put them in a rulefile.
It seems the rules that aren't working have some non-ascii characters.
One example is:
O43 [ 3?A
The question-mark isn't an actual question-mark when looking at the hex:
4f3433205b2033ff41
I assume this is something with formatting, but since rules don't have any --hex parameter I am not entirely sure how to fix this (be able to use it in a rulefile).
I used the latest hashcat release version.
I tried searching the forum, but either my searching skills failing me or no one asked this question before.
RE: Rule generater generates unusable rule - Snoopy - 02-23-2022
well that seems funny indeed because --debug-mode=1 tells to output the rules which found a password
i did some fast research and the only thing/rule i found was
Title w/Nth separator
3NX
Upper case the letter after the Nth instance of a char
see rule based attack, section Implemented specific functions https://hashcat.net/wiki/doku.php?id=rule_based_attack
so what i think happened here, hashcat works on byte size when attacking, thats for example the reason why you need a mask of size 3 to bruteforce the € sign, because its hex representation is €:e282ac given this info lets review this rule/hexrepresentation (i splitted it for better understanding)
4f3433 20 5b 20 33ff41
4F3433 = O43
20 = [SPACE]
B5 = [
now to the interesting part
33 ff 41
33 = 3 (see mentioned rule above)
FF = ÿ (according to the rule this is a counter 0-9, A-Z, so there seems to be the problem)
41 = A (the splitter) -> BUT
FF isnt a valid counter, a single F is so the "real" rule schould be something like 3F F41 (ô) or 0F41 (A) as seperator sign but im not quite sure that this is a rule which would be generated by hascat (this could be the case if hashcat uses your given wordlist as input for separator signs but i dont know whether this is the fact) see EDIT 2: for this.
this is a real nice finding, but need further investigation, i will try to reproduce this by just generating rules with standalone rules_generator hoping it uses the same generator engine like hashcat and looking for these specific 3NX rules
EDIT:
did you copied this rule from stats.txt into a rulefile or did you used stats.txt as rulefile and hashcat tells you "irregular rule detected"?
in the meantime maybe a dev takes a look at this thread, keep calm
EDIT 2:
can you reproduce this with setting --debug-mode=4 and share a specific entry?
i assume that there are some non plain ascii but UTF-8 chars inside your dict which are the reason and resulting in this behavior