Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 18 Aug 2017 19:16:03 +0000
From: Glen B <lucky0106@....com>
To: "john-users@...ts.openwall.com" <john-users@...ts.openwall.com>
Subject: Re: Custom Windows build 1.8.0.9 - What happened to
 zip2john?

I really liked the earlier versions of JtR that were self-contained and didn't require downloading anything else to be honest. If this is just a symlink though, what is it symlink-ing to? The john binary? If so, couldn't I just run john directly?

I'm loading an Ubuntu VM right now to hopefully get to the bottom of this (and crack this bloody zip file that I've been working at for the past few days, lol)

Glen

----- Reply message -----
From: "Solar Designer" <solar@...nwall.com>
To: "john-users@...ts.openwall.com" <john-users@...ts.openwall.com>
Subject: [john-users] Custom Windows build 1.8.0.9 - What happened to zip2john?
Date: Fri, Aug 18, 2017 10:11 AM

On Fri, Aug 18, 2017 at 06:43:34PM +0200, magnum wrote:
> On 2017-08-18 17:39, Glen B wrote:
> >I was having issues with earlier builds and getting a hash of a ZIP file
> >read properly (according to zip2john at the time, it was a pkzip2
> >format). I've downloaded the latest Windows build from the wiki, John
> >the Ripper v1.8.0.9-jumbo-1-bleeding (Bleeding version on 2017-03-06).
> >Something that's new to me is that the zip2john executable seems to have
> >been replaced with a different file. The text initially reads "symlink"
> >with some non-text characters following. I'm assuming this is a linux
> >symlink file, which neither Windows nor I know how to interpret.
> >
> >I'm not having much luck searching GitHub for an explanation of this
> >change. Can anyone offer any tips on how I'm supposed to proceed with
> >cracking a zip file at this point?
>
> I believe you need to run from a Cygwin shell, not the CMD.EXE Windows
> shell.

That's what I think, too.

However, the reported problem indicates that something went wrong with
our Cygwin builds, and if it's still the case then we need to fix that.
We should have continued using the symlink.c wrapper instead of relying
on Cygwin's symlinks in that build.  Now, even more recent changes (as
discussed on a GitHub issue on fuzzing) may have changed that further.
Either way, our future Cygwin builds should be such that they'd be
usable without Cygwin installed, as long as the DLLs are included.

Alexander

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ