[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201120145653.GA30736@openwall.com>
Date: Fri, 20 Nov 2020 15:56:54 +0100
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Session management on AMI - Interrupting and resuming
Hi Mike,
On Fri, Nov 20, 2020 at 10:01:38PM +0900, SQP Admin wrote:
> We are currently running an Openwall Amazon AMI, running an incremental
> session on a ZIP archive. We have chosen to go with a c5.24xlarge
> infrastructure and using multiple CPU threads like so:
>
> john --session=XX --incremental=Alnum --fork=96 xxxx.hash
>
> We are in a situation where we expect getting a correct guess will take
> some time and also have budget restrictions. We understand sessions can
> be interrupted and resumed using the --restore=[sessionname] option. Here
> are my questions:
>
> 1. Is the approach we've taken to take advantage of the 96 CPUs correct?
> (--fork=96) - or is there a better way of leveraging that instance
> performance?
The approach you've taken is probably optimal, but we need to know
whether your archive is of PKZIP (fast) or WinZip (slow) kind. For
PKZIP, "--fork" is certainly the way to go. For WinZip, OpenMP works
well enough and is more flexible (allows you to adjust thread count on
restore) and enables incremental mode to test passwords in a slightly
more optimal order.
More importantly, does "--incremental=Alnum" match what you somehow know
about the password? Are you confident the password doesn't use
characters outside of this character set, and why?
The way incremental mode works, limiting the character set to Alnum (62
different characters) provides only a slight reduction in cracking time
(if the password fits this character set) than the default (letting JtR
use all 95 printable characters, but aware that most of those are rather
uncommon and are only commonly seen in certain combinations). So you
need to be very confident the password fits this character set in order
to reasonably limit the attack like that.
> 2. We had to logout from our ssh session a couple of times and don't
> know how to reconnect to our John session. We understand using
> --status=[sessionname] prints a status of the relevant session, however
> is there a way to reconnect to the session as when it was launched the
> first time and when pressing any key would display the status?
There are two ways:
1. Interrupt the session e.g. with "killall john", then restore it
almost right away (giving JtR just a little time to fully shut down)
with "john --restore=XX".
2. Use one of the tools "screen" or "tmux", both of which are readily
available in the AMI. You'd use them before you start the original
session, or before you restore it, so that you wouldn't have to do the
interrupt and restore thing again, but would simply re-attach to the
running session.
https://en.wikipedia.org/wiki/GNU_Screen
https://www.gnu.org/software/screen/
https://www.howtogeek.com/662422/how-to-use-linuxs-screen-command/
https://en.wikipedia.org/wiki/Tmux
https://github.com/tmux/tmux/wiki/Getting-Started
https://www.hamvocke.com/blog/a-quick-and-easy-guide-to-tmux/
https://www.howtogeek.com/671422/how-to-use-tmux-on-linux-and-why-its-better-than-screen/
> 3. As we are not connected to the John session anymore, we are unable to
> figure out how to interrupt it gracefully, as we would usually do using
> "q" when connected to a live session. Could you please advise on how to
> interrupt sessions after reconnecting to the instance's ssh?
The simplest way is "killall john". This isn't the cleanest (it'd be
cleaner to send the signal only to the parent process and let it handle
the rest), but it's clean enough. JtR intercepts the signal and makes a
final update of the .rec files before terminating. Even if it didn't,
by default it updates those files every minute anyway.
> 4. We are on monthly budget and are looking into the possibility of
> running our crack like so:
> - when budget is reached, interrupt the session, save .rec files locally
> and terminate the instance.
> - when a new budget is approved, launch a new similar instance, move
> back the .rec files to that instance and use the --restore command to
> resume it.
>
> Is this approach correct? If this works, we would need to understand how
> to interrupt a background session, as described in 3. Could you please
> advise?
The approach is correct, but if your monthly budget is fixed and known
in advance then you could choose an instance type that fits the budget
without you needing to interrupt and restore - e.g., maybe c5.18xlarge
just fits the budget? Of course, the largest instance is more optimal
in that it'd eventually crack the password sooner (even if merely sooner
within a particular month), but it sounds like using it would be more
work for you.
Most importantly, are you running this instance as spot? You really
should be, and maybe c5.24xlarge will fit your budget then, without
having to interrupt it?
> Thank you very much for your time and support.
Thank you for the very reasonable questions, and for supporting our
project by using the AMI.
Alexander
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.
