[john-users] John the Ripper v1.8.0.9-jumbo-1-bleeding (Bleeding version on 2017-09-01), compiled for windows, on the custom-builds site

[r***@netscape.net]

John Users,



I've compiled John the Ripper v1.8.0.9-jumbo-1-bleeding (Bleeding version on
2017-09-01) for 64-bit windows and placed on the custom builds site at,
http://openwall.info/wiki/john/custom-builds



Enjoy.



Information:



Does not include vncpcap2john and SIPdump, since this does
not easily compile on Windows.



This contains the MPI+OMP SSE4.1 build of John the Ripper
for MS Windows 64-bit, compiled in MS Windows with the latest version of
cygwin64.

Your CPU must support the SSE4.1 instruction set in order to
run these.



There are 13 cygwin DLLs need to run John. As requested,
these DLLs are in a separate file above, and must be copied into the run
folder, if you don't already have cygwin64 installed.





Build Info:



$ ./john -list=build-info

Version: 1.8.0.9-jumbo-1-bleeding

Build: cygwin 64-bit SSE4.1-ac MPI + OMP

SIMD: SSE4.1, interleaving: MD4:3 MD5:3 SHA1:1 SHA256:1
SHA512:1

$JOHN is ./

Format interface version: 14

Max. number of reported tunable costs: 3

Rec file version: REC4

Charset file version: CHR3

CHARSET_MIN: 1 (0x01)

CHARSET_MAX: 255 (0xff)

CHARSET_LENGTH: 24

SALT_HASH_SIZE: 1048576

Max. Markov mode level: 400

Max. Markov mode password length: 30

gcc version: 5.4.0

OpenCL headers version: 2.1

Crypto library: OpenSSL

OpenSSL library version: 0100020bf

OpenSSL 1.0.2k 26 Jan 2017

GMP library version: 6.1.2

File locking: fcntl()

fseek(): fseek

ftell(): ftell

fopen(): fopen

memmem(): System's





The following test results are included:

john-built-in-test-results.txt

john-test-suite-test-results.txt



Testing:

************ Errors *****************************

The Built-in test died at: Benchmarking:
PBKDF2-HMAC-MD5-opencl [PBKDF2-MD5 OpenCL 4x]...



Compiled by: Robert B. Harris from VA



http://openwall.info/wiki/john/custom-builds



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

[Frank Dittrich]

Hi Robrt,

Post by r***@netscape.net
Version: 1.8.0.9-jumbo-1-bleeding

Could you clone the git repository, and build from within your local
repository?

Then, the version string would show something like

Version: 1.8.0.6-jumbo-1-3229-g9bb5e94


This means, the binary was built using git commit 9bb5e94, which is 3229
commits after release 1.8.0.6-jumbo-1.
The actual commit id would be really useful in case of bug reports.

BTW:
The "Version: 1.8.0.9-jumbo-1-bleeding" version string when built
outside a git repository is somewhat misleading.

It looks "newer" than the "1.8.0.6-jumbo-1-3229-g9bb5e94", but it isn't.
Instead, this version string has been unchanged since 2016-07-08.
So, we never know if a user is running a more or less current binary or
a binary which is more than one year old.


Regards

Frank

[r***@netscape.net]

I'm not really sure how to do that. Can you point me to some directions on that?



-----Original Message-----
From: Frank Dittrich [mailto:***@mailbox.org]
Sent: Sunday, September 03, 2017 11:29 AM
To: john-***@lists.openwall.com
Subject: Re: [john-users] John the Ripper v1.8.0.9-jumbo-1-bleeding (Bleeding version on 2017-09-01), compiled for windows, on the custom-builds site

Hi Robrt,

Post by r***@netscape.net
Version: 1.8.0.9-jumbo-1-bleeding

Could you clone the git repository, and build from within your local repository?

Then, the version string would show something like

Version: 1.8.0.6-jumbo-1-3229-g9bb5e94


This means, the binary was built using git commit 9bb5e94, which is 3229 commits after release 1.8.0.6-jumbo-1.
The actual commit id would be really useful in case of bug reports.

BTW:
The "Version: 1.8.0.9-jumbo-1-bleeding" version string when built outside a git repository is somewhat misleading.

It looks "newer" than the "1.8.0.6-jumbo-1-3229-g9bb5e94", but it isn't.
Instead, this version string has been unchanged since 2016-07-08.
So, we never know if a user is running a more or less current binary or a binary which is more than one year old.


Regards

Frank


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

[r***@netscape.net]

Why does doing it the git way modify the version string, but downloading it as a zip does not?

-----Original Message-----
From: ***@netscape.net [mailto:***@netscape.net]
Sent: Sunday, September 03, 2017 11:39 AM
To: john-***@lists.openwall.com
Subject: RE: [john-users] John the Ripper v1.8.0.9-jumbo-1-bleeding (Bleeding version on 2017-09-01), compiled for windows, on the custom-builds site

I'm not really sure how to do that. Can you point me to some directions on that?



-----Original Message-----
From: Frank Dittrich [mailto:***@mailbox.org]
Sent: Sunday, September 03, 2017 11:29 AM
To: john-***@lists.openwall.com
Subject: Re: [john-users] John the Ripper v1.8.0.9-jumbo-1-bleeding (Bleeding version on 2017-09-01), compiled for windows, on the custom-builds site

Hi Robrt,

Post by r***@netscape.net
Version: 1.8.0.9-jumbo-1-bleeding

Could you clone the git repository, and build from within your local repository?

Then, the version string would show something like

Version: 1.8.0.6-jumbo-1-3229-g9bb5e94


This means, the binary was built using git commit 9bb5e94, which is 3229 commits after release 1.8.0.6-jumbo-1.
The actual commit id would be really useful in case of bug reports.

BTW:
The "Version: 1.8.0.9-jumbo-1-bleeding" version string when built outside a git repository is somewhat misleading.

It looks "newer" than the "1.8.0.6-jumbo-1-3229-g9bb5e94", but it isn't.
Instead, this version string has been unchanged since 2016-07-08.
So, we never know if a user is running a more or less current binary or a binary which is more than one year old.


Regards

Frank


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

[Frank Dittrich]

Hi Robert,

sorry for the late reply (been busy).

Post by r***@netscape.net
Why does doing it the git way modify the version string, but downloading it as a zip does not?

The version string is modified using a git command in the makefile, as
long as you are inside a git repository.
I think we could manage to execute a similar command whenever github
creates a tar ball or zip file for download, but so far we didn't.
(That version string wouldn't be as useful, since a user could have
changed files in his local directory after download, which the version
string wouldn't reflect.)

Post by r***@netscape.net
I'm not really sure how to do that. Can you point me to some directions on that?

You need to have git installed in addition to the tools you need to
build john.

As long as you don't intend to do john development, you just need 2 git
commands.

For the very first time, you use

***@u16m:~/git$ git clone https://github.com/magnumripper/JohnTheRipper
Cloning into 'JohnTheRipper'...
remote: Counting objects: 77391, done.
remote: Total 77391 (delta 0), reused 0 (delta 0), pack-reused 77391
Receiving objects: 100% (77391/77391), 85.53 MiB | 1.66 MiB/s, done.
Resolving deltas: 100% (60249/60249), done.
Checking connectivity... done.

So, git will then clone the remote repository into a new directory on
your local file system.
The git clone is larger than a tar ball, since it includes the complete
version history for all branches. Later updates will be faster and smaller.
(There are options to create a shallow clone, but that's an advanced topic.)

Now you just cd into the src subdirectory:

***@u16m:~/git$ cd JohnTheRipper/src/

and build john:

***@u16m:~/git/JohnTheRipper/src$ make -s distclean; ./configure
make: *** No rule to make target 'distclean'. Stop.
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking whether to compile using MPI... no
checking for gcc... gcc
[...]
Configure finished. Now 'make clean && make -s' to compile.


Don't worry about "make: *** No rule to make target 'distclean'. Stop."

This message will disappear after you ran ./configure...


***@u16m:~/git/JohnTheRipper/src$ make -s clean
***@u16m:~/git/JohnTheRipper/src$ make -s -j 16
ar: creating aes.a
ar: creating secp256k1.a

Make process completed.



If you wan to update your local git repository, to gat all the changes
since your last update (or since the initial clone), just move into any
directory of your local repository, e.g., into the src subdirectory.

Post by r***@netscape.net
git pull https://github.com/magnumripper/JohnTheRipper

From https://github.com/magnumripper/JohnTheRipper
* branch HEAD -> FETCH_HEAD
Updating 8930fb5..08a5c76
Fast-forward
src/crc32_fmt_plug.c | 2 +-
src/episerver_fmt_plug.c | 2 +-
src/opencl_pfx_fmt_plug.c | 2 +-
src/opencl_wpapsk_fmt_plug.c | 2 +-
src/pfx_fmt_plug.c | 2 +-
src/qnx_fmt_plug.c | 2 +-
src/rar2john.c | 6 ++++--
src/sapH_fmt_plug.c | 2 +-
src/wpapsk_fmt_plug.c | 2 +-
9 files changed, 12 insertions(+), 10 deletions(-)

(I entered a \, to be able to specify the git command on the
continuation prompt. Otherwise, I would have a line break in the git
command which might have been confusing.)

In this case, my output looks somewhat different to the output you'll
get, because I manipulated my local git repository to point to an
earlier commit. So, no new commits needed to be downloaded from github.

But in your case, git would download all the changes that occurred since
your git clone (or since the previous git pull)


Now, you can just repeat the build process with the most recent changes.

***@u16m:~/git/JohnTheRipper/src$ make -s distclean; ./configure



Best regards

Frank