I read lots articles, tutorials and whitepapers whenever I get the chance. Sometimes I’ll read something and feel enlightened. Other times I finish and feel that I’ve somehow lost brain cells (please, no jokes about having none to lose ;) ). Recently some of the tutorials I’ve read on the web have left me feeling extremely underwhelmed. The reasons are because I felt like I didn’t learn anything or that the tutorial, while hitting the point, didn’t actually feel like it delivered the kind of information I was expecting. Since going through a few experiences like this I have started to wonder what really makes up a good tutorial, and how does it differ from a ‘how-to’ or a whitepaper?

I think that my definition of a tutorial is slightly different from the “official” definition, and the one that most other people use. So, here is the obligatory official definition :) (from Dictionary.com):

Tutorial - tutorial … [too-tawr-ee-uhl, -tohr-, tyoo-] …

1. pertaining to or exercised by a tutor: tutorial functions or authority.
2. a class in which a tutor gives intensive instruction in some subject to an individual student or a small group of students.
3. Computers
   1. programmed instruction provided to a user at a computer terminal, often concerning the use of a particular software package and built into that package.
   2. a manual explaining how to use a particular software package or computer system.

Yup, just as I suspected.

OK, a bit of background information. In many fields a tutorial can be a basic step-by-step to doing something - that I’m OK with. But I think that there are some areas of my chosen field (that’d be geekness) where a simple step-by-step just doesn’t cut it. A really good example of this would be my solution/tutorial that I previously blogged about. Regardless of who you are, reading a simple tutorial on this topic would show you how to do it, but it wouldn’t in any way give you the reasons for the steps involved. Now, this solution of mine doesn’t give a complete set of background information required to understand every step, but it does explain areas that are specific to this problem (along with a few extra snippets to help people learn stuff). So some background knowledge is required, and I think that’s the big proviso about tutorials - background knowledge.

I try to write my tutorials in such a way that the amount of background knowledge required is minimal without completely modifying the scope of the tutorial. For example, if I were to write a tutorial on polymorphism, I would expect people to have some knowledge of object orientation and some skills with any form of programming language. Me being me, I’d probably use C++ for my examples, so some understanding of the language and it’s syntax would also be required. I may, during the course of the tutorial, discuss some issues that aren’t directly related to the understanding of polymorphism (such as pointer sizes and vtables), as I might feel that it aids in understanding more of the world that polymorphism lives in. It’s this kind of information that is lacking in most tutorials.

This post was actually inspired by a couple of video tutorials that I watched recently which was designed to show you how to unpack a packed executable, using a few of handy tools (such as a debugger, disassembler and PE explorers). Now, the tutorial (which I’m not going to link to for fear of pissing off the author!) really cut to the chase. It basically went…

Run that, press that, copy that, press that, run that, run this, press that, run that, and you’re done! Congrats you can now unpack exes packed with X.

Hardly inspiring. I wondered if the quality of the tutorials was consistant, so I watched another one - again it was on unpacking, but this time it was a different packing algorithm. It was almost exactly the same, the only apparent differences were the names of the exes that were packed, a few memory addresses, and the disassembled code that was visible in the debugger.

This particular individual has uploaded dozens of these tutorials for the world to view, and I really think he/she believes they’re extremely productive. I can’t help but think that they’re not - they could write a single tutorial that covers the theory of unpacking, with one or two examples, and the reader/viewer would actually learn the principles and techniques behind unpacking, rather than just watching someone else press a few buttons in a certain order. I don’t expect a full run down on what a debugger is, or what reverse engineering is all about, but at least discussing how the packing process works, and why certain steps are taken to unpack the executable would be a very good, and helpful, move. I feel that anything less that this is half-assed!

So, in my world of geekness, a valuable tutorial needs to be more than what the dictionary says a tutorial should be. In my opinion, it should give you the required knowledge to understand what the tutorial is demonstrating and it should be delivered in such a way that allows the viewer to find it easy to understand the examples along with providing information on how to get access to extra information which may aid in their understanding. The feedback I’ve had from my previous reverse engineering solution has been great, and it seems that I’ve covered things in just enough detail to allow people to understand - this may well have been the first time I’ve achieved it.

Now I realise that some of you may jump on my back and yell “Why don’t you practice what you preach!?”, and you’d be quite within your rights to do that :) For your information, I intend to do just that. I will be writing some tutorials and lessons on various topics in the coming weeks, and I will be doing my best to cover the subject in as much detail as possible without changing the scope of the work.