Slides

Tasks

There is a directory for each task number. Makefiles are provided for all of them.

1. allocation types and alignement
   • This is a simple application that allocates some memory and prints the obtained addresses.
   • Observe how all the addresses are 8 bytes aligned (or 16 bytes on a 64bits system).
   • If you eliminate the 8 byte alignment, the pointers are also 4K aligned
   • Why is the first address so different from the rest ?
2. massif
   • Analyze the source code. There are several functions allocating memory on the heap.
   • Build the application
   • Run valgrind with the “massif” tool to profile the heap usage of the application.

   • valgrind --tool=massif --time-unit=B ./massif

     • The time unit option can be “i” (instruction), “ms” (millisecond), “B” (byte). This application runs for a small amount of time, so “B” is the best in this case.
     • A massif.out.$PID file will be created
   • Display the profiling data:

     • ms_print <file>

     • The output will consist of a graph and several detailed snapshots with a call tree
   • Free the memory at the end of the f() and g() functions and redo the profiling
   • Compare the 2 snapshots.
3. information leak
   • Freeing memory does not destroy the data. This small application demonstrates that.
   • Analyze the source and build the application.
   • Use pahole to display the memory layout of “struct data”. Information can be leaked in those holes.
     • compilers might align the fields in a structure
     • pahole uses debugging information from the binary to display the layouts of data structures

     • pahole <file>

     • Install the dwarves package if pahole is not found
   • Implement 2 solutions that will prevent information leak
4. corruption
   • Analyze the source code.
   • Build and run.
   • Supply an invalid index (negative). What happens ? Try with an index of -1. What now ? Why ?
     • Remember the layout of the memory chunks
   • Run under gdb with the same index. Find out what is stored at that memory location.

     •        gdb corrupt
              breakpoint 27
              run -1 70
             

   • GDB commands for displaying memory contents:
     • x/bx address
       • print a byte in hex from that address
       • use 'w' to display a word (int)
     • x/wx ptr - 1
       • display a word at (ptr - sizeof(*ptr))
   • You should see something like:

     •  0x804a004:       0x00000031

     • This is the allocated chunk size:
       • user data: COUNT * sizeof(long) = 10 * 4 = 40 octets
       • allocator data: 8 octets
       • 1 - the bit that says it's the first chunk
       • TOTAL: 49 = 0x31
5. string length
   • The application in over.c reads a user name and a password from standard input.
   • It displays a welcome message if the combination is right.
   • What happens when you supply the correct information ?
   • Fix the application so that the string format won't overrun the allocated buffer.
     • Options: increase the allocated size, use snprintf()
6. tokenize
   • This application splits a string containing the PATH environment variable and displays each path.
   • Eventually, it tries to run “gcc”, but fails.
   • Find out what is wrong and fix it
     • Hint: strtok
     • Hint: use strdup