Hacker News new | ask | show | jobs
Defusing a binary bomb with gdb – Part 1 (blog.carlosgaldino.com)
54 points by carlosgaldino 3880 days ago
9 comments

I took the course the book was designed for at CMU (and with the guys who wrote it, all CS majors have to take it), everyone on campus always knew when "bomb-lab" was happening because people would post on FB "Just defused a bomb", confusing anyone who was new around =P

Not setting off the bomb is pretty easy as long as you remember to set a break point right before the "explode" function before every gdb run. Super satisfying when you get through all six stages. (there's also a secret bonus stage)

The book/course is the best designed one I've ever seen for the subject matter. Highly recommend it for anyone interested in taking it on, and on taking any course that is based on it.

I also took a class designed around this class at UCLA. The bomb lab was absolutely the standout, both in terms of what I learned and how much I enjoyed it.

Didn't see it mentioned, but the really cool thing is that the bomb required internet access and would phone home to a server to dock points if you let it go off. As you said, all it required was that one breakpoint, but it still made everything feel more critical.

I remember opening up the binary in IDA and patching out all the phoning home, allowing me to tinker with it as I pleased. I then patched out all the key checking and hooked it back online, only to realize in horror that all the inputs were validated server side. :(
Yea, I didn't mention the "phone home" part, that's important =P

Even though it is "easy" to avoid it, there were still a bunch of people who accidentally triggered it every semester.

Maybe the online part is only available for students enrolled at CMU which is not my case. Self-study students download a different binary. Although it would be fun if it also had some online stuff.
If I am not mistaken, the book is called Computer Systems: A Programmer's Perspective (CS:APP) by Randal E. Bryant and David R. O'Hallaron. It's very nicely written, and 3rd edition just came out this year. Coursera also has an archive of a great course based on this book from University of Washington - 'The Hardware/Software Interface'.
You're right, that's what it's called (still have my copy at home). I took the course with Bryant and O'Hallaron. Super smart guys, very nice too. They're the kind of professors that really care more about students learning the stuff rather than administrative stuff or arbitrary policies.

Haven't seen the Coursera course, but it'd be really hard to make a bad course based on this book. It's both creative enough to keep attention, and doesn't skip anything.

This was one of my favorite lab assignments when I was at university. If I recall correctly this lab was run back to back with another really fun one out of the same book. The other had to do with modifying code to take advantage of some compiler optimizations. Loop unrolling, array layout, stuff like that.

allow me to brag a bit: I was the only one in my class to not set off the bomb!

At least for the first stage you don't actually need to run the executable (under gdb or otherwise). You can just get the string with objdump:

    $ objdump -s --start-address 0x402400 bomb|head

    bomb:     file format elf64-x86-64

    Contents of section .rodata:
     402400 426f7264 65722072 656c6174 696f6e73  Border relations
     402410 20776974 68204361 6e616461 20686176   with Canada hav
     402420 65206e65 76657220 6265656e 20626574  e never been bet
     402430 7465722e 00000000 576f7721 20596f75  ter.....Wow! You
     402440 27766520 64656675 73656420 74686520  've defused the
     402450 73656372 65742073 74616765 2100666c  secret stage!.fl
It's actually possible to defuse the whole thing by just decompiling it into assembly and reading that, but you have to really know and be comfortable with ASM. There are a handful of students that do it each year at CMU though, so it's not unsurmountable.

Students who are really comfortable with ASM will get through it fast by reading it, and those who are less so will GDB their way to the right answer. Which is exactly how a good CS assignment should work, where it scales for each skill level very well. Hence one of the reasons this book is great!

Cool, thanks for sharing.
In the course I took, the program would call home whenever it exploded and deduct points from your grade on the assignment. So naturally I just went in with hexedit and deleted that particular call to that function in explode_bomb.
Yea, that's how it works at CMU too. Usually, we just made sure to set a breakpoint there.
It was a pain in the butt to find the bomb executable, so for anyone interested, here is the link for a Linux/x86-64 binary bomb: http://csapp.cs.cmu.edu/3e/bomb.tar
Well that's part of it, the real meat is in "phases.c", which would need to be generated by the instructors (and uniquely for each student). This way no two student's answers are both the same, and there's no public source code to reference to figure out what the bomb is "doing" to the input and what input it actually needs in order to "defuse" properly, without trial-and-error and debugging, or reading the ASM disassembly throughly if that's your style.
I remember doing this assignment in 2003 with i386 executables.
iirc there are (at least ;) ) 6 levels
this was one of the assignments for the CS107 class at Stanford. it was fun :-).