I found a bug in function generate_random_rule() in script src/cpu_rules.c. The problem occurs when rule _RULE_OP_MANGLE_EXTRACTMEMORY (written as 'X') is generated. This rule function inserts substring of length M starting from position N of word saved to memory at position I (for example X243). Here are exactly described 3 operands (XNMI):
N -> starting position to extract from memory
M -> length of substring which will be extracted from memory
I -> position in password to insert extracted substring to
The problem occured when generating second operand (M). There is a random number p2 generated (minimal should be number 1), and instead of using variable p2 when indexing array, there is used variable p1 (which results in potentially generating number 0).
I found this bug, because I used function _apply_rulecpu() for validating created rules, and when randomly generated rule with the above described function was created, it was not always valid, because in second operand it expected number >= 1.
Good find, I'll merge. I also checked rp_cpu.c in hashcat source, but this version of the rule engine is a lot more modern and doesn't seem to be affected. Thanks!
I found a bug in function generate_random_rule() in script src/cpu_rules.c. The problem occurs when rule _RULE_OP_MANGLE_EXTRACTMEMORY (written as 'X') is generated. This rule function inserts substring of length M starting from position N of word saved to memory at position I (for example X243). Here are exactly described 3 operands (XNMI):
The problem occured when generating second operand (M). There is a random number p2 generated (minimal should be number 1), and instead of using variable p2 when indexing array, there is used variable p1 (which results in potentially generating number 0).
Can be seen here:
I found this bug, because I used function _apply_rulecpu() for validating created rules, and when randomly generated rule with the above described function was created, it was not always valid, because in second operand it expected number >= 1.