Braque *Bottle and Fishes* c.1910–2 (Tate). /proc just like analytical cubism displays a process through many angles.

Journey into the machine, `/proc`

7 min readFeb 22, 2018

(Note all examples below are for ubuntu14.04 LTS in a vagrant box. gdb version 7.7 is used, gcc version 4.8 and python 3.4. I am using scripts stored on github)

/proc presentation

The proc file system is a virtual file system. It’s sometimes referred to as a process information pseudo-file system. It doesn’t contain ‘real’ files but runtime system information (e.g. system memory, devices mounted, hardware configuration, etc). It acts as an interface with the kernel. Looking into the subdirectories and files, one can not only read the information, but also change certain kernel parameters at runtime (and more, see below).

Here I will focus on reading process specific information. I will use a simple script (infinite_loop running continuously in another terminal than the one I am using to type commands) to give examples.

/proc contains one subfolder for each process currently running. This folder is named after the process pid. Below I give an exert of what it looks like for my toy script.

vagrant@vagrant-ubuntu-trusty-64:~$ ps aux | grep infinite
vagrant  23984  0.0  0.0   4324   356 pts/0    S+   03:13   0:00 ./infinite_loop
vagrant  23986  0.0  0.1  10460   936 pts/3    S+   03:13   0:00 grep --color=auto infinite
vagrant@vagrant-ubuntu-trusty-64:~$ ls -l /proc/23984
total 0
dr-xr-xr-x 2 vagrant vagrant 0 Feb 22 03:22 attr
-rw-r--r-- 1 vagrant vagrant 0 Feb 22 03:22 autogroup
-r-------- 1 vagrant vagrant 0 Feb 22 03:22 auxv
-r--r--r-- 1 vagrant vagrant 0 Feb 22 03:22 cgroup
--w------- 1 vagrant vagrant 0 Feb 22 03:22 clear_refs
-r--r--r-- 1 vagrant vagrant 0 Feb 22 03:13 cmdline
-rw-r--r-- 1 vagrant vagrant 0 Feb 22 03:22 comm
-rw-r--r-- 1 vagrant vagrant 0 Feb 22 03:22 coredump_filterdr-x------ 2 vagrant vagrant 0 Feb 22 03:22 map_files
-r--r--r-- 1 vagrant vagrant 0 Feb 22 03:13 maps
-rw------- 1 vagrant vagrant 0 Feb 22 03:22 mem
-r--r--r-- 1 vagrant vagrant 0 Feb 22 03:22 mountinfo
-r--r--r-- 1 vagrant vagrant 0 Feb 22 03:22 mounts

All files and directories show a size of 0, but as I will read them, it will be obvious they are not empty.

I wanted in a script to compare the number of pids in ls /proc, and ps aux. The result, as expected is in both cases I get the same number of pids, with one pid present in one output and not the other: the pid of ls and ps processes respectively.

./compare_pids.py 
Number of pids for ls /proc: 98 and ps: 98
pids differ for 26812 and 26813

I will focus on /maps and /mem

/proc/[pid]/maps

It displays the currently mapped memory regions and their access permissions.

For my example:

vagrant@vagrant-ubuntu-trusty-64:~$ ps aux | grep infinite
vagrant  23984  0.0  0.0   4324   356 pts/0    S+   03:13   0:00 ./infinite_loop
vagrant  23986  0.0  0.1  10460   936 pts/3    S+   03:13   0:00 grep --color=auto infinite
vagrant@vagrant-ubuntu-trusty-64:~$ cat /proc/23984/maps
00400000-00401000 r-xp 00000000 08:01 395098                             infinite_loop
00600000-00601000 r--p 00000000 08:01 395098                             infinite_loop
00601000-00602000 rw-p 00001000 08:01 395098                             infinite_loop
00708000-00729000 rw-p 00000000 00:00 0                                  [heap]
7f3fb0b7f000-7f3fb0d39000 r-xp 00000000 08:01 2006                       /lib/x86_64-linux-gnu/libc-2.19.so
7f3fb0d39000-7f3fb0f39000 ---p 001ba000 08:01 2006                       /lib/x86_64-linux-gnu/libc-2.19.so
7f3fb0f39000-7f3fb0f3d000 r--p 001ba000 08:01 2006                       /lib/x86_64-linux-gnu/libc-2.19.so
7f3fb0f3d000-7f3fb0f3f000 rw-p 001be000 08:01 2006                       /lib/x86_64-linux-gnu/libc-2.19.so
7f3fb0f3f000-7f3fb0f44000 rw-p 00000000 00:00 0 
7f3fb0f44000-7f3fb0f67000 r-xp 00000000 08:01 2019                       /lib/x86_64-linux-gnu/ld-2.19.so
7f3fb1154000-7f3fb1157000 rw-p 00000000 00:00 0 
7f3fb1163000-7f3fb1166000 rw-p 00000000 00:00 0 
7f3fb1166000-7f3fb1167000 r--p 00022000 08:01 2019                       /lib/x86_64-linux-gnu/ld-2.19.so
7f3fb1167000-7f3fb1168000 rw-p 00023000 08:01 2019                       /lib/x86_64-linux-gnu/ld-2.19.so
7f3fb1168000-7f3fb1169000 rw-p 00000000 00:00 0 
7fffa32f7000-7fffa3318000 rw-p 00000000 00:00 0                          [stack]
7fffa33c9000-7fffa33cb000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]

The man page gives a great detailed explanation of the different fields (man proc). Here is how it defines the different fields from left to right:

The address field is the address space in the process  that  the  mapping occupies. 
The perms field is a set of permissions:
                   r = read
                   w = write
                   x = execute
                   s = shared
                   p = private (copy on write)
The offset field is the offset into the file/whatever;
dev is the device (major:minor);
inode is the inode on that device.  0  indicates  that  no inode is associated with the memory region, as would be the case with BSS(uninitialized data).
The pathname field will usually be the file that is backing the  mapping.
There are additional helpful pseudo-paths:
[stack] The initial process's  (also  known  as  the  main  thread's) stack.
[vdso] The virtual dynamically linked shared object.
[heap] The process's heap.

It looks like all the different address fields are continuous. This is because we observe the virtual memory layout of the process. For each process the kernel creates a mapping between the physical memory and the hardware.

Reading the above file, I was surprised my process (infinite_loop) is listed 3 times, same for the libc-2.19.so. Processes can be divided into several contiguous parts, with different permissions for each address segment. I need to look more into it to find a good explanation. This reference explains about how ELF files (standard binary files format on my machine) are divided in at least 3 regions:

•Code which is executed; this region is normally not writable;
•Data which is modified; this region is normally not executable;
•Data which is not used at run-time; since not needed it should not be loaded at startup.
Modern operating systems and processors can protect memory regions to allow and disallow reading, writing, and executing separately for each page of memory.

This maps file is used by gdb, the gdb commandinfo proc mappings displays it. Let’s try:

vagrant@vagrant-ubuntu-trusty-64:$ gdb attach -p 23984
...
Could not attach to process.  If your uid matches the uid of the target process, check the setting of /proc/sys/kernel/yama/ptrace_scope, or try again as the root user.  For more details, see /etc/sysctl.d/10-ptrace.conf
ptrace: Operation not permitted.
(gdb)

The error message above is pretty interesting with regards to our topic: it asks to modify a kernel parameter at runtime (/proc/sys) in order to complete the action (more details: https://www.kernel.org/doc/Documentation/security/Yama.txt)

vagrant@vagrant-ubuntu-trusty-64:~$ sudo gdb attach -p 23984
...
(gdb) info proc mappings
process 23984
Mapped address spaces:Start Addr           End Addr       Size     Offset objfile
            0x400000           0x401000     0x1000        0x0 /home/vagrant/infinite_loop
            0x600000           0x601000     0x1000        0x0 /home/vagrant/infinite_loop
            0x601000           0x602000     0x1000     0x1000 /home/vagrant/infinite_loop
            0x708000           0x729000    0x21000        0x0 [heap]
      0x7f3fb0b7f000     0x7f3fb0d39000   0x1ba000        0x0 /lib/x86_64-linux-gnu/libc-2.19.so
      0x7f3fb0d39000     0x7f3fb0f39000   0x200000   0x1ba000 /lib/x86_64-linux-gnu/libc-2.19.so
      0x7f3fb0f39000     0x7f3fb0f3d000     0x4000   0x1ba000 /lib/x86_64-linux-gnu/libc-2.19.so
      0x7f3fb0f3d000     0x7f3fb0f3f000     0x2000   0x1be000 /lib/x86_64-linux-gnu/libc-2.19.so
      0x7f3fb0f3f000     0x7f3fb0f44000     0x5000        0x0 
      0x7f3fb0f44000     0x7f3fb0f67000    0x23000        0x0 /lib/x86_64-linux-gnu/ld-2.19.so
      0x7f3fb1154000     0x7f3fb1157000     0x3000        0x0 
      0x7f3fb1163000     0x7f3fb1166000     0x3000        0x0 
      0x7f3fb1166000     0x7f3fb1167000     0x1000    0x22000 /lib/x86_64-linux-gnu/ld-2.19.so
      0x7f3fb1167000     0x7f3fb1168000     0x1000    0x23000 /lib/x86_64-linux-gnu/ld-2.19.so
      0x7f3fb1168000     0x7f3fb1169000     0x1000        0x0 
      0x7fffa32f7000     0x7fffa3318000    0x21000        0x0 [stack]
      0x7fffa33c9000     0x7fffa33cb000     0x2000        0x0 [vdso]
  0xffffffffff600000 0xffffffffff601000     0x1000        0x0 [vsyscall]
(gdb)

Now there are the mappings, where can we access the memory?

/proc/[pid]/mem

The proc man page explains: This file can be used to access the pages of a process’s memory.

So let’s do it. Reading above, the heap is both readable and writable. Is it possible to open the mem file, locate the heap, inside the heap locate the string the infinite_loop is continuously writing and overwriting it?

That is what this python script is doing. It requires to be run as root to open the /mem file of another process. It will look for the infinite_loop process, then read its maps file, find the heap, open the mem file, and replace “World” with “Good Night”:

vagrant@vagrant-ubuntu-trusty-64:~$sudo ./read_write_heap.py 
[*] Maps: /proc/23984/Maps
01526000-01547000 rw-p 00000000 00:00 0                                  [heap][*] Found [heap]:
    pathname = [heap]
    addresses = 01526000-01547000
    permissions = rw-p
    offset = 00000000
    inode = 0
[*] Addr start [01526000] | end [01547000]
[*] Mem: /proc/23984/mem
[*] Found World at 0x16
    Overwriting the heap

In the other terminal

$ ./infinite_loop
Hello World
Hello World
Hello World
Hello World
Hello World
Hello World
Hello World
Hello Good Night
Hello Good Night

It is also possible to do it in gdb.

I set a breakpoint where printf resides (in order to find out the address I used objdump) In the previous gdb session:

(gdb) break *0x4005dd
Breakpoint 1 at 0x4005dd: file infinite_loop.c, line 13.
(gdb) p s2
$1 = 0x20ad010 "Hello World"
(gdb) p strcpy($1, "Good Night")
$2 = 34263056
(gdb) p s2
$3 = 0x20ad010 "Good Night"
(gdb) clear
(gdb) c

In the other terminal:

$ ./infinite_loop
Hello World
Hello World
Hello World
Hello World
Hello World
Hello World
Hello World
Hello World
Hello World
Hello World
Hello World
Hello World
Hello World
Good Night
Good Night
Good Night
Good Night
Good Night