Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@Chick3nman
Copy link
Contributor

This new rule inserts the desired byte X every N bytes in the password buffer.

The rule is written vNX where v is our operator, N is how many bytes between insertions, and X is the byte to insert.

The behavior of the rule is such that if the last position in the buffer is equal to N bytes after the previous insertion, X will be inserted at the end as well. If the value of N is 0, this rule cannot operate and returns the initial buffer. If the value of N is larger than the length of the original buffer, again we cannot operate and must return the original buffer.

Password1

v0_
v1_
v2_
v3_
v4_
v5_
v6_
v7_
v8_
v9_
vA_

Password1
P_a_s_s_w_o_r_d_1_
Pa_ss_wo_rd_1
Pas_swo_rd1_
Pass_word_1
Passw_ord1
Passwo_rd1
Passwor_d1
Password_1
Password1_
Password1

#define RULE_OP_MANGLE_TITLE 'E'
#define RULE_OP_MANGLE_TO_HEX_LOWER 'h'
#define RULE_OP_MANGLE_TO_HEX_UPPER 'H'
#define RULE_OP_MANGLE_INSERT_EVERY 'v'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you check JtR compatibility?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, v is currently unused by JTR. I would have preferred to use I but JTR implements it as adding ing to the end of the password. No other tools use v or I.

@fukc-gihtub
Copy link

Could this rule op also insert the byte at the beginning? It's easier to truncate than to prepend the same byte.

v1_ [ / v1_ ^_

@Chick3nman
Copy link
Contributor Author

Could this rule op also insert the byte at the beginning? It's easier to truncate than to prepend the same byte.

v1_ [ / v1_ ^_

I had considered this but it doesn't fit the operational definition of how I intended for the rule to work. I'm inserting a character "every N characters from the start of the string". Which is just a bit different from "interleave X character every N bytes" in my opinion.

@Chick3nman
Copy link
Contributor Author

Could this rule op also insert the byte at the beginning? It's easier to truncate than to prepend the same byte.

v1_ [ / v1_ ^_

Having thought about this some more, I think I may actually be coming around to the idea of changing the behavior to include the preceding position. It's not how I had intended the rule originally, but I think it may be more useful as in your example, a value agnostic [ is "easier" than a value specific prepend. I'd like some more input on this from others before I change the behavior, but this does seem like it may be good change overall.

@fukc-gihtub
Copy link

As the author of a Markov rule generator, I think it would be more useful.

@fukc-gihtub
Copy link

In a small survey I ran, 6 people voted for the original behavior and 1 for the change.

@Chick3nman
Copy link
Contributor Author

In a small survey I ran, 6 people voted for the original behavior and 1 for the change.

To clarify, original behavior is how it is in the PR now, and change is including the character in the first index (0)?

@fukc-gihtub
Copy link

Yes.

@Chick3nman
Copy link
Contributor Author

In that case, I will leave it as it is and have it merged. Thanks for the input :)

@fukc-gihtub
Copy link

There are conflicts currently that prevent merging.

@jsteube jsteube merged commit 5e7bd33 into hashcat:master Nov 16, 2025
15 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants