Splendidly_null

[sPlico]

I guess most of us have by now started to use JTR in one way or another so I thought I'd start this thread so we might be able to share some experiences concerning JTR ?

First of all what do I use:
1. The latest (stable) version of john-w16 that can be downloaded from "openwall" (home-site of JTR). The version that's still under development is suposed to be faster and I'll give it a try lateron......
2. a "bat" file to start the program including the use of a wordlist which makes for a better performance.

A. "John -single passfile.txt" (or john -s.......)
As we all probably know this method is usually the best command line to start with as it will result in the highest compilation-rate. In my case a rate of > 10 million is quite usual as my john.pot file has become quite large. What does it do ?
Well I am not an expert but I think I am not far of off when I say that with this method basically JTR uses the allready "usernames" in the passfile which as you know are not encrypted in the passfile. When you run this method you can see things like:

billy99 (billy)
asshole1 (asshole)
sexy69 (sexy)
position69 (position)
etc.

The passfile (the origin) might looks like this (just example!):

billy:kuHLB/.KHKHKH
asshole:q.MHTNMj
sexy:ENHTJHjhkuv
position:ejb.JGJYGJ
etc.

As said this outcome leads me to believe that in the single method
the plain usernames (in this case: billy, asshole, sexy and position) are tried first to make a quick assessment of the easy to crack passess. (asside from a few other assumption I am as yet trying to figure out). I think the "-rules" command also plays a role in this .... (see below).

B. "John -w:wordlist.txt passfile"
This is basically the same thing as above (would also explain the high sampling rate). The extra speed advantage of the single method (compared to the wordlist method) probably lies in the place where to look for "what to try"..... In single method the encrypted passess and the used wordlist are basically the same file (as explained in A.) but with the wordlist method each sampling has to be taken from the wordlist so basically you have 2 files: 1. The samples (=wordlist) and 2. "what to try it on" (the passfile, or logrules...). This means that JTR has to jump from the wordlist to the passfile and visa-versa....... this takes more time and thus it runs at about 10 of the speed achieved by the single method. Sampling speed is in the range of 600.000 (with surfing)to > 800.000 (without surfing).

TIP: For the best possible successrate I've used a little (naughty) trick. I've leeched/copied nearly all the passess from the forum (2001-2002) and converted them into one single wordlist which I use in JTR. (as this is the ONLY board I visit I did not think this would be a problem.....as I am keeping it in the family....)
The reason is simple ...... "proven" passess must have the highest successrate so I went the extra "mile" (took me several weeks) and collected nearly all.......
TIP2: Aside from using them directly I've also converted stricktly alpha singles to both Upper and lowercase and removed all the dubs I allready had. (assumption is that Uppercase letter are only rarely combine with numbers ?).

C. john -w:"wordlist.txt -rules (-salts:2) passfile.txt"
This method does the same as B but it also goes a bit further. Besides the whole singles in the wordlist it also tries parts of the the singles in the wordlist as samples. So if your wordlist contains the single "asshole" it will also try "ass" and "hole" as samples.
Personally I beleive that -rules does the same as the incremental method but based on the fact that a single can be seen as an character/number sequence which are all tried. And thus also the samples "as", "shole", "less" etc. are tried as samples.....
The inclusion of the -salts:X indicates basically the priority that JTR should use to figure things out. I think that the higher X the more JTR focuses on a simmilar encryption (possibly meaning the same pass). As some words are more common than others as passess it's likely that JTR will thus find certain passess faster as it than has more material to figure things out.

D. john -w:wordlist.txt -rules -stdout:8 | unique huge.lst
john -w:huge.lst passfile.txt
These 2 command lines tell JTR to make it's own wordlist based on a wordlist provided by you. Basically what it does is to make a (very very large) wordlist based on hte wordlist provided and the -rules command I just explained. Number "8" indicates that the maximum for any generated single is 8. Based on say a wordlist with some 200.000 singles (3 to 8 positions) this will generate a singles list of some 50 MB !!!!! This list will subsequently be used as the samplelist in the session indicated with: "john -w:huge.lst passfile.txt".
My experience with this option is that it takes a very very long time to complete and will only speedup the initial results obtained by JTR. But the advantage is obvious. As a wordlist is handled faster than an incremental method you are basically exchanging HD space for a bit of extra speed so there are some advantages to have here but they are somewhat relative as it will take a seriously long time to sample the whole list.

E. john -makechars:all.chr
john -makechars:alpha.chr -external:filter_alpha
john -makechars:digits.chr -external:filter_digits
john -makechars:lanman.chr -external:filter_lanman
This should only be attempted when your john.pot file has become sufficiently large!!!!!!!! Basically what it does is make some new character-sets for the incremental methods. In itself it can allready be usefull for the i:alpha and i:digits methods because most passess will cover the ranges a to z and 0 to 9. So by doing this for both the alpha and digit character sets could provide you with some extra speed. But for the i:all and i:lanman it will most likely result in a (small) disadvantage. For i:all this is obvious because chances are high that your john.pot will not cover the whole (ASCII) set. For i:Lanman it's not really obvious because it covers both letter and numbers asswell as some special characters/signs so I am unsure here what you could miss in your char-set but I get an error on this asswell (although it works ?). So my guess would be is to backup all character sets, than activate this option and subsequently replace the generated all.chr and lanman.chr files with the originals again. Just to make sure you are not missing anything ?

F. An example of a (complete) bat file:

john -single passfile.txt
john -w:wordlist (-rules -salts:2) passfile
john -i:digits passfile.txt
john -i:alpha passfile.txt
john -i:lanman passfile.txt
john -i:all passfile.txt
john -show passfile.txt >outputfile.txt

You can copy the text given above into wordpad and save as "anyname.bat" in your JTR run directory. If you press this file after saving than a dos window will popup showing you what's happening (see example given at A). If you don't have a good wordlist than you could leave the second commandline out but it's wise to include it and make a wordlist form some of the lists provided for you in the Vault.
TIP: When JTR runs all the found passess are stored and listed in a file called john.pot (as indicated above). This file will however not contain the usernames from the original passfile meaning that it could be wise to include the (readeable) usernames from the passfile in your wordlist before starting JTR. This may sound illogical compared to what explained above (as the -single method allready might be using these to make a fast run) but I've found that it does make a little difference when you run it.
Please note the sequence of the command lines in the example bat-file given above. It's based on the number of possibillities each of the commands handles before stepping to the next. It's obvious that digits only cover 10 possibilities per position and alpha 26, lanmann (characters + digits) > 26 and all basically the whole ASCII-set. So the sequence is chozen on the bases of an increasing number of possibillities to make sure that the easiest found passess will found first (a bit like -salts does). Also alot of times when a pass becomes "violated" the username stays the same and the pass is changed to alpha-numerical or only digits so these are likely to be found first.
TIP: based on the (relatively) limmited number of samples in the i:digits range it might be wise to exclude all singles in your wordlist that contain only digits as they are likely to be found reasonably quick......

[sPlico]

This is part of the upper post, couldn't fit it in


F. I've got several logs what do I do ?
Well you could run it in dos with john passfile1.txt passfile2.txt etc. But I personally think it might be unwise to do so. Aside from being a little teadious I think it might be better to merge all the files into one big passfile (which will increase the initial output significantly!). Use Raptor and merge all your logs together and remove the dubs, and than save the updated passfile before running it with JTR ! An advantage of this method is that similar decryptions/passess will be removed by Raptor and thus save JTR time to focus on what hasn't been decrypted yet.
There is however one funny thing you might discover. Although Raptor has removed the dubs the output file will still contain dubs if you filter it again ? Well my guess is that although the encryptions in the passfile might be the same (aside from having the same username) not all the encryptions used to generate the encryption by the webmasterprogram are the same....and thus resulting in the same combo's although the origin is not the same ? It seems logical to assume this because if all encryptions where in fact the same there would not be any real use for JTR as Raptor would also be able to complete the job using a (big) reference file to search for the passess !
By merging all the logs from the forum and supplied to me by dutchbot I've gathered a passfile with some 130.000 encrypted log rules of which some 45.000 have been decrypted, after removing dubs some 40.000 unique one's remain....).

G. An idea (a bit above my head but feasible ?)
When AD finds a weak loggin goes through 3 stages. The first indicates a "This is a fake reply.....(1/3) The second stage act's like a crossreference with the log-file from the membersite (2/3). And finally you get the confirmation that it's a weak loggin and added in the progress (yellow) area (3/3).
What I aim to say here is that in the second stage (2/3) the loggin tried by AD changes into dome kind of encryption that might be the encryption used for the pass in the log-file of the membersite. I am no expert but if this is true than it could be and option (for someone much more experienced than me !) to see if this is true because if it is this might be a way to (also) make a crossreference from AD with JTR. What I mean is that if the encryption displayed by AD in the second stage is registered in a file this file would than hold the same kind of information john.pot does for JTR. Catching 2 flies with one stone ? => JTR learning while hacking (LOL) ?

H. The incremental methods (i:digits, alpha, lanman, all) basically try everything so should be used when all sensible options (to use first have expired...). Because of the sampling the rate is also slightly lower 400.000 (with surfing) to 600.000 (without).

I. passfile => john.pot => outputfile => what is what ?
Passfile = the log-file lines like "monkey:DYFFHhdhcj.",
John.pot = registered/found/decrypted passess like "DYFFHhdhcj.:monkey1" (with mokey1 being the pass),
Outputfile = found combo's like "monkey:monkey1" (in this example).

So if we look at the columns in each file and call the left column of the passfile (containing all the readable usernames) column 1 and the right column (containing the encrypted pass) column 2, than we can say that:
John.pot will contains "encrypted single from column 2:found pass",
Outputfile will contain "readable username column 1:found pass".

Or grafically (according to used example):
Passfile => "monkey:DYFFHhdhcj."
John.pot => "DYFFHhdhcj.:monkey1"
Outputfile => "monkey:monkey1"

I hope this might help someone at one point ?

I've seen that there are tutorials in several places in the crackers forum so if this is better moved elsewhere please do so ?

Heli

[sPlico]

My reply

It's a pretty good tutorial, but, im not sure when it was made since there are some falacies in there. I'll try to fix it in my post.

Single mode, as found in jtr documentation
"This is the mode you should start cracking with. It will try using the
login/GECOS information as passwords. Since the information is only used
on the account it was taken from (and on passwords with the same salt,
which takes almost no extra time), "single crack" mode is much faster than
the wordlist mode, which allows using a lot of rules (they are always
enabled for this mode) in a reasonable time. Guessed passwords are also
tried on the entire password list, just in case more users have the same
password. Of course, this will only get those passwords that are based on
the information used."
So, what this does is use "usernames" from the pfile as a wordlist (with rules found in[List.Rules:Single]) and tries that usernames on it's designated pass and all other encrypted passes with the same salt AND ONLY ON SAME SALT (because it takes almost not extra time at all). This means, it's not thorough as a -wordlist mode (which runs one word against ALL encrypted passes, no matter how many salts). Also, when it guesses a pass, it tries that same one on ALL passes because there is reasonable belief someone else might use that one aswell (and this also doesn't take much time because it's 1 pass on many salts).

That's why we musn't confuse -w mode and -si mode. That's what causes the real slowdown from -si mode to -w mode.

This chapter C needs whole rewriting. "-rules" just uses the wordlist supplied and applies the rules to it. And 1 at a time. Meaning, if you have 10 rules, it will first apply the 1st rule to the whole wordlist and run it against pfile, then 2nd rule to the whole wlist and go against whole pfile etc etc. (The actuall steps are 1st rule -> 1st word in wordlist -> whole pfile, 1st rule -> 2nd word in wordlist -> whole pfile, 1st rule -> 3rd word in wordlist -> whole pfile etc etc).
QUOTE
This method does the same as B but it also goes a bit further. Besides the whole singles in the wordlist it also tries parts of the the singles in the wordlist as samples. So if your wordlist contains the single "asshole" it will also try "ass" and "hole" as samples.

Im not sure where he got this but it doesn't do this. It can only do this if you supply the right rule (for this example, to try "ass" and "hole" from asshole you'd need 2 rules (/]/]/]/] and /[/[/[, it can be other ways but lets take this for example). BUT. These are done GLOBALLY, so, it would work only for the supplied word, but if you have something like "trustno1" in wordlist it would try "stno1" and "trus" and these don't really make much sense. JTR doesn't have any way of recognising words (as ass or hole). It does what you tell him to do, and that's that.
QUOTE
Personally I beleive that -rules does the same as the incremental method but based on the fact that a single can be seen as an character/number sequence which are all tried. And thus also the samples "as", "shole", "less" etc. are tried as samples.....

Also doesn't go. JTR can't recognise words/parts of words. It's rather easy to test this, and it doesn't do it.

QUOTE
The inclusion of the -salts:X indicates basically the priority that JTR should use to figure things out. I think that the higher X the more JTR focuses on a simmilar encryption (possibly meaning the same pass). As some words are more common than others as passess it's likely that JTR will thus find certain passess faster as it than has more material to figure things out."

-salts is used to "speed" a process a bit, but it also misses any passwords who's salt doesn't have the total of number we specified. Using -salts:2 for example will make John try salts with two or more passwords and skip those with 1 salt. By that, using -salts:1000 will make John try salts with 1000 or more passwords and skip those salts that have 999 or less encryptions.
For those that don't know, "salts" are the first 2 letters in DES encrpytion.
Examples:
notmenow:OxGqomf32Jid.
novaless:NZVa1AqAxgmOA
nubbycat:qoPggbFi1e3zI
salamou2:203CWm7aBA8xg
nutz1414:Ca3yrdjzo.EDg
salhomon:TEGoFFiV8scak
00241145:Gl0NyIvNCVznM
nookjay3:35QFwwgaEJtgU
norapiss:49IMzFpu9fAhQ
Are all different salts. Load that in jtr and you'll see "Loaded 9 passwords with 9 different salts (Traditional DES [64/64 BS MMX])"
But, on
notmenow:OxGqomf32Jid.
novaless:OxVa1AqAxgmOA
nubbycat:OxPggbFi1e3zI
salamou2:Ox3CWm7aBA8xg
nutz1414:Ox3yrdjzo.EDg
salhomon:TEGoFFiV8scak
00241145:TE0NyIvNCVznM
nookjay3:TEQFwwgaEJtgU
norapiss:TEIMzFpu9fAhQ
you will see "Loaded 9 passwords with 2 different salts (Traditional DES [64/64 BS MMX])"
QUOTE
D. john -w:wordlist.txt -rules -stdout:8 | unique huge.lst
john -w:huge.lst passfile.txt

I saw this in jtr documenatation aswell, but don't see any special usage in it except some slight "speed" gains and alot of diskspace occupied.

For "-makechars" i'd add something also from jtr documentation:
If you got a password file and already have a lot of passwords cracked
or sniffed, and the passwords are unusual, then you might want to generate
a new charset file, based on characters from that password file only:

john -makechars:custom.chr passwd.1
This will create a specific charset only for that passfile.

Chapter G. is also full of falacies. As figured by Sentinel, AD's fake protection is the same as "afterfingerprinting" in his tool. Im sure you know this Splendid, but i'll write for those that don't. Basically what this does is. Checks a combo against a site. If it gets a 200 OK response, it then sends some "fake" combo to the site (like "lf23kljdsf:dfsj23") and looks at the reply. If the reply for that one was also 200 OK it marks it as FAKE, if the reply was something else, it marks it as good (the actuall DETAILS noone actually knows because AD is not open source), but it is the basic principle. It doesn't try to "guess" encryption or something.

That's all i have for today. My conclusion for everyone would be like this.
1.st Don't dismiss the single mode so fast. Because of it's mode and speed it is VERY usefull for VERY complex rules that in -w mode would take ages. It's the single most powerfull mode in john there is if you ask me.
2.nd If you know some kind of rule is VERY VERY COMMON (like adding numbers behind a username $[0-9]) it is better to use -w mode.
3.rd Running -i:digits isn't as long as it might seem. Running that on 1 salt pfile will finish in about 10 minutes.
4.th when you fail in everything, switch to -i mode.

That's all for now. JTR is so extensive theme that we could talk for ages about it. I believe this will be enough for now for a little addition the the tutor up there.


part2

I myself always combine my pfiles together in 3 categories. All, tested against wordlist, newest. I almost never run 1 single pfile if that's what you meant.
Also, adding "69" after a word was my 1st rule i ever made LOL.
Btw, prepending "the" (<6^e^h^[tT]), appending "cat" (<6$c$a$t) and some things like that also give some more hits (dog, dr., cunt, etc etc, whatever you can think off).