[john-users] John the Ripper on Windows (includes OpenCL on Windows)

[Claudio André]

Hi all, after a private discussion about JtR on Windows I would like to
share my point of view [1].
---

I would say that if you need John for Windows you should use
https://rebrand.ly/JtRWin64 [2][3]:
- it is 100% JtR magnum's source code;
- it is built and tested on an actual (and auditable) Windows machine;
- it works on CMD, no need to install CygWin, ...
- I (tried, at least, to) handled all details;

For example: from jeff at
https://www.openwall.com/lists/john-users/2018/09/12/5

Warning: '/dev/shm' does not exists or is not a directory.
POSIX shared memory objects require the existance of this directory.
Create the directory '/dev/shm' and set the permissions to 01777.
For instance on the command line: mkdir -m 01777 /dev/shm
No OpenCL devices found

This is a known issue, please read:
- https://github.com/magnumripper/JohnTheRipper/issues/3191

Well, my advice is (and it applies to all "Windows situations"):
- use the package (https://rebrand.ly/JtRWin64) and check if it works;
- or verify if replacing cygOpenCL-1.dll with OpenCL.dll JtR works;
- or what happens if other format is used;

What I know:
- CygWin OpenCL DLL needs proper ICD information;
- This information might be in some package I'm not aware (yet). I need
to play with CygWin when I put my hands on some M$ box.
- I doubt you have all the necessary things in the right place.
- Anyway, IMO, the choices made by CygWin make sense;

That said, I know the package works "out of the box" for some people.
Still need to test it in the wild.

Claudio

[1] I'm not a mailing list user [4]. So, I'm afraid I can't be part of
the discussions.
[2] The readme is at
https://github.com/claudioandre-br/packages/blob/master/john-the-ripper/readme.md#windows
[3] At least,
     - check if you are running an updated CygWin
     - check if you have installed all needed CygWin OpenCL packages
     -  run `strace -e -f trace=open john [arguments]`
     And so on.
[4] They are pre-flood tech, IMO.

[Solar Designer]

Hi Claudio,

Thank you for posting this in here, and sorry for trying to get you into
a discussion on a mailing list again (I'll CC you, as I understand
you're not currently subscribed).

Post by Claudio André
I would say that if you need John for Windows you should use
- it is 100% JtR magnum's source code;
- it is built and tested on an actual (and auditable) Windows machine;
- it works on CMD, no need to install CygWin, ...
- I (tried, at least, to) handled all details;

Great, thanks! In what way is that Windows machine "auditable"? Isn't
it a third-party machine that we know little about? I'm also concerned
about the third-party link redirect service and third-party file
download hosting service (even if same company as the CI service where
we build these). Anyway, this is better than nothing for those
knowingly accepting the risk, so I've just added such links to:

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

Even though I didn't verify these downloads in any way (beyond my https
client checking the certificate's validity, which passed), I've just
added copies to:

https://download.openwall.net/pub/projects/john/contrib/windows/

which is linked not only from our wiki, but also from JtR homepage:

https://www.openwall.com/john/#contrib

Since the original filenames were non-informative, I've renamed the
files as follows:

mv win_x64.zip john-1.8.0.13-jumbo-b7eae75d7-win64.zip
mv lib_x64.zip john-1.8.0.13-jumbo-b7eae75d7-win64-libs.zip

My intent is to enable people to download this specific revision, which
will hopefully be reasonably usable for a while, without incurring the
risk of using third-party build, download, and link redirect services
for each additional download. (That risk would have been incurred just
once: when this specific build was made and when I downloaded it.)

Since my trust in these unofficial builds is limited, I am not
PGP-signing them. Unfortunately, this also means that if our server is
compromised, we might serve compromised downloads with no easy way for
users to detect that.

Ideally, we should be making builds that we could trust, and would be
willing to sign.

Post by Claudio André
- CygWin OpenCL DLL needs proper ICD information;

Most relevant is this comment:

https://github.com/magnumripper/JohnTheRipper/issues/3191#issuecomment-404051085

"arcfide commented on Jul 11

Okay, I got this fixed up. If you see claudioandre-br's comment, that's where ICD Vendor files are mentioned. He also gives a working example of a build that seems to work. I've got this working now on the current build.

It doesn't require any hard hacks, but I did figure out that the OpenCL drivers with Cygwin don't work without an ICD Vendor file. That means that there has to be a location to find such files. That means that the OpenCL support works on Windows if you run JtR from inside of a Cygwin installation.

To make this work for me on Windows, I installed Cygwin with OpenCL, and then created the /etc/OpenCL/vendors/nvidia.icd file that included the Cygwin path to nvopencl.dll mentioned above. After I did that, I ran JtR from inside of the Cygwin Terminal, which mounts and makes available the /etc/ directory. That has fixed things, and I can now see all of my devices and I can run JtR on the GPU with the appropriate speedups."

Claudio, I notice that your win_x64.zip includes:

33 08-09-18 18:42 etc/OpenCL/vendors/amd.icd
33 08-09-18 18:42 etc/OpenCL/vendors/nvidia.icd

BTW, somehow it also includes what's probably a left-over from testing:

99286 08-09-18 18:43 run/john.log
355 08-09-18 18:43 run/john.pot

Post by Claudio André
[2] The readme is at
https://github.com/claudioandre-br/packages/blob/master/john-the-ripper/readme.md#windows

Thanks. I also took this opportunity to add more links to your Ubuntu
snap package, which you also documented in there.

Alexander

[Claudio André]

Post by Solar Designer

Post by Claudio André
I would say that if you need John for Windows you should use
- it is 100% JtR magnum's source code;
- it is built and tested on an actual (and auditable) Windows machine;
- it works on CMD, no need to install CygWin, ...
- I (tried, at least, to) handled all details;

Great, thanks! In what way is that Windows machine "auditable"? Isn't
it a third-party machine that we know little about?

It means anyone can see what these machines have installed (packages and
versions) [1].
- See https://www.appveyor.com/docs/build-environment/
  1. The history of build worker image updates can be found online.
  2. Before rolling out an image update they do perform some testing.
- I guess any customer (deploying directly from AppVeyor) can ask for a
report about their environment.

=> In fact, AppVeyor allows us to run builds on our own cloud. So, if
needed, it just a matter of money to control 100% the process.

Post by Solar Designer
I'm also concerned
about the third-party link redirect service and third-party file
download hosting service (even if same company as the CI service where
we build these).

This was on purpose (the link is):
- Upgradeable: At this very moment the ZIP points to a version from 20
days ago. Later, today, I will update the ZIP to include latest changes
(e.g., the ETA bug fix). The link will reflect the change.
- Safe: I'm not offering a ZIP file to download. I offer a full view of
the build process. Anyone can see and analyze ALL build process and logs.
- Safe: I compute and print (using the read only log) the hash of the
ZIP file. I want people to see notice the computed hash.

Post by Solar Designer
https://openwall.info/wiki/john/custom-builds
Even though I didn't verify these downloads in any way (beyond my https
client checking the certificate's validity, which passed), I've just

You have a hash to verify these ZIP files (the algorithm used is SHA256).

Post by Solar Designer
Since my trust in these unofficial builds is limited, I am not
PGP-signing them. Unfortunately, this also means that if our server is
compromised, we might serve compromised downloads with no easy way for
users to detect that.
Ideally, we should be making builds that we could trust, and would be
willing to sign.

Again, you have a hash to verify these ZIP files (20 years in the
future). Also, as a customer, people do deploy directly from the CI
provider. So, it is just a matter of using your own cloud.

Post by Solar Designer

Post by Claudio André
- CygWin OpenCL DLL needs proper ICD information;

https://github.com/magnumripper/JohnTheRipper/issues/3191#issuecomment-404051085
"arcfide commented on Jul 11
Okay, I got this fixed up. If you see claudioandre-br's comment, that's where ICD Vendor files are mentioned. He also gives a working example of a build that seems to work. I've got this working now on the current build.
It doesn't require any hard hacks, but I did figure out that the OpenCL drivers with Cygwin don't work without an ICD Vendor file. That means that there has to be a location to find such files. That means that the OpenCL support works on Windows if you run JtR from inside of a Cygwin installation.
To make this work for me on Windows, I installed Cygwin with OpenCL, and then created the /etc/OpenCL/vendors/nvidia.icd file that included the Cygwin path to nvopencl.dll mentioned above. After I did that, I ran JtR from inside of the Cygwin Terminal, which mounts and makes available the /etc/ directory. That has fixed things, and I can now see all of my devices and I can run JtR on the GPU with the appropriate speedups."
33 08-09-18 18:42 etc/OpenCL/vendors/amd.icd
33 08-09-18 18:42 etc/OpenCL/vendors/nvidia.icd

Basically,
- CygWin is not needed to run JtR. But, of course, one can run JtR from
inside CygWin
- From a user point of view, to run OpenCL on Windows from inside CygWin:
   - Install the OpenCL package and:
       "echo 'c:\Windows\System32\amdocl64.dll' >
{john}/etc/OpenCL/vendors/amd.icd"
       "echo 'c:\Windows\System32\nvopencl.dll' >
{john}/etc/OpenCL/vendors/nvidia.icd"
- For Intel, `strace`, I have no idea what is the filename.

Post by Solar Designer
99286 08-09-18 18:43 run/john.log
355 08-09-18 18:43 run/john.pot

I'll take a look.

Claudio


[1] Build worker image is a template used to provision a virtual machine
for your build. Physical implementation of the template depends on the
build cloud platform and can be a master VHD for Hyper-V and Azure,
snapshot or image for GCE or AWS.