[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <72194567043d294c210ecbb4d136b151@smtp.hushmail.com>
Date: Sat, 22 Dec 2012 11:57:38 +0100
From: magnum <john.magnum@...hmail.com>
To: john-users@...ts.openwall.com
Subject: Re: Rulesets combination and logs
On 22 Dec, 2012, at 3:39 , Rich Rumble <richrumble@...il.com> wrote:
> On Fri, Dec 21, 2012 at 6:44 PM, magnum <john.magnum@...hmail.com> wrote:
>> As you probably know there is this workaround though:
>>
>> ./john -w:wordlist -rules:best -stdout | ./john -pipe -rules:leetspeek hashfile
>>
>> This accomplishes the exact same thing but is not resumable. You could of course make it resumable by letting the first process produce a temporary output file instead of piping it, but that file could get mind-bogglingly huge. On the other hand you could get rid of some dupes by throwing unique into the mix:
>>
>> ./john -w:wordlist -rules:best -stdout | ./unique templist && ./john -w:templist -rules:leetspeek hashfile
> When doing "john stdout" to another instance of john (pipe for
> instance), does one need to do anything else to make sure the second
> instance is keeping up? What if I'm doing an office2010 file and I get
> 60-70 c/s (not kilo not M just 60-70), I'm sure the --pipe instance
> will begin to miss the hundreds/thousands/millions of iterations from
> the --stdout instance, they'd have to get queued somewhere. It's
> probably true of faster formats too, but currently I'm dealing with a
> very slow one.
You can rest assured there's no such problem at all. The first process will kindly wait for the buffer to get less full.
magnum
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.
