Hacker Theory: 101

Anyone who has ever sat in front of a computer with the intention of using it has, at least subconsciously, questioned themselves along the following lines:

"What can I do?"
"How do I... ?"
"Why does this... ?"

The first question might not be a recurring one, but it should be. Knowing what you are capable of is very important. Can you process a list of 100 names into mailing labels? Can you send an email? Can you create a website?

The tasks that we perform are the ones that we can perform. The rest are tasks that we will either never take up, or ones that we will abandon in frustration. But those that we are capable of, we do not have to question; when it comes time to use the skills we have, we know what to do. Stating that is being redundant with logic itself, but bear with me.

I don't have to wonder what to do about a lot of things. The reason is not that I understand how to do those things. (I do, and that's nice). The real reason I don't have to wonder how to do a lot of things is that I understand why they work. If I run into a problem with a program somebody else wrote, I know how to get around it a lot of times simply because I know the thinking process that goes into writing such a program.

I'd like you to take that approach. Don't simply question how to send an email. Ask yourself, "Why does this work?" It is tempting to ask yourself how it works, but that's just details. Why, why does this work?

Here's an example to show the difference between those questions:

Lets say you're the newest employee at the United States Mint. You're all stoked about printing money, and of course you're going to be responsible about the whole thing. So, the first question you have is "How do we print money?" You're introduced to machines, inks, computers, papers, fibers, watermarking techniques, and all the rest of the process. (I used to visit the Denver Mint – its very cool to watch!) Eventually, as your experience grows, you fit into the work team there and you begin feeling a bit like a machine yourself. But you know how it works, and that's enough to get the job done.

Now, back up a moment and look outside the boxed-in view of that fictional day job. Before you were introduced to how the process works, people had to invent the process. They had to make the machines. Somebody had to design the money, and somebody had to approve the design. Efforts were made to ensure the uniqueness and security of not only the process, but of the resulting product as well. On the other end of the spectrum, downstream from you are millions of businesses, customers, counterfeiters, and FBI agents spending quite a bit of time handling your product. The customer holds their bills up to the light to look for a watermark. The business owner runs a special marker across a $20 to make sure it is real. The counterfeiter does their best to imitate the whole affair, and the FBI man has to sniff out his criminal substitute. I've heard that the FBI prepares for the investigation of counterfeiting by examining a real dollar bill intensely. They look at the real deal so that they will notice any departure from that pattern when they come across a fraud.

With all this in mind, ask yourself – "Why does this work?" Why does the process, which you've learned to be a small part of, come together into one big functional system?

The answer to most questions in that vein is that people decided to do things in a certain way, successfully tested and implemented that method, and have been able to contain departures from that method at an acceptable level ever since.

I think I'll say that again.

People decided to do things in a certain way, successfully tested and implemented that method, and have been able to contain departures from that method at an acceptable level ever since.

Leaving analogy-land... Most computer users only interest themselves in the middle of that reality – learning how a method has been implemented, and how they can use that method in a routine manner.

Hackers look at the whole she-bang. I'm not just curious in how to repeat a process another guy came up with. I want to know why they chose that method. What other methods could they have chosen? When they tested their method, what were the results? Was this the best way of implementing that method? Could there be improvements? Are there holes in their thinking? Are there holes in there implementation? What departures from this method can and do occur? How are these departures contained? Is it possible to depart from this method in a way that cannot be contained?

As you may begin to see, the simple process of intense examination has already led to questions that raise ethical and even moral questions of their own. That's a discussion for another post, though.

A Lesson in Thinking, as Given to Me

One of the first things to examine as you begin learning about computers is naturally the reason driving you to do so. Is it curiosity? A desire for power? Social status? Income? A deep need to author, to create?

When I was little, I was always fascinated by people using computers. By pressing buttons (and sometimes, by moving a small plastic brick on a cable with three buttons), computer users were able to change things. They knew how to "go places" without physically moving; how to solve problems in a seated position. It was a restful, potent, mysterious thing they did. And I wanted to do that too.

The first computer I got my hands on was a TRS-80 Model 100 – the original laptop. The last, and favorite, machine that Bill Gates personally worked on, the "trash-80" was an amazing little machine. It booted instantly, had no hard-drive, and contained no real productive software (would you use a computer today that couldn't permanently store anything internally?) besides some simple note-taking and calendar(ish) features.

But there was BASIC.

I was fascinated by the fact that I could give commands to the computer, and it would listen to me. I was aware that computers had to respond when a user interacted with it (something that M$ Windows threw out as 'old-school' later), but captivated by the fact that I could tell the computer how to respond when other users were at the keys. Trisha and Megan (we were all about 7-9 years old back then) were probably so sick of me asking them to guess endless sequences of numbers and passwords I coded into my little programs. That's actually about all I did for a while:

I created code for the sole purpose of challenging them to "break in", with their only reward being my respect and a terse "Success" message at the end.

Sometimes it was easy, other times it was boring. Heh heh. But I was tickled pink at their efforts... What could that next 10-digit number possibly be? ;]

Of course, eventually I shared with them my dirty secret – you can always see what a hard-coded password is if you can just get hold of the source code. Press the right function key, or type "LIST" at the prompt, and you've got my sneaky plans all laid out for you. But I gave that knowledge at a price – now they had to create sequences for me!

We also played hide-and-go-seek.

Three events boosted my confidence and curiosity immensely.

1. Having discovered that the secrets were in the source, I was quite naturally curious to see everyone's source code, and learn how they did what they did.
2. I got hold of a book with line after line of printed code, and painstakingly copied the ones I could understand. (If I couldn't change it myself, I didn't want to run it).
3. QBasic, DOS, and the use of a hard drive on the super-advanced 386 opened a world of graphics (mostly colors and line patterns), system exploration, and the ability to return to multiple .bas files over and over without fearing loss of code.

However, the single most important event was definitely an encounter I had with another hacker. All I remember now (I'm writing this about 20 years after these events took place) was that I was either being baby-sat or, at the very least, entertained by one of my parents' friends. Him and his wife were over at our house in Denver, and I was showing him my little "office" in the basement, and the programs I would work on. He told me he was impressed with my "setup" and progress in coding, and we had what is now my first recollection of a "talking shop" experience regarding technology. Then he told me something that got me so stoked, I had to go jump on the trampoline to burn off the energy – he was going to write me a GAME on the trash-80, right there, with no reference books or anything. Wowww! I waited and waited... and waited. Before he left with his wife later that night, he handed me a machine that was far more intelligent, far more valuable, far more inspiring, far more useful than the one I had handed him...

This computer knew how to play Rock-Paper-Scissors!

I played and played, and studied and studied, the code this man had written from scratch. Sadly, the code was lost when the batteries ran out and the trash-80 could no longer keep it in RAM. But not before it had made an indelible mark in my life.

As a homeschooler, I was (and still am) armed with the tools needed to be a good hacker. Self-study, self-motivation, and an absence of the herd-mentality that many public and private schoolers must overcome.

But enough about me. Hopefully you now understand a little about my motivation(s) in writing code - to create, with a child-like fascination. What are yours? What motivations drive you to learn, understand, and grow your skills with computers?

Take Me to School!

Have you ever lurked on an IRC channel, seen a desperate (off-topic, and likely from a 14-year-old) broadcast plea along the lines of "plz take me to school! teach me to hack i will be your apprentice plez kthx", and thought to yourself "he's talking to me, poor guy." Heh heh.

Well, though many of us aren't that rude or deluded, I think inside all of us we have a desire to be led by a Master into the mysterious lands of computer Kung-Fu.

My Kode-Fu is strong, and I'm here to help. (Warning: authors in mirror may be less arrogant than they appear). ;]

Consider this a crash-course in meeting your goals. Computers, applications, and programming languages are all tools, and many true hackers see their mastery and comprehension as a goal within itself. However, at the heart of every effort to comprehend, be it ever-so-slight, lies a desire to utilize that comprehension.

So, while some posts may seem circular ("I'm learning to write Elisp code for Emacs so that I can create tools to better write Elisp code in Emacs?", you entreat?), I will leave you with an anecdote to ponder as you begin your lessons...

I heard a story once of a young man who left his family to go live with a Kung Fu master in the mountains. He was eager to begin learning all the tricks and secrets that would give him the skills his master had. The first task that he was given when he arrived was to carry a bucket down to the well, fill it up, and bring it back to the school. He was instructed to slap the surface of the water with his palm, splashing the water out of the bucket until it was empty, and then repeat the process. He was very frustrated with this task, and felt cheated out of the training he had come for – especially when the weeks ran on into months, with no change in his daily routine of emptying the bucket with the palms of his hands. Finally, after 12 months had gone by, he was allowed to return to his family for a visit. They asked him what he had learned during the year, and he angrily told them that he had been given a pointless task to keep him occupied the entire time. He was hurt and frustrated by his waste of time and yelled out, "I have learned NOTHING!", slapping his hand down on the solid oak table in front of him as he did. The table split in two, and his family backed away in awe of the power he had been given by his wise teacher.