Teaching Ruby to a 9-Year-Old Part 3: Let's Program a Robot

This is part of a series of posts titled "Teaching Ruby to a 9-Year-Old."  See the Introduction for more information.

Computers Need to be Taught

Computers are giant calculators, and they can do billions of math problems every second.  They're also good at doing the same thing over and over.  But remember, they speak Computer Talk, not English.  And they have to be taught to do everything.  This can be a lot of work, but it's worth it in the end.

With Ruby, you can tell the computer to make decisions and do things.  We need to be careful how we tell it, though, because of the way computers think.  Let's look at a couple examples.

When Mom and Dad tell you, "Go put on your shoes for school," what are they really telling you to do?  In our house, it means:

1. Put on your backpack
2. Grab your water bottle
3. Go out into the garage
4. Put on your shoes

You know this because Mom and Dad taught you that.  (Sometimes Mom and Dad will remind you, and they'll even tell you all of those steps one by one!)  Remember, computers are dumb and have to be told everything.  Everything!  

Programming a Robot

So let's pretend we have a robot, which is really just a computer shaped like a human, and let's teach it how to do things.

Let's say that the robot already knows what things are.  It just doesn't know how to do stuff yet.  In Ruby, we'll put a list of actions together and define that list as something called a function.  (Define means to explain what something means.  For example, I just defined the word define.  Get it?)

Defining "Put on shoes for school" in Ruby

Now we've taught our robot something:  "If I say put_on_shoes_for_school, then grab_backpack, grab_water_bottle, go_into_garage, place_shoes_on_feet, that's it."

Notice that there are no spaces in the actions.  Also notice that you say "that's it" by writing "end".

If you programmed this into your robot, and then you gave your robot a command:  "put_on_shoes_for_school", what do you think the robot would do?  Let's try it using Ruby!

Step 1 - Defining function put_shoes_on_for_school

Okay, this part worked great.  Ruby gave us a fist-bump.  Let's tell it to put_on_shoes_for_school now.

Uh oh!  Why did Ruby barf?

Oh no!  It looks like Ruby didn't like what you said.  What do you think happened?

Remember how we learned that computers have to be told how to do everything?  Let's look closer at what we told it to do.  When we said put_on_shoes_for_school, Ruby said, "Okay, I'll start by grab_backpack.  Oh no!  I don't know how to grab_backpack!  I'm going to barf now!"

See?  We gave Ruby a list of things to do, but we didn't tell it how to do all of those things.  Make sense?  Here's what a more complete program might look like:

So now, if you told the robot to grab_backpack, grab_water_bottle, or go_into_garage, it knows what to do!

Oh my gosh, do you see what just happened?  Somehow you've ended up learning about a whole page of computer code!  If you showed this code to most grownups, they'd tell you it's too hard to figure out.  Just tell them all you're doing is defining some functions, duh!  We haven't even done the hard stuff yet!

Teaching Ruby to a 9-Year-Old, Part 2: The Smart - Dumb Computer

This is part of a series of posts titled "Teaching Ruby to a 9-Year-Old."  See the Introduction for more information.

Computers are Really Smart...

Computers are basically giant calculators.  Type in a big multiplication problem, and watch how long it takes to figure out the answer.  Note:  On computers, we say "times" with a *.

This took less than 1 second.  My computer is super smart!

Computers are Also Really Stupid and Stuck Up.

Computers speak their own special language.  If you say something to the computer, and you don't say it exactly the right way, it says it doesn't understand.  Then it barfs on you. Look at these examples when I try to tell it to clear the screen:

Don't Make the Computer Barf

When we write a computer program, we need to be sure we don't make the computer sick.  This means we have to be very careful about how we write things.  Even something as simple as forgetting to put the period at the end of a sentence can make the entire program not work.

 

Nil

A long time ago, I put Ruby on my tablet.  I thought it was broken because it kept saying nil all the time.  Later on, I learned that nil is good!

The word "nil" means "nothing."  When Ruby tells you "nil," it means "Nothing is wrong.  I'm not going to barf on you."  So whenever you see that word on your screen, get excited because the computer just gave you a high-five (or fist bump)!

Teaching Ruby to a 9-Year-Old, Part 1 - Introduction

I Learned This When I Was a Child

I learned how to write computer programs when I was a boy.  This was due to interest as much as necessity.  Our Commodore 64 and Texas Instruments TI-994-A didn't have a mouse, Windows, or any of the other features we currently take for granted.  I wasn't a child prodigy; programming was simply part of the experience of using a computer.  The language was called BASIC, and that word best describes my abilities at the time.


Fast forward more years than I like to acknowledge, and my grasp of computer programming is still nascent, or perhaps adolescent, at best.

Although not required for my daily work, knowing how to program (or "script" as we say now) could be very helpful and lucrative.  So I've set upon the journey of learning, and what an adventure that has been.  Like many computer geeks, my knowledge is fragmented.  I have great understanding of certain advanced subjects and little understanding of others.  Like most people who don't understand programming, when looking at lines of code, such as this simple snippet, I feel like it might as well be written in hieroglyphics. 

A snippet of code I wrote for submission to the metasploit project.

This fragmentation of knowledge is a strange combination.  On certain subjects, I could teach a college-level course.  On others, I need to sit in a class and have an instructor mete out knowledge as if I'm a child.  After many false starts - reading books that quickly traveled beyond my comprehension - I had  the realization that (with respect to computer programming) I need to be taught like a child.  This ultimately led to some measurable advances in my education and understanding.

If this is you - if the words in the picture above seem like complete gibberish - I encourage you to keep reading.

Teaching Ruby to a 9-Year-Old

My son is 9 years old and is interested in math and science.  But for the son of a Digital Forensic Analyst, he's woefully uneducated regarding computers.  I've often heard the expression, "The best way to learn is by teaching," so I've dedicated myself to learning Ruby by teaching him.  Convincing him was easy:   He was hooked the minute he discovered that, with a few lines of code, he could make the computer display the word "butt" on the screen 100,000 times.  I hope he never gets too old to enjoy that experience.

In this series of posts, I will chronicle my method of explanation.   If you're already knowledgeable about computer programming, these posts will drive you crazy with their slow pace and simplistic language.  But if you're like me, wanting to learn this one bite at a time, you may find them helpful.

So, fellow Grownups - set your ego aside and put on your thinking caps.  The bell has rung; class has begun.

Note:  If you want to follow along, you will need to install Ruby and use a programming-friendly text editor like Notepad++.

A Shout-Out to a Great Piece of Software

I want to take an opportunity to write about a piece of software I use in every single investigation.  Please note that I do not work for the software company, nor do I receive any compensation from them.

SAW (SMART Acquisition Workshop) is a staple in my forensics lab.  The software is made by Andrew Rosen of ASR Data.  I'll take a moment to mention here that his software (an entire Forensics suite, including SAW) is cheaper than the stuff from Big G or Big A, and he doesn't charge annual "maintenance" fees.

This is how SAW works, as I understand it.  When imaging a device, instead of writing out a cluster of zeroes, it simply makes a note of it.  The resulting file is often significantly smaller than a dd image would be because it is a sparse file.

SAW imaging a 160GB 2.5" SATA HDD.

In the example shown in the picture (sorry for the bad quality), the Source device is mostly empty.  Because SAW creates a sparse file, the acquisition process isn't slowed by having to write zeroes to the Target drive.  Note the current acquisition speed of 82.28 MB / second on a standard USB3 connection and the amount of data "optimized."

The resulting evidence file in this particular case (a 160 GB drive) was just over 6 GB - a whopping 96% reduction in file size.

The use of a sparse file is a clever idea in several ways:

First, the original data is not altered or compressed.  What is missing from the end file is what wasn't there in the first place (e.g. thousands of 4k chunks of \x00).  Andrew likes to say, "What's missing from the file is Nothing.  Nothing is missing."

(That play on words reminds me of a co-worker who called IT and stated his keyboard wasn't working. When the tech arrived, my co-worker stated, "Seems like somebody spilled coffee on it." The tech picked up the keyboard and out poured what seemed like a full mug's worth of coffee.  The tech said: "Be honest, you did this, didn't you?" to which my co-worker replied, "Well, I'm somebody!")

Second, the resulting sparse file can be read (e.g. keyword searched, carved, etc.) by any other program without that program supporting a specific decompression algorithm.  Additionally, the processor isn't bogged down with any decompression.  For the drive shown in the picture, it would mean no waiting for the hard drive to read out 154 gigabytes of zeroes on every job.  I've run tools like IEF against such files with great success.

Third, if you want to mount an actual image, with zeroes and all, you simply instantiate one using a companion piece of software called Smart Mount.  Smart Mount presents the filesystem with a dd image (called 'image.dd') while simultaneously creating a mount point that can be browsed manually.  That's neat and all, but what is significant is how the zeroes are re-inserted.

When the OS reads the instantiated image.dd, or you browse through the mounted filesystem, the "missing" zeroes are read not from the hard drive (remember, they were never included in the forensic image), but instead from /dev/zero.  So the processor, not the hard drive, is slinging those zeroes about.

I wrote this as some food for thought that might help some of you - especially those of you who find your storage arrays filling up with mostly-empty forensic images.  Again, I use this piece of software on every forensics or data recovery job I perform.