Hashcat-style "ASCII increment/decrement" rules

[magnum]

I had a look at implementing what Hashcat describes like this:

Ascii increment +N Increment character @ N by 1 ascii value
Ascii decrement -N Decrement character @ N by 1 ascii value

The code for doing this is totally trivial but there are other caveats:

* The '+' is already used for concatenation of Single mode pairs.
* The '-' at the beginning of line will be parsed as an invalid rule-reject.

Despite this I managed to implement them like this: The '+' will only mean "increment ASCII" if we did not use a '1' or '2' command first. And if you want to place '-N' in the start of a line, you can prepend a no-op 'M' to protect it from being parsed as a rule-reject. But this was mostly for trying it out, I don't think this is satisfactory. If nothing else, I'd actually like to use this *with* Single mode pair words.

There's also the question how to handle an incremented \xFF. Hashcat will gladly increment it to a zero but this will be an actual \x00 possibly in the middle of the word, while JtR would truncate the word at that point. IMO we could just leave this as it happens to end up.

But back to the commands. What should we call them instead? We could say 'i' for increment and 'd' for decrement but both are already taken. As are '<' and '>'. I'm out of ideas.

I enclose the experimental patch (against bleeding-jumbo) in case someone wants to play with it or comment on some other problems it might add.

magnum

[JimF]

Ascii increment +N Increment character <at> N by 1 ascii value
Ascii decrement -N Decrement character <at> N by 1 ascii value
* The '+' is already used for concatenation of Single mode pairs.
* The '-' at the beginning of line will be parsed as an invalid rule-reject.
Despite this I managed to implement them like this: The '+' will only mean

"increment ASCII" if we did not use

a '1' or '2' command first. And if you want to place '-N' in the start of

a line, you can prepend a no-op 'M' to

protect it from being parsed as a rule-reject. But this was mostly for

trying it out, I don't think this is

satisfactory. If nothing else, I'd actually like to use this *with* Single

mode pair words.

There's also the question how to handle an incremented \xFF. Hashcat will

gladly increment it to a zero but

this will be an actual \x00 possibly in the middle of the word, while JtR

would truncate the word at that

point. IMO we could just leave this as it happens to end up.

I know this was message was a bit old (that is why I appended most of the
original message), and that there never was a reply to it.

I have opened an issue request for a new feature for bleeding, to try to get
some specific HC only rules added to john.

https://github.com/magnumripper/JohnTheRipper/issues/2095

There are more rules than just the 2 listed here. Several which I think look
very powerful. All should be trivial to add to the existing rule set, with
the exception of these 2 (the + and -), but as Magnum has mentioned,
actually adding the + and - is not all that hard. There may be a case or 2
that can not be handled, but those cases should pretty few.


Magnum noted that before starting anything on this, that it should be
brought to the ML first, and I do agree, since this is a change to default
behavior.

Jim.