In this programming assignment, we will not be writing assembly code. Instead, you are given four programs that we call
binary bombs. When executing each of these programs, you must enter a sequence of keycodes to safely defuse the “bomb”. Some of these programs will only ask for 1 input code, some will ask for multiple. If even a single incorrect keycode is given, the program will print “Havoc!” and let loose the dogs of war.
Many Assemblies "Strangers from distant lands, friends of old. You’ve been summoned here to answer the threat of the Binary Bombs. Edstem stands upon the brink of destruction. None can escape it. You will unite or you will fall. Each student is bound to this fate, this one doom. The bombs cannot be defused by any craft that we here possess. They were made in the fires of x86 assembly. Only there can they be unmade... They must be taken deep into GDB and cast into the fiery chasm from whence they came. Each of you must do this." * * * In this programming assignment, we will not be writing assembly code. Instead, you are given four programs that we call binary bombs. When executing each of these programs, you must enter a sequence of keycodes to safely defuse the “bomb”. Some of these programs will only ask for 1 input code, some will ask for multiple. If even a single incorrect keycode is given, the program will print “Havoc!” and let loose the dogs of war. Generating the Bombs Each student will have their own unique version of the bomb programs. In your home directory, you will find an executable called mission. Run this executable (./mission) to generate the bombs. Once the generator finishes executing (and self-destructs), you will find four executables b1.bomb through b4.bomb in your home directory. Defusing the Bombs The only hope for defusing the bombs lies in GDB. Each bomb program expects one or more sets of input as keys. The programs themselves provide no hint whatsoever as to what the keys may look like. It is only by disassembling these programs that we may learn of their secrets. As we explained during discussion, you can use objdump to disassemble each program. But the far superior option would be to use GDB to inspect and step through the assembly instructions, printing out registers and variables when necessary. Discussion video on GDB w/ assembly: To run gdb on a particular bomb (say b1), gdb ./b1.bomb which will launch the debugger and ready you for a debugging session. The command run causes the debugger to run the program, in this case prompting you for input. However, before running the debugger, you likely need to first set some breakpoints. Breakpoints are places in the code where the debugger will stop running and let you take control of the debugging session. For example, a common thing to do will be to fire up the debugger, and then break main to set a breakpoint at the main() routine of the program, and then type run to run the program. When the debugger enters the main() routine, it will then stop running the program and pass control back to you, the user. Ignore the line saying ‘Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.166.el6_7.7.i686’ if you see it. This is intended. At this point, you will need to do some work. You may type layout asm for switching to assembly layout where you can see the assembly instructions on the top window and you may type your gdb commands at the bottom window. Other commands you may find helpful: · b *(main+
): setting a breakpoint for a particular instruction at an offset from main (or any other function). · b *: setting a breakpoint at a particular instruction at an address. · stepi: steps through the code one instruction at a time. · nexti: execute the next instruction (without stepping into functions). · info registers: shows the contents of the registers. · p $eax: prints the value of a register (simply replace eax with other registers). · p *((int *)($ebp-0x10)): prints an integer stored at -0x10($ebp). You can use this format to print other variables at different locations in memory. (Refer to the discussion video for a more detailed explanation on this one.) GDB Cheatsheet: https://darkdust.net/files/GDB%20Cheat%20Sheet.pdf Getting comfortable with navigating gdb will make this project go much more smoothly, so spend some time learning it! One thing to notice: using the keyboard up and down arrow keys (or control-p and control-n for previous and next, respectively) allows you to go through your gdb history and easily re-execute old commands; if you are in layout asm (i.e., assembly layout mode) only CTRL+p and CTRL+n works. Getting good at using your history, whether in gdb or more generally in the shell you use, is a good idea. Preparing Your Submission To submit your keycode(s) for each bomb, create a file named bX.solution, and put each code on its own line. For instance, if for b2.bomb the keycodes were 298475, Gandalf the Grey, 9DV1df, and !290dflj19, then you should create a file b2.solution that looks like this: 298475 Gandalf the Grey 9DV1df !290dflj19 To test if you have created your solution files correctly, for each bomb, you can do something like ./b1.bomb < ./b1.solution="" --="" to="" provide="" your="" solution="" file="" as="" input="" to="" each="" bomb,="" and="" if="" your="" keycodes="" are="" correct,="" you="" should="" see="" the="" success="" message="" in="" the="" end.="" notes/hints="" ·="" even="" in="" the="" main()="" function,="" not="" all="" assembly="" instructions="" are="" relevant="" for="" detonating="" or="" defusing="" the="" bomb.="" ·="" upon="" successful="" defusal,="" the="" `success()`="" function="" is="" called,="" otherwise,="" the="" `bomb()`="" function="" is="" called.="" grading="" you="" will="" only="" receive="" points="" for="" each="" bomb="" program="" if="" you="" successfully="" defuse="" it.="" there="" will="" be="" no="" partial="" credits="" if="" you="" only="" manage="" to="" figure="" out="" one="" of="" the="" several="" keys="" for="" a="" program.="" ---="" fell="" deeds="" awake:="" binary="" and="" assembly!="" registers="" shall="" be="" shaken,="" memory="" be="" splintered,="" a="" gdb-day,="" a="" terminal="" day,="" ere="" the="" sun="" rises!="" with="" that="" he="" seized="" a="" great="" horn="" from="" j="" his="" teaching="" assistant,="" and="" he="" blew="" such="" a="" blast="" upon="" it="" that="" it="" burst="" asunder.="" and="" straightway="" all="" the="" horns="" in="" the="" host="" were="" lifted="" up="" in="" music,="" and="" the="" blowing="" of="" the="" horns="" of="" cse="" coursein="" that="" hour="" was="" like="" a="" storm="" upon="" the="" plain="" and="" a="" thunder="" in="" the="" mountains.="" &="" description="" asien="" ne="" i="SAS" rn="" |="" on)="" the="" only="" hope="" for="" defusing="" the="" bombs="" lies="" in="" gdb.="" each="" bomb="" program="" expects="" one="" or="" more="" sets="" of="" input="" as="" keys.="" the="" programs="" themselves="" provide="" no="" hint="" whatsoever="" as="" to="" what="" the="" keys="" may="" look="" like.="" it="" is="" only="" by="" disassembling="" these="" programs="" that="" we="" may="" learn="" of="" their="" secrets.="" as="" we="" explained="" during="" discussion,="" you="" can="" use="" objdump="" to="" disassemble="" each="" program.="" but="" the="" far="" superior="" option="" would="" be="" to="" use="" gdb="" to="" inspect="" and="" step="" through="" the="" assembly="" instructions,="" printing="" out="" registers="" and="" variables="" when="" necessary.="" discussion="" video="" on="" gdb="" w/="" assembly:="" https://podcast.ucsd.edu/watch/wi23/cse30_b01/7="" watch="" the="" discussion="" video="" if="" you="" don't="" know="" how="" to="" use="" gdb!="" (see="" also:="" jerry="" when="" someone="" needs="" help="" but="" doesn't="" review="" the="" discussions.)="" to="" run="" gdb="" on="" a="" particular="" bomb="" (say="" b1),="" gdb="" ./bl.bomb="" which="" will="" launch="" the="" debugger="" and="" ready="" you="" for="" a="" debugging="" session.="" the="" command="" run="" causes="" the="" debugger="" to="" run="" the="" program,="" in="" this="" case="" prompting="" you="" for="" input.="" however,="" before="" running="" the="" debugger,="" you="" likely="" need="" to="" first="" set="" some="" breakpoints.="" breakpoints="" are="" places="" in="" the="" code="" where="" the="" debugger="" will="" stop="" running="" and="" let="" you="" take="" control="" of="" the="" debugging="" session.="" for="" example,="" a="" common="" thing="" to="" do="" will="" be="" to="" fire="" up="" the="" debugger,="" and="" then="" break="" main="" to="" set="" a="" breakpoint="" at="" the="" main()="" routine="" of="" the="" program,="" and="" then="" type="" run="" to="" run="" the="" program.="" when="" the="" debugger="" enters="" the="" main()="" routine,="" it="" will="" then="" stop="" running="" the="" program="" and="" pass="" control="" back="" to="" you,="" the="" user.="" |="" ignore="" the="" line="" saying="" ‘missing="" separate="" debuginfos,="" use:="" debuginfo-install="" glibc-2.12-1.166.el6_7.7.i686'="" if="" you="" sna="" ie="" eee="" [te="" at="" this="" point,="" you="" will="" need="" to="" do="" some="" work.="" you="" may="" type="" layout="" asm="" for="" switching="" to="" assembly="" layout="" where="" you="" can="" see="" the="" assembly="" instructions="" on="" the="" top="" window="" and="" you="" may="" type="" your="" gdb="" commands="" at="" the="" bottom="" window.="" other="" commands="" you="" may="" find="" helpful:="" ®="" b="">) : setting a breakpoint for a particular instruction at an offset from main (or any other function). ® b x
: setting a breakpoint at a particular instruction at an address. ® stepi : steps through the code one instruction at a time. Vv Feedback a + B b4.solution B b1.solution | “IRIN B b3.solution B b1.bomb | DE FECTED) Terminal he [user@sahara ~]$ ls bl.bomb bl.solution b2.bomb b2.solution b3.bomb b3.solution b4.bomb b4.solution [user@sahara ~]$ gdb ./bl.bomb GNU gdb (GDB) 12.1 Copyright (C) 2022 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: --Type for more, q to quit, c to continue without paging--RET Find the GDB manual and other documentation resources online at: For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from ./bl.bomb... This GDB supports auto-downloading debuginfo from the following URLs: Enable debuginfod for this session? (y or [n]) y Debuginfod has been enabled. To make this setting permanent, add 'set debuginfod enabled on' to .gdbinit. Download failed: No route to host. Continuing without debug info for /home/./bl.bomb. (No debugging symbols found in ./bl.bomb) (gdb) gdb ./bl.bomb Undefined command: "gdb". Try "help". (gdb) break main Breakpoint 1 at 0x1262 (gdb) run Starting program: /home/bl.bomb Download failed: No route to host. Continuing without debug info for system-supplied DSO at 0xf7fc7000. [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". Breakpoint 1, 0x56556262 in main () (gdb) bl.bomb Undefined command: "bl.bomb". Try "help". (gdb) help List of classes of commands: aliases -- User-defined aliases of other commands. breakpoints -- Making program stop at certain points. data -- Examining data. files -- Specifying and examining files. internals -- Maintenance commands. obscure -- Obscure features. running -- Running the program. PARR + All changes saved @ v/ Mark Reset Many Assemblies "Strangers from distant lands, friends of old. You’ve been summoned here to answer the threat of the Binary Bombs. Edstem stands upon the brink of destruction. None can escape it. You will unite or you will fall. Each student is bound to this fate, this one doom. The bombs cannot be defused by any craft that we here possess. They were made in the fires of x86 assembly. Only there can they be unmade... They must be taken deep into GDB and cast into the fiery chasm from whence they came. Each of you must do this." * * * In this programming assignment, we will not be writing assembly code. Instead, you are given four programs that we call binary bombs. When executing each of these programs, you must enter a sequence of keycodes to safely defuse the “bomb”. Some of these programs will only ask for 1 input code, some will ask for multiple. If even a single incorrect keycode is given, the program will print “Havoc!” and let loose the dogs of war. Generating the Bombs Each student will have their own unique version of the bomb programs. In your home directory, you will find an executable called mission. Run this executable (./mission) to generate the bombs. Once the generator finishes executing (and self-destructs), you will find four executables b1.bomb through b4.bomb in your home directory. Defusing the Bombs The only hope for defusing the bombs lies in GDB. Each bomb program expects one or more sets of input as keys. The programs themselves provide no hint whatsoever as to what the keys may look like. It is only by disassembling these programs that we may learn of their secrets. As we explained during discussion, you can use objdump to disassemble each program. But the far superior option would be to use GDB to inspect and step through the assembly instructions, printing out registers and variables when necessary. Discussion video on GDB w/ assembly: To run gdb on a particular bomb (say b1), gdb ./b1.bomb which will launch the debugger and ready you for a debugging session. The command run causes the debugger to run the program, in this case prompting you for input. However, before running the debugger, you likely need to first set some breakpoints. Breakpoints are places in the code where the debugger will stop running and let you take control of the debugging session. For example, a common thing to do will be to fire up the debugger, and then break main to set a breakpoint at the main() routine of the program, and then type run to run the program. When the debugger enters the main() routine, it will then stop running the program and pass control back to you, the user. Ignore the line saying ‘Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.166.el6_7.7.i686’ if you see it. This is intended. At this point, you will need to do some work. You may type layout asm for switching to assembly layout where you can see the assembly instructions on the top window and you may type your gdb commands at the bottom window. Other commands you may find helpful: · b *(main+): setting a breakpoint for