[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <656AD7A2-0E16-43F3-A6A3-02B596A8098B@shinnok.com>
Date: Mon, 13 Jul 2015 12:37:59 +0300
From: Shinnok <admin@...nnok.com>
To: john-dev@...ts.openwall.com
Subject: Re: *2john conversion support
> On Jul 10, 2015, at 5:27 PM, Rich Rumble <richrumble@...il.com> wrote:
>
> When I read the the Johnny goal of making cracking easier for users I
> immediately thought of how easy to use Passware and some of
> Elcomsoft's recovery tools are. They are in essence "next next finish"
> tools. You are presented with a choice (recover password from: A:
> Password Protected File, B: Hashed Password(s), C: Encrypted file(s)).
> Chose A, B or C and go to next, let's pick A ->next, Which type of
> file... Office, Browser, PDF, PGP, Compressed Archive... unknown...
> ->next
> The "trouble" with *2john.exe on windows is the lack of some binaries,
> there are 19 currently that compile for me when making john, possibly
> more if I had pcap sources installed... I've created an additional 28
> exe's from the python scripts by using pyinstaller and or py2exe. For
> most *nix flavors, python is easy to install and so are the required
> python lib's. One caveat to the *2john binaries that do compile is
> that most if not all require the john binary to work, and in addition
> to that, they require (unless modified) john to be called "J O H N"
> and not something like john_mpi.exe etc. Has to be john.exe (or john)
> I would love Johnny to go down the "next next finish" route, and to
> use *2john, but there are going to be some hurdles, and those above
> are just the ones I know about or have run into. If there were more
> binaries and less *2john scripts, you'd certainly have an easier time
> getting windows (I realize there are other OS's :) to use the *2john
> tools easier and without yet another "pack" of user contributed tools
> to download and use. I'm sure that would translate to other OS's too,
> not everyone has Python installed or want's too. Just my two cents of
> input :) For ease of use in file recovery, which I think most *2john
> tools are, next, next, finish is what I'd like to see. Perhaps the
> same for Johnny, I feel bad saying it since the interface isn't setup
> that way, but it's an idea.
Last I checked, Elcomsoft had a separate tool for each target and one wizard or similar to what you're describing that would open the right tool based on the selections followed by the user.
The biggest issues stopping us from doing more than what I proposed are:
1. The tools are written in different languages
2. They don't follow an interface for either parameters, input nor output(error reporting, etc..)
3. We don't have a maintainer for those and trying to make heads or tails of it will already take too much of mine and Mathieu's time. We don't even know how many of them are still supposed to work, we don't have a file format/version to script mapping, etc..
Maybe for another GSoC, we could have a potential task up for 2john script maintainer, to take care of converting them to a single scripting language, normalize to a single interface for parameters, input and output, test them and write some documentation. And after that work is done, Johnny could pick the results up and make more of it through an UI.
PS: The john binary requirement and naming strict is interesting, thanks for bringing that up.
Regards,
Shinnok
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.
