Appreciate the work, but it appears that your rule can be emulated by the swap rule eg s01 s12 s23 s34 s45 s56 s67 s78 s89 s90 so it doesn't make sense to have a single rule achieve the same result with an existing rule.

Appreciate the work, but it appears that your rule can be emulated by the swap rule eg s01 s12 s23 s34 s45 s56 s67 s78 s89 s90 so it doesn't make sense to have a single rule achieve the same result with an existing rule.

True. But his suggestion is to replace all that with F. There's a limit to how many functions a rule can hold, so it absolutely makes sense.

It's not quite right. You cannot use "s" since after "s01" you lose information where initial ones were.

Your output:

00
000
0000
00000
000000
0000000
00000000
000000000
0000000000

0000000000

I think you can do something like this:

s9@ s89 s78 s67 s56 s45 s34 s23 s12 s01 s@0

I'll test it, it might be too slow. Maybe not.

@b8vr The limit for rule functions is 31 operations, i think having to dedicate 10 or so to replacements to achieve this is not too unreasonable. The main issue that @blazer2x has brought up is that it appears you can emulate this completely with existing rule functions, which makes this a little less useful than it probably seems. The majority of rule functions implement some functionality that can't be precisely emulated by other rules. There's still plenty of overlap, especially among the original JTR compatible rule list, and you can achieve similar outcomes through a few different mixtures of rule operations, but a rule operation that has 100% overlap with existing rule ops may not be best use of the limited rule operator signatures that are left.

@mohemiv

It's not quite right. You cannot use "s" since after "s01" you lose information where initial ones were.

Your output:

00
000
0000
00000
000000
0000000
00000000
000000000
0000000000

0000000000

I think you can do something like this:

s9@ s89 s78 s67 s56 s45 s34 s23 s12 s01 s@0

I'll test it, it might be too slow. Maybe not.

I don't think the output would be all 0s, but I agree that it looks like you need to add an extra step or so to make it work identically. This is also relatively similar to how the +N ASCII increment functionality would work, but that's position based so only partial overlap. Unless this rule is particularly fast compared to the sXX method or offer some case where using the sXX rules can't do this, I agree with @blazer2x that maybe we don't need it implement as it's own rule.

Meanwhile, to test the speed we need to write an optimized code since the current code is quite dodgy.

Then we can decide that we don't need this rule. But it would be better to have on optimized code here anyway.

@b8vr The limit for rule functions is 31 operations, i think having to dedicate 10 or so to replacements to achieve this is not too unreasonable. The main issue that @blazer2x has brought up is that it appears you can emulate this completely with existing rule functions, which makes this a little less useful than it probably seems. The majority of rule functions implement some functionality that can't be precisely emulated by other rules. There's still plenty of overlap, especially among the original JTR compatible rule list, and you can achieve similar outcomes through a few different mixtures of rule operations, but a rule operation that has 100% overlap with existing rule ops may not be best use of the limited rule operator signatures that are left.

@mohemiv

It's not quite right. You cannot use "s" since after "s01" you lose information where initial ones were.
Your output:

00
000
0000
00000
000000
0000000
00000000
000000000
0000000000

0000000000

I think you can do something like this:

s9@ s89 s78 s67 s56 s45 s34 s23 s12 s01 s@0

I'll test it, it might be too slow. Maybe not.

I don't think the output would be all 0s, but I agree that it looks like you need to add an extra step or so to make it work identically. This is also relatively similar to how the +N ASCII increment functionality would work, but that's position based so only partial overlap. Unless this rule is particularly fast compared to the sXX method or offer some case where using the sXX rules can't do this, I agree with @blazer2x that maybe we don't need it implement as it's own rule.

I kindly disagree.
I don't see how this is covered using other rules. Rules are applied one at a time, so the rules
s01 s12 s23 s34 s45 s56 s67 s78 s89 s90
would indeed change every digit to 0's.
The rules
s9@ s89 s78 s67 s56 s45 s34 s23 s12 s01 s@0
would work on strings containing only digits, but a string containing @ would have those replaced by 0's.
I can't see any way to add 1 to every digit without changing something else using current rules.
I think there are many usecases where incrementing digits could be useful.

Ah yeah, I do see how it becomes all 0s, you are correct. I had already copied the inverted one to test with the place holder and not the original when I quickly tested it, that was entirely my mistake. Also to be clear, I do agree that this could be useful, just voicing agreement with the concerns about rule functions with overlap. More rule functions is something I've also been working on so the constraints of the function syntax are still fresh for me. Trying to fit a bunch of new rules into the limited syntax is tough and making efficient use of the remaining symbols will be a growing concern.

I'm not actually interested in merging this. I'd like to know how we can optimize this and what the speed difference will be.

Next, if the speed will be great and we see applications for this in master (and not in forks), maybe we can merge this. Maybe not.

Regarding limited syntax, perhaps we need compound rules, for example:

F0 => Rule A
F1 => Rule B
F2 => Rule C
...

We can reserve a letter F for Forks, so anyone can implement their own rules using F letter and it'll never be used in hashcat.

I can't see any way to add 1 to every digit without changing something else using current rules.

I think we can use a binary symbol instead of @, so there will be no conflict with 99.99999% of passwords.

The rules
s9@ s89 s78 s67 s56 s45 s34 s23 s12 s01 s@0
would work on strings containing only digits, but a string containing @ would have those replaced by 0's.

Instead of @ you could use for example TAB or CR (using hex notation s9\x0D ... s\x0D0) for the temporary.

Edit: using LF \x0A is better yet - it "can't" be in the original word anyway. I'm assuming hashcat supports hex notation like JtR.

The rules
s9@ s89 s78 s67 s56 s45 s34 s23 s12 s01 s@0
would work on strings containing only digits, but a string containing @ would have those replaced by 0's.

Instead of @ you could use for example TAB or CR (using hex notation s9\x0D ... s\x0D0) for the temporary.

Edit: using LF \x0A is better yet - it "can't" be in the original word anyway. I'm assuming hashcat supports hex notation like JtR.

Ah right. Yes, that makes sense. I didn't think about that. I guess to be on the safe side, you could use any non-printable character.