2 rules not implemented

[Skwerl23]

First rule that isn't implemented exists on John. It's the S rule. This rule allows the switching of case on all characters including symbols.

The second rule that doesn't exist but should is the ability to apply rules to sections of passwords.
E.g.
d S{9-16)

This rule would double the password and then apply shift case rule to characters 9-16

[Skwerl23]

To better give examples. S will take something like P@$$w0rd and make it p244W)RD

And the the second rule I wrote it would turn
P@$$w0rd int P@$$w0rdp244W)RD

[Skwerl23]

I take it back. M rule does what I want. I need to practice it. So with S rule we could do
SMI4 should make P@$$w0rd P@$$w0rdp244W)RD

If I understand M rule correctly

[jsteube]

It's not that, it's more like I don't like the idea of it. If you want to switch cases for 9-16 you would write:

T8 T9 TA.. and so on.

When it comes to P@$$w0rd -> p244W)RD it's even worse as this depends on the keyboard layout. On my german keyboard the @ char would be translated to " char.

[Skwerl23]

I'm speechless at the lack of care. I understand the different keyboards. An Sg rule could exist for German. This would find ten fold the passwords as it's a common tactic to double while holding shift. Thanks for looking at it. :/

[jsteube]

No it's like that this rule was written without thinking of it's implications in the first place. There's a design error in it, why should I buy it.

[roycewilliams]

I'd be curious to hear from @magnumripper about how this "S" rule is implemented in JtR, relative to keyboard and character sets. It would have to be a keyboard-specific lookup table of some kind, I guess? It sounds a bit complicated.

[Skwerl23]

I understand it's area specific. Why not a language input to hashcat like --language=German and then T could apply the correct shift case to that. This tactic is common on more complicated passwords. When a website says "must have 2 upper 2 lower 2 numbers and 2 symbols" people just use 8 digit passwords and hold shift and retype em.

[magnumripper]

Off the top of my head, the S rule in JtR is simply hard-coded for a US keyboard. You could of course make custom rules for custom keyboards (not using S but eg. s1! s2" s3# s4$ and so on) but it'd be slower.

[Skwerl23]

The problem with the s1! Type rule is that it is a cross the board. And not on part of the password. My ultimate goal is to brute Force passwords where the first half is unshifted and the second half is shifted. I could do something like
?1?1?1?1?1?1?1?1?2?2?2?2?2?2?2?2 and then have 1 = ?l?d and 2 = ?u?s but this does so many more characters. I'm trying to brute Force simplistic doubled and shifted passwords like
hashcat7HASHCAT&
This is a common tactic employed by my co-workers and I need to squash it by finding the weak passwords this way. I've done a few tricks by using paste and an instance of hashcat combinating with a 2nd instance of hashcat combinating with the reverse characters. Or tr command. But this requires three instances of hashcat and is super slow. About 1/10th the speed. If I'm lucky. And hashcat fails to load 3 instances a lot and I get it cracking 8 character passwords half the time I run it.