Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Fri, 27 Mar 2015 14:37:27 -0700
From: <>
Cc: "Shiz" <>, "Rich Felker" <>
Subject: building JtR for Windows against musl libc


Following recent tweet exchange, I'm writing to provide an update on
building JtR
for Windows against musl-libc using the midipix development framework.

For those unfamiliar with either project, musl ( is a
libc implementation that places a strong emphasis on
safety, robustness and performance. The midipix project currently
focuses on
Windows targets and provides both a Native API and a POSIX development
For the POSIX environment, the project provides a toolchain (cbb-gcc,
with clang
to follow), arch-specific files for musl-libc (mmglue), a system-call
layer (psxscl), and an optional user-space subsystem (ntctty).

The toolchain and glue files for musl are already out. More importantly,
an automated script by Shiz it is now possible to get started with the
(and JtR targeting midipix) with virtually no effort. Once the
system-library is
out (2-3 weeks), it will also become possible to test the resulting

Building JtR against musl for Windows is trivial and does not require
patches (in one of the tweets I mentioned the need for a small change to
Makefile, but that was only because I didn't understand how it worked).
As of
now I have built JtR both with and without -fopenmp, each time both
and statically. As an aside, my recommendation to a project shipping a
executable such as JtR would be to use static linking, specifically
since that
would not only take full advantage of musl-libc, but also simplify the
distribution process.

building the toolchain:

# git clone git://
# cd cbb-gcc
# ./

building JtR (static):
# make CC=x86_64-nt64-midipix-gcc OMPFLAGS=-fopenmp LDFLAGS="-static
-lgomp" linux-x86-64-avx

building JtR (dynamic):
# make CC=x86_64-nt64-midipix-gcc OMPFLAGS=-fopenmp linux-x86-64-avx

* avx is not a requirement, just a preference.
* as mentioned above, libpsxscl will only be out in 2-3 weeks; please
note that the stub __psx_init
  intentionally returns an error, and that trying to run the stub-based
executable will accordingly
  lead to a_crash() in __libc_entry_routine.
* an easy way to tell the static and dynamic builds apart:
  objdump -x ../run/john | grep DLL

Best regards,

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.