Category: Utility Scripts
Author/Contact Info Alien
Description: Simple script if you have a md5 hash and want to crack it ! 
#!/usr/bin/perl 
#attempts to crack a md5 hash using a dictionary file
#you run the program this way
# perl md5 hash_to_crack dictionary_file


use warnings; 
use strict;
use Digest::MD5 qw(md5_hex); 
my $hash=shift || die "Give me a hash to crack\n";
my $file=shift || die "Give me a dictionary file\n";
open(F,$file) || die "can't open the file\n";
while(<F>)
{
print "Processing $_";
chomp($_);
my $t=md5_hex($_);
print " $t\n";
die "Found it -> $_\n" if($t eq $hash);
}
Replies are listed 'Best First'.
Re: MD5 Cracker
by Limbic~Region (Chancellor) on Nov 16, 2006 at 15:02 UTC
    Alien,
    You have several issues with your post. First, you aren't following some best practices:
    • 3 arg open (fenLisesi points out the danger above)
    • lexical filehandle
    • indentation

    Additionally, you fail to mention Salt (cryptography). Your title is also misleading. It seems to imply you can crack any MD5 hash when in fact it could only find entries in the user provided dictionary.

    Cheers - L~R

[reply]
Re: MD5 Cracker
by geekphilosopher (Friar) on Dec 10, 2006 at 18:39 UTC
    If you're interested in breaking cryptography, you may want to check out Rainbow Tables, which can also be used to break (unsalted) hashes such as MD5.
[reply]
Re: MD5 Cracker
by parv (Parson) on Nov 16, 2006 at 05:48 UTC
    I like the fact that success is printed on (default) standard err, while the progress goes to (default) standard out so that both output may be redirected elsewhere independently.
[reply]
      Howver, the error codes are a bit screwy, and this seems like just the thing you'd want to automate. 
      .
.
.
   if ($t eq $hash) {
      print STDERR "Found it -> $_\n" 
      exit(0);
   }
}

exit(1);

      [download]
[reply]
[d/l]
Re: MD5 Cracker
by fenLisesi (Priest) on Nov 16, 2006 at 10:53 UTC
    Could someone call this with a filename such as '> $INTERESTING_FILE'? Cheers.

    Update: I see that I did not explain my point well at all ($INTERESTING_FILE is meant to be a shell var, for one). Let me put forth a worst case scenario: A crazed admin installs this utility setuid root and a user calls it with a string that will cause this utility to open the system password file in write mode. Typically, it would just be able to mess up the files on which the user already has write access, which is not a big problem. It is probably best, though, to always keep in mind the concentric-circles approach to security and use Taint, avoid the shell, etc. Also, Corion mentioned in the CB that a self-respecting developer would salt the data passed by the user, so even if the data were a dictionary word, this utility would not work.

[reply]
[d/l]
[select]

Back to Code Catacombs