Your task is to get CTARGET to execute the code for touchl when getbuf executes its return statement, rather than returning to test. Note that your exploit string may also corrupt parts of the stack not directly related to this stage, but this will not cause a problem, since touch1 causes the program to exit directly. Some Advice: • All the information you need to devise your exploit string for this level can be determined by exam- ining a disassembled version of CTARGET. Use objdump -d to get this dissembled version. • The idea is to position a byte representation of the starting address for touchl so that the ret instruction at the end of the code for getbuf will transfer control to touch1. • Be careful about byte ordering. • You might want to use GDB to step the program through the last few instructions of getbuf to make sure it is doing the right thing. • The placement of buf within the stack frame for getbuf depends on the value of compile-time constant BUFFER_SIZE, as well the allocation strategy used by GCC. You will need to examine the disassembled code to determine its position. 4.2 Level 2 Phase 2 involves injecting a small amount of code as part of your exploit string. Within the file ctarget there is code for a function touch2 having the following C representation: 1 void touch2 (unsigned val) /* Part of validation protocol */ printf("Touch2!: You called touch2 (0x%.8x)\n", val); 2 { 3 4 vlevel if (val = 2; == cookie) { 5 6 validate (2); 7 } else { 8 9 printf("Misfire: You called touch2 (0x%.8x) \n", val); fail (2); 10 } 11 exit (0); 12 } Your task is to get CTARGET to execute the code for touch2 rather than returning to test. In this case, however, you must make it appear to touch2 as if you have passed your cookie as its argument. Some Advice: • You will want to position a byte representation of the address of your injected code in such a way that ret instruction at the end of the code for getbuf will transfer control to it. • Recall that the first argument to a function is passed in register %rdi. 6 • Your injected code should set the register to your cookie, and then use a ret instruction to transfer control to the first instruction in touch2. • Do not attempt to use jmp or call instructions in your exploit code. The encodings of destination addresses for these instructions are difficult to formulate. Use ret instructions for all transfers of control, even when you are not returning from a call. See the discussion in Appendix B on how to use tools to generate the byte-level representations of instruction sequences. 4.3 Level 3 Phase 3 also involves a code injection attack, but passing a string as argument. Within the file ctarget there is code for functions hexmatch and touch3 having the following C representations: 1 /* Compare string to hex represention of unsigned value */ 2 int hexmatch (unsigned val, char *sval) 3 { 4 LO 5 6 7 8 9 } 10 char cbuf[110]; /* Make position of check string unpredictable */ char *s = cbuf +random() % 100; sprintf(s, "%.8x", val); return strncmp(sval, S, 9) 11 void touch3 (char *sval) == Oi 12 { 13 vlevel = 3; /* Part of validation protocol */ 14 15 16 17 if (hexmatch (cookie, sval)) { printf("Touch3!: You called touch3(\"%s\")\n", sval); validate (3); } else { 18 19 printf("Misfire: You called touch3(\"%s\")\n", sval); fail (3); 20 } 21 exit (0); 22 } Your task is to get CTARGET to execute the code for touch3 rather than returning to test. You must make it appear to touch 3 as if you have passed a string representation of your cookie as its argument. Some Advice: • You will need to include a string representation of your cookie in your exploit string. The string should consist of the eight hexadecimal digits (ordered from most to least significant) without a leading “Ox." 7

Your task is to get CTARGET to execute the code for touchl when getbuf executes its return statement, rather than returning to test. Note that your exploit string may also corrupt parts of the stack not directly related to this stage, but this will not cause a problem, since touch1 causes the program to exit directly. Some Advice: • All the information you need to devise your exploit string for this level can be determined by exam- ining a disassembled version of CTARGET. Use objdump -d to get this dissembled version. • The idea is to position a byte representation of the starting address for touchl so that the ret instruction at the end of the code for getbuf will transfer control to touch1. • Be careful about byte ordering. • You might want to use GDB to step the program through the last few instructions of getbuf to make sure it is doing the right thing. • The placement of buf within the stack frame for getbuf depends on the value of compile-time constant BUFFER_SIZE, as well the allocation strategy used by GCC. You will need to examine the disassembled code to determine its position. 4.2 Level 2 Phase 2 involves injecting a small amount of code as part of your exploit string. Within the file ctarget there is code for a function touch2 having the following C representation: 1 void touch2 (unsigned val) /* Part of validation protocol / printf("Touch2!: You called touch2 (0x%.8x)\n", val); 2 { 3 4 vlevel if (val = 2; == cookie) { 5 6 validate (2); 7 } else { 8 9 printf("Misfire: You called touch2 (0x%.8x) \n", val); fail (2); 10 } 11 exit (0); 12 } Your task is to get CTARGET to execute the code for touch2 rather than returning to test. In this case, however, you must make it appear to touch2 as if you have passed your cookie as its argument. Some Advice: • You will want to position a byte representation of the address of your injected code in such a way that ret instruction at the end of the code for getbuf will transfer control to it. • Recall that the first argument to a function is passed in register %rdi. 6 • Your injected code should set the register to your cookie, and then use a ret instruction to transfer control to the first instruction in touch2. • Do not attempt to use jmp or call instructions in your exploit code. The encodings of destination addresses for these instructions are difficult to formulate. Use ret instructions for all transfers of control, even when you are not returning from a call. See the discussion in Appendix B on how to use tools to generate the byte-level representations of instruction sequences. 4.3 Level 3 Phase 3 also involves a code injection attack, but passing a string as argument. Within the file ctarget there is code for functions hexmatch and touch3 having the following C representations: 1 / Compare string to hex represention of unsigned value / 2 int hexmatch (unsigned val, char sval) 3 { 4 LO 5 6 7 8 9 } 10 char cbuf[110]; /* Make position of check string unpredictable / char s = cbuf +random() % 100; sprintf(s, "%.8x", val); return strncmp(sval, S, 9) 11 void touch3 (char sval) == Oi 12 { 13 vlevel = 3; / Part of validation protocol */ 14 15 16 17 if (hexmatch (cookie, sval)) { printf("Touch3!: You called touch3(\"%s\")\n", sval); validate (3); } else { 18 19 printf("Misfire: You called touch3(\"%s\")\n", sval); fail (3); 20 } 21 exit (0); 22 } Your task is to get CTARGET to execute the code for touch3 rather than returning to test. You must make it appear to touch 3 as if you have passed a string representation of your cookie as its argument. Some Advice: • You will need to include a string representation of your cookie in your exploit string. The string should consist of the eight hexadecimal digits (ordered from most to least significant) without a leading “Ox." 7