Defusing Bomb - Assembler Programming and Computer Organization - Lecture Slides, Slides of Computer Architecture and Organization

Download Defusing Bomb - Assembler Programming and Computer Organization - Lecture Slides and more Slides Computer Architecture and Organization in PDF only on Docsity!

CS140 Lab

Defusing The Bomb

Step 2: Defuse Your Bomb Your job is to defuse the bomb. You can use many tools to help you with this; please look at the hints section later in this document for some tips and ideas. The best way is to use your favorite debugger to step through the disassembled binary. Each time your bomb explodes it notifies the staff, and you lose 1/4 point (up to a max of 10 points) in the final score for the lab. So there are consequences to exploding the bomb. You must be careful! Each phase is worth 20 points, for a total of 100 points. The phases get progressively harder to defuse, but the expertise you gain as you move from phase to phase should offset this difficulty. However, the last phase will challenge even the best students, so please don’t wait until the last minute to start. The bomb ignores blank input lines. If you run your bomb with a command line argument, for example,

linux> ./bomb answers_so_far.txt

then it will read the input lines from answers_so_far.txt until it reaches EOF (end of file), and then switch over to stdin. In a moment of weakness, Dr. Evil added this feature so you don’t have to keep retyping the solutions to phases you have already defused.

To avoid accidently detonating the bomb, you will need to learn how to single-step through the assembly code and how to set breakpoints. You will also need to learn how to inspect both the registers and the memory states. One of the nice side-effects of doing the lab is that you will get very good at using a debugger. This is a crucial skill that will pay big dividends the rest of your career. Logistics

You should do the assignment on the lab machines. In fact, there is a rumor that Dr. Evil really is evil, and the bomb will always blow up if run elsewhere. There are several other tamper-proofing devices built into the bomb as well, or so they say.

There are many tools which are designed to help you figure out both how programs work, and what is wrong when they don’t work. Here is a list of some of the tools you may find useful in analyzing your bomb, and hints on how to use them.

gdb The GNU debugger, this is a command line debugger tool available on virtually every platform. You can trace through a program line by line, examine memory and registers, look at both the source code and assembly code (we are not giving you the source code for most of your bomb), set breakpoints, set memory watch points, and write scripts. Here are some tips for using gdb.

To keep the bomb from blowing up every time you type in a wrong input, you’ll want to learn how to set breakpoints. The CS:APP Student Site at http://csapp.cs.cmu.edu/public/students.html has a very handy two- page gdb summary For other documentation, type “help” at the gdb command prompt, or type “man gdb”, or “info gdb” at a Unix prompt.

What works AMAZINGLY well is defining a file with various commands that you want to use every time you run gdb. Then start gdb with a switch that specifies you should use that file. My file contained these (and other) commands:

man gdb <-- contains lots of useful options gdb -x CommandFile bomb - so you don't have to set breakpoints, etc every time, you can use this -x option.

My file contained these (and other) commands: b key_ b *0x08048dd display/i $pc display $eax r in

Useful commands within gdb help - Everything you would ever need to know. r - Start running - using an input file lets the bomb get previous successes from that file. stepi - Step a single assembler instruction c - Continue to the next breakpoint b - Sets a breakpoint at the specified address disassemble