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.