To actually access it, you first need to attach to the target process using ptrace(…), the system’s debugging API.
You shouldn't need to do that.
lseek(…) to a specific offset, and then read(…) or write(…) as you would with a normal file
(or you can use pread/pwrite)
the ptrace(…) function also supports a better-known PTRACE_PEEKDATA and PTRACE_POKEDATA interface, but come on
fwiw a third alternative are the process_vm_readv/process_vm_writev syscalls which also don't require attaching with ptrace()
Some readers might find it amusing that back then, Linux 2.2 allowed you to call mmap(…) on the resulting /proc//mem file descriptor
ooh, I didn't know that bit of history, interesting
You can peek at process metadata via a pseudo-filesystem called /proc, but the data doesn’t seem particularly interesting. It’s the stuff you see in the output of ps or top:
Fun story: /proc/$pid/environ and /proc/$pid/cmdline work very similarly to /proc/$pid/mem, except that they are read-only and restrict the view of memory to a subrange of the virtual address space. (and cmdline also does some munging of the data iirc.)
So even when you run "ps aux" or such, behind the scenes this is reading from the memory of the listed processes, almost like /proc/$pid/mem would.