http://expertsaustralia.com/# This project must be done individually. It is academic misconduct to share your work with others in any form including posting it on publicly accessible web sites, such...

• This project must be done individually.

It is academic misconduct to share your work with others in any form including posting it on publicly accessible web sites, such as GitHub.

It is academic misconduct for you to copy or use some or all of a program that has been written by someone else.

• All work for this project is to be done on the CS Department's instructional Linux machines. You're encouraged to remotely login using ssh on Macs or on Windows using an ssh client such as MobaXterm.


• All projects in this course are graded on CS Department's instructional Linux machines. To receive credit, make sure your code runs as you expect on these machines.

There are two main objectives of this project. The first is to quickly become familiar with x86 assembly language. The second relates to the first: to gain some familiarity with powerful tools that help with this process, namelygdb(the debugger) andobjdump(the disassembler).

In this assignment, you will be defusing four binary bombs. The idea is simple: each bomb is an executable program that prompts the user for five inputs via the stdin console, one at a time, in order to defuse the bomb. If you type in the right values, you successfully defuse the bomb. If not, the bomb explodes! (Don't worry, it just prints that the bomb explodes; no real harm is done to you or your computer)

Getting the Required Files

The four bombs are unique for every student and are located in the following directory:

/p/course/cs354-skrentny/public/students//p5/

Replace with your actual cs login and copy the contents of the above directory into your working directory. There should be 4 executable files namedb1,b2,b3, andb4.

Please copy your executable bombs to your own private directory, and work towards finding your solutions in your own directory. That way, you will have the original executables in your student directory if you accidentally overwrite an executable.

Defusing the Bombs

The challenge is to figure out the correct set of 5 inputs expected by each of the four bombs. You can run each bomb interactively, and type in your guesses, one at a time. This will be useful in defusing each bomb with a debugger, as described in the next section. Take a look at the sample run below:

[skrentny@jimbo] (55)$ ls
b1* b2* b3* b4*
[skrentny@jimbo] (56)$ ./b1
input 1 (of 5)? 951905
input 2 (of 5)? 1234
BOMB EXPLODED
[skrentny@jimbo] (57)$ ./b1
input 1 (of 5)? 951905
input 2 (of 5)? 994563
input 3 (of 5)? 493693
input 4 (of 5)? 828695
input 5 (of 5)? 278566
success!
[skrentny@jimbo] (58)$

Your task is to figure out all the inputs and create four files,b1.solution,b2.solution,b3.solutionandb4.solution, where each file contains the five lines of input demanded by its associated bomb. We will test your solution files as show below.

[skrentny@jimbo] (70)$ ls
b1* b1.solution b2* b2.solution b3* b3.solution b4* b4.solution
[skrentny@jimbo] (71)$ cat b1.solution

951905
994563
493693
828695
278566
[skrentny@jimbo] (72)$ ./b1

input 1 (of 5)? input 2 (of 5)? input 3 (of 5)? input 4 (of 5)? input 5 (of 5)? success!
[skrentny@jimbo] (73)$

All 5 inputs need to be correct to defuse a bomb. As long as the bomb explodes, no points will be given no matter how many inputs were correct before the explosion.

Make sure you create this file with a text editor (vim/gedit/nano) on a Linux Machine. If you are usingWindows or Mac, editing locally followed by uploading will fail forb2. Use remote accessing tools like ssh or MobaXterm instead. Make sure your solution file contains five non-empty lines.Remember to press enter or return after the last line in the solution file. The bomb will be trapped into an infinite loop if the solution file contains less than 5 lines. If that happens, press ctrl-c to break.

This testing also uses another shell skill that you have already used: IO redirection. In this case the contents of a file are redirected as stdin to the program.

To figure out how to defuse your binary bombs, you will use two powerful tools:objdumpandgdb. Both are critical in reverse engineering each binary bomb to understand what it does.

objdump

objdumpis a command in linux to display information about object files. For our purposes the two important command line options are:

• 
  -dwhich disassembles a binary


• 
  -swhich displays the full binary contents of the executable

For example, to see the assembly code of bomb b1, you might type:

objdump -d b1

This will show an assembly listing of each function in the bomb. Your first task then might be to look atmain()and figure out what the code is doing.

The-sflag is also quite useful, as it shows the contents of each segment of the executable. This may be needed when looking for the initial value of a given variable.

By redirecting stdout, you can capture the output ofobjdumpin a file, such that you can look at this output without having to regenerate it every time. And, you can use both command line options at the same time to create a full dump of the contents of the executable as well as the disassembled contents.

gdb

By now, you likely have used the debugger, gdb, to help find segmentation faults, but it is an even more powerful ally in your search for clues to defuse each binary bomb. To rungdbon bombb1enter at the linux prompt:

gdb b1

which will launch the debugger and start a debugging session. Ignore the ‘no debugging symbols found’ warning on the last line. This is intended. The commandruncauses 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 before typing run in the debugger is:

break main

to set a breakpoint at themain()routine of the program, and then type:

run

to run the program. When the debugger enters themain()routine, it will then stop running the program and pass control back to you, the user.

You will need to learn some basic commands in gdb in order to set breakpoints at various functions and addresses in your code, step through instructions, and examine the contents of memory addresses and registers in order to figure out the inputs that each bomb is expecting. We’ve listed some commands for you to get started with but you will have to read up more about gdb on your own to explore these and other commands fully.

• 
  break: sets up a breakpoint at the location which can be a function name or the address of an instruction. So for instance “break *0x804861a” will set a breakpoint at the instruction address 0x804861a. Note when specifying an address in break it has to be of the form*addr.


• 
  continue: resumes the execution until any breakpoint is reached again


• 
  stepi: steps through the code one instruction at a time


• 
  info registers: shows you the contents of all of the registers of the system


• 
  x/nfu: The examine command, which shows you the contents of memory.n,f, anduare all optional parameters that specify how much memory to display and how to format it.addris the hexadecimal address you want to look at. So for instance “x/3ub 0x54320” is a request to display 3 bytes (b) of memory formatted as unsigned decimal integers (u) starting at the address 0x54320.

Getting good with gdb will make this project go smoothly, so spend the time and learn! One thing to notice: using the keyboards up and down arrows (or ctrl-p and ctrl-n for previous and next, respectively) allows you to go through your gdb history and easily re-execute old commands. Getting good at using your history, whether in gdb or more generally in the shell you use, is a good idea.

There are plenty of good tutorials and resources online to get started with gdb. We will list a few to get you started off:

• Basic gdb example (Links to an external site.)Links to an external site.


• A nice introduction (Links to an external site.)Links to an external site. for those who like videos


• Handy gdb cheatsheet (Links to an external site.)Links to an external site.


• Gdb text user interface(TUI) (Links to an external site.)Links to an external site. mode. This is worth taking the time to learn, because it lets you look at the assembly code and registers side by side as you step through it. Typelayout asmin gdb to try it out.

• x86 cheat sheet


• Functionstrtol()corresponds to the use ofatoi()in C source code.


• Every C program has amain()function. Figure out how to locate it.


• A loop inmain()iterates five times. Remember that each bomb requires five inputs.


• On a wrong input, functionbomb()is called. This results in an explosion.


• If all five inputs are correct, functionsuccess()is called.


• Function arguments are set up in the call stack just prior to the function call.


• The two parameters tostrcmp()are addresses to 2 C strings.

We will test your solution files by running them as shown in the sample output. It is your responsibility to ensure that your solutions correctly defuse each of the four binary bombs on the CS Linux lab machines.

Submit the followingsource filesunder Project 5 in Assignments on Canvas on or before the deadline:

1. b1.solution


2. b2.solution


3. b3.solution


4. b4.solution

It is your responsibility to ensure your submission is complete with the correct file names having the correct contents. The following points will seem obvious to most, but we've found we must explicitly state them otherwise some students will request special treatment for their carelessness:

• 
  You will only receive credit for the files that you submit.You will not receive credit for files that you do not submit. Forgetting to submit, not submitting all the listed files, or submitting executable files or other wrong files will result in you losing credit for the assignment.