Potential bug in mask length parameter

[ret2src]

Hi and thanks for all the awesome password cracking stuff you do!

I think I found a bug in the length parameter. The following command produces masks starting from 4 characters (?x?x?x?x):

ptt -f cracked.txt -t mask -l 8-14 -m 5 > ptt_masks_based_on_cracked.hcmask

However, as a user I expect it to produce masks starting at 8 characters (?x?x?x?x?x?x?x?x).

Is this behavior intended or did you simply forget to subtract hashcat's question mark escape character?

[JakeWnuk]

Hey thanks for opening an issue!

What version are you using? On v0.3.0 I did something silly and made -l check inputs rather than outputs when attempting to make it easier to use with the rule transformations.

I realized this was very confusing and fixed it in v0.3.1 back to the way it was prior.

[ret2src]

$ ptt --version                                                                
flag provided but not defined: -version
Usage of Password Transformation Tool (ptt) version (0.3.1):

Seems to be the current version (which doesn't have a --version flag :smile: )

[JakeWnuk]

Ah. Based on a test, it seems like everything is as intended:

root@[24-09-03 12:56:00]:[/data]
$ echo 'test' | ptt -t mask -l 8-14
?l?l?l?l

root@[24-09-03 12:56:05]:[/data]
$ echo 'testtest' | ptt -t mask -l 8-14

root@[24-09-03 12:56:08]:[/data]
$ echo 'testtest' | ptt -t mask -l 8-16
?l?l?l?l?l?l?l?l

The output of the -t flag is 8 characters, so in the first example it is shown, however, the second input would be 16 characters, making it fall outside the range, when the range is expanded, the input is included again.

This is somewhat related to what I was working on in v0.3.0 where the length flag would filter on input rather than output, so cases like this were easier to navigate. It caused some friction with some transformation modes and wouldn't be standardized across all modes, so it was reverted.

Please let me know if this provides some insight into the trouble being experienced, and if there are any specific examples that may help to identify any possible issues. I know there are probably a few challenging to replicate bugs in the program.

[ret2src]

I'm a little bit confused. While the following output is indeed eight characters long, it does not represent eight but four characters in hashcat:

$ echo 'test' | ptt -t mask -l 8-14
?l?l?l?l

Therefore, I would expect -l 8 to simply drop the four-character mask ?l?l?l?l.

A possible solution could be to subtract all ? characters from the output, so that the actual characters produced by the mask are counted. This would, however, introduce a length-miscalculation bug for literal question mark characters.

[JakeWnuk]

Yup, we are on the same page. So here's the situation:

The help text for -l:

  -l value
        Keeps output equal to or within a range of lengths. Accepts ranges separated by '-'.

So the idea in v0.3.0 was to make it filter on inputs, so if we try the example:

$ go install github.com/jakewnuk/ptt@v0.3.0
$ echo 'test' | ptt -t mask -l 4
?l?l?l?l

This works! It also fixes the interaction with rules pretty well:

$ echo 'test' | ptt -t rule-prepend-remove -l 4
[ [ [ [ ^t ^s ^e ^t

However, it becomes confusing when using it with other modes:

root@[24-09-03 13:53:54]:[/data]
$ echo 'testTest' | ptt -t pop
test
Test

root@[24-09-03 13:54:57]:[/data]
$ echo 'testTest' | ptt -t pop -l 4

Therefore, the idea was, "what if every transformation mode had its own way to filter for length?" to account for these situations.

Well, the issue came up that the length filtering can be applied before or after the transformation and some transformation like rule-*-remove may need more complex logic to perform filtering. Furthermore, the user may have to remember how each transformation mode is implemented and how they handle the -l flag. There is also accounting for templates and output that may have used multiple transformation modes to create it.

This led to the revert in v0.3.1 where -l once again worked on output rather than inputs:

root@[24-09-03 13:55:00]:[/data]
$ go install github.com/jakewnuk/ptt@v0.3.1
go: downloading github.com/jakewnuk/ptt v0.3.1

root@[24-09-03 14:00:44]:[/data]
$ echo 'testTest' | ptt -t pop -l 4
test
Test

root@[24-09-03 14:00:51]:[/data]
$ echo 'test' | ptt -t mask -l 4

root@[24-09-03 14:01:09]:[/data]
$ echo 'test' | ptt -t mask -l 4-8
?l?l?l?l

From here, I am not quite sure how to handle it. I think it may be easier for the end user to make their own adjustments based on what they are expecting. I may attempt again in v0.3.2 but any input or feedback into what would be preferred would be appreciated. The code for this lives in main.go:172.

[JakeWnuk]

Going to go ahead and close this issue. Please feel free to reopen it with any additions or suggested changes, or if there is another issue related to this one.