Bug Hunter Diary

As the debugger output shows, mediaserverd crashed while tryingto reference an unmapped memory location. To further analyze thecrash, I printed the current call stack:(gdb) backtrace#0 0x314780ec in memmove ()#1 0x3493d5e0 in MP4AudioStream::ParseHeader ()#2 0x00000072 in ?? ()Cannot access memory at address 0x72This output was intriguing. The address of stack frame #2 had anunusual value (0x00000072), which seemed to indicate that the stackhad become corrupted. I used the following command to print thelast instruction that was executed in MP4AudioStream::ParseHeader() (seestack frame #1):(gdb) x/1i 0x3493d5e0 - 40x3493d5dc :bl 0x34997374 The last instruction executed in MP4AudioStream::ParseHeader() wasa call to memcpy(), which must have caused the crash. At this time, thebug had exhibited all the characteristics of a stack buffer overflowvulnerability (see Section A.1).I stopped the debugging session and rebooted the device.After the phone started, I attached the debugger to mediaserverdagain, and this time I also defined a breakpoint at the memcpy() callin MP4AudioStream::ParseHeader() in order to evaluate the functionarguments supplied to memcpy():(gdb) break *0x3493d5dcBreakpoint 1 at 0x3493d5dc(gdb) continueContinuing.I opened test case number 40 (file40.m4a) in MobileSafari inorder to trigger the breakpoint:[Switching to process 27 thread 0x9c0b]Breakpoint 1, 0x3493d5dc in MP4AudioStream::ParseHeader ()The arguments of memcpy() are usually stored in the registers r0(destination buffer), r1 (source buffer), and r2 (bytes to copy). I askedthe debugger for the current values of those registers.142 Chapter 8