Question

I have been playing a while with ptrace. I followed some tutorials like this one or this one. So far, when I have a ptrace-d child process, I am able to:

• Detect system calls and browse the registers.
• Fetch the strings contained in addresses pointed by the registers, thanks to the PTRACE_PEEKDATA option of ptrace.
• Change the values of those registers and change memory values in the user space of the child process thanks to the PTRACE_POKEDATA option of ptrace.

My problem is the following: let’s say that for example I have just detected an open system call. I can modify the filename of the file to be opened thanks to the address stored in the ebx register. However, I wonder if I can just change the filename to anything I want, any size. If the name I am changing to is really large (let’s say 50 times the original filename length), wouldn’t I be messing with some memory I should not be writing on? Should I ‘allocate’ some memory in the child’s memory space? If so, how would this be done?

Note that the child process is some program executed with execve, I cannot access its source code.

Answer 1

The pathname passed to open could be dynamically allocated by the program (so its on the heap or stack somewhere), or it could be in the read-only section if it was a compile-time constant. In either case, you don’t know what other parts of the program might be using it, so its probably not a good idea to change its contents. You would definitely overwrite adjacent memory if you wrote past the current length (which would probably lead to subtle problems like corrupting heap meta-data or corrupting other random allocation objects).

Here are some random ideas (totally untested) on how to allocate memory in a child process:

• invoke an mmap syscall on its behalf (this would probably be pretty tricky) but would get you a page (or more) of memory to play with
• allocate some space in the current stack (don’t change the child’s registers, but use your knowledge of which part of the stack the child is using to put temporary objects in the unused section). Technically its legal for the child process to do this same thing (so you could end up corrupting that data), but its very unlikely.
• hide stuff at the far end of the stack, (again assuming the child isn’t also playing this trick).
• I didn’t think invoking malloc would be easy, but googling for ‘ptrace child allocate memory’ I found: http://www.hick.org/code/skape/papers/needle.txt (which finds the malloc routine used by the ELF dynamic linker and constructs a call out to there to allocate memory).