|
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.