Page 5 of 7 FirstFirst ... 34567 LastLast
Results 41 to 50 of 66

Thread: new version of crunch

  1. #41
    Member
    Join Date
    Mar 2010
    Posts
    87

    Default

    Quote Originally Posted by bofh28 View Post
    No. crunch will not output a compressed file. You can do that after crunch is done. I leave it to the user to choose which compression algorithm they want to use (zip, bz2, tgz, lzma, etc).
    I was thinking with my new i7 build I could leave it run for a few weeks and not have to worry about disk space shortage to much.

    still I wonder if I output it directly to pyrit if it is faster that way or generate a wordlist?

  2. #42
    Good friend of the forums
    Join Date
    Jan 2010
    Location
    outside chicago, il
    Posts
    442

    Default

    Quote Originally Posted by intertan View Post
    I was thinking with my new i7 build I could leave it run for a few weeks and not have to worry about disk space shortage to much.

    still I wonder if I output it directly to pyrit if it is faster that way or generate a wordlist?
    I guess I could add a flag when the -o option is used to compress the file after the rename..... I will have to think about this one a little bit. If I do this there will only be three options, gzip, bz2, and lzma and it will do maximum compression i.e. gzip -9 for example.
    I like the bleeding edge, but I don't like blood loss

  3. #43
    Good friend of the forums
    Join Date
    Jan 2010
    Location
    outside chicago, il
    Posts
    442

    Default

    I broke down and signed for a sourceforge.net account. You can download crunch 1.7 at https://sourceforge.net/projects/crunch-wordlist/
    The project is very basic at this point. I hope to add the code to the svn repository and create a better website. I just need some time to get it all done
    I like the bleeding edge, but I don't like blood loss

  4. #44
    Just burned his ISO
    Join Date
    May 2009
    Posts
    16

    Default

    Nice
    It will be easier to get releases now!

  5. #45
    Junior Member
    Join Date
    Mar 2006
    Posts
    28

    Default

    Here is part-2 of my tests to see if it is faster to save the results of crunch to file or to run crunch during an actual password attack and pipe the output into your password cracker

    Experiment #2)
    Goal: Run the previous tests again with a much larger set of inputs

    New crunch command:
    ./crunch 1 7 abcdefghijklmnopqrstuvwxyz > 1_7_loweralpha.txt

    File size of input: 62 Gigs

    The experiment setup is the same as the previous tests:
    Cracking 1 Md5 hash to maximize the time spent reading input

    Using the saved file and cat'ing it into JtR
    Command:
    time cat ./1_7_loweralpha.txt | ../../John/run/john -stdin -format=raw-MD5 one_tough_hash.txt

    Results:
    Loaded 1 password hash (Raw MD5 [raw-md5])
    guesses: 0 time: 0:01:22:53 c/s: 1679K trying: zzzzzzz

    real 82m54.145s
    user 71m20.918s
    sys 2m44.841s

    Running crunch and piping the output into JtR
    Command:
    time ./crunch 1 7 abcdefghijklmnopqrstuvwxyz | ../../John/run/john -stdin -format=raw-MD5 one_tough_hash.txt

    Results:
    Loaded 1 password hash (Raw MD5 [raw-md5])
    guesses: 0 time: 0:01:58:43 c/s: 1172K trying: zzzzzzz

    real 118m43.774s
    user 128m30.011s
    sys 2m38.801s


    Conclusion:
    At this point I did start to see a noticeable improvement of saving the results of crunch to disk, with the pre-generation of the input dictionary file saving around 26 minutes, (or 57 minutes of user time which would have an impact in a multi-threaded password cracker).

    Using the worst case scenario: On a single-threaded cracker this means that it would take around 22 hours to process a 1 terabyte pre-generated input dictionary using MD5, or 31 hours if you run Crunch during the cracking session.

    This should be a fairly accurate upper limit of the time savings since an input dictionary larger than 1 terabytes would be rare, (and any file compression would further reduce the time savings as the attacker is forced to unzip/untar it before use). Also, with many hash types such as WPA, (which uses 4096 rounds of SHA1), an attacker would spend much more time on the hashing function. This reduces the relative time savings of pre-generating the input dictionary. Aka in a cracking session that lasts less than 2 hours, a time savings of 30 minutes is significant. On the other hand, a cracking session that lasts 10 months, (due to a stronger hash), the 30 minute time saving due to pre-generating the input dictionary becomes less significant. Even if a fast hash like MD5 is used, pre-generation of a brute force input dictionary generally still will not be that effective due to the fact that many cracking sessions will run longer than disk space would allow, (aka you often wouldn't only try to brute-force passwords that were 1-7 characters long containing lower-alpha characters).

    As always, if you have any questions/comments please let me know. Also, in a bit of shameless self promotion, I maintain a password cracking blog at Reusable Security

  6. #46
    Good friend of the forums
    Join Date
    Jan 2010
    Location
    outside chicago, il
    Posts
    442

    Default

    crunch 1.8 is available at SourceForge.net: crunch - wordlist generator

    It adds support for compressing the output. See the man file for details.
    I like the bleeding edge, but I don't like blood loss

  7. #47
    Developer
    Join Date
    Mar 2007
    Posts
    6,126

    Default

    Nice, I'll get this updated right away for the next release.

  8. #48
    Member
    Join Date
    Mar 2010
    Posts
    87

    Default

    Quote Originally Posted by bofh28 View Post
    crunch 1.8 is available at SourceForge.net: crunch - wordlist generator

    It adds support for compressing the output. See the man file for details.
    thanks for doing this. my i7 975 should be uop and running in the next week or 2, depending on when my nb/sb water block comes in

  9. #49
    Developer
    Join Date
    Mar 2007
    Posts
    6,126

    Default

    1.8 committed and should be available soon

  10. #50
    Very good friend of the forum Virchanza's Avatar
    Join Date
    Jan 2010
    Posts
    863

    Default

    I know I've harked on about this a bizzillion times in the past... but there's something awry if the password file version is faster than the on-the-fly version. The on-the-fly version cuts out the disk-read-disk-write phase and so should be faster all the time.

    If the password file version is faster, there must be some sort of bottleneck in the on-the-fly version, perhaps something to do with the way in which input is read from STDIN.

    I can't stress this enough though, the on-the-fly version should never be slower (especially when you take into account the time wasted creating the dictionary file).
    Ask questions on the open forums, that way everybody benefits from the solution, and everybody can be corrected when they make mistakes. Don't send me private messages asking questions that should be asked on the open forums, I won't respond. I decline all "Friend Requests".

Page 5 of 7 FirstFirst ... 34567 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •