[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Sun, 07 Aug 2016 17:47:57 -0700
From: <writeonce@...ipix.org>
To: "Solar Designer" <solar@...nwall.com>, john-users@...ts.openwall.com
Subject: RE: JtR homepage update; Windows builds
> On Fri, Jul 29, 2016 at 01:00:43PM +0300, Solar Designer wrote:
> > On Fri, Jul 29, 2016 at 02:27:58PM +0530, Dhiru Kholia wrote:
> > > On Thu, Jul 28, 2016 at 11:41 PM, Solar Designer <solar@...nwall.com> wrote:
> > > > Latest development build for Windows, updated automatically (ZIP)
> > > >
> > > > pointing to:
> > > >
> > > > http://daily-builds.appspot.com/latest
> > >
> > > The code behind this site is at https://github.com/kholia/daily-builds URL.
> > >
> > > > Since I wasn't involved in the setup of the latter, I'd like to know who
> > > > was (magnum?) and how/where the builds are done. I notice they're with
> > > > MinGW rather than Cygwin - do we consider this reliable, complete enough,
> > > > and recommended for use? I guess it doesn't include OpenCL support,
> > > > does it? What about OpenMP and "--fork"? Other features?
> > >
> > > The builds are done on infrastructure provided by
> > > https://circleci.com/ and the CircleCI configuration resides in
> > > "circle.yml" file in the JtR jumbo repository.
> > >
> > > See https://github.com/magnumripper/JohnTheRipper/issues/1378 for more
> > > details about the setup.
> >
> > Thanks. Is it possible to do Cygwin builds using that infrastructure?
>
> Per that GitHub issue, I understand that the problem is those builds are
> done in a Linux container, and Cygwin doesn't support that. MinGW does.
> As a maybe-better alternative to MinGW, I hope we'll get JtR buildable
> and fully functional with midipix:
>
> http://midipix.org
>
As part of alpha release preparation we've added JtR to midipix_build.sh
for inclusion in the release tarball. After reading this thread I went
on to test the binary, then realized that x86-64.S was still an open
issue due to the different calling conventions. As all global functions
in x86-64.S take two arguments at the most, I went ahead and patched the
relevant spots using #ifdef __PE__ and a push-mov-pop wrapping method
(note that in the WIN64 ABI, both %rdi and %rsi are nonvolatile
registers). After applying the attached patch, all tests passed.
Attached log is from a Dell Latitude E5450, JtR built with -g3 -O2, musl
libc and libpsxscl built with -g3 -O0.
todo items:
1. signed .zip and .tar.gz of a statically linked john plus ntctty plus
ptycon, allowing users to run jtr in either a pty-based (midipix) or a
pipe-based (cygwin,msys) terminal, as well as inside of the native
console window (possibly invoked from within cmd.exe or powershell).
2. [cross-]build jumbo.
Item (1) is mostly a technicality, awaiting midipix alpha release. Item
(2) will probably require some extra work (iirc. last time I checked the
jumbo configure script tried running test programs even in
cross-compilation mode).
PS. the attached patch should also work for other win64 targets
(cygwin,mingw) as long as you #define __PE__ (which is a midipix
toolchain builtin) at the top of x86-64.S as needed.
> > > OpenMP is supported in these builds. However, the builds are not 100%
> > > reliable. I just found out that the builds do not run on Windows 10
> > > at all.
> >
> > > I don't think that anyone is actively working on fixing these issues.
> > > So these builds should not be considered fit for users yet.
> >
> > OK. I've just removed the link from JtR homepage.
>
> Meanwhile, the latest semi-official build of jumbo was of 1.7.9-jumbo-5,
> which is ancient. I've just replaced it (on the website) with a build
> of 1.8.0-jumbo-1 that I happened to have made in December 2014, but
> never released (since I wanted to make a cleaner build, but never got
> around to it). It's also very old by now, indeed.
>
> Before ZIP'ing it up, I ran:
>
> peflags --dynamicbase=true --nxcompat=true *.exe
>
> in the "run" directory. If there are no problem reports from this, we
> should make it default settings for our Windows builds. I previously
> brought this up here:
>
> http://www.openwall.com/lists/john-dev/2012/12/09/24
>
> Per my reading of what others were saying at the time, I thought that
> ASLR breaks Cygwin:
>
> http://cygwin.com/ml/cygwin/2012-04/msg00443.html
>
> However, I observed no ill effects in my quick testing of binaries with
> the above peflags applied to them.
>
> Another thing I do for (semi-)official Windows builds of JtR is convert
> text files to DOS linefeeds and add .txt suffixes (with a script) except
> to files that had a .txt suffix already or were outside of doc/. This
> time, I did it for doc/* and run/*.conf and run/password.lst. I used to
> also rename john.conf to john.ini (JtR itself checks for both
> filenames), but this time I did not because we got many other *.conf
> files included from the main john.conf now, and it would be inconsistent
> to rename just the top file, and it would be too much of a change to
> patch all the .include directives.
>
> These text file conversions and renames were not included in unofficial
> builds by JtR users.
>
> I'd appreciate comments on how the community would like this handled for
> Windows builds going forward, especially if we automate them. Such as:
> is it desirable that text files be converted to DOS linefeeds? Which
> text files should this apply to? Besides those I mentioned, there are
> also many Perl and Python scripts under run/ - I did not convert them
> now, but maybe we should be doing that as well?
>
> Alexander
>
View attachment "john.diff" of type "text/x-diff" (7000 bytes)
View attachment "john.log" of type "text/x-c++" (1159 bytes)
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.
