HTTP Digest access authentication
                  ---------------------------------



- How to create the password string :
-------------------------------------


user:$MAGIC$response$user$realm$method$uri$nonce$nonceCount$ClientNonce$qop

'$' is use as separator, you can change it in HDAA_fmt.c


Example of password string :

user:$response$679066476e67b5c7c4e88f04be567f8b$user$myrealm$GET$/$8c12bd8f728afe56d45a0ce846b70e5a$00000001$4b61913cec32e2c9$auth

Here the magic is '$response$'





- Demonstration :
-----------------

Tested on a : AMD Athlon(tm) 64 Processor 3000+

$ cat ./htdigest
moi:$response$faa6cb7d676e5b7c17fcbf966436aa0c$moi$myrealm$GET$/$af32592775d27b1cd06356b3a0db9ddf$00000001$8e1d49754a25aea7$auth
user:$response$679066476e67b5c7c4e88f04be567f8b$user$myrealm$GET$/$8c12bd8f728afe56d45a0ce846b70e5a$00000001$4b61913cec32e2c9$auth

$ ./john ./htdigest
Loaded 2 password hashes with 2 different salts (HTTP Digest access authentication [HDAA-MD5])
kikou            (moi)
nocode           (user)
guesses: 2  time: 0:00:01:27 (3)  c/s: 670223  trying: nocode





- Legacy HDAA support:
----------------------

If the system you are testing uses the old HDAA algorithm, you may cut the string after the nonce:

$ cat ./htdigest
user:$response$8663faf2337dbcb2c52882807592ec2c$user$myrealm$GET$/$8c12bd8f728afe56d45a0ce846b70e5a$

LM/NTLM Challenge / Response Authentication
JoMo-Kun (jmk at foofus dot net) ~ 2010

Microsoft Windows-based systems employ a challenge-response authentication
protocol as one of the mechanisms used to validate requests for remote file
access. The configured/negotiated authentication type, or level, determines how
the system will perform authentication attempts on behalf of users for either
incoming or outbound requests. These requests may be due to a user initiating a
logon session with a remote host or, in some cases, transparently by an
application they are running. In many cases, these exchanges can be replayed,
manipulated or captured for offline password cracking. The following text
discusses the available tools within the John the Ripper "Jumbo" patch for
performing offline password auditing of these specific captured challenge-
response pairs.

Why might these exchanges be of interest? A primary point of most penetration
tests is to find avenues through which the assessor can gain unauthorized access
to some resource. This often relies on the compromise of a system's local
accounts or the exploitation of some service-level vulnerability. The ability to
capture on-the-wire authentication exchanges and to crack the associated
password adds another option to the mix. The fact that these exchanges can be
cracked aids in demonstrating to clients why one authentication algorithm may be
preferred to another.

A given server is likely to use one of the following protocols for
authentication challenge-response: LMv1, NTLMv1, LMv2 or NTLMv2. It should be
noted that these protocols may use the LM and NTLM password hashes stored on a
system, but they are not the same thing. For an excellent in-depth discussion of
the protocols see the Davenport paper entitled "The NTLM Authentication Protocol
and Security Support Provider" [1]. For the purposes of this discussion, the key
item of note is that the LMv1 and NTLMv1 protocols consist of only a single
server challenge. This allows an attacker to force a client into authenticating
using a specific challenge and then attack that response using precomputed
Rainbow Tables.

There are a variety of methods for capturing challenge-response pairs, including
the use of tools such as MetaSploit and Ettercap. The author's preferred method
is to use a modified version of Samba[2]. The provided patch sets the server's
challenge to a fixed value (i.e. 0x1122334455667788) and logs all authentication
attempts in a format suitable for use with John. The patch also includes a
modification to the nmbd application. Nmbd is used to respond to broadcast
requests for NetBIOS name/IP information. The modified service simply responds
to all requests with its own IP address, often resulting in hosts unknowingly
authenticating to the wrong system. Another common method of forcing systems to
authenticate to the Samba server is through the use of HTML image source tags.
For example, simply inserting the tag "<img src=file://192.168.1.10/logo.gif>"
into a HTML message will cause some email client applications to automatically
perform an authentication attempt. Other examples include the use of specialized
desktop.ini files and many other mischievous tricks.

It is also worth noting that these challenge/response protocols are not limited
to the Microsoft File and Print Services. For example, Cisco's LEAP wireless
security mechanism, EAP-PEAP and PPTP all utilize a MS-CHAP handshake, or
modified variant. The NTLMv1 challenge/response set can be extracted from this
exchange and subjected to a brute-force guessing attack. Further discussion on
this subject is outside of the scope of this write-up, but would certainly
reveal numerous additional uses.

The LMv1 challenge-response mechanism suffers a number of technical limitations.
As previously noted, only a server challenge is used. This means that if the
challenge is set to a constant value, a given password will always result in
the same client authentication response. This allows for the precomputation of
password / LMv1 responses and their subsequent retrieval using tools such as
RainbowCrack.

To further exacerbate the issue, the LM hash used during the generation of the
LMv1 response converts a password into (at most) two 7 character upper-case
passwords. The LM hash is then split into three pieces prior to calculating the
LMv1 response. This process greatly reduces the size of the Rainbow Tables which
need to be calculated in order to break a given password. For example, the
so-called "halflmchall" tables widely available on the Internet utilize only the
first third of the LMv1 response to break the first 7 characters of the
respective password. The netnlm.pl script discussed in this document can be used
to attempt to break the remaining characters of the password and its original
case-sensitive version. The following is an example of cracking a captured
LMv1/NTLMv1 challenge/response set.

Example LMv1/NTLMv1 Challenge/Response (.lc Format):
user::WORKGROUP:5237496CFCBD3C0CB0B1D6E0D579FE9977C173BC9AA997EF:A37C5C9316D9175589FDC21F260993DAF3644F1AAE2A3DFE:112233445566778

LMv1 Response: 5237496CFCBD3C0CB0B1D6E0D579FE9977C173BC9AA997EF
NTLMv1 Response: A37C5C9316D9175589FDC21F260993DAF3644F1AAE2A3DFE
Server Challenge: 112233445566778

RainbowCrack look-up of password's first 7 characters (upper-cased) using first
third (8 bytes) of LMv1 response:
$ rcrack halflmchall/*.rt -f 5237496CFCBD3C0C
Result: CRICKET

First netntlm.pl Pass (Crack Remaining Characters):
$ netntlm.pl --file capture.lc --seed CRICKET
Result: CRICKET88!

Second netntlm.pl Pass (Determine Case Sensitive Password)[a]:
$ netntlm.pl --file capture.lc
Result: Cricket88!

[a] Note that the case-sensitive password will be shown about a third through
the script's output following the text: "Performing NTLM case-sensitive crack
for account".

The following is an example of cracking a captured NTLMv1 challenge/response. If
the LMv1 and NTLMv1 response hashes within a given client response are
identical, it typically means one of two things: either the client machine is
configured to send only a NTLMv1 response (e.g. LAN Manager Authentication Level
Group Policy Object set to "Send NTLM response only"), or the user's password is
greater than 14 characters. If the password is indeed over 14 characters in
length, it is unlikely a suitable Rainbow Table set is available and brute-force
guessing will be exhaustively time-consuming.

Example NTLMv1 Challenge/Response (.lc Format):
user::WORKGROUP:A37C5C9316D9175589FDC21F260993DAF3644F1AAE2A3DFE:A37C5C9316D9175589FDC21F260993DAF3644F1AAE2A3DFE:1122334455667788

John Usage:
$ john --format=netntlm capture.lc

The LMv2 and NTLMv2 challenge/response protocols both employ unique client
challenges. This additional data effectively defeats the ability to precompute
password/response pairs via Rainbow Tables. It should also be noted that
despite its name, the LMv2 response is computed using a NTLM hash. This results
in a much harder-to-crack response hash, as the password was not truncated to
seven characters or upper-cased during the process.

The use of NTLMv2 is now the default policy within Microsoft Windows Vista and
Windows 7. Its use can be enforced for older versions via the LAN Manager
Authentication Level Group Policy Object ("Send NTLMv2 response only" (level 3
or higher)).

Example LMv2 Challenge/Response (.lc Format):
user::WORKGROUP:1122334455667788:6FAF764ECFDF1D1D9E7BA7B517190F3B:E15C1A679C7609CE

John Usage:
$ john --format=netlmv2 capture.lc

Example NTLMv2 Challenge/Response (.lc Format):
user::ATS-W759420A:1122334455667788:02E12C3C2B2F5799D2C1A7661AE80491:0101000000000000B0736308F1C9CA01DABA9E3A11AFD91F0000000002001000310030002E0030002E0032002E0032000000000000000000

John Usage:
$ john --format=netntlmv2 capture.lc


[1] http://davenport.sourceforge.net/ntlm.html
[2] http://www.foofus.net/jmk/smbchallenge.html

[![Build Status](https://travis-ci.com/magnumripper/JohnTheRipper.svg?branch=bleeding-jumbo)](https://travis-ci.com/magnumripper/JohnTheRipper)
[![Circle CI](https://circleci.com/gh/magnumripper/JohnTheRipper/tree/bleeding-jumbo.svg?style=shield)](https://circleci.com/gh/magnumripper/JohnTheRipper/tree/bleeding-jumbo)
[![Downloads](https://img.shields.io/badge/Download-Windows%20Build-blue.svg)](https://rebrand.ly/JtRWin64)
[![License](https://img.shields.io/badge/License-GPL%20v2%2B-blue.svg)](https://github.com/magnumripper/JohnTheRipper/blob/bleeding-jumbo/doc/LICENSE)
[![LoC](https://tokei.rs/b1/github/magnumripper/JohnTheRipper?category=code)](https://github.com/magnumripper/JohnTheRipper/tree/bleeding-jumbo)
[![Contributors](https://img.shields.io/github/contributors/magnumripper/JohnTheRipper.svg?label=Contributors)](https://github.com/magnumripper/JohnTheRipper/graphs/contributors)
[![Search hit](https://img.shields.io/github/search/magnumripper/JohnTheRipper/goto.svg?label=GitHub%20Hits)](https://github.com/search?utf8=%E2%9C%93&q=john%20the%20ripper&type=)

John the Ripper
===============

This is the community-enhanced, "jumbo" version of John the Ripper.
It has a lot of code, documentation, and data contributed by jumbo
developers and the user community.  It is easy for new code to be added
to jumbo, and the quality requirements are low, although lately we've
started subjecting all contributions to quite some automated testing.
This means that you get a lot of functionality that is not necessarily
"mature", which in turn means that bugs in this code are to be expected.

If you have any comments on this release or on JtR in general, please
join the john-users mailing list and post in there:

https://www.openwall.com/lists/john-users/

Licensing info:

https://openwall.info/wiki/john/licensing

For contributions to John the Ripper Jumbo, please use a
[pull requested (PR) on GitHub](https://github.com/magnumripper/JohnTheRipper/blob/bleeding-jumbo/CONTRIBUTING.md).

Included below is basic John the Ripper core documentation.

---

	John the Ripper password cracker.

John the Ripper is a fast password cracker, currently available for
many flavors of Unix, macOS, Windows, DOS, BeOS, and OpenVMS (the latter
requires a contributed patch).  Its primary purpose is to detect weak
Unix passwords.  Besides several crypt(3) password hash types most
commonly found on various Unix flavors, supported out of the box are
Kerberos/AFS and Windows LM hashes, as well as DES-based tripcodes, plus
hundreds of additional hashes and ciphers in "-jumbo" versions.


	How to install.

See INSTALL for information on installing John on your system.


	How to use.

To run John, you need to supply it with some password files and
optionally specify a cracking mode, like this, using the default order
of modes and assuming that "passwd" is a copy of your password file:

	john passwd

or, to restrict it to the wordlist mode only, but permitting the use
of word mangling rules:

	john --wordlist=password.lst --rules passwd

Cracked passwords will be printed to the terminal and saved in the
file called $JOHN/john.pot (in the documentation and in the
configuration file for John, "$JOHN" refers to John's "home
directory"; which directory it really is depends on how you installed
John).  The $JOHN/john.pot file is also used to not load password
hashes that you already cracked when you run John the next time.

To retrieve the cracked passwords, run:

	john --show passwd

While cracking, you can press any key for status, or 'q' or Ctrl-C to
abort the session saving its state to a file ($JOHN/john.rec by
default).  If you press Ctrl-C for a second time before John had a
chance to complete handling of your first Ctrl-C, John will abort
immediately without saving.  By default, the state is also saved every
10 minutes to permit for recovery in case of a crash.

To continue an interrupted session, run:

	john --restore

These are just the most essential things you can do with John.  For
a complete list of command line options and for more complicated usage
examples you should refer to OPTIONS and EXAMPLES, respectively.

Please note that "binary" (pre-compiled) distributions of John may
include alternate executables instead of just "john".  You may need to
choose the executable that fits your system best, e.g. "john-omp" to
take advantage of multiple CPUs and/or CPU cores.


	Features.

John the Ripper is designed to be both feature-rich and fast.  It
combines several cracking modes in one program and is fully
configurable for your particular needs (you can even define a custom
cracking mode using the built-in compiler supporting a subset of C).
Also, John is available for several different platforms which enables
you to use the same cracker everywhere (you can even continue a
cracking session which you started on another platform).

Out of the box, John supports (and autodetects) the following Unix
crypt(3) hash types: traditional DES-based, "bigcrypt", BSDI extended
DES-based, FreeBSD MD5-based (also used on Linux and in Cisco IOS), and
OpenBSD Blowfish-based (now also used on some Linux distributions and
supported by recent versions of Solaris).  Also supported out of the box
are Kerberos/AFS and Windows LM (DES-based) hashes, as well as DES-based
tripcodes.

When running on Linux distributions with glibc 2.7+, John 1.7.6+
additionally supports (and autodetects) SHA-crypt hashes (which are
actually used by recent versions of Fedora and Ubuntu), with optional
OpenMP parallelization (requires GCC 4.2+, needs to be explicitly
enabled at compile-time by uncommenting the proper OMPFLAGS line near
the beginning of the Makefile).

Similarly, when running on recent versions of Solaris, John 1.7.6+
supports and autodetects SHA-crypt and SunMD5 hashes, also with
optional OpenMP parallelization (requires GCC 4.2+ or recent Sun Studio,
needs to be explicitly enabled at compile-time by uncommenting the
proper OMPFLAGS line near the beginning of the Makefile and at runtime
by setting the OMP_NUM_THREADS environment variable to the desired
number of threads).

"-jumbo" versions add support for hundreds of additional hash and cipher
types, including fast built-in implementations of SHA-crypt and SunMD5,
Windows NTLM (MD4-based) password hashes, various macOS and Mac OS X
user password hashes, fast hashes such as raw MD5, SHA-1, SHA-256, and
SHA-512 (which many "web applications" historically misuse for
passwords), various other "web application" password hashes, various SQL
and LDAP server password hashes, and lots of other hash types, as well
as many non-hashes such as SSH private keys, S/Key skeykeys files,
Kerberos TGTs, encrypted filesystems such as macOS .dmg files and
"sparse bundles", encrypted archives such as ZIP (classic PKZIP and
WinZip/AES), RAR, and 7z, encrypted document files such as PDF and
Microsoft Office's - and these are just some examples.  To load some of
these larger files for cracking, a corresponding bundled *2john program
should be used first, and then its output fed into JtR -jumbo.


	Graphical User Interface (GUI).

There is an official GUI for John the Ripper: Johnny.

Despite the fact that Johnny is oriented onto JtR core, all basic
functionality is supposed to work in all versions, including jumbo.

Johnny is a separate program, therefore you need to have John the Ripper
installed in order to use it.

More information about Johnny and its releases is on the wiki:

https://openwall.info/wiki/john/johnny


	Documentation.

The rest of documentation is located in separate files, listed here in
the recommended order of reading:

* INSTALL - installation instructions
* OPTIONS - command line options and additional utilities
* MODES - cracking modes: what they are
* CONFIG (*) - how to customize
* RULES (*) - wordlist rules syntax
* EXTERNAL (*) - defining an external mode
* EXAMPLES - usage examples - strongly recommended
* FAQ - guess
* CHANGES (*) - history of changes
* CONTACT (*) - how to contact the author or otherwise obtain support
* CREDITS (*) - credits
* LICENSE - copyrights and licensing terms
* COPYING - GNU GPL version 2, as referenced by LICENSE above

(*) most users can safely skip these.

There are a lot of additional documentation files in jumbo's "doc"
directory, which you'll also want to explore.

Happy reading!

Here's how to build a CPU-fallback chain (with OpenMP fallback too) for
distros. See params.h for some background detail. The only actually tricky
part is escaping the quotes enough to survive just long enough.

We set the shared directory to /usr/local/share/john in this example, and the
path to executables to /usr/local/bin. The default private directory is ~/.john
and it will be created at runtime if it doesn't exist. Note that no make
target currently does the actual copy to final destination, we do that manually.

The user should always simply run "john" which in this case is AVX512 but will
seamlessly fallback to john-avx2 -> john-xop -> john-avx -> john-sse4.1 ->
john-ssse3 -> john-sse2 and finally to any of them with -non-omp, if
appropriate.

	./configure --disable-native-tests CPPFLAGS='-DJOHN_SYSTEMWIDE -DJOHN_SYSTEMWIDE_EXEC="\"/usr/local/bin\"" -DJOHN_SYSTEMWIDE_HOME="\"/usr/local/share/john\""' --disable-openmp &&
	make -s clean && make -sj4 strip &&
	mv ../run/john ../run/john-sse2-non-omp &&
	./configure --disable-native-tests CPPFLAGS='-DJOHN_SYSTEMWIDE -DJOHN_SYSTEMWIDE_EXEC="\"/usr/local/bin\"" -DJOHN_SYSTEMWIDE_HOME="\"/usr/local/share/john\"" -DOMP_FALLBACK -DOMP_FALLBACK_BINARY="\"john-sse2-non-omp\""' &&
	make -s clean && make -sj4 strip &&
	mv ../run/john ../run/john-sse2 &&
	rm -rf ../run/*.dSYM &&
	sudo mv ../run/{john-*,*2john,unshadow,unique,undrop,unafs,base64conv,tgtsnarf,mkvcalcproba,genmkvpwd,calc_stat,raw2dyna,cprepair,SIPdump} /usr/local/bin &&
	./configure --enable-simd=ssse3 --disable-openmp &&
	make -s clean && make -sj4 strip &&
	mv ../run/john ../run/john-ssse3-non-omp &&
	./configure --enable-simd=ssse3 CPPFLAGS='-DJOHN_SYSTEMWIDE -DJOHN_SYSTEMWIDE_EXEC="\"/usr/local/bin\"" -DJOHN_SYSTEMWIDE_HOME="\"/usr/local/share/john\"" -DOMP_FALLBACK -DOMP_FALLBACK_BINARY="\"john-ssse3-non-omp\"" -DCPU_FALLBACK -DCPU_FALLBACK_BINARY="\"john-sse2\""' &&
	make -s clean && make -sj4 strip &&
	mv ../run/john ../run/john-ssse3 &&
	./configure --enable-simd=sse4.1 --disable-openmp &&
	make -s clean && make -sj4 strip &&
	mv ../run/john ../run/john-sse4.1-non-omp &&
	./configure --enable-simd=sse4.1 CPPFLAGS='-DJOHN_SYSTEMWIDE -DJOHN_SYSTEMWIDE_EXEC="\"/usr/local/bin\"" -DJOHN_SYSTEMWIDE_HOME="\"/usr/local/share/john\"" -DOMP_FALLBACK -DOMP_FALLBACK_BINARY="\"john-sse4.1-non-omp\"" -DCPU_FALLBACK -DCPU_FALLBACK_BINARY="\"john-ssse3\""' &&
	make -s clean && make -sj4 strip &&
	mv ../run/john ../run/john-sse4.1 &&
	./configure --enable-simd=avx --disable-openmp &&
	make -s clean && make -sj4 strip &&
	mv ../run/john ../run/john-avx-non-omp &&
	./configure --enable-simd=avx CPPFLAGS='-DJOHN_SYSTEMWIDE -DJOHN_SYSTEMWIDE_EXEC="\"/usr/local/bin\"" -DJOHN_SYSTEMWIDE_HOME="\"/usr/local/share/john\"" -DOMP_FALLBACK -DOMP_FALLBACK_BINARY="\"john-avx-non-omp\"" -DCPU_FALLBACK -DCPU_FALLBACK_BINARY="\"john-sse4.1\""' &&
	make -s clean && make -sj4 strip &&
	mv ../run/john ../run/john-avx &&
	./configure --enable-simd=xop --disable-openmp &&
	make -s clean && make -sj4 strip &&
	mv ../run/john ../run/john-xop-non-omp &&
	./configure --enable-simd=xop CPPFLAGS='-DJOHN_SYSTEMWIDE -DJOHN_SYSTEMWIDE_EXEC="\"/usr/local/bin\"" -DJOHN_SYSTEMWIDE_HOME="\"/usr/local/share/john\"" -DOMP_FALLBACK -DOMP_FALLBACK_BINARY="\"john-xop-non-omp\"" -DCPU_FALLBACK -DCPU_FALLBACK_BINARY="\"john-avx\""' &&
	make -s clean && make -sj4 strip &&
	mv ../run/john ../run/john-xop &&
	./configure --enable-simd=avx2 --disable-openmp &&
	make -s clean && make -sj4 strip &&
	mv ../run/john ../run/john-avx2-non-omp &&
	./configure --enable-simd=avx2 CPPFLAGS='-DJOHN_SYSTEMWIDE -DJOHN_SYSTEMWIDE_EXEC="\"/usr/local/bin\"" -DJOHN_SYSTEMWIDE_HOME="\"/usr/local/share/john\"" -DOMP_FALLBACK -DOMP_FALLBACK_BINARY="\"john-avx2-non-omp\"" -DCPU_FALLBACK -DCPU_FALLBACK_BINARY="\"john-xop\""' &&
	make -s clean && make -sj4 strip &&
	mv ../run/john ../run/john-avx2 &&
	./configure --enable-simd=avx512f --disable-openmp &&
	make -s clean && make -sj4 strip &&
	mv ../run/john ../run/john-avx512f-non-omp &&
	./configure --enable-simd=avx512f CPPFLAGS='-DJOHN_SYSTEMWIDE -DJOHN_SYSTEMWIDE_EXEC="\"/usr/local/bin\"" -DJOHN_SYSTEMWIDE_HOME="\"/usr/local/share/john\"" -DOMP_FALLBACK -DOMP_FALLBACK_BINARY="\"john-avx512f-non-omp\"" -DCPU_FALLBACK -DCPU_FALLBACK_BINARY="\"john-avx2\""' &&
	make -s clean && make -sj4 strip &&
	mv ../run/john ../run/john-avx512f &&
	./configure --enable-simd=avx512bw --disable-openmp &&
	make -s clean && make -sj4 strip &&
	mv ../run/john ../run/john-non-omp &&
	./configure --enable-simd=avx512bw CPPFLAGS='-DJOHN_SYSTEMWIDE -DJOHN_SYSTEMWIDE_EXEC="\"/usr/local/bin\"" -DJOHN_SYSTEMWIDE_HOME="\"/usr/local/share/john\"" -DOMP_FALLBACK -DOMP_FALLBACK_BINARY="\"john-non-omp\"" -DCPU_FALLBACK -DCPU_FALLBACK_BINARY="\"john-avx512f\""' &&
	make -s clean && make -sj4 strip &&
	rm -rf ../run/*.dSYM &&
	sudo mv ../run/{john,john-*} /usr/local/bin &&
	sudo mkdir -p /usr/local/share/john &&
	sudo cp -a ../run/* /usr/local/share/john &&
	sudo mv /usr/local/share/john/*.{pl,py,rb} /usr/local/share/john/{relbench,benchmark-unify,mailer,makechr} /usr/local/bin &&
	echo All Done

PLEASE NOTE: You should definitely consider:

	sudo make shell-completion

Or something to that end - depending on what your tree looks like you might
simply want to symlink /usr/local/share/john/john.*_completion into
/etc/bash_completion.d instead.

Intel MIC (Xeon Phi) is a coprocessor computer architecture developed by Intel.
Program built for MIC cannot run on normal Intel processors. So you need to
have a MIC coprocessor and related enviroments setup before trying to build
John the Ripper (JtR) for MIC. Tutorial on how to setup the software
environments for MIC can be found on Intel's website.


-----------------------
Library Denpendencies:
-----------------------

JtR requires some libraries that are not available on MIC, which means you'll
need to build them for MIC by yourself.
These libraries are:
    Zlib (libz)
    GMP (libgmp)
    OpenSSL/LibreSSL (libssl & libcrypto)

They can be downloaded from their websites. But building them requires some
effort, and only the mentioned versions are guaranteed to work.
Assuming those libraries are to be install under path $MIC and the path to
JtR is $JOHN, then follow the steps below.

Build Zlib (version 1.2.8):
$ cd */zlib-1.2.8
$ CC="icc -mmic" ./configure --prefix=$MIC
$ make && make install

Build GMP (version 6.0.0a):
$ cd */gmp-6.0.0
$ ./configure CC="icc -mmic" --host=k1om --prefix=$MIC
$ make && make install

OpenSSL and LibreSSL offer almost the same functionality, you can use either one
as convenient.

Build OpenSSL (version 1.0.2a)
$ cd */openssl-1.0.2a
$ ./Configure linux-x86_64-icc -mmic no-asm shared --prefix=$MIC
$ make && make install

Build LibreSSL (version 2.1.6):
$ cd libressl-2.1.6
$ ./configure CC="icc -mmic" --host=k1om-linux --prefix=$MIC
$ make && make install


--------------
Building JtR:
--------------

After building those libraries, now it's straightforward to build JtR for MIC.

$ cd $JOHN/src
$ ./configure CC="icc -mmic" CPPFLAGS="-I$MIC/include" LDFLAGS="-L$MIC/lib" --host=mic-linux
$ make && make install

After that, you can use scp to transfer the executables and config files you
need under directory $JOHN/run to MIC.
You also need to transfer some dynamic libraries to MIC, which is requried by
JtR at runtime, including those mentioned above (under $MIC/lib) and the
following:
    libiomp*
    libimf
    libirng
    libintlc
    libsvml
They can be found under /opt/intel/lib/mic or some other directory you
specified when installing Intel compiler.


---------
Contact:
---------

If you still have problem building JtR for MIC, feel free to contact
<zhanglei.april@gmail.com> or JtR's mailing list.

Have fun.
Lei Zhang

====================
PRELUDE:
====================

You can use OpenCL if your video card - from now GPU - supports it.
ATI/AMD, Intel and Nvidia support it through their SDK available at
nvidia, Intel and ATI/AMD website.

Some recent distros have all (proprietry) stuff available as normal
packages.  N.B.  DON'T use X11 opensource drivers provided by your
distribution, only the vendor-supplied drivers support OpenCL.  Either
install fglrx (for old AMD cards) or nvidia dkms package or go directly
with the ones provided by nvidia and ATI.

Notice: Beignet, Mesa, and POCL are not officially supported, but may
be usable in some OpenCL formats.

You can also use OpenCL with CPU, mostly useful if you have several
(or loads of) cores.  This sometimes outperforms the CPU-only formats
due to better scaling than OMP, or due to vectorizing.  See Intel's
and AMD's web sites for drivers.  Note that an Intel driver does
support AMD CPU's and vice versa.

Ensure good cooling; Keep an eye on temperatures.  If the OpenCL runtime
supports it, GPU temperature will be monitored and shown on status lines
and there is a user changeable limit in john.conf that will terminate a
session at 95°C.

This code has been tested on Linux, macOS and Windows, see doc/BUGS for
known issues.

GPU formats won't improve your speed on very short runs due to longer
startup.  It also can't use GPU-side mask generation with "single mode"
so can't be significantly faster than on CPU for the few fastest of
formats in that mode.  For most formats though, "single mode" works fine
nowadays with the only caveats that you might need a whole lot of memory
(you'll get helpful messages if you need to adjust buffer size) and it
might resume pretty poorly (meaning if you stop it and then resume, a
good deal of work will be repeated before actually catching up).


====================
COMPILING:
====================

The new autoconf (./configure) should find your OpenCL installation and
enable it.  If it doesn't, you may need to pass some parameters about where
it's located, e.g.,
    ./configure LDFLAGS=-L/opt/AMDAPP/lib CFLAGS=-I/opt/AMDAPP/include
    make -sj4

To force a build without OpenCL, use:
    ./configure --disable-opencl
    make -sj4


ATI/AMD suggest you to use ATISTREAMSDKROOT env variable to
provide where you have installed their SDK root.
nvidia simply install it in /usr/local/nvidia .

The legacy Makefile assumes you have $ATISTREAMSDKROOT set up to point
to your ATI installation or you have $NVIDIA_CUDA pointing to nvidia
installation.

If in doubt do a

$ updatedb && locate CL/cl.h && locate libOpenCL.so

to locate your path to the includes and libOpenCL.

Adjust NVIDIA_CUDA or ATISTREAMSDKROOT to your needs and
if something is still wrong (but it shouldn't) send
an email to john-users@lists.openwall.com for help.


====================
Supported formats:
====================

See output of "./john --list=formats --format=opencl"


====================
USAGE:
====================

If no --format is given, john will always pick a CPU format.  To use OpenCL
you must explicitly select the format, e.g., --format=wpapsk-opencl


====================
Vectorized formats:
====================

A few formats will ask your device if it runs better vectorized,  and at what
width, and act accordingly.   A vectorized format runs faster on such devices
(notably CPUs,  depending on driver,  and pre-GCN AMD GPUs).  However, a side
effect might be register spilling which will just make it slower.  If a format
defaults  to vectorizing,  --force-scalar  will disable it.  You can also set
ForceScalar = Y  in john.conf to disable it globally.

If/when a format runs vectorized, it will show algorithm name as e.g.
[OpenCL 4x] as opposed to just [OpenCL].


====================
Work size tuning:
====================

All OpenCL formats will auto-tune to best speed, limited by things like
device memory or total duration for a batch of passwords.  You can override
the auto-tune using the command-line options -lws=N and/or -gws=N for local
and global work sizes respectively.  If one is given, the other will be auto-
tuned.  As an alternative, environment variables LWS and GWS can be used
instead, with the difference that the latter won't be stored to a session
file.  If both are used, the command-line options silently take precedence
over the environment variables.


====================
Watchdog Timer:
====================


If your GPU is also your active display device, a watchdog timer is enabled
by default - killing any kernel that runs for more than about five seconds
(nvidia) or two seconds (AMD).  You will normally not get a proper error
message, just some kind of failure after five seconds or more, like:

  OpenCL error (CL_INVALID_COMMAND_QUEUE) in file (OpenCL_encfs_fmt.c) (...)

Our goal is to split such kernels into subkernels with shorter durations but
in the meantime (and especially if running slow kernels on weak devices) you
might need to disable this watchdog.  For nvidia cards, you can check this
setting using "--list=OpenCL-devices".  Example output:

    Platform #0 name: NVIDIA CUDA, version: OpenCL 1.1 CUDA 4.2.1
        Device #0 (1) name:     GeForce GT 650M
        Device vendor:          NVIDIA Corporation
        Device type:            GPU (LE)
        Device version:         OpenCL 1.1 CUDA
        Driver version:         304.51
        Global Memory:          1023.10 MB
        Global Memory Cache:    32.0 KB
        Local Memory:           48.0 KB (Local)
        Max clock (MHz) :       900
        Max Work Group Size:    1024
        Parallel compute cores: 2
        Stream processors:      384  (2 x 192)
        Warp size:              32
        Max. GPRs/work-group:   65536
        Compute capability:     3.0 (sm_30)
        Kernel exec. timeout:   yes            <-- enabled watchdog

This particular output is not always available under macOS.  We are
currently not aware of any way to disable this watchdog under macOS.  Under
Linux (and possibly other systems using X), you can disable it for nvidia
cards by adding the 'Option "Interactive"' line to /etc/X11/xorg.conf:

    Section "Device"
        Identifier     "Device0"
        Driver         "nvidia"
        VendorName     "NVIDIA Corporation"
        Option         "Interactive"        "False"
    EndSection

At this time we are not aware of any way to check or change this for AMD cards.
What we do know is that some old AMD drivers will crash after repeated runs of
as short durations as 200 ms, necessating a reboot.  If this happens, just
upgrade your driver.


=====================
Multi-device support:
=====================

Currently only mscash2-OpenCL support multiple devices by itself.  However,
all other formats can use it together with MPI or the --fork option.  For
example, let's say you have four GPU or accelerator cards in your local host:

$ ./john -fork=4 -dev=gpu,acc -format=(...)

The above will fork to four processes and each process will use a different
GPU or Accelerator device.  The "-dev" option (--device) is likely needed
because it defaults to 'all' which may include unwanted devices.  Instead
of -dev=gpu,acc (use all/any GPUs and accelerators) you could specify them
explicitly if needed, e.g. -dev=1,2,6,7.

Or maybe you have two cards in a remote host called alpha and one card in
a host called bravo.  Build with MPI support and use this variant of the above:

$ mpirun -host alpha,alpha,bravo ./john -dev=gpu,acc -format=(...)

The above will start two processes on alpha, using different GPUs, as well
as one process on bravo.  In this case, the "-dev=gpu" option will be
enumerated on each host so if GPUs are devices 2 & 4 on alpha but device 1 on
bravo, that is not a problem.

If for some reason you want to run e.g.  two processes on each GPU, just double
the -fork argument or the MPI number of hosts (using -np option to mpirun).
The device list will round-robin.

Cracking PDF files with JtR
---------------------------

1. Run pdf2john.pl on the .pdf file(s).

E.g. $ ../run/pdf2john.pl test.pdf > hashes

2. Run john on the output of pdf2john.pl program.

E.g. $ ../run/john hashes

Cracking PST files with JtR
---------------------------

1. Run pst2john on the .pst file(s).

E.g. $ ../run/pst2john test.pst > hashes

2. Run john on the output of pst2john program.

E.g. $ ../run/john hashes

The "pst2john" program currently lives outside the JtR repository, and is
available at the https://github.com/kholia/pst2john URL.

Cracking TACACS+ hashes with JtR
---------------------------------

* Extract TACACS+ hashes from the .pcap file.

  $ ../run/pcap2john.py target.pcap > hashes


* Attack these hashes using JtR Jumbo.

  $ ../run/john --format:tacacs-plus hashes


* Reducing false positives based on the raw ideas contained in PR #2926. These
  ideas were also discovered by atom from the hashcat project.

  This technique requires having (at least) two TACACS+ packets with the same
  "seq_no" (last field in the hash) value, and using the same password.

  Sample hashes which satisy both these constraints,

  $ cat hashes
  $tacacs-plus$0$6d0e1631$d623c7692ca7b12f7ecef113bea72845$c004
  $tacacs-plus$0$6d0e1631$f7711e4b904fc4a4753e923e9bf3d2cc33e9febd3d2db74b9aa6d20462c2072013c77345d7112400d7b915$c002

  Cracking these hashes results in the following pot file,

  $ cat ../run/john.pot
  $tacacs-plus$0$6d0e1631$d623c7692ca7b12f7ecef113bea72845$c004:1234
  $tacacs-plus$0$6d0e1631$d623c7692ca7b12f7ecef113bea72845$c004:2u}0K!^
  $tacacs-plus$0$6d0e1631$d623c7692ca7b12f7ecef113bea72845$c004:ei,}3W#
  $tacacs-plus$0$6d0e1631$d623c7692ca7b12f7ecef113bea72845$c004:1234
  $tacacs-plus$0$6d0e1631$d623c7692ca7b12f7ecef113bea72845$c004:i8}42d$
  $tacacs-plus$0$6d0e1631$f7711e4b904fc4a4753e923e9bf3d2cc33e9febd3d2db74b9aa6d20462c2072013c77345d7112400d7b915$c002:I[s)|~#
  $tacacs-plus$0$6d0e1631$f7711e4b904fc4a4753e923e9bf3d2cc33e9febd3d2db74b9aa6d20462c2072013c77345d7112400d7b915$c002:4XdKNPF
  $tacacs-plus$0$6d0e1631$f7711e4b904fc4a4753e923e9bf3d2cc33e9febd3d2db74b9aa6d20462c2072013c77345d7112400d7b915$c002:9bf_6z+
  $tacacs-plus$0$6d0e1631$f7711e4b904fc4a4753e923e9bf3d2cc33e9febd3d2db74b9aa6d20462c2072013c77345d7112400d7b915$c002:1234
  $tacacs-plus$0$6d0e1631$f7711e4b904fc4a4753e923e9bf3d2cc33e9febd3d2db74b9aa6d20462c2072013c77345d7112400d7b915$c002:1234

  Filtering out the false positives (thanks to atom),

  $ perl -ne 'while (<>) { chomp; /(c00\d):(.*)/ or next; $db->{$2}->{$1} = undef; } for $pw (keys %{$db}) { next if scalar keys %{$db->{$pw}} == 1; print "$pw\n" }' < ../run/john.pot
  1234

  This reveals the actual password to be "1234".

Cracking ZIP files with JtR Jumbo
=================================

1. Run zip2john on password protected .zip file(s).

E.g. $ ../run/zip2john target.zip > hash

2. Run john on the output of zip2john.

E.g. $ ../run/john hash

3. Wait for the password to get cracked.

---------
Overview
---------
If you have ZTEX boards USB-FPGA 1.15y, you can use them with JtR.
Available "formats" are descrypt-ztex, bcrypt-ztex, sha512crypt-ztex,
Drupal7-ztex, sha256crypt-ztex, md5crypt-ztex, phpass-ztex.

-------------
How to build
-------------
To build JtR bleeding-jumbo with ZTEX 1.15y board support, install
libusb (e.g., the libusb-devel package on Fedora) in addition to jumbo's
usual dependencies.  Then use "./configure --enable-ztex".  The rest of
the build is as usual for jumbo.

---------------
Usage on Linux
---------------
To access a ZTEX board as non-root (and you shouldn't build nor run JtR
as root) on a Linux system with udev, add this:

ATTRS{idVendor}=="221a", ATTRS{idProduct}=="0100", SUBSYSTEMS=="usb", ACTION=="add", MODE="0660", GROUP="ztex"

e.g. to /etc/udev/rules.d/99-local.rules (create this file).  Then issue
these commands as root:

groupadd ztex
usermod -a -G ztex user # where "user" is your non-root username
systemctl restart systemd-udevd # or "service udev restart" if without systemd

In order to trigger udev to set the new permissions, (re)connect the
device after this point.

-----------------
Usage on Windows
-----------------
It requires WinUSB driver to access the board.
You can install the driver using Zadig 2.2 software.

----------------------
Format Specific Notes
----------------------
descrypt-ztex. That's a fast "format", USB 2.0 is unable to transfer
password candidates from the host at the rate they are computed.
Use mask mode to allow on-board candidate generation.
Other feature is the limit of no more than 2,047 hashes per salt.

bcrypt-ztex. You have to adjust TargetSetting in john.conf,
section [ZTEX:bcrypt] to reflect settings of your hashes.
Big difference between TargetSetting and setting of your hashes
would result in performance degradation or timeout.

sha512crypt-ztex, Drupal7-ztex. These 2 formats use same bitstream.
You'll have to adjust TargetRounds in john.conf in sections
[ZTEX:sha512crypt], [ZTEX:Drupal7] to reflect approximate rounds
setting of your hashes.

-----------------------------
Runtime Frequency Adjustment
-----------------------------
Frequency adjustment is available. You can set non-default frequency
in john.conf on per-format basis, in section [ZTEX:format_name].
Extreme overclocking results in some guesses being lost without notice,
you should check if 100% of test passwords are found at given frequency.
More overclocking results in errors. On error, JtR resets the board
while other boards continue operating. If there's a single board then
it waits until the board is up.

---------------------------
Troubleshooting ZTEX board
---------------------------
You can test the board using Ztex SDK. There are example applications
and FWLoader maintenance utility (requires java runtime).
Version ztex-140813b from http://www.ztex.de/ is known to work.
As 1.15y board is out of production, newer SDK versions might have limited
support for this board.

---------------
Various Issues
---------------
You can select a limited set of boards using "--devices" command-line
option (i.e. --dev=04A36E0000,04A36D0000). Several instances of john
each one with its own set of boards can be invoked. Right now such usage
is considered experimental - on some USB subsystems several instances
conflict one with another and errors appear.

Each board has a factory programmed Serial Number (SN). JtR displays
SNs on startup and in information/error messages. To hide SNs, you can
list SNs of your boards in [List.ZTEX:Devices] section in john.conf.
Board numbers (starting from 1) will appear instead of SNs. You can
specify these numbers in --dev command-line option.

================================================================================
This patch is Copyright (c) 2012, Mougey Camille (CEA/DAM), Lalet Pierre (CEA/DAM)
and it is hereby released to the general public under the following terms:
Redistribution and use in source and binary forms, with or without modification,
are permitted.
================================================================================

The package contains:

+ README:
        This file.

+ kdcdump.patch:
        A patch for MIT Kerberos 5 kdb5_util tool. Run it on a KDC server as
root to export the realm database unencrypted.

+ kdcdump2john.py:
        Converts the output of the previous tool in a JohnTheRipper
understandable format.

+ john.krb5-18-23_fmt.patch:
        Provide the format "krb5-18" (Kerberos5 aes256-cts-hmac-sha1-96) and
"krb5-23" (arcfour-hmac) for JohnTheRipper software. Tested on 1.7.9-jumbo-6.

================================================================================

Example:

>kdb5_util.patched
...
test/admin@OLYMPE.OL
18,fc77e6ffc07b469ba90ad4a979bcbb64709177c74af7f8eceaada0cdc84c1117
23,1667b5ee168fc31fba85ffb8f925fb70
16,52d5670752073ee6644a578945ada45efd2cc149a1620ea4
...

>kdb5_util.patched > dump; python kdcdump2john.py dump;
...
test/admin@OLYMPE.OL:$krb18$OLYMPE.OLtestadmin$fc77e6ffc07b469ba90ad4a979bcbb647
09177c74af7f8eceaada0cdc84c1117
test/admin@OLYMPE.OL:$krb23$1667b5ee168fc31fba85ffb8f925fb70
...

>python kdcump2john.py dump > job; john job --format=krb5-23;
...
aqzsedrf	(test/admin@OLYMPE.OL)

================================================================================


Note:
        If the KDC server is not properly configured and provide the both
format, prefer the Arcfour-hmac format.

# Credits and Contributors
Credits go to:

* philsmd, hashcat project

# License/Disclaimer

License: belongs to the PUBLIC DOMAIN, donated to hashcat, credits MUST go to hashcat and philsmd for their hard work. Thx

Disclaimer: WE PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE Furthermore, NO GUARANTEES THAT IT WORKS FOR YOU AND WORKS CORRECTLY

Cracking Apple Disk Images (DMG)
================================

1. Run dmg2john on .dmg file(s).

E.g. $ ../run/dmg2john test.dmg > hash

2. Run john on the output of dmg2john.

E.g. $ ../run/john hash

3. Wait for the password to get cracked.

You can use the "dmg-opencl" format if you have a GPU
for faster cracking.

This document is about cracking password protected BitLocker encrypted
volumes with JtR.

Step 1: Extract the hash
------------------------

In order to use the BitLocker-OpenCL format, you must produce a well-formatted
hash from your BitLocker encrypted image. Use the bitlocker2john tool to
extract hashes from password protected BitLocker encrypted volumes. It returns
four output hashes with different prefixes:

* If the device was encrypted using the User Password authentication method,
  bitlocker2john prints these two hashes:
  * $bitlocker$0$... : it starts the User Password fast attack mode
  * $bitlocker$1$... : it starts the User Password attack mode with MAC verification (slower execution, no false positives)

* In any case, bitlocker2john prints these two hashes:
  * $bitlocker$2$... : it starts the Recovery Password fast attack mode
  * $bitlocker$3$... : it starts the Recovery Password attack mode with MAC verification (slower execution, no false positives)

Hash extraction example,

$ ../run/bitlocker2john minimalistic.raw  # operate on a disk image
Signature found at 0x00010003
Version: 8
Invalid version, looking for a signature with valid version...
Signature found at 0x02110000
Version: 2 (Windows 7 or later)
VMK entry found at 0x021100b6
Key protector with user password found
minimalistic.raw:$bitlocker$0$16$e221443f32c419b74504ed51b0d66dbf$1048576$12$704e12c6c...

Instead of running bitlocker2john directly on BitLocker encrypted devices
(e.g. /dev/sdb1), you may use the dd command to create a disk image of a
device encrypted with BitLocker

$ sudo dd if=/dev/disk2 of=disk_image conv=noerror,sync
+4030464+0 records in
+4030464+0 records out
+2063597568 bytes transferred in 292.749849 secs (7049013 bytes/sec)

For further details about User Password and Recovery Password attacks, please
refer to the Wiki page: http://openwall.info/wiki/john/OpenCL-BitLocker.

Step 2: Attack!
---------------

Use the BitLocker-OpenCL format specifying the hash file:

$ ./john --format=bitlocker-opencl --wordlist=wordlist target_hash

Currently, this format is able to evaluate passwords having length between 8
(minimum password length) and 55 characters.

The mask you can use to generate Recovery Passwords is:

-mask=?d?d?d?d?d?d[-]?d?d?d?d?d?d[-]?d?d?d?d?d?d[-]?d?d?d?d?d?d[-]?d?d?d?d?d?d[-]?d?d?d?d?d?d[-]?d?d?d?d?d?d[-]?d?d?d?d?d?d

Links
-----

Samples BitLocker images for testing are available at,

* https://github.com/kholia/libbde/tree/bitlocker2john/samples
* https://github.com/e-ago/bitcracker/tree/master/Images

Samples of User Password/Recovery Passwords dictionaries are available at
https://github.com/e-ago/bitcracker/tree/master/Dictionary

More information on BitLocker cracking can be found at,

* http://openwall.info/wiki/john/OpenCL-BitLocker
* https://github.com/e-ago/bitcracker

Cracking Ethereum Geth/Mist/MyEtherWallet/Presale wallets
=========================================================

1. Run ethereum2john.py on .json wallet file(s).

E.g. $ ../run/ethereum2john.py ethwallet.json > hashes

2. Run john on the output of ethereum2john.py utility.

E.g. $ ../run/john hashes

3. Wait for the password(s) to get cracked.


To use a GPU for cracking run john as,

$ ../run/john --format=ethereum-opencl hashes  # for Ethereum wallets using PBKDF2

$ ../run/john --format=ethereum-presale-opencl hashes  # for Ethereum presale wallets

This document is about cracking password protected FileVault 2 encrypted
volumes with JtR.

First, build the "fvde2john" (https://github.com/kholia/fvde2john) project from
source. See https://github.com/libyal/libfvde/wiki/Building for help.


Second, use the built fvde2john project to extract hash(es) from the encrypted
FileVault 2 volume.

$ tar -xJf fvde-1.raw.tar.xz  # sample image for testing, from fvde2john project

$ sudo kpartx -v -a fvde-1.raw
add map loop2p1 (253:5): 0 1048496 linear /dev/loop2 40

$ sudo fvdetools/fvdeinfo -p dummy /dev/mapper/loop2p1  # this extracts the hashes
fvdeinfo 20160918

$fvde$1$16$e7eebaabacaffe04dd33d22fd09e30e5$41000$e9acbb4bc6dafb74aadb72c576fecf69c2ad45ccd4776d76


Here is how to extract hashes without using kpartx,

$ fdisk -l fvde-2.raw
Disk fvde-2.raw: 512 MiB, 536870912 bytes, 1048576 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: EBED216B-95C5-40D3-9C15-D352C8E9E357

Device      Start     End Sectors  Size Type
fvde-2.raw1    40 1048535 1048496  512M Apple Core storage

40 (Start) * 512 (Sector size) => 20480 => volume offset

$ ./fvdetools/fvdeinfo -o 20480 fvde-2.raw
fvdeinfo 20160918

$fvde$1$16$94c438acf87d68c2882d53aafaa4647d$70400$2deb811f803a68e5e1c4d63452f04e1cac4e5d259f2e2999
$fvde$1$16$94c438acf87d68c2882d53aafaa4647d$70400$2deb811f803a68e5e1c4d63452f04e1cac4e5d259f2e2999


Finally, give this hash string to JtR jumbo to crack.

$ cat hash
$fvde$1$16$e7eebaabacaffe04dd33d22fd09e30e5$41000$e9acbb4bc6dafb74aadb72c576fecf69c2ad45ccd4776d76

$ ../run/john hash -wordlist=wordlist
Using default input encoding: UTF-8
Loaded 1 password hash (FVDE, FileVault 2 [PBKDF2-SHA256 AES 256/256 AVX2 8x])
Will run 4 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
openwall         (?)


For more help with fvde2john, see the following URLs,

https://github.com/libyal/libfvde/wiki
https://github.com/libyal/libfvde/wiki/Troubleshooting

Building JtR-jumbo on FreeBSD
=============================

If you want to build "krb5-18_fmt.c" on FreeBSD then install "security/krb5"
from ports.

How to get & crack AS/400 hashes?

Assuming you have been granted access to an AS/400 server with *ALLOBJ and *SECADM privileges,
you will be able to download and crack the password hashes that are stored on the system to
assess password strength. Depending on the current setting of the QPWDLVL system value,
password hashes are stored in different formats on the AS/400:

QPWDLVL 0:
IBM DES hashes (supported by JtR with our 'as400-des' format plugin)
LM hashes (supported by default by JtR)
SHA1 uppercase hashes (supported by JtR with our 'as400-ssha1' format plugin)

QPWDLVL 1:
IBM DES hashes (supported by JtR with our 'as400-des' plugin)
SHA1 uppercase hashes (supported by JtR with our 'as400-ssha1' plugin)

QPWDLVL 2:
IBM DES hashes* (supported by JtR with our 'as400-des' plugin)
LM hashes** (supported by default by JtR)
SHA1 uppercase hashes*** (supported by JtR with our 'as400-ssha1' plugin)
SHA1 mixed case hashes (supported by JtR with our 'as400-ssha1' plugin)

QPWDLVL 3:
SHA1 uppercase hashes*** (supported by JtR with our 'as400-ssha1' plugin)
SHA1 mixed case hashes (supported by JtR with our 'as400-ssha1' plugin)

* Only if QPWDMAXLEN <=10
** Only if QPWDMAXLEN <=14
** Depending on password policy configuration

In this tutorial we describe how to extract and assess the strength of all these types
of hashes. Obviously, if LM hashes are available, you should go for these as these can be cracked very
efficiently by JtR or by using other programs and a rainbow table.
If LM hashes are not available, our 'as400-des' and 'as400-ssha1' plugins have you covered.

PREREQUISITES
In order to be able to grab and crack the hashes, you will need:
- the latest version of IBMiScanner (part of hack400tool), available on https://github.com/hackthelegacy/hack400tool
- the latest john the ripper jumbo release including our 'as400-des' and 'as400-ssha1' plugins.

LM hashes:
- Open IBMiScanner tool
- Provide at minimum: Username, Password, IP address/DNS name
- Click "Connect"
- From the list of available scans, select option 26: 'SECURITY: Get John the Ripper hashes (LM hash)'
- In the output directory, a file named 'lmhashes.txt' will be created.
- Copy the file to your John the Ripper 'run' directory
- Run john the ripper: john --format=LM {filename}
Enjoy the passwords :)

DES hashes:
- Open IBMiScanner tool
- Provide at minimum: Username, Password, IP address/DNS name
- Click "Connect"
- From the list of available scans, select option 29: 'SECURITY: Get John the Ripper hashes (DES)'
- In the output directory a file named 'DES-hashes.txt' will be created.
- Copy the file to your John the Ripper 'run' directory
- Run john the ripper: john --format=as400-des {filename}
Enjoy the passwords :)

SHA-1 hashes:
(Please note that this method is generic for both mixed and upper case)
- Open IBMiScanner tool
- Provide at minimum: Username, Password, IP address/DNS name
- Click "Connect"
- From the list of available scans, select option 27: 'SECURITY: Get John the Ripper hashes (SHA-1 hash uppercase)' for uppercase hashes.
- For mixed case hashes, you can choose for option 28: 'SECURITY: Get John the Ripper hashes SHA-1 hash mixed case)' respectively.
- In the output directory, a file named 'SHA-uc-hashes.txt' for uppercase hashes or 'SHA-mc-hashes.txt' for mixed case hashes will be created.
- Copy the file to your John the Ripper 'run' directory
- Run john the ripper: john --format=as400-ssha1 {filename}
Enjoy the passwords :)
Note: In case you used an older version of the IBMiscanner tool that outputs hashes in the format userid:hash, you can
use the ibmiscanner2john.py script to convert the file into a format that can be processed by JtR

http://hackthelegacy.org for more information and tooling.

The 'as400-ssha1' plugin was developed by Bart Kulach (@bartholozz) and Rob Schoemaker (@5up3rUs3r) with support of JimF (aka jfoug).
The 'as400-des' plugin was developed by Bart Kulach (@bartholozz) and Rob Schoemaker (@5up3rUs3r) with support of Dhiru Kholia.
The IBMiscanner tool is developed and maintained by Bart Kulach (@bartholozz).

Cracking LUKS passphrases
=========================

1. Run luks2john on a LUKS encrypted device or the output of
   cryptsetup luksHeaderBackup <device> --header-backup-file <file>

2. Run john on the output of luks2john

NOTES:

This version of John the Ripper supports cracking LUKS passphrases in a
very limited fashion.
The luks2john utility extracts just the information of one keyslot (the one
with the lowest iteration count), instead of extracting the information of
all used keyslots.
John's current LUKS hash representation has several drawbacks.
(Some information is stored more than once. The hash representation is
longer than it needs to be.)

For that reason, the LUKS hash representation used by this John the Ripper
version will most likely not be supported in future John the Ripper versions
which address the issues mentioned above.

That means, once a future John the Ripper release with full support for
cracking LUKS passphrases is released, you'll most likely need to re-run
luks2john on the LUKS encrypted device or LUKS header backup, and you'll
need to re-run john so that the new LUKS hashes will be stored in your pot file.
(The passwords you found for the old LUKS hash representation will work
for the new LUKS hash representation.)

IBM Lotus Domino hash extractor
===============================

It just reads the user.id file and extracts the ciphered blob at offset 0xD8
(16 bits word at offset 0xD6 is the blob size) and converts it to a hexadecimal
string to be used with the JtR plugin.

Usage
=====

1. Run lotus2john.py on Lotus Notes ID files

E.g. $ ../run/lotus2john openwall.id > hashes

2. Run john on the output of lotus2john.py utility

E.g. $ ../run/john hashes

Have fun :)

Fedora >= 22 cross-compiling instructions
=========================================

32-bit builds
-------------

$ sudo dnf install mingw32-openssl mingw32-openssl-static \
	mingw32-gcc mingw32-gcc-c++ binutils -y

$ ./configure --host=i686-w64-mingw32

$ make -sj4

64-bit builds
-------------

$ sudo dnf install mingw64-openssl mingw64-openssl-static \
	mingw64-gcc mingw64-gcc-c++ mingw64-winpthreads-static \
	mingw64-zlib-static mingw64-libgomp mingw64-binutils -y

$ ./configure --host=x86_64-w64-mingw32

$ make -sj4

Notes
-----

Ubuntu (and similar systems) do not have a full MinGW environment.

configure on my newest 64 bit Fedora required this:

AR=/usr/bin/x86_64-w64-mingw32-ar STRIP=/usr/bin/x86_64-w64-mingw32-strip \
	OPENSSL_LIBS="-lssl -lcrypto" ./configure --host=x86_64-w64-mingw32 \
	--build=x86_64-pc-linux

configure was not setting ar or strip properly. I have wine installed, so
without the --build the configure was NOT thinking it was doing a cross
compile. Also, the OPENSSL_LIBS had to be force listed for this cross
compile to link right.

Cracking RACF DES hashes with JtR
=================================

1. Run racf2john on RACF database files.

E.g. $ ../run/racf2john racf_database > hashes

2. Run john on the output of racf2john.

E.g. $ ../run/john hashes


Other useful RACF utilities
===========================

* https://www.nigelpentland.co.uk/utilities/ (includes RACFSNOW, racfmask, and racfunmask)

* https://github.com/zedsec390/masking (unmasks pre-DES RACF masked password hashes)

Cracking Tezos keys with JtR Jumbo
==================================

1. Run tezos2john.py and provide it with the required data. Run tezos2john.py
   without any options to see the usage instructions.

E.g. $ ../run/tezos2john.py 'put guide flat machine express cave hello connect stay local spike ski romance express brass' 'jbzbdybr.vpbdbxnn@tezos.example.org' 'tz1eTjPtwYjdcBMStwVdEcwY2YE3th1bXyMR' > hashes

E.g. $ ../run/tezos2john.py 'monster crack glance favorite humble group bone grid clock bottom employ gold jelly fatigue tragic' 'pfbbhuvm.jlbcintw@tezos.example.org' 'tz1Zgd3LHuryw6rBzsQKnBMVqu99KzWankj8' >> hashes

The passwords for these sample hashes are "4FGU8MpuCo" and "VPhvU2LgyJ" respectively.

2. Run john on the output of tezos2john.py script.

E.g. $ ../run/john hashes

3. Wait for the password(s) to get cracked.

#!/usr/bin/python

"""

Dumping APEX hashes
===================

1. Automated Way

C:\apex>sqlplus sys as sysdba

SQL*Plus: Release 11.2.0.2.0 Production on Fri Feb 22 17:20:51 2013

Copyright (c) 1982, 2010, Oracle.  All rights reserved.

Enter password:

Connected to:
Oracle Database 11g Express Edition Release 11.2.0.2.0 - Production

SQL> @dump-apex-hashes.sql

$ python apex2john.py apex-hashes.txt > apex-hashes-JtR

$ john pex-hashes-JtR # use JtR-jumbo from https://github.com/magnumripper/JohnTheRipper/
Loaded 1 password hash (dynamic_1: md5($p.$s) (joomla) [128/128 SSE2 intrinsics 10x4x3])
password         (?)
guesses: 1  time: 0:00:00:00 DONE (Thu Feb 21 17:33:43 2013)  c/s: 375  trying: 123456 - boomer

2. Manual Way

SQL> alter session set current_schema = APEX_040200;

Session altered.

SQL> select user_name,web_password2,security_group_id from wwv_flow_fnd_user;

USER_NAME
--------------------------------------------------------------------------------
WEB_PASSWORD2
--------------------------------------------------------------------------------
SECURITY_GROUP_ID
-----------------
ADMIN
F96D32CBB2FBE17732C3BBAB91C14F3A
10

...

$ cat dump-apex-hashes.sql
set colsep ','
set echo off
set feedback off
set linesize 1000
set pagesize 0
set sqlprompt ''
set trimspool on
set headsep off
set termout off
alter session set current_schema = APEX_040200;
spool "apex-hashes.txt"
select user_name,web_password2,security_group_id from wwv_flow_fnd_user;
spool off

"""

import hashlib

username = "ADMIN"
sgid = "10"
password = "password"

# APEX 4.2.1 algorithm
print username, sgid, password, hashlib.md5(password + sgid + username).hexdigest()

# should print "f96d32cbb2fbe17732c3bbab91c14f3a" which is the actual hash

	Enabling bash completion for John the Ripper

To enable bash completion for john and unique for all users, just use

make bash-completion

You need administrative privileges for this make target, because
the script john.bash_completion will be copied to /etc/bash_completion.d/.

To enable bash completion just for your user, it is enough to source
the bash completion script in your  ~/.bashrc
To to this, add the following line to your ~/.bashrc file:
. <path_to_john's_config_directory>/john.bash_completion

To just enable bash completion for john and unique temporarily,
just execute the following command in your current session:
$ . <path_to_john's_config_directory>/john.bash_completion

(The $ just indicates the command prompt, it is not part of the command.)

If you build different john versions, say a default (non-omp) version
named john, and an omp-enabled version named john-omp, you can enable
the same bash completion logic for the john-omp binary by adding this line
to your ~./bashrc file:
complete -F _john john-omp


	Prerequisites

The bash completion for john requires bash version >= 4,
and extended pattern matching features enabled.
If the command
	shopt -p extglob
prints
	shopt -s extglob
then the extended pattern matching features are enabled.
If this command
prints
	shopt -u extglob
then they are disabled.


	Features

The bash completion for unique does nothing for a non-jumbo build.
For a jumbo build, it supports completion for the command line options
which only exist for the jumbo version.


The bash completion for john supports file name completion for
password (hash) files.
It also supports completion for the command line options.


Abbreviated command line options are completed to their long form,
with two leading '-' characters.
For options with a mandatory value, the completion also adds the '='
character.


	Examples

$ ./john -w[tab]
results in completion to
$ ./john --wordlist=

$ ./john --wordlist=[tab][tab]
will list all file names in the current directory as possible completions.


$ ./john -fo[tab]

$ john --f[tab]
for an official, non-jumbo john version 1.7.8 results in completion to
$ john --format=

$ john --format=[tab][tab]
for the official john version 1.7.8 will list all the supported formats
as possible completions:
AFS    BF     BSDI   crypt  DES    LM     MD5

$ john --format=D[tab]
will be completed to
$ john --format=DES


For a jumbo version, e.g. 1.7.9-jumbo-5,
$ ./john -f[tab]
will become
$ ./john --f
The reason is that --format is not the only option starting with --f.

For this version,
$ ./john --f[tab][tab]
will list all possible completions like this:

$ ./john --f
--field-separator-char=  --fix-state-delay=       --format=

$ ./john --fo[tab]
will become
$ ./john --format=

$ ./john --format=[tab]tab]
will list all available formats of this version as possible completions:

$ ./john --format=
afs           lm            netntlm       raw-sha
bf            lotus5        netntlmv2     raw-sha1
bfegg         md4-gen       nsldap        raw-sha224
bsdi          md5           nt            raw-sha256
crc32         md5ns         nt2           raw-sha384
crypt         mediawiki     oracle        raw-sha512
des           mscash        oracle11      salted-sha1
dmd5          mscash2       pdf           sapb
dominosec     mschapv2      phpass-md5    sapg
dummy         mskrb5        phps          sha1-gen
dynamic       mssql         pix-md5       ssh
epi           mssql05       pkzip         sybasease
hdaa          mysql         po            trip
hmac-md5      mysql-fast    rar           xsha
hmailserver   mysql-sha1    raw-md4       xsha512
ipb2          nethalflm     raw-md5       zip
krb4          netlm         raw-md5thick
krb5          netlmv2       raw-md5u

$ ./john --format=a[tab]
will become
$ ./john --format=afs

To get possible completions for values of an option, it is not required
to use the full name of that option.
Instead, it is possible to start the option name with just one '-' character
instead of two.

It is also possible to use the ':' character (colon) instead of the '='
character (equal sign) to separate option name and value, because john
also supports this character as a separator between option and value.
(The completion logic for options with a colon as a separator depends on
the value of the environment variable COMP_WORDBREAKS.
The default logic explained here assumes that COMP_WORDBREAKS contains
the colon. The logic used when COMP_WORDBREAKS doen't contain the colon
is mentioned in the last chapter ("Config variables") of this document.)

Furthermore, the option name can be abbreviated, provided it is not ambiguous.

E.g., for an official, non-jumbo john version 1.7.8 bash completion will list
all supported hash formats as possible completions, if the  [tab] key
is pressed twice at the end of the command line:
$ john -f:
$ john -f=
$ john --f:
$ john --f=
$ john -fo:
$ john -fo=
$ john --fo:
$ john --fo=
...

For a jumbo build, the first 4 examples will not work, because the option name
is ambiguous.
A jumbo version also has the options --field-separator-char= and
--fix-state-delay=, so at least the first two letters of the option name
must be specified.

If future john versions get new options with names beginning with --fo,
even more letters need to be specified.

Similarly, for an official john version 1.7.8 build,
$ john -f:c[tab]
would become
$ john -f:crypt

And
$ john -fo=D[tab]
will become
$ john -fo=DES

That means, only the value will be completed, the option name and the separator
between option name and value remain unchanged.
This is OK, because john also supports using an abbreviated option name,
as long as it is not ambiguous.


If the john version supports the --list=hidden-options option, then the
hidden options (not mentioned in john's usage output) are also considered as
valid completions for option names.


	Special completion for certain options

	--format=

As mentioned above in the general description of the completion logic,
the completion logic considers all the supported formats, as listed
in john's usage output.
For the jumbo version, there is a special handling for the dynamic formats
(see the files DYNAMIC and DYNAMIC_SCRIPTING for more information).

$ ./john --format=dy[tab]
will become
$ ./john --format=dynamic

$ ./john --format=dynamic[tab]
will become
$ ./john --format=dynamic_

$ ./john --format=dynamic_[tab][tab]
will list all available dynamic formats, like this:

$ ./john --format=dynamic_
dynamic_0     dynamic_1006  dynamic_15    dynamic_22    dynamic_3
dynamic_1     dynamic_1007  dynamic_16    dynamic_23    dynamic_4
dynamic_10    dynamic_1008  dynamic_17    dynamic_24    dynamic_5
dynamic_1001  dynamic_1009  dynamic_18    dynamic_25    dynamic_6
dynamic_1002  dynamic_11    dynamic_19    dynamic_26    dynamic_7
dynamic_1003  dynamic_12    dynamic_2     dynamic_27    dynamic_8
dynamic_1004  dynamic_13    dynamic_20    dynamic_28    dynamic_9
dynamic_1005  dynamic_14    dynamic_21    dynamic_29


	--rules and --single

For official john version of john which don't support optional values
for --rules and --single, completion will just add a trailing space
at the end of the command line, so that the user can continue typing
the next word (e.g., an option or file name) on the command line.

Jumbo versions, however, support an optional value, as indicated by
john's usage output (--rules[=SECTION] and --single[=SECTION]).

For a jumbo version, the completion logic for options --rules
and --single depends on the contents of the environment variable
__john_completion, see the last chapter ("Config variables")
of this document.
The default logic works like this:

$ ./john --rules[tab][tab]
will list possible completions like this:
$ ./john --rules
--rules           --rules=single
--rules=NT        --rules=wordlist

In the above example, the upper case section name NT indicates that
the list of rules sections is a hard coded list of sections known to
exist in (almost) every john version.


For more recent versions which support the --list=rules option,
the list of section names will be obtained by interpreting the config
file (default john.conf or john.ini, unless another config file is
specified on the command line, see john's option --config=...)

In this case, the list of possible completions looks like this:

$ ./john --rules
--rules           --rules=single
--rules=nt        --rules=wordlist

(Please note that in this case all section names are lower case,
because john doesn't distinguish upper and lower case characters
in section names.)

If you add a section [List.Rules:My_Test] to john.conf,
$ ./john --rules[tab][tab]
will list possible completions like this:

$ ./john --rules
--rules           --rules=nt        --rules=wordlist
--rules=my_test   --rules=single

Since --single can use the same sections,
$ ./john --single[tab][tab]
will list possible completions like this:
$ ./john --single
--single           --single=nt        --single=wordlist
--single=my_test   --single=single

If you use another config file name my.conf with these rules sections
[List.Rules:some_rules]
[List.Rules:more_rules]
you can specify this config file on the command line.

$ ./john --conf=my.conf --rules[tab][tab]
will list possible completions like this:

$ ./john --conf=my.conf --rules
--rules             --rules=some_rules
--rules=more_rules

The same possible completions are listed if you switch the sequence
of the options on the command line, place the cursor immediately after
the word "--rules", and press the  [tab] key twice.

$ ./john --rules[tab][tab] --config=my.conf
will list possible completions like this:
$ ./john --rules --config=my.conf
--rules             --rules=some_rules
--rules=more_rules

$ ./john --rules=s[tab] --config=my.conf
will become
$ ./john --rules=some_rules --config=my.conf


	--incremental

The option --incremental can be used with and without a value.
Possible values are the Incremental section names defined in john.conf
(or another config file specified with --config=..., see the description
of the completion logic for --rules and --single).

The completion logic depends on the contents of the environment variable
__john_completion, see the last chapter ("Config variables")
of this document.
The default logic works like this:

If the john version doesn't support the --list=inc-modes option,
possible completions will be listed based on the john version and
incremental mode sections known to exist in (almost) all john versions:

$ ./john --incremental[tab][tab]
will list possible completions like this:

$ ./john --incremental
--incremental         --incremental=Alnum   --incremental=Digits
--incremental=All     --incremental=Alpha   --incremental=LanMan

If the john version supports --list=inc-modes, the possible completions
will be obtained by interpreting the config file (default john.conf or
john.ini, unless another config file is specified on the command line,
see john's option --config=...).

In this case, the possible completions listed might look like this:

$ ./john --incremental
--incremental          --incremental=all7     --incremental=digits
--incremental=all      --incremental=all8     --incremental=digits8
--incremental=all15    --incremental=alnum    --incremental=lanman
--incremental=all6     --incremental=alpha

$ ./john --incremental=l[tab]
will become
$ ./john --incremental=lanman

If all the incremental mode names are listed in lower case, you can also
use
$ ./john --incremental=L[tab]
This will become
$ ./john --incremental=lanman
as well.


	--external

If the john version supports the --list=externals option, the possible
completions will be obtained by interpreting the config file (default john.conf or
john.ini, unless another config file is specified on the command line,
see john's option --config=...).

In this case, the possible completions listed might look like this:

$ ./john --external=
appendluhn                filter_alnum
atleast1-generic          filter_alpha
atleast1-simple           filter_digits
autoabort                 filter_lanman
autostatus                filter_no_cap_or_symbols
datetime                  keyboard
double                    knownforce
double10                  lanman
double10_alnum            parallel1_2
double_all                parallel2_2
double_alnum              policy
dumb16                    repeats
dumb32                    strip
dumbforce                 subsets

(A config file specified on the command line will be taken into account when
determining the possible completions, see the description of the completion
for the options --incremental, --rules and --single.)


If the john version doesn't support the --list=externals option, the possible
completions are hard coded, depending on the john version you try to run.
In this case, the possible completions listed might look like this:

$ ./john --external=
AppendLuhn        DateTime          Filter_Digits     Parallel
AtLeast1-Generic  Double            Filter_LanMan     Policy
AtLeast1-Simple   DumbForce         Keyboard          Repeats
AutoAbort         Filter_Alnum      KnownForce        Strip
AutoStatus        Filter_Alpha      LanMan            Subsets

(john version 1.7.9-jumbo-5)

For john version 1.7.8, the list will look like this:

$ john --external=
AppendLuhn        DumbForce         Keyboard          Repeats
AtLeast1-Generic  Filter_Alnum      KnownForce        Strip
AtLeast1-Simple   Filter_Alpha      LanMan            Subsets
DateTime          Filter_Digits     Parallel
Double            Filter_LanMan     Policy

$ john --external=Da[tab]
will become
$ john --external=DateTime


	--make-charset=

Completion will list names of .chr files and directories in the
current directory for completion.

$ ./john --make-charset=[tab][tab]
might list completions like this:

$ ./john --make-charset=
all.chr     alpha.chr   lanman.chr
alnum.chr   digits.chr  subdir/

Please note that an existing file will be overwritten
when executing the command. So please be careful!


	--config=

If the john version supports the --config= option, possible completions
are all directory names and file names with the extensions .conf and .ini.
(Files with extensions .CONF, .INI, .Conf, .Ini will also be considered,
because the search is not case sensitive.)


	--pot=

If the john version supports the --pot= options, possible completions
are all directory names and file names with the extension .pot.
(The search is not case sensitive, so file names with extensions .POT
and .Pot will also be considered during completion.)


	--restore and --status

The options --restore and --status can be used without a value (in this case,
the session name will be "john") or with a value (session name).

Since names of john sessions are possible completions,
the possible completions are derived from .rec file names.
In addition, names of sub directories are also considered, since .rec files
might be located in a sub directory.
(For --restore=, only names of sessions not currently running should be
considered. This is not yet implemented.)

The completion logic for these options depends on the contents of the
environment variable __john_completion, see the last chapter
("Config variables") of this document.

The default logic works like this:

$ ls *.rec
john.rec  test1.rec

$ ls -d subdir/ testdata/
subdir/  testdata/

$ john --status[tab][tab]
will list possible completions like this:

$ john --status
--status           --status=subdir    --status=testdata
--status=john      --status=test1

A similar list of completions for --restore:
$ john --restore
--restore           --restore=subdir    --restore=testdata
--restore=john      --restore=test1

$ john --restore=[tab][tab]
will list possible completions like this:

$ john --restore=
john      subdir/   test1     testdata/

$ john --restore=t[tab]
will become
$ john --restore=test

$ john --restore=test[tab][tab]
will list possible completions like this:

$ john --restore=test
test1     testdata/



	Config variables

	COMP_WORDBREAKS

You shouldn't change the contents of this variable unless you really know
what you are doing!
Usually, you should leave this value unchanged.
(You never know which other completion scripts depend on the
contents of COMP_WORDBREAKS.)

Use the following command to show the contents of COMP_WORDBREAKS:

$ echo "$COMP_WORDBREAKS"

"'><=;|&(:

You can also use:

$ echo $COMP_WORDBREAKS
"'><=;|&(:

(Note that with the second command (without quotes), you'll not see that
the variable also contains a line feed character.)


The completion logic implemented for john depends on whether or not
COMP_WORDBREAKS contains the colon character (':').

If COMP_WORDBREAKS doesn't contain the colon, this is the completion logic:

$ john -opt:val[tab]
becomes
$ john -opt=val

$ john -opt:[tab]
becomes
$ john -opt=

This means, for an option (beginning with at least one '-' char) followed
by a colon (':') as a delimiter, possibly followed by other characters
(except '=' or ':') the colon will be replaced by an equal sign.
Pressing the  [tab] key again will then invoke the normal completion logic
as described throughout this document.


To remove the colon from COMP_WORDBREAKS, use:
$ COMP_WORDBREAKS="${COMP_WORDBREAKS//:/}"

To add the colon to COMP_WORDBREAKS, use:
$ COMP_WORDBREAKS="${COMP_WORDBREAKS}:"

As always, the $ indicates the command prompt, and it is not part
of the command.

If you want to add this command to your ~/.bashrc, you'll have to use
COMP_WORDBREAKS="${COMP_WORDBREAKS//:/}"
or
COMP_WORDBREAKS="${COMP_WORDBREAKS}:"


	__john_completion

The value of the variable __john_completion is used to adjust the completion
logic for options that can be used either with a value or without a value.

These options are
--restore
--status
--incremental

Furthermore, in jumbo versions, these options can be used with or
without a value:
--rules
--single
--show

(There are other options that can be used with or without a value.
But the completion logic for those other options is more or less limited
to a usage hint, and therefore doesn't depend on the value of the variable
__john_completion.)


For the option --show, the completion logic will always work like this:
$ ./john -sho[tab]
becomes
$ ./john --show

The cursor is positioned exactly after the "w", no trailing space is added
in this case.
(For an option that doesn't allow any values, a trailing space would be added.)


If __john_completion is not defined or has any other value than 2,
the default completion logic is used.
It works like this:

$ ./john --show[tab]
just lists the possible completions like this:

$ ./john --show
--show       --show=

To add a file name, you'll first have to add the space, to separate
the file name from the option name.
To further expand the option instead, you'll have to type the '='
(equal sign).

If __john_completion has the value 2, the following alternative completion
logic is implemented for options that can be used with or without a value.

$ ./john --show[tab]
will become
$ ./john --show=


Completion of --option= does not depend on the value of  __john_completion.

$ ./john --show=[tab][tab]
left   types

Since there is just one possible value for --show=l,
$ ./john --show=l[tab]
will become
$ ./john --show=left

(A space character will be added after "--show=left".)

So, if you prefer to hit the [tab] key instead of typing '=',
you might want to add this line to your ~/.bashrc file:
__john_completion=2

Cracking bitcoin-qt (bitcoin) wallet files with john
====================================================

1. Run bitcoin2john.py on bitcoin wallet file(s).

E.g. $ ../run/bitcoin2john.py wallet.dat >> hashes

2. Run john on the output of bitcoin2john.py script.

E.g. $ ../run/john hashes

3. Wait for the password(s) to get cracked.

This coding style is borrowed from Kernel CodingStyle
(https://www.kernel.org/doc/Documentation/CodingStyle).

	Chapter 1: Indentation

1.1 Indentation is one tab per level. Recommended tab width is 4 or 8 for jumbo
and 8 for core but it mostly just affects where a line exceeds max length.

1.2 Indent with tabs, align with spaces. E.g.

'->' is tab, '.' is space.

void *memmem(const void *haystack, size_t haystack_len,
.............const void *needle, size_t needle_len)
{
->	haystack_ = (char*)haystack;
->	needle_ = (char*)needle;
->	last = haystack_+(haystack_len - needle_len + 1);
->	for (; haystack_ < last; ++haystack_)
->	{
->	->	if (hash == hay_hash &&
->	->	....*haystack_ == *needle_ &&
->	->	....!memcmp (haystack_, needle_, needle_len))
->	->	->	return haystack_;

->	->	hay_hash += *(haystack_+needle_len);
->	}

->	return NULL;
}

1.3 Ease multiple indentation levels in switch(), for(), while()...

	switch (suffix) {
	case 'G':
	case 'g':
		mem <<= 30;
		break;
	case 'M':
	case 'm':
		mem <<= 20;
		break;
	case 'K':
	case 'k':
		mem <<= 10;
		/* fall through */
	default:
		break;
	}

	for (size = 0; size < PASSWORD_HASH_SIZES; size++)
	if (format->methods.binary_hash[size] &&
	    format->methods.get_hash[size](i) !=
	    format->methods.binary_hash[size](binary)) {
		do_something();
	}

1.4 Don't put multiple statements on a single line. A good example is:

	if (condition)
		do_something();


	Chapter 2: Breaking long lines and strings

The limit on the length of lines is 80 columns.

However, there are some cases that the lines can exceed 80 columns. Never break
user-visible strings such as print messages, because that breaks the ability
to grep for them.

E.g.:

	fprintf(stderr, "Error, a c%c found in expression, but the data for this const was not provided\n", pInput[2]);


	Chapter 3: Placing Braces and Spaces

3.1 Braces

3.1.1 Function

Put the opening brace at the beginning of the next line, thus:

int function(int x)
{
	body of function
}

3.1.2 Others

Put the opening brace last on the next line, thus:

	if (x is true) {
		we do y
	}

This applies to all non-function statement blocks (if, switch, for,
while, do).  E.g.:

	switch (action) {
	case KOBJ_ADD:
		return "add";
	case KOBJ_REMOVE:
		return "remove";
	case KOBJ_CHANGE:
		return "change";
	default:
		return NULL;
	}

Note that the closing brace is empty on a line of its own, _except_ in
the cases where it is followed by a continuation of the same statement,
ie a "while" in a do-statement or an "else" in an if-statement, like
this:

	do {
		body of do-loop
	} while (condition);

and

	if (x == y) {
		..
	} else if (x > y) {
		...
	} else {
		....
	}

3.2 Spaces

3.2.1 Use a space after (most) keywords.

Use a space after these keywords:

	if, switch, case, for, do, while

but not with sizeof, typeof, alignof, or __attribute__.  E.g.,

	s = sizeof(struct file);

3.2.2 Do not add spaces around (inside) parenthesized expressions.

This example is *bad*:

	s = sizeof( struct file );

3.2.3 When declaring pointer, the preferred use of '*' is adjacent to the data
name or function name. E.g.:

	char *linux_banner;
	unsigned long long memparse(char *ptr, char **retptr);
	char *match_strdup(substring_t *s);

3.2.4 When type conversin, add a space before '*'.

E.g:

	hostSalt = (cl_uint *) mem_alloc(SALT_BUFFER_SIZE);

3.2.5 Use one space around (on each side of) most binary and ternary operators,
such as any of these:

	=  +  -  <  >  *  /  %  |  &  ^  <=  >=  ==  !=  ?  :

but no space after unary operators:

	&  *  +  -  ~  !  sizeof  typeof  alignof  __attribute__  defined

no space before the postfix increment & decrement unary operators:

	++  --

no space after the prefix increment & decrement unary operators:

	++  --

and no space around the '.' and "->" structure member operators.

3.2.6 Don't leave whilespace at the end of lines.

Don't do this:

	do_something();. // '.' is a space

3.2.7 There should not be any spaces between lables and left column.

E.g:

void f()
{
	...
out:
	free(p);
	return;
}


	Chapter 4: Naming

GLOBAL variables (to be used only if you _really_ need them) need to
have descriptive names, as do global functions.  If you have a function
that counts the number of active users, you should call that
"count_active_users()" or similar, you should _not_ call it "cntusr()".

We use names prefixed by crk_ for global functions in cracker.c, ldr_ for
ones from loader.c and so on.


	Chapter 5: Declaration

5.1 Functions declartion

In function prototypes, include parameter names with their data types.
Although this is not required by the C language, it is preferred in Linux
because it is a simple way to add valuable information for the reader.

5.2 Variables declaration

Add a blank line after variables declaration. E.g:

void function(void)
{
	unsigned char master[32];

	sevenzip_kdf((unsigned char*)saved_key[index], master);
}


	Chapter 6: Commenting

6.1 C89 style and C99 style

C89:

/* ... */

C99:

// ...

Use C89 style in core, and both are ok in jumbo.

cprepair is a tool that reads br0ken files that may either contain text
accidentally encoded to UTF-8 twice, and/or is a mix of correct UTF-8 and a
legacy codepage - and tries to output fixed data.

Usage:
./cprepair <INFILE >OUTFILE

To see what would be converted, try:
./cprepair -s -d <INFILE

The legacy codepage defaults to CP1252 but can be chosen with -i.

For use on a john.pot file and if you only want to convert stuff after the
first colon, add -p option.

The output is always correct UTF-8 but might not always be a correct conversion,
especially if the input contains a mix of legacy codepage encodings. For strings
like "Müller" or "Стандарт" it is easy (for a human) to guess a correct
encoding but for a string made of random characters of which just one is 8-bit
you can never know.

A very good example use of this tool is fixing the original RockYou dataset.

= Intro
=======

EPiServer is a popular webbased content management system from Elektropost (http://www.episerver.com).
You can dump the password hashes using the SQL syntax "select name, salt, hash from tblSID". The tblSID
tabel stores interesting things such as usernames, salt and password hashes, but also passwords in cleartext.
If a password can be found in cleartext it is found in the password column of tblSID.

= Usage
=======

The format of the password file needs to be: <user>:<salt> <hash>. (Currently you need to include
an inital 0x of both salt and hash.)

--- Contents of an example epipasswd file ---

webadmin:0x6631F625DEC28716FC24FA3CC1B3E2055E4281F4465226905C10D3456035 0x4F25D9BD24B81D85B1F2D106037C71CD2C828168
epiuser:0x48F9BA13F54CE7AF669C76EEBC6BEA4564EBB77F1866CA5F2B297F7159C1 0xDA4260812C195025B4442C5C84E0F890122B285A

-------------- End --------------------------

You can then run "john epipasswd", the format will be autodetected.
In case you'd like to check the performance of the patch try "john --test --format:epi".

-johannes

Cracking PGP Desktop / OpenPGP / GnuPG private (secret) keys with john
======================================================================

1. Run gpg2john on PGP private key files (supports .skr files too!)

E.g. $ ../run/gpg2john openwall.sec.asc > hashes
E.g. $ ../run/gpg2john openwall.skr > hashes

Ensure that the input file to gpg2john contains a single private key.

2. Run john on the output of gpg2john.

E.g. $ ../run/john hashes

Cracking IOS 7 restrictions PIN code
====================================

1. Fetch the file com.apple.restrictionspassword.plist from your phone. How
   you do this is out of scope for this document, just google it.


2. Run ios7tojohn on that file, redirecting output to a new file. Eg:

   $ ./ios7tojohn com.apple.restrictionspassword.plist > ioshash


3. Run john on the new file, only using four digits (it's a PIN code):

   $ ./john ioshash -inc:digits -min-len=4 -max-len=4


4. The password will get cracked in a split second. This is not because Apple
   used a very poor hash mechanism but because the keyspace of a PIN code is
   so very tiny.

Cracking Apple's Mac OS Keychain files
======================================

1. Run keychain2john on .keychain file(s).

E.g. $ ../run/keychain2john login.keychain > hash

2. Run john on the output of keychain2john.

E.g. $ ../run/john hash

3. Wait for the password to get cracked.

Cracking GNOME Keyring files
============================

1. Run keyring2john on .keyring file(s).

E.g. $ ../run/keyring2john Default.keyring > hash

2. Run john on the output of keyring2john.

E.g. $ ../run/john hash

3. Wait for the password to get cracked.

Cracking KeyStore files
======================

1. Run keystore2john.py on .jks file(s).

E.g. $ ../run/keystore2john.py <name>.jks > hash

2. Run john on the output of keystore2john.py utility.

E.g. $ ../run/john hash
     or, for the OpenCL version:
     $ ../run/john --format=keystore-opencl hash

3. Wait for the password to get cracked.

"THE BEER-WARE LICENSE" (Revision 42)
=====================================
<jean-christophe.delaunay (at) synacktiv.com> wrote this file.  As long as you
retain this notice you can do whatever you want with this stuff. If we meet
some day, and you think this stuff is worth it, you can buy me a beer in
return.   Fist0urs


Cracking Kerberos Ticket Granting Service (TGS) tickets within _Microsoft Active Directory_
===========================================================================================

(Skip to part "How to retrieve TGS tickets" if you just want to know how to get TGS to crack).

What is it
----------

Within a _Micorosft Active Directory_ environment, registered services (as MsSQL or so) rely on a domain account in order to be functional.
This domain account should be a service account but administrators can provided whichever account they want provided that it has sufficient rights.
Such specific accounts are easily identifiable by their LDAP attribute _servicePrincipalName_ (SPN) and can be listed by *any authenticated user* in the domain (whatever are his rights in the domain).
Furthermore any authenticated can request a TGS ticket for these accounts. Nevertheless, if one can request such tickets, it does not mean that he would be able to impersonate these accounts.
Indeed, the important part assuring that a user submitting a ticket is its legit owner is encrypted with a key. This key is derived from a secret only known by the legit account which is its **domain account password**. This attack is known as "Kerberoast" and was discovered by Tim Medin.

So, having a valid domain user, one can request tickets for accounts having a SPN and try to retrieve the corresponding passwords.

Algorithm details
-----------------

_Active Directory_ offers 4 algorithms to generate the encryption key:

* DES (disabled by default, not really usefull)
* RC4-HMAC-MD5 (enctype 23)
* AES128-CTS-HMAC-SHA1-96 (enctype 17) - with 4096 PBKDF2 HMAC-SHA1 iterations
* AES256-CTS-HMAC-SHA1-96 (enctype 18) - same number of algo/iterations

At the moment only etype 23 is implement within john but etype 17 and 18 are yet to come.

How to retrieve TGS tickets
---------------------------

_GetUserSPNs.py_ from [impacket](https://github.com/SecureAuthCorp/impacket) by @asolino permits to obtain these tickets:

```

usage: GetUserSPNs.py [-h] [-target-domain TARGET_DOMAIN] [-request]
                      [-request-user username] [-save]
                      [-outputfile OUTPUTFILE] [-debug]
                      [-hashes LMHASH:NTHASH] [-no-pass] [-k]
                      [-aesKey hex key] [-dc-ip ip address]
                      target

Queries target domain for SPNs that are running under a user account

positional arguments:
  target                domain/username[:password]

```

Provided my domain is CONTOSO, username is "fistouille" and password "kariontounu", requesting tickets would be as follows:

```

$ python GetUserSPNs.py -target-domain CONTOSO -request -outputfile KRB5TGS.dump CONTOSO/fistouille:kariontounu

```

**_KRB5TGS.dump_ now contains ready-to-crack hashes for both JtR and hashcat**

Another tool, [kerberoast](https://github.com/skelsec/kerberoast) from @skelsec, offers the ability to retrieve such tickets (among many other things).

You can get it from [github](https://github.com/skelsec/kerberoast) or install it with **pip3** (_Python 3.6_ is required):

```

$ git clone https://github.com/skelsec/kerberoast
$ python3 setup.py install

OR

$ pip3 install -r requirements.txt
$ pip3 install kerberoast

```

Usage:

```

usage: kerberoast.py [-h] [-v]
                     {ldap,brute,asreproast,spnroast,spnroast-sspi,auto} ...

Tool to perform kerberoast attack against service users in MS Active Directory

positional arguments:
  {ldap,brute,asreproast,spnroast,spnroast-sspi,auto}
                        commands
    ldap                Enumerate potentially vulnerable users via LDAP
    brute               Enumerate users via brute-forcing kerberos service
    asreproast          Perform asrep roasting
    spnroast            Perform spn roasting (aka kerberoasting)
    spnroast-sspi       Perform spn roasting (aka kerberoasting)
    auto                Just get the tickets already. Only works on windows
                        under any domain-user context

```

Provided the aforementioned information plus a _Domain Controller_ IP/FQDN (eg. 10.123.42.42), we can request tickets as follows:

```

# we first list all user accounts having an SPN
$ python3 kerberoast.py ldap all CONTOSO/fistouille:kariontounu@10.123.42.42 -o ldapenum

# we then ask for TGS for these accounts
$ python3 kerberoast.py spnroast CONTOSO/fistouille:kariontounu@10.123.42.42 -t ldapenum_spn_users.txt

```

**_ldapenum_spn_users.txt_ now contains ready-to-crack hashes for both JtR and hashcat**

Finally, _kerberoast_ python tool also implements Windows implicit authentication mechanism which is really useful during _Red Team_ security assessments.

Cracking KWallet files
======================

1. Run kwallet2john on .kwl file(s).

E.g. $ ../run/kwallet2john <name>.kwl > hash

2. Run john on the output of kwallet2john.

E.g. $ ../run/john hash

3. Wait for the password to get cracked.

Rexgen.txt - This document describes how to use the rexgen library, to perform
regex expression work within JtR.  Rexgen library is copywrite Jan Starke,
jan.starke@outofbed.org   The regex.c code in JtR by JimF, Spring 2014.

First off, see the section at the bottom of this document about how to obtain
build and install librexgen.

Usage within JtR: --regex[=option=option2=option3]=expression

The current options we have are:
    case      will tell librexgen to do case insensitive work
    alpha     This will use replaceable alphabets.  This can do some REALLY
              fun things, like replace a letter with a word, etc. The alphabet
              will be run to convert the reg-ex AFTER the word has been
              prepared and delivered.  Fun things like f mapping to ph
              or M mapping to |\/| can be done.  Case can also easily be
              done here if the case option is also used. These options
              are stored in the regex_alphabets.conf file in ./run dir
              of JtR.  There are these current alphabets:
              The default (if just =alpha is used). It is an empty
              alphabet, nothing will change.  alpha:case  This is the
              same as using the case option.  alpha:leet  This is a
              simple 1337 (elite) transform, where some common lower
              case letters are changed to numbers.  alpha:leet_case
              is the same leet, but has full case conversion handled.
              alpha:leet2 and alpha_leet2_case are a little stronger
              elite stuff (with and without casing).  alpha:leet3
              and alpha:leet3_case are strong elite, but probably
              overkill as far as password guessing goes. They will
              certainly find more, but there are a LOT of obsure multi-
              letter replacements which likely are not seen in garden
              variety passwords. h -> h H  |-|  ]-[  }-{  (-)  )-(  }{  #
              is one example of alpha:leet3.
              alpha:ascii2nonascii is a alphabet which will convert ascii
              characters into non ascii utf8 characters which 'look'
              similar (i.e. a with grave, umlat, accent, hook, etc)


Currently, rexgen can be used stand alone, OR with wordlist and rules.
There are plans to also add this to single mode at some time.

The command line switch for stand along is --regex[=case]=expression
The expression is a stand along rexex expression.  If the optional
=case is there, then the expression is handled in a case insensitive
manner (case mangling).  So using:  --regex=case=pass  would use these:
PASS
PASs
PaSS
PaSs
pASS
pASs
paSS
paSs
PAsS
PAss
PasS
Pass
pAsS
pAss
pasS
pass

Stand alone usage is not most useful (especially since the rexgen built
command can do this and more).  But it is there more to use as 'testing'
for building expressions (along with using JtR's --stdout).


RexGen in --wordlist mode:

This is more powerful. It addes rexgen logic to each word from the wordlist
to happen AFTER any rules (JtR rules) are applied.  In this mode, all \0 will
be replaced with the current word (from wordlist, with rules applied), and
then all of the regular expressions will be performed on this word.


------------------------------------------------
--- Obtaining, building, installing rexgen.  ---
------------------------------------------------
First off, you must obtain and install rexgen library. It can be found here:

https://github.com/teeshop/rexgen

git clone --recursive https://github.com/teeshop/rexgen.git

As of this writing the last known good version is 2.0.8 so you may want
to check that out.

Once you download it, it requires a cmake environment, along with flex and
bison to be installed and working.  To build, see instructions on this page:

https://github.com/teeshop/rexgen/blob/master/README.md

Instead of just running ./install.sh, you can first run ./build.sh
as a regular user and then just run ./install.sh as root.

cd rexgen/src
./build.sh
sudo ./install.sh

If there are no errors (especially from cmake), librexgen should be installed.

To test:
rexgen '[0-2]password[A-C]'
0passwordA
1passwordA
2passwordA
0passwordB
1passwordB
2passwordB
0passwordC
1passwordC
2passwordC

Once you are at this point, rexgen is installed.  JtR ./configure now needs
--enable-rexgen to detect and use the library.

Note, JtR help document is NOT here to troubleshoot installation of this
library.  A simple how to do it (when thing work right), is what was listed.
If there problems beyond what is addressed in this document, then the lib's
author is probably the best way to go.  A quick 'help me' post on john-users
may get the proper answer, AND if we get a quick resolve, we will likely
update this document listing this issue.  But anything past the basics,
are really beyond the scope of the JtR developers.

Cracking Mozilla Firefox, Thunderbird and SeaMonkey master passwords
====================================================================

1. Run mozilla2john.py on key3.db file.
     ./mozilla2john /some/path/key3.db > mozilla.in

2. Run john on output of mozilla2john.
     ./john mozilla.in

3. Wait for master password to get cracked.

====================
CAUTION:
====================
    Please note that MPI is only for multi-machine clusters with shared
    network storage.  Merely having it compiled in (even if unused) may have
    security and reliability drawbacks.  Most users should read up on the
    --fork options instead, which gets compiled in automagically if your
    system supports it.

====================
PRELUDE:
====================
    The original implementation was ca. 2004 by Ryan Lim as an academic
    project.  It was later picked up and maintained at bindshell.net, adding
    fixes for the JtR 1.7 releases and various cipher patches.

    In 2008, it was picked up by AoZ and stripped back down to the original
    MPI-only changes to improve its compatibility with the 'jumbo' patchsets,
    which had better-maintained alternate cipher support. Up to this point,
    the patch only worked for Incremental mode.

    In 2010, it was extended by magnum to support all cracking modes. It was
    far from perfect (with the exception of Markov mode and some cases of
    Wordlist mode use) but worked just fine. From version 1.7.7-Jumbo-5, the
    patch was incorporated in the main tree.

    In 2013, core John got support for node/fork and MPI was unified with this
    code. This means significantly better QA and also better scaling in some
    cases. Note that the new -fork option deprecates MPI for use on a single
    host! MPI works exactly like -fork except you can span the processes over
    several remote hosts.

====================
COMPILING:
====================
    You must have an operational MPI environment prior to both compiling and
    using the MPI version. Configuring one is outside the scope of this
    document but it's trivial. What is most important is that all nodes see
    the same working directory - normally you'd use NFS but other alternatives
    exist (file locking needs to be properly supported though). The nodes may
    use different binaries if required (eg. compiled for different CPU archs)
    as long as they are the exact same John version. But the config files
    SHOULD be shared over the network, and the directory where session
    (.rec) files and log files are created MUST be a shared network one.

    For a single, multi-core, host you don't need much configuration. MPICH2
    or OpenMPI does the job fine, for example. Most testing of MPI is now
    made using the version of OpenMPI included with latest LTE Ubuntu.

    Debian/Ubuntu/Mint Linux example for installing OpenMPI:
    sudo apt-get -y install libopenmpi-dev openmpi-bin

    The new autconf (./configure) system does not build MPI unless told so.
    It should detect and enable MPI if it's installed properly and you supply
    the "--enable-mpi" option. Normally this should do:
        ./configure --enable-mpi

    Note that MPI works just fine together with OpenMP (a.k.a OMP) enabled
    as well.  When MPI is in use (with more than one process), OMP is
    automagically disabled. Advanced users may want to change this setting
    (change MPIOMPmutex to N in john.conf) and start one MPI node per
    multi-core host, letting OMP do the rest. Warnings are printed; these
    can be muted in john.conf too.

====================
USAGE:
====================
    Typical invocation is as follows (mpiexec is usually synonym to mpirun):
        mpirun -np 4 -host host1[,host2...] ./john pwfile

    The above will launch four parallel processes that will split the job in
    a more-or-less even fashion. If no -host is given, it will run all
    processes on your local host (and -fork=4 would be a better option then).

    Using "mpirun -np <num> ./john ..." can be seen as functionally equivalent
    to "./john -fork=<num> ..." in that it will start the same number of
    processes and parse the optional "-node" option equally. The main
    practical difference is that -fork can only run on your local host, while
    MPI can run partly or solely on one or more remote hosts.

    Actually, MPI and -fork are so similar, and MPI "fakes" the -fork option
    in the session file, so you can start a session as MPI and later resume
    it without MPI - it will then use fork instead. Or vice versa.

    Both these will start nodes 1-4 out of 4 total:
	./john -fork=4 ...
	mpirun -np 4 ./john ...

    All these will start nodes 5-8 out of 12 total:
	./john -fork=4 -node=5/12 ...
	./john -fork=4 -node=5-8/12 ...
	mpirun -np 4 ./john -node=5/12 ...
	mpirun -np 4 ./john -node=5-8/12 ...

    All these will refuse to run (-node parameter ambigous):
	./john -node=2
	./john -fork=4 -node=2
	mpirun -np 4 ./john -node=2

    This will start node 7 out of 12, or nodes 3-4 (but using just one process)
    out of 16, MPI build or not:
        ./john -node=7/12 ...
        ./john -node=3-4/16 ...

    This will start node 7/12 on a remote node:
        mpirun -host hostname -np 1 ./john -node=7/12 ...

    This will start nodes 3-4/16 (using just one process) on a remote node:
        mpirun -host hostname -np 1 ./john -node=3-4/16 ...

    The following is rejected - you can't use -fork and mpirun [with -np > 1]
    at the same time:
        mpirun -np 4 ./john -fork=...

    This is somewhat more advanced, it will start 1-4/4 on one remote node:
        mpirun -host hostname -np 1 ./john -fork=4 ...

    This will do the same as above, but somewhat less efficiently:
        mpirun -host hostname -np 4 ./john ...


    In INCREMENTAL mode, the job is automagically split as evenly as possible
    without performance loss. This is not perfect so in some cases, some nodes
    will complete earlier than others.

    In MARKOV mode, the range is automagically split evenly across the nodes,
    just like you could do manually. This does not introduce any overhead,
    assuming job runs to completion.

    The single and wordlist modes scale well and cleartexts will not be tried
    by more than one node (except when different word + rule combinations
    result in the same candidate, but that problem is not MPI specific).

    In SINGLE mode, and sometimes in Wordlist mode (see below), john will
    distribute the rules (after preprocessor expansion). This works very well
    but will not likely result in a perfectly even workload across nodes.

    WORDLIST mode with rules will work the same way. Without rules, or when
    rules can no longer be split across the nodes, john will switch to
    distributing words instead.

    If the --mem-file-size parameter (default 5000000 [bytes]) will allow the
    file to be loaded in memory, this will be preferred and each node will
    only load its own share of words. In this case, there is no further
    distribution and no other overhead. Note that the limit is per node, so
    using the default and four nodes, a 16 MB file WILL be loaded to memory,
    with 4 MB on each node. To enforce this regardless of wordlist size, use
    -mem-file-size=0.

    In EXTERNAL mode, john will distribute candidates in the same way as in
    Wordlist mode without rules. When attacking very fast formats, this scales
    poorly.


    You may send a USR1 signal to the parent MPI process (or HUP to all
    individual processes) to cause the subprocesses to print out their status.
    Be aware that they may not appear in order, because they blindly share the
    same terminal.

    skill -USR1 -c mpirun
    - or -
    pkill -USR1 mpirun

    Another approach would be to do a normal status print. This is now done
    without mpirun, all nodes will be printed:

    ./john --status

    This will dump the status of each process as recorded in the .rec files.


    You may send a USR2 signal to the parent MPI process (or to all individual
    processes) for manually requesting a "pot file sync". All nodes will
    re-read the pot file and stop attacking any hashes (and salts!) that some
    other node (or independant job) had already cracked.  Current code handles
    this automagically with default config and no user intervention.


====================
MISC TIPS:
====================
    All MPI nodes must share the same working directory, usually over NFS. When
    a larger number of nodes is in use, the overhead for writing to the log
    file (which includes file locking) may become an overhead. Use the -nolog
    option to disable logging or -verb=2 option to reduce chatter.

====================
CAVEATS:
====================
    - This implementation does not account for heterogeneous clusters or nodes
      that come and go.
    - Benchmark virtual c/s will appear inflated if launching more processes
      than cores available. It will basically indicate what the speed would be
      with that many real cores.
    - Aborting a job using ctrl-c may kill nodes without updating state
      files and logs. I have tried to mitigate this but it is still a good
      idea to send a -USR1 to the parent before killing them. You should
      lower the SAVE parameter in john.conf to 60 (seconds) if running MPI,
      this will be the maximum time of repeated work after resuming.

============================================================
Following is the verbatim original content of this file:
============================================================

This distribution of John the Ripper (1.6.36) requires MPI to compile.

If you don't have MPI, download and install it before proceeeding.

Any bugs, patches, comments or love letters should be sent to
jtr-mpi@hash.ryanlim.com. Hate mail, death threates should be sent to
/dev/null.

Enjoy.
--
Ryan Lim <jtr-mpi@hash.ryanlim.com>

Cracking Password Safe 3.x and Password Gorilla databases with john
===================================================================

1. Run pwsafe2john on .psafe3 files.

E.g. $ ../run/pwsafe2john pwsafe-openwall.psafe3 > hashes

2. Run john on the output of pwsafe2john.

E.g. $ ../run/john hashes

3. Wait for the password to get cracked.

Cracking password protected ssh private keys
============================================

1. Build JtR-jumbo

2. Run ssh2john.py on SSH private key file(s)

3. Run john on the output of step 2.

This file contains all the prior copyright headers from the independent
XXX2john.py PCAP conversion utilities.  These have all been combined into
a single ./run/pcap2john.py, and all of the copyright statements placed
here.

This file should also contain information and help on how to use the tool,
how to obtain the pcap input data, etc.  For now, I will simply provide a
link to a large resource on git owned by Dhiru.

https://github.com/kholia/my-pcaps/
or a full zip: https://github.com/kholia/my-pcaps/archive/master.zip

################################################################################
# from bfd2john.py
####
# Parser for BFD authentication packets.
#
# This software is Copyright (c) 2014 Dhiru Kholia <dhiru at openwall.com>, and
# it is hereby released to the general public under the following terms:
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted.
################################################################################

################################################################################
# from vtp2john.py
####
# Parser for VTP MD5 authentication packets.
#
# This software is Copyright (c) 2014 Alexey Lapitsky <lex at realisticgroup.com> and Dhiru Kholia <dhiru at
# openwall.com>, and it is hereby released to the general public under the following terms:
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted.
#
# Output Hash Format:
#
# $vtp$1/2/3$vlans_data_length$vlans_data$salt_length$salt$hash
################################################################################

################################################################################
# from vrrp2john.py
####
# Cracker for VRRP authentication (cisco variant).
#
# Output Format,
# packet_number:$vrrp$algo_type$salt$have_extra_salt$extra_salt$hash
#
# $ md5sum i86bi-linux-l3-ipbase-12.4.bin
# 3e79a8010a4174dc316a55e6d1886f3c  i86bi-linux-l3-ipbase-12.4.bin
#
# $ md5sum i86bi-linux-l3-adventerprisek9-15.4.1T.bin
# 2eabae17778316c49cbc80e8e81262f9  i86bi-linux-l3-adventerprisek9-15.4.1T.bin
#
# This software is Copyright (c) 2014 m3g9tr0n (Spiros Fraganastasis)
# <spirosfr.1985 at gmail.com> and Dhiru Kholia <dhiru at openwall.com>, and it
# is hereby released to the general public under the following terms:
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted.
################################################################################

################################################################################
# from tcpmd5tojohn.py
####
# Cracker for "TCP MD5 Signatures", http://www.ietf.org/rfc/rfc2385.txt
# Written by Dhiru Kholia <dhiru at openwall.com> in October 2013
################################################################################

################################################################################
# from s7tojohn.py
####
# s7tojohn.py, parse .pcap files and output JtR compatible hashes.
# Extended by Narendra Kangralkar <narendrakangralkar at gmail.com>
# and Dhiru Kholia <dhiru at openwall.com>
#
# S7 protocol, is used for communication between Engineering Stations,
# SCADA, HMI & PLC and can be protected by password.
#
# Original Authors: Alexander Timorin, Dmitry Sklyarov
#
# http://scadastrangelove.org
#
# __author__      = "Aleksandr Timorin"
# __copyright__   = "Copyright 2013, Positive Technologies"
# __license__     = "GNU GPL v3"
# __version__     = "1.2"
# __maintainer__  = "Aleksandr Timorin"
# __email__       = "atimorin@gmail.com"
# __status__      = "Development"
#
################################################################################

################################################################################
# from rsvp2john.py
####
# Based on http://tools.ietf.org/html/rfc2747 and some reversing.
#
# Output Format: packet_number:$rsvp$algo_type$salt$$hash
#
# This software is Copyright (c) 2014 Dhiru Kholia <dhiru at openwall.com>,
# and it is hereby released to the general public under the following terms:
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted.
################################################################################

################################################################################
# from ntp2john.py
####
# NTP authentication parser.
#
# http://tools.ietf.org/html/rfc5905
# http://tools.ietf.org/html/rfc1305
# http://www.eecis.udel.edu/~mills/ntp/html/authentic.html
#
# This software is Copyright (c) 2014 Spiros Fraganastasis <spirosfr.1985 at
# gmail.com> and Dhiru Kholia <dhiru at openwall.com>, and it is hereby
# released to the general public under the following terms:
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted.
################################################################################

################################################################################
# from isis2john.py
####
# Parser for IS-IS MD5 authentication packets.
#
# This software is Copyright (c) 2014 Dhiru Kholia <dhiru at openwall.com>, and it is hereby released to the general
# public under the following terms:
#
# Redistribution and use in source and binary forms, with or without modification, are permitted.
################################################################################

################################################################################
# from hsrp2john.py
####
# Cracker for HSRP v2 MD5 authentication.
#
# http://www.rfc-editor.org/rfc/rfc1828.txt
# https://www.ietf.org/rfc/rfc2281.txt
# http://www.gotohack.org/2011/01/scapy-hsrp-md5-auth-dissecter-to.html
# "i86bi-linux-l3-ipbase-12.4.bin" is fun ;)
#
# This is dedicated to Darya. You inspire me.

# This software is Copyright (c) 2014 Dhiru Kholia <dhiru at openwall.com>, and
# it is hereby released to the general public under the following terms:
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted.
################################################################################

################################################################################
# from glbp2john.py
####
# Cracker for GLBP authentication. Wireshark dissects GLBP messages pretty
# nicely.
#
# Output Format,
# packet_number:$glbp$algo_type$salt$have_extra_salt$extra_salt$hash
#
# $ md5sum i86bi-linux-l3-ipbase-12.4.bin  # GLBP TLV version 3.0
# 3e79a8010a4174dc316a55e6d1886f3c  i86bi-linux-l3-ipbase-12.4.bin
#
# $ md5sum i86bi-linux-l3-adventerprisek9-15.4.1T.bin  # GLBP TLV version 2.0
# 2eabae17778316c49cbc80e8e81262f9  i86bi-linux-l3-adventerprisek9-15.4.1T.bin
#
# This software is Copyright (c) 2014 Spiros Fraganastasis <spirosfr.1985 at
# gmail.com> and Dhiru Kholia <dhiru at openwall.com>, and it is hereby
# released to the general public under the following terms:
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted.
################################################################################

################################################################################
# from gadu2john.py
####
# This software is Copyright (c) 2013 Lukas Odzioba <ukasz at openwall dot net>
# and it is hereby released to the general public under the following terms:
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted.
#
# output format:
# gadu-gadu number:$dynamic_24$sha1(pass.salt)$HEX$salt$
#
# We could use user status description and client language in GECOS field, but
# this is not currently supported.
#
# "GG32" "hash function" used by ancient clients is not supported.
#
# Tested on:
#
# ekg: 10.1.0.11070
# kadu 0.12.3
# pidgin 2.110.6
#
################################################################################

################################################################################
# from eigrp2john.py
####
# Cracker for EIGRP authentication (MD5 and SHA-256 variants). Currently, this script is very speculative!
# http://tools.ietf.org/html/draft-savage-eigrp-02
#
# Wireshark dissects EIGRP messages pretty nicely.
# http://c0decafe.de/svn/codename_loki/trunk/modules/module_eigrp.py is cool
#
# Output Format,
# packet_number:$eigrp$algo_type$salt$have_extra_salt$extra_salt$hash
#
# $ md5sum i86bi-linux-l3-ipbase-12.4.bin  # EIGRP TLV version 3.0
# 3e79a8010a4174dc316a55e6d1886f3c  i86bi-linux-l3-ipbase-12.4.bin
#
# $ md5sum i86bi-linux-l3-adventerprisek9-15.4.1T.bin  # EIGRP TLV version 2.0
# 2eabae17778316c49cbc80e8e81262f9  i86bi-linux-l3-adventerprisek9-15.4.1T.bin
#
# "c3660-js-mz.124-11-T.image" uses EIGRP TLV version 1.2 and we can't crack
# such hashes currently (for unknown reasons).
#
# This is dedicated to Darya. You inspire me.
#
# This software is Copyright (c) 2014 Dhiru Kholia <dhiru at openwall.com>, and
# it is hereby released to the general public under the following terms:
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted.
################################################################################