New rule function "backtrack" & reflect #

New rule function "backtrack" & reflect # - Printable Version

+- hashcat Forum (https://hashcat.net/forum)
+-- Forum: Deprecated; Ancient Versions (https://hashcat.net/forum/forum-46.html)
+--- Forum: Feature Requests (https://hashcat.net/forum/forum-7.html)
+--- Thread: New rule function "backtrack" & reflect # (/thread-1610.html)

New rule function "backtrack" & reflect # - pragmatic - 09-29-2012

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!

RE: New rule function "backtrack" & reflect # - Hash-IT - 09-29-2012

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.

RE: New rule function "backtrack" & reflect # - atom - 09-29-2012

If this is about keyboard-walks, why dont you just use a keyboard walk generator and pipe it to stdin?

RE: New rule function "backtrack" & reflect # - pragmatic - 09-30-2012

(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.

RE: New rule function "backtrack" & reflect # - atom - 09-30-2012

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 ?

RE: New rule function "backtrack" & reflect # - pragmatic - 10-01-2012

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.

RE: New rule function "backtrack" & reflect # - atom - 10-01-2012

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

RE: New rule function "backtrack" & reflect # - Hash-IT - 10-01-2012

(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

RE: New rule function "backtrack" & reflect # - pragmatic - 10-03-2012

(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.