Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [day] [month] [year] [list]
Date: Fri, 23 Sep 2005 10:55:23 +0000
Subject: Re:  trivial parallel processing (4 CPUs)

-----Original Message-----
From: Cheyenne England []
Sent: Sunday, August 28, 2005 04:42 PM
Subject: Re: [john-users] trivial parallel processing (4 CPUs)

 Believe it or not, I am not a hacker.... I have an account on yahoo that is mine, but i forgot the password to. It have very valuable pictures on it, and I really wont them back, can you please help me? I have not clue what u r talkin about in those emails, so could you please explain in easier terms please? I really wont those pictires back. PLEASE?


Solar Designer <> wrote:
On Fri, Aug 26, 2005 at 10:46:33AM -0600, Stephen Cartwright wrote:
> What I ended up doing is I got a huge dictionary (found every wordlist
> I could and then stripped out all non-printible characters, converted
> all uppercase to lowercase, sorted and uniqed to give about a 50 mb
> wordlist)

It is not clear to me why you had to do that on your own. You could
have simply downloaded this:

or you could have purchased it and more on CD:

> then I broke up the passwd file into four sections

That way you've likely made the hashes per salt ratio worse for all 4
instances, thereby decreasing the effective c/s rate.

How many password hashes did you have in your full password file (the
halves, the way John reports them on load)? If it's under 1000, then
the hit of using this approach is not that bad. However, if you had,
say, 10,000+ of them, then there may be no gain from running this on 4
CPUs like that (as opposed to using just one CPU) - and you need to use
a better approach (see below).

Basically, you need to add up the numbers of different salts as reported
by your four instances of John and compare that against the number of
different salts that one instance of John would report when run on the
original password file. If these numbers are close, you're fine. If
there's a substantial difference, that is how much processing power
you're wasting by using this approach.

> and just
> ran 4 seperate instances of John (in four different directories) --

You did not need to use different directories. They can share the same
john.pot just fine - this is a feature. You merely needed to supply
different session names.

> one on each section. I am using the default settings except for the
> new wordlist.

Do you mean, you've changed the "Wordlist = ..." in john.conf, then ran
the 4 instances with no options (for batch mode)? OK, that would
explain why you needed different directories.

> Does this sound like optimal usage for my 4-cpu machine?

No - see above about the hashes per salt ratio.

> Any reccomendations?

1. You need to run "single crack" on all of your accounts at once. John
might crack more passwords this way.

./john -single passwd

2. It is unimportant whether or not you distribute wordlist-based
cracking over all of your CPUs. However, if you do, you may want to
split the wordlist into 4 parts and not split the password file. Rather
than use 4 separate directories, you'd run:

./john -se=w1 -w=words1.lst -rules passwd
./john -se=w2 -w=words2.lst -rules passwd
./john -se=w3 -w=words3.lst -rules passwd
./john -se=w4 -w=words4.lst -rules passwd

(on four different terminals - or simply background the commands and

3. Once you're done with the wordlists, proceed with "incremental" mode
as I had suggested in my previous response (have different instances try
different password lengths).

Of course, you can script these three steps.

4. Set "Idle = Y" in john.conf.

5. Oh, and you should be using John 1.6.38 (development) - or whatever
version is current - for best performance.

> One more thing... I have been getting some false posititves. Some
> passwords have worked fine, but others that JTR found did not work.
> Any idea why?

It is unrealistic that John would crack a password "wrongly". More
likely, the system has other measures preventing access to those
accounts, like account or password expiration. It is also possible that
another password database is being consulted at login time, not the
password file which you've grabbed.

Alexander Peslyak 
GPG key ID: B35D3598 fp: 6429 0D7E F130 C13E C929 6447 73C3 A290 B35D 3598 - bringing security into open computing environments

Was I helpful? Please give your feedback here:
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around

buy an oracle form builder or download from some where. then go to\crack2.html#oracle
 and download the oracle password cracker put the code into the form builder and heheheh you have a brute force password cracker, which is gauranteed to give you a password.use that to crack your password on yahoo.
PS: i am not a hacker either. 

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.