|
Message-ID: <AANLkTin4Qqm+_nRUR1hj1qA46S93fK4H4E74xwnnUUFQ@mail.gmail.com> Date: Mon, 25 Oct 2010 10:36:53 -0400 From: Charles Weir <cweir@...edu> To: john-users@...ts.openwall.com Subject: Re: Solution to this 'l33t' rules problem? This is a really interesting problem since it's certainly a needed attack type to target more advanced passwords. As Brad pointed out, the posted suggestion by Solar and Rich to generate replacement rules can get really nasty when multiple replace types are implemented at the same time, such as 'p@...ord'. I spent a little bit of time trying to write a script to auto-generate a JtR config file that would contain those thousands, (if not more), of potential replacement rules but I eventually ended up dropping that approach and instead decided to make use of JtR's -stdin option. On a side note, JtR's -stdin option is one of the main reasons I use John. If you can think of a way to generate guesses, even if JtR's built in mangling rules doesn't support it, you can always write your own program/script to generate the guesses and still use JtR on the back-end to handle all of the hashing. To that end I wrote the program 'noobify', which is available at the following link: http://sites.google.com/site/reusablesec/Home/password-cracking-tools/noobify Yes the name is a play on l33tify ;) I tried to make it as customizable as possible. Below is an explanation of a couple of the design choices: 1) As the name implies, it will apply every possible replacement rule to an input word and then output it for JtR to hash. Aka the word 'noobify' could generate n0obify, n00bify, n00b1fy, n0ob1fy, no0bify, no0b1fy, noob1fy ... 2) It reads in the replacements to use from a tab separated text file, (the default file is replacements.txt). This allows the user to specify the specific replacements they want to use, vs hard-coding them in. For example, you can also do things like uppercase vowels if you want by replacing 'a' with 'A', etc. This also allows the user to have multiple replacement profiles for use in different cracking sessions. 3) It replaces substrings instead of characters. This allows for multi-character replacements. The most common 'l33t' example would be replacing 'f' with 'ph', but it actually opens up a bunch of other options as well. For example you can replace '2009' with '2010', or 'monday' with 'tuesday'. The replacements do not have to be the same size. 4) Currently it works a lot like middlechild, http://sites.google.com/site/reusablesec/Home/password-cracking-tools/middle-child in that it will take input from stdin, and then output it to stdout. Probably the most common use of it would be: cat <input_dictionary> | ./noobify | ./john -stdin -format=<hashtype> <target_hashes> 5) Currently it doesn't apply any other mangling rules. If you want to apply additional mangling rules you do have a couple of different options available to you. The first is to use noobify to generate a custom input dictionary instead of piping the output directly into John. Then you can use that input dictionary with all of your existing JtR mangling rules. The second option is to chain the output into a second mangling program like middlechild. For example, the below command would also capitalize the first letter and append two digits followed by one special character: cat <input_dictionary> | ./noobify | ./middlechild -capFirst -append D2S1 | ./john -stdin -format=<hashtype> <target_hashes> The advantage of this approach is that it works for much larger input dictionaries, since you don't have to save the mangled results to file. The downside though is that it applies EVERY mangling rule to each word before moving on to the next one. When you use John's rules you can optimize it a lot more to try high probability rules first, which will usually result in you cracking passwords much sooner in your cracking session. 6) I practice "agile development", which is a nicer way of saying that I try to get a proof of concept working before I focus on making it 'good'. Currently there's a lot of inefficiencies in the code that make it run fairly slow compared to most other mangling rules, (the biggest probably being in how I currently identify replacements in the actual word). I should be able to fix some of them fairly soon, but even in it's current state, at least you can make guesses which were difficult to generate beforehand. Also as stated above, you can always save the results to file, making the running time of this tool only a one time cost. 7) I just realized I forgot to test it, but theoretically the tool supports deletions as well, (in the replacement file just have the value you want to delete followed by a tab and then a return). This way you can do things like remove spaces and punctuation from a passphrase input dictionary. If it crashes horribly when you try to do this I should have a fix soon ;) 8) Yes the code is C++ so you will have to compile it. I realize I should have written it as a script to make it easier to use, but I like writing in C++. The code is GPL'd so feel free to modify it. 9) The default replacement file I included is just a proof of concept. Aka I got tired after entering the different replacements in for 'january', aka january->february, etc, so I didn't do any of the other months ;) 10) As an addendum to the previous point, be careful when you a copying and pasting replacement rules, since many editors will paste spaces instead of tabs. As always, if you have any questions/comments/suggestions, please let me know. Matt Weir http://reusablesec.blogspot.com
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.