Choose color scheme

About the Author

521 Posts By ben

  • OpenMPI distributed password cracker: crackzor

    Download

    crackzor_1.1.c.gz

    Previous versions:

    crackzor_1.0.c.gz

    Quick start
    1. Download & extract with “tar zxvf crackzor_1.0.tar.gz”
    2. Make sure you have the right packages in place
      sudo apt-get install build-essential libopenmpi-dev openmpi-bin libssl-dev
    3. Compile with
      mpicc -O3 crackzor.c -o crackzor -lm -lssl -lcrypto
    4. Create a file called “machines” containing a newline separated list of every machine that are in your cluster, for example:
      machine00.domain.com
      machine01.domain.com
      machine02.domain.com
      machine03.domain.com
      machine04.domain.com
    5. Open MPI uses SSH for communication between nodes, as such, you need to make sure that the node you will be launching crakzor from is able to do SSH key based authentication to all the other nodes in the cluster. For my example above, if machine00 is where you will be working from, you will want to
      ssh-copy-id machine0X.domain.com

      where X E [0,4] (yes, machine00 needs to be able to SSH to itself).

    6. You now need to disseminate your executable across all the machines that will be running it:
      for machine in `cat machines`; do scp crackzor $machine:~; done

      Pro-tip: having network storage attached to all the machines makes this step unnecessary.

    7. Run with:
      mpirun -npernode Y -machinefile machines crackzor fbade9e36a3f36d3d676c1b808451dd7 abcdefghijklmnopqrstuvwxzy 1 1

      where Y is the number of cores each machine in your cluster has. If you are running this on machines with 2 CPUs with 8 cores each, Y = 8 * 2 = 16.

    Tested on Ubuntu 10.04 64b / Ubuntu 12.04 64b / Ubuntu 14.04 64b

    Screenshots
    mpirun -npernode 16 -machinefile machines ./crackzor 7ca4793dcdff46ecda38e48d65b6c913 abcdefghijklmnopqrstuvwxzyABCDEFGHIJKLMNOPQRSTUVWXYZ 1 7

    This is what “htop” looks like with a bunch of processes spawned & hammering every core:

    Statistics

    For the purpose of testing crackzor, we give it the md5 hash of an 8 character word and tell it to bruteforce it up to 7 characters. This insures that we will compute every permutation up to 7 character longs. The characters I asked it to permute are “abcdefghijklmnopqrstuvwxzyABCDEFGHIJKLMNOPQRSTUVWXYZ”, our sample space size is thus 52^7 + 52^6 + 52^5 + 52^4 + 52^3 + 52^2 + 52^1 = 1,048,229,971,204.

    Here is the raw data, and here it is graphed:

    I wish it would show the linear progression more but 3 things got in the way:

    1. approaching the machine’s actual number of cores on the Dell blades leave little room for linear expansion
    2. which is emphasized in a multiuser environment where other users run other computation
    3. the EC2 bar flattens the graph a bit but I still wanted to show how it compares

    Ideally I would run through a few iterations of EC2 to observe its progression but hey, it’s expensive :).

    Limitations
    • Right now, the only hashing algorithm supported by crackzor is MD5. It can very easily be expanded upon.
    • I also may not be using the fastest MD5 method with the fastest call, distribution is what I’m interested in.
    • Distributing password cracking among multiple machines is throwing linear resources to an exponential problem!
  • Beehive in place & housing a colony!

    Well, this is it. After much prep work I have finally released my first package of bees in the hive. Everything did not go according to plan, the candy separating the queen from the rest of the colony had already been eaten. As a result the queen did not get a chance to be released by the workers. I managed to keep her in there while I was releasing the remaining 3lbs of bees. Things went well other than this and I am hopeful that she’ll be accepted by the others as they had been traveling together for a while. I’ll try and locate her in a couple of days and if I can’t find her, I will rush order another queen. It’s nice that I get another shot if needed.

    All the extensive information I gathered online (various blogs, Youtube videos) prepared me pretty well for what to do. Nothing however can prepare you for the experience of handling a liquid-like swarm of buzzing bees. It was very impressive & I was definitely glad I got a full suit. Not that they were even really pissed at me for shaking them in their new hive. But it felt like a wrong move could change everything for the worse very fast. I eventually learned to trust my suit.

    I went back to install an electric fence with a friend the next morning (bears & skunks are an issue in the area), no buzzing was to be heard. Nothing at all, I opened a couple of bars and couldn’t see a thing. Finally I found them on a few bars and disturbing them made the whole swarm start the day. It was super cool to see them do their thing.

    The hive in its final location, with a new roof & fenced in to withstand the local wildlife

    The hive actually faces an orchard which is starting to bloom, perfect timing for some pollination help. I intend on taking more pictures in a few days.

  • tcpdump full packets to a file

    Because I always end up wasting 20 minutes looking it up.

    tcpdump -i ethX -s 0 -w traffic.pcap
  • Getting the top bars ready

    The bars’ width is already at the optimal length at which bees build their combs, but to make sure they get it right we guide them by pouring wax along the middle of the bars. Supposedly they’ll know to expand on it.

    Might as well use the remaining wax for something

  • Add fault tolerance to cron noise

    Not all cron jobs are created equal, and some of them can afford to fail sporadically before we need to worry about them. Maybe they rely on a third party server, and we don’t want the occasional fail to pollute our inbox.

    Here is a little cron job wrapper I created that will suppress stderr but keeps track of the job’s returned exit codes. Above a certain threshold of consecutive abnormal exits it doesn’t suppress stderr anymore.

    
    # if the counter file doesn't already exist we create/initialize it
    if [ ! -f /tmp/counter_ri7g3 ] ;
    then
        echo 0 > /tmp/counter_ri7g3 ;
    fi ;
    
    # we pull the current counter
    counter=`cat /tmp/counter_ri7g3` ;
    
    # if the counter is still small, we send stderr to /dev/null
    if [ $counter -lt 5 ] ;
    then
        $1 > /dev/null 2>&1 ;
    # otherwise stderr will follow its normal path and find its way to email
    else
        $1 > /dev/null ;
    fi ;
    
    # lastly if running the $1 resulted in an abnormal exit, the counter is incremented
    if [ ! $? = 0 ] ;
    then
        counter=`cat /tmp/counter_ri7g3` ;
        echo "$counter+1" | bc > /tmp/counter_ri7g3 ;
    # and if $1 exited normally, we reset the counter
    else
        echo 0 > /tmp/counter_ri7g3 ;
    fi ;
    
    

    a cron entry calling it looks as such:

    
    30 * * * *      root      /usr/local/bin/cron_wrapper "/path/to/script arg_1 arg_2"