Linux – Comment lire depuis /proc/$pid/mem sous Linux ?

Le proc(5) de Linux la page man me dit que /proc/$pid/mem "peut être utilisé pour accéder aux pages de la mémoire d'un processus". Mais une simple tentative de l'utiliser ne me donne que

$ cat /proc/$$/mem /proc/self/mem
cat: /proc/3065/mem: No such process
cat: /proc/self/mem: Input/output error

Pourquoi cat n'est-il pas capable d'imprimer sa propre mémoire (/proc/self/mem ) ? Et quelle est cette étrange erreur "pas de processus de ce type" lorsque j'essaie d'imprimer la mémoire du shell (/proc/$$/mem , évidemment le processus existe) ? Comment puis-je lire depuis /proc/$pid/mem , alors ?

Réponse acceptée :

/proc/$pid/maps

/proc/$pid/mem affiche le contenu de la mémoire de $pid mappé de la même manière que dans le processus, c'est-à-dire l'octet à l'offset x dans le pseudo-fichier est le même que l'octet à l'adresse x Dans le processus. Si une adresse n'est pas mappée dans le processus, la lecture à partir de l'offset correspondant dans le fichier renvoie EIO (Erreur d'entrée/sortie). Par exemple, étant donné que la première page d'un processus n'est jamais mappée (de sorte que le déréférencement d'un NULL le pointeur échoue proprement plutôt que d'accéder involontairement à la mémoire réelle), en lisant le premier octet de /proc/$pid/mem produit toujours une erreur d'E/S.

La façon de savoir quelles parties de la mémoire du processus sont mappées est de lire /proc/$pid/maps . Ce fichier contient une ligne par région cartographiée, ressemblant à ceci :

08048000-08054000 r-xp 00000000 08:01 828061     /bin/cat
08c9b000-08cbc000 rw-p 00000000 00:00 0          [heap]

Les deux premiers nombres sont les limites de la région (adresses du premier octet et de l'octet après le dernier, en hexa). La colonne suivante contient les autorisations, puis il y a des informations sur le fichier (décalage, périphérique, inode et nom) s'il s'agit d'un mappage de fichier. Voir le proc(5) page man ou Comprendre Linux /proc/id/maps pour plus d'informations.

Voici un script de preuve de concept qui vide le contenu de sa propre mémoire.

#! /usr/bin/env python
import re
maps_file = open("/proc/self/maps", 'r')
mem_file = open("/proc/self/mem", 'rb', 0)
output_file = open("self.dump", 'wb')
for line in maps_file.readlines():  # for each mapped region
    m = re.match(r'([0-9A-Fa-f]+)-([0-9A-Fa-f]+) ([-r])', line)
    if m.group(3) == 'r':  # if this is a readable region
        start = int(m.group(1), 16)
        end = int(m.group(2), 16)
        mem_file.seek(start)  # seek to region start
        chunk = mem_file.read(end - start)  # read region contents
        output_file.write(chunk)  # dump contents to standard output
maps_file.close()
mem_file.close()
output_file.close()

/proc/$pid/mem

[Ce qui suit est pour un intérêt historique. Cela ne s'applique pas aux noyaux actuels.]

Depuis la version 3.3 du noyau, vous pouvez accéder à /proc/$pid/mem normalement tant que vous n'y accédez qu'aux décalages mappés et que vous avez l'autorisation de le tracer (mêmes autorisations que ptrace pour un accès en lecture seule). Mais dans les noyaux plus anciens, il y avait quelques complications supplémentaires.

Si vous essayez de lire à partir du mem pseudo-fichier d'un autre processus, ça ne marche pas :vous obtenez un ESRCH (Aucun processus de ce type) erreur.

Les permissions sur /proc/$pid/mem (r-------- ) sont plus libérales que ce qui devrait être le cas. Par exemple, vous ne devriez pas pouvoir lire la mémoire d'un processus setuid. De plus, essayer de lire la mémoire d'un processus pendant que le processus le modifie pourrait donner au lecteur une vue incohérente de la mémoire, et pire, il y avait des conditions de concurrence qui pourraient retracer les anciennes versions du noyau Linux (selon ce fil lkml, bien que je ne connais pas les détails). Des vérifications supplémentaires sont donc nécessaires :

• Le processus qui veut lire depuis /proc/$pid/mem doit s'attacher au processus en utilisant ptrace avec le PTRACE_ATTACH drapeau. C'est ce que font les débogueurs lorsqu'ils commencent à déboguer un processus; c'est aussi ce que strace fait aux appels système d'un processus. Une fois que le lecteur a fini de lire depuis /proc/$pid/mem , il doit se détacher en appelant ptrace avec le PTRACE_DETACH drapeau.
• Le processus observé ne doit pas être en cours d'exécution. Appelant normalement ptrace(PTRACE_ATTACH, …) arrêtera le processus cible (il envoie un STOP signal), mais il y a une condition de concurrence (la livraison du signal est asynchrone), donc le traceur doit appeler wait (comme documenté dans ptrace(2) ).

En relation:Gardez NumLock toujours activé?

Un processus exécuté en tant que root peut lire la mémoire de n'importe quel processus, sans avoir besoin d'appeler ptrace , mais le processus observé doit être arrêté, sinon la lecture renverra toujours ESRCH .

Dans la source du noyau Linux, le code fournissant des entrées par processus dans /proc est dans fs/proc/base.c , et la fonction à lire depuis /proc/$pid/mem est mem_read . La vérification supplémentaire est effectuée par check_mem_permission .

Voici un exemple de code C à attacher à un processus et à lire un morceau de mem fichier (erreur de vérification omise) :

sprintf(mem_file_name, "/proc/%d/mem", pid);
mem_fd = open(mem_file_name, O_RDONLY);
ptrace(PTRACE_ATTACH, pid, NULL, NULL);
waitpid(pid, NULL, 0);
lseek(mem_fd, offset, SEEK_SET);
read(mem_fd, buf, _SC_PAGE_SIZE);
ptrace(PTRACE_DETACH, pid, NULL, NULL);

J'ai déjà posté un script de preuve de concept pour vider /proc/$pid/mem sur un autre fil.