Linux C++ ptrace -- Map all cells of a child processes memorys

Question

I have a linked list similar to this:

class MemoryCell
{
protected:
    unsigned char* _address; // the address offset (in another process)
    unsigned int _size;  // the size of this memory block
    unsigned char* _buffer; // the data

    MemoryCell* _next; // points to next memory cell to form linked list
};

Then I have a MemoryMapper class which will hold the head. I want to get all of the memory cells in it.

// void MemoryMapper::MapAllCells(unsigned int procId)//
unsigned int offset = 0x0;
while (true)
    {
        long memoryData = ptrace(PTRACE_PEEKDATA, procId, offset);
        if (memoryData == -1) break; // need to check for errno(3) too
       // add new MemoryCell w/ data to head of linked list
       // how to get next offset based on what was returned?

it breaks right away at address 0. I thought it might start at 0x0 for that process but I guess I need the real offset. But how can I get the next offset as well (based on size of previous)?

Hope it was clear but I can clarify if needed Thanks

score 0 · Accepted Answer · answered Apr 14 '12 at 22:21

0

You can't get this information from ptrace(); you can get it from /proc/PID/maps for the child process, though. Note that address 0 is typically not mapped, in order to catch NULL pointer references, and may not make sense for PTRACE_PEEKDATA (separate I and D isn't generally used these days, and in its absence address 0 is usually text, not data; whether the kernel bothers to distinguish, I don't know off the top of my head).

answered Apr 14 '12 at 22:21

geekosaur

59,309
11
123
114

interesting. can you help point in the direction of making some sense of the data contained in the maps file? std:: cluttering the search – r00t_ Apr 14 '12 at 22:26
I tried testing it on a process. unsigned long long offset = 0x7f64e21c3000; But it still breaks without reading? – r00t_ Apr 14 '12 at 22:39
What error do you get? Is the process owned by your uid? Do you otherwise have access to it (either via `PTRACE_ATTACH` or by it using being a child and invoking `PTRACE_TRACEME`)? – geekosaur Apr 14 '12 at 23:02
yea is owned by my uid... tried using PTRACE_ATTACH beforehand but still not working. Not savvy enough from the man page how to tell which error I am getting. http://pastebin.com/yF2rfSRw – r00t_ Apr 15 '12 at 00:52
hmm its failing on the attach too.. errno is 1. then to read memory errno is 3 – r00t_ Apr 15 '12 at 01:07
You should check `errno`, as with any other C system call, both with the `PTRACE_ATTACH` call and the `PTRACE_PEEKDATA` call. I think I'd be using `/proc/PID/mem` instead of `ptrace()` if the memory (as opposed to registers, or stopping/tracing the program) is all you care about, by the way; also, reading memory is potentially quite meaningless while the program is running, I would suspect it wants you to stop the process so you get a meaningful snapshot of its memory. – geekosaur Apr 15 '12 at 01:08
Eventually I will need to overwrite the values, which I will probably need ptrace for? btw when I try to read /proc/PID/mem from the terminal I need to do so as the superuser, and then it doesnt print anything out? r00t@:/proc/27589$ more mem mem: Permission denied r00t@:/proc/27589$ sudo more mem [sudo] password for r00t: r00t@:/proc/27589$ – r00t_ Apr 15 '12 at 01:18
I think, if `more mem` makes sense to you, you don't quite have what you're trying to do worked out fully yet. You should also look into what specific `errno` values mean. I will however note that these failures are related. – geekosaur Apr 15 '12 at 01:27
memory editing is a traditional difficulty I have only played with in macroquest2. I did `file mem` too and it said was empty. I mean if its representing the actual memory I thought there'd be something in it but Im not some redhat certified engineer either. Also have no idea which the error codes actually mean. Are these them? 1. [EIO] Specifies that the request parameter does not have one of the listed values, or is not valid for the machine type on which the process is executing. ..... 3. [EIO] Specifies that the addressed used is either out of bounds or improperly aligned. ? – r00t_ Apr 15 '12 at 01:34
ok, I read the manual (`man 3 errno` on Linux) for you: `1` is `EPERM` ("Permission denied"). Neither `file` nor `du` will do anything sensible with `mem` because it isn't a real file, it a process's address space, and address 0 is not mapped (see start of this discussion); programs that expect files do not know what to do with this. – geekosaur Apr 15 '12 at 01:38
man this sucks why would it deny its owned by r00t and im running this program as r00t. when I ran it as root I could attach but not read. side note: added you on twitter btw – r00t_ Apr 15 '12 at 01:41
Typically it's security-related. I don't know specific details but you should not get that from `/proc/PID/mem` if your really are the same uid (try `ls -l`) and a quick test seems to work on the Linux systems I have accessible. – geekosaur Apr 15 '12 at 01:47
-rw------- 1 r00t r00t 0 2012-04-14 18:50 mem.... so yea owned by me...dunno why I need actual root to act on it. I btw I'll look into ./mem in C++ more but only can you tell me if I can edit values in it? If not ptrace driving me insane. – r00t_ Apr 15 '12 at 01:51
`write()` works (see `man 4 proc`); again, you probably need to stop the process before writing to its memory if you want anything like consistency. – geekosaur Apr 15 '12 at 01:53
man i dont even know im really bothered cuz I wrote the windows section of this code so easily and now I cant get it to work on linux. gonna look into the write() of mem.. btw r00t@:/proc/6741$ man 4 proc No manual entry for proc in section 4.... anyways thanks for the help deserve the selected answer i gave cuz no1 else knows wtf – r00t_ Apr 15 '12 at 02:14

Linux C++ ptrace -- Map all cells of a child processes memorys

1 Answers1