Rule generater generates unusable rule

[Toetje]

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.

[Snoopy]

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