Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Wed, 27 Apr 2011 12:37:22 -0500
From: (minga)
Subject: CNTL-C During Rule Generation causing problems


I have run into a small problem, that is starting to turn into a
larger problem.

During rule generation/expansion the 'catch' mechanism when a user
hits CNTL-C (or a kill signal is sent) is not working as I would
expect it. 

An example is in:

-c T0Q
-c T1QT[z0]
-c T2QT[z0]T[z1]
-c >D TDQT[z0]T[z1]T[z2]T[z3]T[z4]T[z5]T[z6]T[z7]T[z8]T[z9]T[zA]T[zB]T[zC]

When it gets to that last rule, expanding out all the possible 
combinations is taking a LOOOOONG time. Now, Im used to this as a 

But, we are working in a grid environment where jobs need to be able
to be killed and restored in a predictable manner. When a process is
killed during the cracking process (_not_ the rule expanding process)
all works according to plan. The session file is created, and can be
restored at a later time with no duplication of work.

But if a process is killed during the rule generation/expansion process
the session file is not updated with its progress, and if the job
is restored at a later time, the rule generation/expansion process
will start all over again at the offending (i.e. large) ruleset.

We have a time-out that says kill every john process after its run
for xx minutes - and then restart it (to get synced john.pot entries
from other jobs). If the timeout is too small - some jobs
will be stuck in an infinite loop of continually generating
rules, but not using them to crack. These john processes get
stuck at 99% - and never complete - therefor clogging up the
'grid' with bad processes.

My options are:

1) Set the timeout to be a larger value. Which I would prefer not to do.

2) Write rules that dont expand into such large values. 
   Which I could do, if I totally understood:

   -c TDQT[z0]T[z1]T[z2]T[z3]T[z4]T[z5]T[z6]T[z7]T[z8]T[z9]T[zA]T[zB]T[zC]

   I would prefer to not have to write weaker rules in order to get
   around an annoyance/bug in the code. (Maybe its a feature?)
   Its not just Rules:NT - other rules are causing fail conditions 
   as well.

3) Somehow change the behavior of CNTL-c during the rule 
   generation/expansion process. When I replicate this bug
   by hand - I have to hit CNTL-C twice to break out of a rule 
   generation/expansion process (and after one CNTL-C - 
   strace still shows john generating _something_).

   Can this be done with crk_process_key() somewhere around line
   315 in wordlist.c ? ( My coding is rusty, sorry. )
   It seems like the do/while loop around that line number does
   not have a break; in the section around "if (rules) { " 
   (approx line 312 or so). Should it?

4) Use smaller wordlists. 

-Rick / Minga

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.