20-minute Intro to Hacking

Do you want to learn how to hack, but you don’t even know how to code? This post is for you. I developed these slides for a talk I am giving tomorrow to aspiring college students at College Track SF. If you have any feedback or questions, please email me at mikegagnon@gmail.com. This talk is also available in PowerPoint and PDF format.

Beyond the ethical and moral reasons, there are very practical reasons why you should follow ethics:

  • It’s very easy to be caught. Even the most sophisticated hackers get caught. See for example Kevin Mitnick, Jeanson James Ancheta, and Albert Gonzalez.
  • The penalties for unethical hacking are steep. The above listed hackers all spent at least 5 years in prison (Albert Gonzalez is currently serving 20). Also, once you are convicted of a computer crime, it is very difficult to get a job having anything to do with computers. Employers will be scared of you. Furthermore many ethical-hacking jobs (mostly in the government) will require that you take a lie detector test, and they will ask if you have committed computer crimes.
  • There are great rewards for being ethical. For example, if you figure out how to hack Google (using ethical techniques) you can tell Google how you did it and they will give you a reward as much as $20,000. There are also lots of high-paying jobs for ethical hackers.

Here are some guidelines on how to be ethical:

  • Never hack someone’s system without their permission
  • If you identify a way to hack someone’s system you should tell them so they can fix it. Once they fix it, you can publicize your hack and earn respect from other hackers (and employers).

Hacking is fun. That’s probably the number one reason ethical hackers hack. But it can also be very lucrative, as I mentioned in this last slide. This slide tells you how can you make money as an ethical hacker.

Hopefully, you’re dying to know “How do I hack!?” It’s like hot wiring a car. To hot wire a car, you simply cut into the right part of the car, find the right pair of wires, and connect them together. It’s actually very simple once you know how a car works. I would wager that every good auto mechanic knows how to hot wire a car. Once you know how a car works, hacking the car is pretty obvious.

Hacking computers is similar. Once you know how a computer works, hacking is often pretty simple. Hacking only seems mysterious to people who don’t know how computers work. One of my favorite all time quotes is:

Any sufficiently advanced technology is indistinguishable from magic.

Though, I would actually say “Any technology you don’t understand is indistinguishable from magic.” Once computers are no longer magic, you realize they are simply machines that can be manipulated just like any other machine you understand.

Computers talk to each other kind of like the way people talk to each other. For example, I could ask you “What’s 2+2?” (the request), you could calculate that and give me the answer (the response).

Going farther with this analogy, let’s imagine there is a group of people gathered in a room. Every person in the room represents a computer. One person represents a “server,” which is simply a person (or computer) that receives requests, calculates results, and sends them back as responses. All the other people are “clients,” which are simply people (or computers) that give requests to servers.

The one person designated as the server will do math problems for you if you request it. The server can only work on one math problem at a time. The clients take turns asking the server to do math problems.

Let’s think about hacking the server. Is there a way you could crash the server? Could you send a math problem to the server, that clogs it?

If you ask the server “What’s 3278398457234 divided by 93672511″ I bet it would take a very long time for the person to calculate the result. And since the server can only work on one problem at a time, all the other client’s would be ignored while the server is working on that one really hard problem.

You can crash computers like this!

This type of attack is called a “denial of service” (DoS) because it denies other clients access to the service. It won’t always work because a good program will realize it is being overloaded and quit before it gets clogged. But sometimes it works.

Ok, you now know a technique for crashing computers. Be ethical! Don’t go around the web trying to overload other people’s computers. If you want to experiment crashing computers, try crashing your own computer. For example, is there a way you could overload your own web browser? Or could you overload other applications on your own computer?

If you do stumble upon a way to overload someone’s website, send the owner an email so that they can fix it. Once they fix it, you can tell the whole world about your discovery and earn the respect of the world.

I’ve set up a puzzle for you. Can you figure out how to crash my server? Try it out at http://hackerpuzzle.herokuapp.com. If you figure it out, send me an email at mikegagnon@gmail.com and I’ll post your name on the puzzle’s Hall of Fame.

Hopefully you’re really excited to start hacking now. Stay out of trouble, and be ethical.

Here are extra tips to go along with this slide:

  • Notice: I never said you have to be a genius. There is a myth that hackers are all geniuses. In actuality, great hackers became great through years of practice and study.
  • To be a good hacker, you must know how to code. There are several great websites that you can use to teach yourself how to code:
  • Knowing math makes you a better hacker. Computer science is mostly based on math, and lots of computer-security techniques are based on math. As proof of the importance of math in hacking, the United States hacking agency (the NSA) employs more mathematicians in the United States than any other company or agency.
  • There are lots of hacking challenges on the Web. Just search for them. I should warn you that my hacking puzzle is probably the easiest hacking challenge on the Web, so don’t be discouraged if it takes you a while to start solving other challenges. Just keep learning everything you can about computers and coding, and you’ll get there.

 

My talk on Type classes in Scala

Yesterday I gave a talk on type classes in Scala at Twitter. The “slides” are on Github: https://github.com/mikegagnon/type_class_tech_talk

Type classes represent an effective (and popular) design pattern in Scala that is useful for developing beautiful APIs. They also allow you to accomplish type-system feats that wouldn’t otherwise be possible in Scala.

In the talk, I describe what type classes are, why they are useful, and how you can use them in Scala.

Overall, I think the talk went great. Everyone seemed very interested and involved. I also received some great feedback from the audience. (Please send pull requests and file issues.)

This was my first talk that I wrote up first as a self-contained tutorial, then presented directly from the tutorial. Overall I liked this format a lot, and I think it worked great for the audience. Although it took longer to prepare than slides would have, I think the extra preparation time was worth it.

For one, Scala programmers across the Web can now benefit from the talk.

But it also made a great format for a live presentation.

For instance, I progressed through the talk by scrolling down, instead of jumping from one slide to the next. This approach has the advantage that the audience can read ahead, or behind, while I present.

I think another important benefit is that members of the audience, if they are inclined, can read instead of listen. (I know I usually digest written information better than oral information).

It was also nice working in Github rather than PowerPoint, Google Docs, or WordPress. Github’s markdown syntax is easy to write and looks great when rendered. It’s also nice being able to fix errors in the talk as the audience members point them out. Github is also a handy place to solicit feedback in the form of pull requests and issues. Although, it would be better if other users could simply edit my doc as if it were a wiki, requiring my permission though to merge their changes.

I think the Github format for talks is a keeper.