Need to do the attached document
CS 154, Autumn 2020: Project 2 (“p2bomb”): Defusing a Binary “Bomb” Due: Sunday, November 1st at 11:59pm This project involves “defusing” a “binary bomb”. The bomb is an executable binary, compiled from C code, consisting of a sequence of six phases, each of which prompts you to enter a string. However, due to remote learning challenges, you only need to defuse the first 4 phases. If you type a correct string, then the phase is defused and the bomb proceeds to the next phase. Otherwise, the bomb terminates. The bomb is defused when every phase has been defused. Your goal is to defuse your bomb before the due date. Step 1: Get Your Bomb To obtain your bomb, use a web browser to go to the bomb server http://bomb.cs.uchicago.edu:15213. However, this server is only accessible within uchicago network, so there are few ways to get there: a) You are physically on campus and connect to the wifi network b) Install cVPN https://its.uchicago.edu/2018/09/11/training-tip-cvpn/ c) Use vDesk (Remote Desktop Linux) https://howto.cs.uchicago.edu/techstaff:vdesk?s[]=vdesk After you figure out a way to access http://bomb.cs.uchicago.edu:15213, you need to fill the form in order to get a bomb that is uniquely generated for you. On the first line of the form, you should enter your CNetID. On the second line of the form, enter your email address, then click “Submit”. The server will build your customized bomb and return it to your browser in a .tar file named bombN.tar, where N is the unique number of your bomb. If you make a mistake requesting a bomb (such as neglecting to save it), request another one. If you are frustrated by having gotten too many explosions (say, before you learn how to set breakpoints), and want to start again, you can also just restart with a new bomb. However, every bomb generated by the server is different, and requires different solutions. Step 2: Run Your Bomb Running your bomb is the first thing to do before you can actually start to defuse it, so read these instructions carefully. The bomb that you just downloaded will only run on the CSIL linux machines. You can access them by running ssh
[email protected], and replacing CNET with your CNetID. This will randomly assign you to one of the available linux machines (linux1 through linux5). Once you’re in, you will be able to find your CNET-cs154-aut-20/p2bomb directory. Now, you must copy your bombN.tar file into this directory, svn add it, and commit it. If you are using the SSH Extension for VS Code, then you can just drag-and-drop your bombN.tar file into the file tree in VS Code. This is the easiest method. If you are just using plain ssh, then you can use scp to copy it over. On your laptop, navigate to the directory with the bombN.tar file, and run a command like scp bombN.tar
[email protected]:~/, replacing N and CNET as appropriate. Then, when you ssh onto the linux machines, you should see your bombN.tar file in your home directory. If you are still having trouble copying your bomb over, please ask on Piazza and/or come to the TA office hours. 1 http://bomb.cs.uchicago.edu:15213 https://its.uchicago.edu/2018/09/11/training-tip-cvpn/ https://howto.cs.uchicago.edu/techstaff:vdesk?s[]=vdesk http://bomb.cs.uchicago.edu:15213 Now that you have your bombN.tar file on the linux machines, run tar xvf bombN.tar. This creates a ./bombN directory containing: • README: Identifies the bomb and its owner. • bomb: The executable binary bomb. • bomb.c: Source file with the bomb’s main() routine. Finally, to run your bomb: cd bombN gdb bomb break phase 1 run (Note: break is for putting a breakpoint, and run is for starting the program execution from the beginning of the program. More about GDB commands is here http://www.yolinux.com/TUTORIALS/GDB-Commands.html. Also check Piazza, the TA will have a post with some GDB resources that they will keep up-to-date) Step 3: Defuse Your Bomb Reading through bomb.c will show you the basic steps the bomb uses to process the string inputs through its six phases. You do not get to see the source for the phase 1, phase 2, ... functions (called from main()). You have to reverse-engineer them. Your job is to “defuse” the bomb, which simply means that the bomb execution has to reach its final return 0. Defusing each phase earns you 10 points; an ideal score is 40 points. If you complete phases 5 or 6, your score may end up over 40; in that case, it will be rounded down to 40. You can use many tools to help you with this; please look at the Hints section below for some tips and ideas. The best way is to use a debugger to step through the disassembled binary. If your bomb “explodes” it reports to the bomb scoreboard at http://bomb.cs.uchicago.edu:15213/scoreboard. Be careful! With each explosion you will lose 1/2 point (up to a max of 20 points) in the final score for the project. We do round up to an integral score, so the first explosion is “free”. Every bomb is different, so the required solutions are also different. The phases get progressively harder to defuse, but expertise you gain as you move from phase to phase should offset this difficulty. Even more so than with the previous project, there is no way to do this project in one night: it takes time, care, and insight. Start now. The bomb ignores blank input lines. If you run your bomb with a command line argument, for example, linux> ./bomb sol.txt then it will read the input lines from sol.txt until it reaches EOF (end of file), and then switch over to stdin. This feature saves you from having to repeatedly retype the solutions to phases you have already defused. To avoid accidentally detonating the bomb, you will need to learn how to single-step through the assembly code and how to set breakpoints (this is covered in Lab 2). You will also need to learn how to inspect both the registers and the memory state. A nice side-effect of doing the project is that you will get very good at using a debugger. Handin There is nothing to hand in. The bomb will report to the scoreboard when a phase is defused. You can track how you (and others) are doing at: http://bomb.cs.uchicago.edu:15213/scoreboard. Remember, bomb.cs.uchicago.edu 2 http://www.yolinux.com/TUTORIALS/GDB-Commands.html http://bomb.cs.uchicago.edu:15213/scoreboard https://canvas.uchicago.edu/courses/29783/files?preview=4194891 http://bomb.cs.uchicago.edu:15213/scoreboard is only accessible by using VPN or vDesk. This web page is updated every 30 seconds to show the progress on each bomb. You know which line corresponds to you because you know the number N of your bomb bombN. Hints The TA may give you more hints, check out the Piazza post. Basically, there are many ways to defuse your bomb. You can examine it in great detail without ever running it, and figure out exactly what it does. This is a useful technique, but not always easy to do. You can also run it under a debugger, watch what it does step by step, and use this information to defuse it. This is probably the fastest way. A bad strategy would be brute force: writing a program that tries every possible key to find the right one. This will not work, because you lose credit with every explosion, and there are too many strings to try. There are many tools which are designed to help you figure out both how programs work, and what is wrong when they do not work. Here are some tools that may be useful: • gdb The GNU debugger, the command line debugger tool available on the CSIL machines, and covered in Lab 2. 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, set breakpoints. Being careless about this is the easiest way to lose points. – The CS:APP Student Site at http://csapp.cs.cmu.edu/public/students.html has a single-page gdb sum- mary. – For other documentation, type “help” at the gdb command prompt, or type “man gdb”, or “info gdb” at a Unix prompt. Some people also like to run gdb under gdb-mode in emacs. • objdump -t This command will print out the bomb’s symbol table. The symbol table includes the names of all functions and global variables in the bomb, the names of all the functions the bomb calls, and their addresses. You may learn something by looking at the function names! • objdump -d Use this to disassemble all of the code in the bomb. You can also just look at individual functions. Reading the assembler code can tell you how the bomb works. Although objdump -d gives you a lot of information, it does not tell you the whole story. Calls to system- level functions are displayed in a cryptic form. For example, a call to sscanf might appear as: 8048c36: e8 99 fc ff ff call 80488d4 <_init+0x1a0> To determine that the call was to sscanf, you would need to disassemble within gdb. • strings This utility will display the printable strings in your bomb, but the results will not be very informative (though possibly amusing). Your bomb expects you to supply certain strings, but the validity of the string is not assessed by simply comparing it to some internally stored correct string. Rather, the strings you provide to your bomb have to be crafted according to your understanding of the bomb’s computation. Acknowledgments This is based on the “bomblab” project developed by the authors of our textbook. 3 https://canvas.uchicago.edu/courses/29783/files?preview=4194891 http://csapp.cs.cmu.edu/public/students.html