Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 27 Nov 2018 17:46:24 +0100
From: Solar Designer <>
Subject: Re: Most efficient way to brute force

On Mon, Nov 26, 2018 at 08:21:58PM -0500, Powen Cheng wrote:
> This is the test setup that I am stuck with so I want to make sure that
> these two commands are the most efficient way to brute force with 8 threads
> per video card.
> As per magnumripper, using two separate terminals.
> OMP_NUM_THREADS=8 ./john -dev=0 -node=1/2 -form=tezos-opencl
> -ses=tezos1 tezos -inc
> OMP_NUM_THREADS=8 ./john -dev=1 -node=2/2 -form=tezos-opencl
> -ses=tezos2 tezos -inc

These may be fine (assuming you have at least 16 logical CPUs), but most
importantly you need to focus the attack based on what you know/recall
about the password.  You previously tried asking about that, and I
recommended that you use mask mode, possibly along with other modes:

This remains my current recommendation.  Have you tried it?  How?
What were the results?

> I was told to use --incremental and I read that I could also create and use
> my own custom Incremental.

You could, but why would you?  Chances are that whatever you know/recall
about the password is best expressed as a mask.

> [Incremental:Custom]
> File = custom.chr
> CharCount = 95
> MinLen = 6
> MaxLen = 8
> So to use my own custom incremental. I would simply add -inc:custom -
> is this correct?
> OMP_NUM_THREADS=8 ./john -dev=0 -node=1/2 -form=tezos-opencl
> -ses=tezos1 tezos -inc:custom
> OMP_NUM_THREADS=8 ./john -dev=1 -node=2/2 -form=tezos-opencl
> -ses=tezos2 tezos -inc:custom

Yes, but you probably don't need to do that.

> Since the MinLen starts at 6. I am guessing that it would start with
> 000000 up to charset?
> Then when Length of 6 is done, it would move to 7 or 0000000, etc.
> Please help me understand how incremental work with John.

Under the hood, and in terms of ordering of candidate passwords tried,
it's far more complex than that.  It will be switching lengths back and
forth, and will be testing weird-looking sequences of characters, trying
to optimize for non-increasing estimated probability of each being the
password.  It estimates those probabilities based on previously known
passwords - the training set used when the .chr file was generated.  For
the .chr files bundled with JtR, the training set is the RockYou leak.

If you generate your own .chr file, you re-train based on whatever is in
your john.pot at that time.

> I want to make sure that I using this brute force as efficient as possible.

What approach is most efficient depends on what you know/recall about
the password.


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.