Please note, this is a STATIC archive of website hashcat.net from 08 Oct 2020, cach3.com does not collect or store any user information, there is no "phishing" involved.

hashcat Forum

Full Version: New rule function "backtrack" & reflect #
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
I believe the following rule functions would be quite useful:

Code:
Reflect    |  FN  |   Duplicate word reversed N times
Backtrack  |  BN  |   Duplicate word reversed except for last character N times
Backtrack  |  b   |   Duplicate word reversed except for last character

F1 | p@ssW0rd | p@ssW0rddr0Wss@p
B1 | p@ssW0rd | p@ssW0rdr0Wss@p
b  | p@ssW0rd | p@ssW0rdr0Wss@p (b/B1 & f/F1 are equivalent just as d/p1 are equivalent)

F2 | p@ssW0rd | p@ssW0rddr0Wss@pp@ssW0rd
B2 | p@ssW0rd | p@ssW0rdr0Wss@p@ssW0rd

The value of this is emphasized by googling a few keyboard patterns.

Code:
pattern : generically expressible by : proposed expression : google hits

qwert (x2)
qwerttrewq :  f  : f : 10,300
qwertrewq  : N/A : b : 79,000

qwert (x3)
qwerttrewqqwert : N/A : F2 :   660
qwertrewqwert   : N/A : B2 : 1,170

qwerty (x2)
qwertyytrewq :  f  : f : 64,700
qwertytrewq  : N/A : b :  9,730

qwe (x3)
qweewqqwe : N/A : F2 : 30,200
qwewqwe   : N/A : B2 : 86,200

qwe (x4)
qweewqqweewq : (f p1) : B3 : 13,900
qwewqwewq    :  N/A   : F3 : 17,900

qwertyuiop (x2)
qwertyuioppoiuytrewq :  f  : f : 7,340
qwertyuiopoiuytrewq  : N/A : b : 4,360

123456789 (x2)
123456789987654321 :  f  : f : 685,000
12345678987654321  : N/A : b : 410,000

As shown by the google hits this idea of not repeating the end character of a pattern before reversing the pattern seems to be roughly as popular (generally the same order of magnitude) as it is to repeat it.

I should clarify that all of the above that are marked as inexpressible can actually be expressed but not generically. They require multi-part duplicate/swap/delete rules that are specific to the input word length (and become increasingly complicated the more sweeps are done). The above proposal creates a general solution that easily allows for multiple sweeps through a pattern without worrying about input lengths.

Finally, as I was writing this I noticed that there is an error in the rules wiki page on the example for the pN function. It shows the following:

Code:
p3 | Pass | PassPassPass

this should be "p2"

Thanks!
Hi pragmatic

What a well thought out and explained feature request. Makes a nice change ! Smile

Even though I doubt I would use it much I hope Atom gives me the nod to add it to the "features to be implemented table", purely because of the time you took to explain it so well.

Thanks.
If this is about keyboard-walks, why dont you just use a keyboard walk generator and pipe it to stdin?
(09-29-2012, 03:07 PM)atom Wrote: [ -> ]If this is about keyboard-walks, why dont you just use a keyboard walk generator and pipe it to stdin?

First, I see use in general words as well:

Code:
mirrorrorrim :  56,900
mirrororrim  : 113,000

backwarddrawkcab :    349
backwardrawkcab  : 18,100

These are biased example since the words are skewed toward "reflection thinking". Let's try a few more general words:

snakeekans : 13,900
snakekans  : 10,100

greenneerg : 10,100
greeneerg  :  8,320

yellowwolley :  33,900
yellowolley  : 186,000

oceannaeco :  1,720
oceanaeco  : 23,200

The idea seems reasonably popular for general use as well as patterns.

There is also a cool construction that can be done with the "b/BN" rules that can't (at least that i can see) be done now without resorting to length specific rules:

If you want a word followed by a single separator followed by that word reversed such as:

mirror:rorrim
mirror|rorrim
mirror rorrim

You can do so using "b" easily with a rule like:

Code:
$: b

This method even plays well with other word mangling rules like r, $s, (] $i $n $g), etc... it creates a lot of flexibility.

Going even further with this, multiple repetitions such as:

mirror!rorrim!mirror

can be achieved with:

Code:
$! ^! B2 [ ]  (where $ represents the first separator and ^ the second)

This extends out to N times where:

Code:
$: ^| B(N-1) [ ]  (where $ will be the odd separator and ^ the even)

All of that said, on the original question of keyboard walks I would say that I prefer the idea of keeping clean wordlists that are as tight as possible and then using rules to mangle them as needed. The idea of generating wordlists, or even directly piping them, that do all of this backtracking however many times seems inefficient compared with having them expanded in hashcat's rule engine (I say while acknowledging that I have no deep insight into hashcat's internals).

Regardless, this functionality would add some unique and seemingly useful flexibility to the hashcat suite.

Finally, on the topic of keyboard walk generators, I was actually starting to write one when I saw the usefulness of having rules like this in hashcat. I have yet to find one that did all that I wanted, although the only one I've found is d3ad0ne's so it's a small sample size. If you have any others you'd recommend I'd love to hear about them and potentially save myself duplicating effort.
JtR has an keyboard walk generator (not sure how good it is compared to deadones) plus you can use --stdout.

About your new function I am thinking of a different way to let you achieve what you are trying to do. A command that enables even more flexibility. I am thinking of a remember function, or memorize function. In a way to make a snapshot of the current buffer and then with another command to append or prepend it. With such a function, it should be possible to do the same but enables even more usage. What you think ?
Thanks for the heads-up about JtR's external keyboard mode, I had no idea that was there and it is quite good. I may still go forward with mine but I'm definitely less motivated now as this is at least 80% of what I was looking for.

On your memorize idea, it sounds very intriguing. Do you have a rough idea of syntax/usage? That would probably be the fastest way for me to understand exactly what you have in mind.
Lets say you have "m1" for memorize, "m2" for append buffer and "m3" for prepend buffer.

The rule: m1 r [ m3

Should do the same as "b".

m1 remembers the original buffer "p@ssW0rd".

r reverses it, so it becomes "dr0Wss@p"

[ removes the first character, so it becomes "r0Wss@p"

m3 prepends the saved buffer, so it becomes p@ssW0rdr0Wss@p

But there should be a lot of other scenarios where this could be used
(10-01-2012, 10:22 AM)pragmatic Wrote: [ -> ]I may still go forward with mine but I'm definitely less motivated now as this is at least 80% of what I was looking for.

Please don't stop development of a new tool because there is an older one that does some of what you want.

If you are waiting for people to show interest then here I am ! Smile
(10-01-2012, 10:45 AM)atom Wrote: [ -> ]Lets say you have "m1" for memorize, "m2" for append buffer and "m3" for prepend buffer.

The rule: m1 r [ m3

Should do the same as "b".

m1 remembers the original buffer "p@ssW0rd".

r reverses it, so it becomes "dr0Wss@p"

[ removes the first character, so it becomes "r0Wss@p"

m3 prepends the saved buffer, so it becomes p@ssW0rdr0Wss@p

But there should be a lot of other scenarios where this could be used

Very interesting, yes. There may be a better way but off the top of my head my other function suggestions BN/FN could be implemented using your new method as:

Code:
f/F1 : f (obviously)

Equivalent to FN (for N > 1):
N Even : m1 f p((N/2)-1) m2
N Odd  : f p((N-1)/2)

&

b/B1 : m1 r [ m3 <- As you pointed out

Equivalent to BN (for N > 1):
N Even : m1 r ] m2 [ p((N/2)-1) m3
N Odd  : m1 r [ m3 m1 ] p(((N-1)/2)-1) m2

Where p0 is assumed to fall out / do nothing.

Obviously these are significantly more complex for this specific use-case than b/BN/FN, but the extra flexibility is very nice.

Perhaps you could consider going one step further with this idea and allow manipulation of the buffer itself using standard rule functions prepended by m. For instance:

m$s <- append s to the buffer
mr <- reverse the buffer
mp3 <- duplicate the buffer three time

etc..

Allowing this kind of functionality could really give a ton of flexibility. Either way though, this buffer idea is a good one, and would be very welcome.