1. A student is testing an implementation of a C function; when compiled with gcc, the following x86-32 assembly code is produced:

Transcription

1 This assignment refers to concepts discussed in the course notes on gdb and the book The Art of Debugging by Matloff & Salzman. The questions are definitely "hands-on" and will require some reading beyond the course notes. Download the file HW10.tar and unpack it on a Linux system. It contains files you will need for this assignment. You may work in pairs for this assignment. If you choose to work with a partner, make sure only one of you submits a solution and that the file lists names and PIDs for both of you. Prepare your answers to the following questions in a single plain ASCII text file. Submit your file to the Curator system by the posted deadline for this assignment. No late submissions will be accepted. You will submit your answers to the Curator System ( under the heading HW A student is testing an implementation of a C function; when compiled with gcc, the following x86-32 assembly code is produced: Q1: pushl %ebp # 1 movl %esp, %ebp # 2 subl $16, %esp # 3 movl 8(%ebp), %eax # 4 andl $1, %eax # 5 movl %eax, -4(%ebp) # 6 sall $31, -4(%ebp) # 7 sarl $31, -4(%ebp) # 8 movl -4(%ebp), %eax # 9 leave # 10 ret # 11 The code uses some instructions that are covered in the supplementary notes posted with the assignment; be sure to read the notes! a) [5 points] The first three instructions create the stack frame for the function. How many bytes are allocated for the frame? Justify your answer. b) [5 points] The function receives one parameter and uses one local automatic variable. Explain how we know this. c) [10 points] Assume the function is named Q1, the parameter is named P1, and the local variable is called L1. Write C code for the function that could have yielded the x86-32 assembly code given above. (Be advised: you may derive a perfectly acceptable answer and find that when you compile it you get slightly different assembly code, so don't use that as your goal.) 1

2 2. A student is testing an implementation of a different C function; when compiled with gcc, the following x86-32 assembly code is produced: Q2: pushl %ebp # 1 movl %esp, %ebp # 2 subl $16, %esp # 3 movl $0, -4(%ebp) # 4 jmp.l2 # 5.L4: # 6 movl -4(%ebp), %eax # 7 sall $2, %eax # 8 addl 8(%ebp), %eax # 9 movl (%eax), %eax # 10 cmpl 12(%ebp), %eax # 11 jg.l6 # 12.L2: # 13 movl -4(%ebp), %eax # 14 cmpl 16(%ebp), %eax # 15 jl.l4 # 16 jmp.l3 # 17.L6: # 18 nop # 19.L3: # 20 movl -4(%ebp), %eax # 21 leave # 22 ret # 23 The code uses some instructions that are covered in the supplementary notes posted with the assignment; be sure to read the notes! a) [3 points] How many parameters does the C function receive? Justify your answer. b) [3 points] How many local automatic variables does the C function use? Justify your answer. c) [3 points] The C function contains a while loop or a do-while loop. Which type of loop is shown above? Justify your answer, and state the line numbers of the instructions that make up the while loop, including the loop test and everything else necessary to execute the loop. d) [3 points] There is also an if-statement in the C function. State the line numbers of the instructions that make up the if-statement, including the test. e) [10 points] Assume the function is named Q2. Suppose that any parameters are named P1, P2, etc, in the order the paraters would be listed in the C code. Suppose the local variables are called L1, L2, etc, in the order they occur in the stack frame for the function, from high addresses to low addresses. Write C code for the function that could have yielded the x86-32 assembly code given above. (Be advised: you may derive a perfectly acceptable answer and find that when you compile it you get slightly different assembly code, so don't use that as your goal.) 2

3 3. A student writes the following C function, which she wants to use to examine the bytes of a 32-bit integer variable; most of the code for that function is shown below: void writebytes(uint32_t N) { printf("n is %"PRIX32"\n", N); // 1 uint8_t* p = (uint8_t*) &N; // 2 uint8_t b3 = *p; // 3 uint8_t b2 = *(p+1); // 4 uint8_t b1 = *(p+2); // 5 uint8_t b0 = *(p+3); // 6 }... When the student tests the function, the results are initially puzzling. a) [2 points] The posted tar file includes a Linux executable, Q3. The executable includes a main() function that calls the function shown above. Execute the program. What does it print? b) [3 points] Start gdb on Q3, and set a breakpoint at writebytes(). Now run Q3; it will halt execution just after entering writebytes(). Using the gdb print command, display the value of N in hex; what is it? c) [6 points] Step (in gdb) until lines 1 through 6 shown above have been executed. Now, use gdb to prove that p does indeed point to N. Describe how you did this; copy/paste the relevant parts of your gdb session in your answer. d) [4 points] Again, using gdb, find the values of the four local variables b3, b2, b1 and b0. State the values, expressed in hex. e) [4 points] Consider your answer to part a), and the fact you proved in part c). Explain precisely why the value you found for b0 makes sense. Warning: a correct answer must take data representation into account. 3

4 4. An executable Q4 segfaults when it is run. A short session with gdb shows some puzzling results: #1054 wdm@centos65:q4> gdb Q4 (gdb) run Starting program: /home/wdm/2505/hw10/q4/q4 Program received signal SIGSEGV, Segmentation fault. 0x080483f5 in Q4 (Sz= ) at Q4.c:18 18 List[idx] = idx * idx; (gdb) print idx $1 = 856 There are at least two strange things here: The value of idx is 856, but the loop is controlled by the test "idx < Sz", where Sz is passed to the function via the call in main(), and the actual parameter there is 10 (see the source code for main(), provided in the HW10.tar). The parameter passed to the function Q4() is huge, not 10. How could that have happened? Let's try another gdb session: (gdb) break Q4 Breakpoint 1 at 0x80483e2: file Q4.c, line 17. (gdb) run Starting program: /home/wdm/2505/hw10/q4/q4 Breakpoint 1, Q4 (Sz=10) at Q4.c:17 17 for (int idx = 0; idx < Sz; idx++) { Missing separate debuginfos, use: debuginfo-install glibc el6_5.4.i686 (gdb) continue Continuing. Breakpoint 1, Q4 (Sz= ) at Q4.c:17 17 for (int idx = 0; idx < Sz; idx++) { a) [2 points] Explain why the information above shows that Q4() is being executed twice. But, there's only one call to Q4() in main(). How can this be? What's on the stack at the moment? (gdb) backtrace #0 Q4 (Sz= ) at Q4.c:18 #1 0x a in?? () #2 0x in puts@plt () #3 0x b in libc_csu_init () #4 0x00b64d36 in libc_start_main () from /lib/libc.so.6 #5 0x in _start () Well, that doesn't look right. There should be a frame for main() and one for Q4(), but we just have frames for library/system functions, one for "??" whatever that is, and we do have one for Q4(). 4

5 Here's what we should have expected to see (restarting execution from the beginning): (gdb) run The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /home/wdm/2505/hw10/q4/q4 Breakpoint 1, Q4 (Sz=10) at Q4.c:17 17 for (int idx = 0; idx < Sz; idx++) { (gdb) backtrace #0 Q4 (Sz=10) at Q4.c:17 #1 0x080483a9 in main () at Q4.c:8 So, on the previous run, the stack's been corrupted somehow let's look at the stack in detail (starting where we left off above, so we've run until main() calls Q4(), and nothing bad seems to have happened yet). Here is information about frame 0 (the one for Q4()): (gdb) info frame 0 Stack frame at 0xffffd2d0: eip = 0x80483b6 in Q4 (Q4.c:17); saved eip 0x80483a9 called by frame at 0xffffd2f0 source language c. Arglist at 0xffffd2c8, args: Sz=10 Locals at 0xffffd2c8, Previous frame's sp is 0xffffd2d0 Saved registers: ebp at 0xffffd2c8, eip at 0xffffd2cc b) [4 points] At what address does the frame for Q4() begin? How do you know that? c) [5 points] What does the following gdb output tell us? (gdb) p/x *(int)($ebp + 4) $8 = 0x80483a9 d) [5 points] The assembly code for main() is shown below. Explain precisely what this tells us about the value that was displayed in the previous part. (gdb) disassem main Dump of assembler code for function main: 0x <+0>: push %ebp 0x <+1>: mov %esp,%ebp 0x <+3>: and $0xfffffff0,%esp 0x a <+6>: sub $0x10,%esp 0x d <+9>: movl $0xa,(%esp) 0x080483a4 <+16>: call 0x80483b0 <Q4> 0x080483a9 <+21>: mov $0x0,%eax 0x080483ae <+26>: leave 0x080483af <+27>: ret End of assembler dump. 5

6 Just for completeness, here's information about frame 1 (the one for main()): (gdb) info frame 1 Stack frame at 0xffffd2f0: eip = 0x80483a9 in main (Q4.c:8); saved eip 0xb64d36 caller of frame at 0xffffd2d0 source language c. Arglist at 0xffffd2e8, args: Locals at 0xffffd2e8, Previous frame's sp is 0xffffd2f0 Saved registers: ebp at 0xffffd2e8, eip at 0xffffd2ec So, now the question is, what happens when we run to the end of Q4()? Let's set a breakpoint at the last instruction before the end of Q4() and run to it: (gdb) break Q4.c:21 Breakpoint 2 at 0x80483d9: file Q4.c, line 21. (gdb) continue Continuing. Breakpoint 2, Q4 (Sz=10) at Q4.c:21 21!! I'm going to be annoying here and NOT show you that C code.!! e) [5 points] Below, we display the contents of the same memory location that was examined in part c). The value has not changed: (gdb) print/x *(int*)($ebp + 4) $3 = 0x80483a9 Now, execute that last instruction in Q4() and see what happens to the value: (gdb) next 22 } (gdb) print/x *(int*)($ebp + 4) $4 = 0x80483b0 Now, value has changed. Below we have part of the code for Q4(): (gdb) disassem Q4 Dump of assembler code for function Q4: 0x080483b0 <+0>: push %ebp 0x080483b1 <+1>: mov %esp,%ebp 0x080483b3 <+3>: sub $0x30,%esp... End of assembler dump. Now, consider the code for Q4(), and the change in that aforementioned value. Explain precisely how this information explains the fact that Q4() was executed twice. 6

7 5. Unpacking the posted tar file HW10.tar will create a subdirectory Q5 containing the following files: Q5driver.c Q5bomb.h Q5bomb.o Q5 a driver file for Q5bomb() header file for importing Q5bomb() to Q5driver.c x86-32 binary for Q5bomb() x86-32 executable for the program The executable Q5 was produced with the command: gcc o Q5 m32 O0 ggdb3 Wall Q5driver.c Q5bomb.o If you want to edit Q5driver.c for some reason, use the command above to recompile. This will not work correctly on your 64-bit Linux install unless you've followed the instructions on the course Forum and enabled 32-bit builds. If that's a problem, complete this question on rlogin. Try executing Q5, and you'll see a message saying you must supply a string on the command line. Try running Q5 with a string of your choosing; unless you are very lucky, a segfault will occur while the function Q5bomb() is running. Your job is now to find a string that will NOT lead to a segfault when you execute Q5. There are many strings that will work. You might find one by trial and error, but that will not yield any credit. You must use gdb to analyze what happens when you execute Q5, and deduce the characteristics of a string that will prevent the segfault. An acceptable answer to this question will: Give a precise explanation of the characteristics a string must have to "defuse" the segfault. Show how you used gdb to determine the answer to the previous part. Here's a sample of my gdb session to give you some inspiration: Start gdb on the executable: #1038 wdm@centos65:q5> gdb Q5 Set execution to halt when Q5bomb() is entered: (gdb) break Q5bomb Breakpoint 1 at 0x804845a Run the program with a string, so we can examine execution: (gdb) run pleasedonotcrash Starting program: /home/wdm/2505/hw10/q5/q5 pleasedonotcrash Breakpoint 1, 0x a in Q5bomb () Let's look at the code for Q5bomb() and see what we can figure out. Unfortunately, whoever compiled Q5bomb.c did not generate debugging information, so all we can do is look at assembly code. That does give us a lot of information, but it will take some digging to get the details. 7

8 At the moment, we just entered he body of the function Q5bomb(), we can use the disassem command in gdb to generate the assembly code from the machine code that's in the executable: (gdb) disassem Q5bomb Dump of assembler code for function Q5bomb: 0x <+0>: push %ebp 0x <+1>: mov %esp,%ebp 0x <+3>: sub $0x28,%esp => 0x a <+6>: cmpl $0x0,0x8(%ebp) 0x e <+10>: je 0x80484bb <Q5bomb+103>... Aha! There's a parameter (well, we knew that if we looked in Q5driver.c). Let's see if it's correct; it should be "pleasedontcrash". How can we display it? Let's try: (gdb) print $ebp + 8 $5 = (void *) 0xffffd2c0 That's the address of the parameter not what we want. Let's try: (gdb) print *($ebp + 8) Attempt to dereference a generic pointer. That doesn t work; $ebp + 8 is a void*, as it says above. We need a typecast; let's try: (gdb) print *(char*)($ebp + 8) $6 = 44 ',' That doesn t work either, at least not the way we wanted; when we dereference $ebp + 8, we get the first byte of the thing it's pointing to, which is actually a pointer to a char array. Remember, the parameter is a char*; let's try: What's going on there? (gdb) print *(*(char**)($ebp+8)) $2 = 112 'p' OK, so the first character is 'p', which is correct. Let's try a little more pointer arithmetic and see what comes next: (gdb) print *(*(char**)($ebp+8)+1) $3 = 108 'l' (gdb) print *(*(char**)($ebp+8)+2) $4 = 101 'e' ($ebp + 8) is the address of the parameter, which is a pointer to the parameter string, which is a char*. So, ($ebp + 8) is a pointer to a char*, hence a char**. We need to typecast it correctly before gdb will let us dereference it, and get string. That's all what I expected, but tedious. Let's try a memory display command: (gdb) x/sb (*(char**)($ebp+8)) 0xffffd52c: "pleasedontcrash" So, *(char**)($ebp + 8) gives us string. Then, we dereference THAT to get the first element of the array. And what's going on here? Well, we know that *(char**)($ebp + 8) gives us string. The gdb command x/nfu is used to display the contents of memory. The parameter to x/nfu is a pointer to a block of memory you want to view. You can look up the details, and the options, but the 's' means treat the block like a null-terminated C-string, if that's possible. Since string points to a null-terminated char array, we see the string "pleasedontcrash". 8

9 Now, you need to analyze the assembly code (disassem) and determine what's going on in the function Q5bomb(). That will give you all the information you need to answer the questions below. Your score on this question will depend largely on providing a good explanation of your analysis, illustrated with "snapshots" of your gdb session(s). You should look at the gdb sessions in this assignment and the course notes for inspiration. a) [6 points] Give a precise explanation of the characteristics a string must have to "defuse" the segfault. This should be as general as possible (e.g., all strings that are exactly 73 characters long and contain the substring "skunk"). b) [12 points] Show how you used gdb to determine the answer to the previous part. For this, you should write explanatory descriptions of what you did, and copy/paste in relevant parts of your gdb session. 9