Violent Ruby: Unix Password Cracker

We’re going to go over how to write a simple Unix Password Cracker in Ruby. While very impractical for any sort of real world use, the password cracking tool we’re going to write will be used to fulfill the same requirements as the following unix password cracker found in Violent Python and more — with a Ruby twist!

Violent Python Example

The following code can be found on GitHub. It requires a hardcoded passwords.txt and dictionary.txt files to be present within the current working directory of the program to attempt to crack an old school style unix password.

Ruby Equivalent

Basically the equivalent to the Python Code, but in Ruby — and much prettier ( in my opinion, of course ):

Unix Password Cracker

Let’s extract out the logic for our unix password cracker in Ruby to create a Unix Password Cracker class that will provide an interface to parse a given /etc/passwd file with a given dictionary, and of course, crack some passwords.

Once we do that, I’ll show you how to leverage it in a command-line application! Though that isn’t the limit to what we could do.

The Major Difference

Instead of simply writing a one-off script with some hardcoded values, we’re doing to create the foundation for other applications to do unix password cracking related tasks. This abstracts the logic away from simply spitting the results to STDOUT and will allow us to build better tools on top of the logic that is cracking a unix password, in a pretty basic form.

We’ll also cover some cool ruby tricks and ensure we’re using inline documentation to describe what’s happening within our code — which I believe you should be doing regardless of the language — and so that we’ll end up with some cool look’n documentation at the end. You’ll see!

Here’s the basics of what we’re going to achieve, covering the basic usage for the Unix Password Cracker class we’re about to write ( sort’of like wish drive development ):

Config

The config part of this class isn’t too complex. Basically all you need is some sort key => value pairing to match what the class would like. In this case, it’s looking for two specific keys which should be file: ( for the /etc/passwd) and dictionary: which should be a file that contains the words you’d like to use for the attack. This allows us to do things like load up a custom YAML or JSON config, convert it to a ruby Hash and you’re in business.

Otherwise, the config can actually be totally ignored and the class be constructed in a different few ways to start cracking passwords which we’ll get into further once we write the code to get the pseudo code we just wrote to work.

Unix Password Cracker Base

Let’s starting writing our class:

That’s a Lot of Documentation

If you’re from the information security community; and you’re used to writing your scripts without any comments this might be a little scary to you.

I’ve learned to love doing this for my code. Moreover, this specific inline documentation syntax ( yardoc ) isn’t all that bad; and actually doing it provides a lot of advantages as your designing your internal API. It also forces you to think a little bit more about what you’re writing because you’re explaining it as you go. The actual underlying communication in the class seems to matter a little more.

It was fairly easy for me to get used to actually putting this kind of work into describing my code; and it can allow others who aren’t familiar with the code a way to be able to understand it — especially if they were to view the html documentation generated when pushed up to ruby gems and rubydoc or generated at the command-line with yardoc.

You can totally ignore it though. And, perhaps if you’re just starting or writing those one off scripts that do exist, it’s not needed. But, when you need to use the “one off script” a bunch of time later down the line, it probably would’ve helped to document it — or write tests — for it when it breaks for some reason two months later when you really needed it. Beyond that: you won’t get pretty documentation like this:

This kind of documentation is really important when writing code. So, might as well do it while your writing the code, right? Write. Code. Right.

Now, to parse an /etc/passwd file, I’ve written a method to mange that logic with two inline examples to help with understanding its usage:

We can use this method in a variety of ways. Here are a few examples of its usage to show some of its flexibility:

But, we haven’t really gotten to crack anything yet, right? Let’s start working on that, because that’s kind of important for a “password cracker”:

However we really haven’t made a main “crack them passwords” method. That’ll help provide more clarity to this class I think:

The final method we’ve yet to implement in order to complete our class — notice how we haven’t wrote a format_result method to format our results? That’s basically the last thing we have to do.

We will mark this as part of our internal ( private ) API and document it as such. This is because we don’t want our “users” — the people who will use this, including ourselves — to really use this method, since it’s not really needed.

Now when we try to crack passwords, the result will be in the form of a hash which is much handier to work with than something directly printed to STDOUT in many cases.

All Together Now

Now that we’ve written our class looking at it in small parts — documenting pretty heavily — let’s look at what that looks like directly from the Violent Ruby source code . For giggles without all of the extra comments, for once, right?

You may have noticed I added some more aliases, because they’re awesome.

Command-Line Application

Let’s build the following command-line application:

To achieve that, all you need is this:

Conclusion

You can check out the code on GitHub with the rest of the Violent Ruby project. If you want to see why you want to use inline documentation, check out the official rubydocs for Violent Ruby’s Unix Password Cracker and I think you’ll like it a lot.

Hopefully you’ve found some good stuff out of all of this information or learned a little bit more about how awesome Ruby can be for Hackers, Forensic Analysts, Penetration Testers and Security Engineers.

Might as well end with this.

See ya’ next time, where I’ll go over how to take this Unix Password Cracker and implement a streaming REST API!