In fact, I think most of the HN crowd would greatly enjoy the "bomb lab" (http://csapp.cs.cmu.edu/public/1e/labs.html -- you can read the writeup but not get the source). The idea is that you have a binary and have to use gdb and some nice dumping tools to "defuse" a bunch of stages of the program, each with increasing difficulty. It's a fabulous exercise, and really makes students pick up a deep appreciation for stepping through assembly and data structures that are just lying around in memory.
I love the bomb lab exercise! LOVE LOVE LOVE LOVE!
At my university, we split the book into two courses if I'm not mistaken. We moved away from a typical OS book (Albert S., Andy T., Stalling, type of book) to this.
There are side effects though. The MOS, OS Concept, OS Concepts + Internals book have a typical path of teaching OS while this book merged the OS and hardware knowledge.
The bomb and buffer overflow labs are probably the most interesting to the HN community, but the shell project is what I consider the most important project in the course. (We have five projects: bomb, buffer overflow, shell, memory allocator, web server.) Our shell assignment is quite a bit different from the original in that we parse the command line for them (putting the commands and pipelines into appropriate data structures), but they have to do everything else, including pipes and I/O redirection.
Email me if anyone is interested in learning more about how we do our course.
Someone mentioned "Why C when higher-level languages will suffice?" and I thought that's pretty much spot on. In a data structures class, it seems easier not to have to debug cryptic core dumps and segmentation faults too often, especially since the focus is on algorithms. At least, that's the impression I got when speaking with TAs and professors.
Or perhaps there are less systems-level programming enthusiasts nowadays?
I took the class you TA'd, way back when the textbook was still a draft and absolutely loved it! As an EE guy, it was great to be able to get at the bits and bytes and really understand what it meant to be fetching, executing, branching to, jumping to instructions, allocating memory etc. The transition from assembly language to C was natural and I loved/hated every single core dump / segmentation fault that came with it. That class helped tremendously in getting me my first job, but I guess there are plenty of jobs that don't require working knowledge of C.
objdump doesn't give you the pretty "graph view," showing the basic block structure of the code. (In particular, this is really nice for switches and other jump tables.) It doesn't make it trivially easy to see where certain rather important-looking strings are referenced in the code. It doesn't show strings that are being referenced right next to the assembly instruction that references them, like changing
push offset aD ; "%d"
mov eax, [ebp-0x4]
mov eax, [ebp-first_number_I_entered]
In addition, the Hex-Rays decompiler (http://www.hex-rays.com/decompiler.shtml) produces C-like output. I don't have a license for it, but I imagine it would make short work of the bomb lab.
For disassembling a large program, sure, but the program and the functions themselves are relatively small. They already know the basic structure of the bomb because we give them a C skeleton that calls all of the functions. The string pointer fetching would probably be the most useful, but once they figure out how to do it once, they only need to do it four or so more times.