Dead-listing while on vacation

I just got back from a nice vacation with no laptop.  What do I do on long plane rides or while listening to the waves lap against the beach?  Dead-listing.

Dead-listing is analyzing the raw disassembly of some target software and figuring it out using only pen and paper.  This is great for vacations because your laptop won’t get sand in it.  You usually have a long period of time to muse about the code in question without interruptions, something hard to find at home these days.  And I’ve gotten some of my best ideas after setting aside my papers for a while and going for a long swim.

Before you leave, pick an interesting target: not too big, not too small.  Not just x86 either — ever wondered how one of your cellphone’s applications worked?  Never looked at a familiar application’s Java bytecode?  Then, get a copy of a disassembler for your target and run it.  I often use IDA but for less common CPU architectures, any one will do.  Remember that you don’t need full analysis at this point, although it’s useful to be able to separate data from instructions and get basic symbols resolved.

Search the assembly code for any external libraries that might be important.  Disassemble them too.  While you’re at it, see if you can find the source code or API reference for any of those files.  Code reuse helps you reduce the amount you have to reverse yourself.

Now take the listing file and do some cleanup.  I like to use a small font that prints well and convert all the call (subroutine) instructions to bold.  I insert some extra empty lines before each call target to allow me room to write notes.  Finally, I print the listing in landscape with two columns per page.  This leaves room for notes on the righthand side of each column and some at the bottom.  A binder clip makes it easy to keep pages in order or remove them to compare.

Since you won’t have access to the Internet, you’ll need to find some basic reference materials.  The key is to get the basics without carrying a ream of paper.  For an embedded system, I usually find or make a small instruction set reference sheet including status flags, I/O port table, PCB layout photos, and any integrated peripherals I find during a brief search of the data accesses.  Print these out and put a full copy of all the files on a USB flash drive.  You might stop by an Internet cafe if you find you really need to read a missing page.  I’ve never found that necessary though.  If I can’t infer the function of a particular I/O access, I’ll just look at the whole block’s general effect and take a guess.

The most important part is to stay light.  You don’t need exhaustive manuals (e.g., instruction timing).  Instead, treat these barriers as a challenge.  For example, most timing loops are relative to each other.  You can figure out that one loop is twice as slow as the other without knowing its exact delay in nanoseconds.  Doing hexadecimal conversions on paper builds character.

Once you’re away, enjoy doing a little bit at a time.  I’d often work through a subroutine or lay out a switch statement over coffee before the family gets moving, then set it aside for the rest of the day.  Before putting it down, keep a separate log of open questions and tasks, marking them off as you solve them.  I usually reserve a page in this notebook as my “symbol table”, marking down function names/addresses as I finalize them.

I mostly work through the code in two modes: looking for high level blocks or walking through a single subroutine in detail.  Was this compiled C or C++?  How does the optimizer work?  When accessing hardware, where did the author use inline assembly?  Draw arrows, bracket blocks, use highlighters if that’s your style.  Since it’s more free-form than working on a computer, you’ll find new ways to annotate it.  The amount of marks per page gives a good idea as to code coverage so you can start a day by refining an existing page or try to take a broad guess what a blank page does.

I am always surprised how much I accomplish in only a little bit of time using this method.  It’s also so much fun.  Throw in reading a few interesting but unrelated books and you may wax philosophical on the meaning of life or why the compiler suddenly switched to byte instead of word operations for a single function.

I hope you have a great summer.  Be sure to stop by my Blackhat 2008 talk, “Highway to Hell: Hacking Toll Systems“.  I’ll be posting more details about it here in the coming weeks.