GDB: lista de todas las regiones de memoria asignadas para un proceso bloqueado

5 minutos de lectura

Tengo un volcado de núcleo completo de un proceso inactivo en una máquina Linux x86 (kernel 2.6.35-22 si es importante), que estoy intentando depurar en GDB.

¿Hay algún comando GDB que pueda usar que signifique “muéstrame una lista de todas las regiones de direcciones de memoria asignadas por este proceso?” En otras palabras, ¿puedo averiguar cuáles son todas las posibles direcciones de memoria válidas que puedo examinar en este volcado?

La razón por la que pregunto es porque necesito buscar en el montón de proceso completo para una cierta cadena binaria, y con el fin de utilizar el find comando, necesito tener una dirección inicial y final. Simplemente buscar de 0x00 a 0xff… no funciona porque find se detiene tan pronto como encuentra una dirección a la que no puede acceder:

(gdb) busque /w 0x10000000, 0xff000000, 0x12345678

advertencia: no se puede acceder a la memoria de destino en 0x105ef883, deteniendo la búsqueda.

Entonces, necesito obtener una lista de todas las regiones de direcciones legibles en la memoria para poder buscarlas una a la vez.

(La razón por la que necesito hacer que es que necesito encontrar todas las estructuras en la memoria que apuntan en cierta dirección.)

Ninguno de show mem, show proc, info mem, info proc parece hacer lo que necesito.

avatar de usuario
Ruso empleado

En GDB 7.2:

(gdb) help info proc
Show /proc process information about any running process.
Specify any process id, or use the program being debugged by default.
Specify any of the following keywords for detailed info:
  mappings -- list of mapped memory regions.
  stat     -- list a bunch of random process info.
  status   -- list a different bunch of random process info.
  all      -- list all available /proc info.

Usted quiere info proc mappingsexcepto que no funciona cuando no hay /proc (como durante la depuración pos-mortem).

Tratar maintenance info sections en lugar de.

  • Esa es una de las primeras cosas que probé, pero parece estar vacío (no hay nada debajo de la fila del encabezado). ¿Tal vez simplemente no funciona para volcados de núcleo?

    – Crashworks

    17 de abril de 2011 a las 4:52

  • maintenance info sections parece ser mucho más portátil y debería ser la respuesta principal aquí.

    – phihag

    23 de febrero de 2012 a las 11:56

  • Si está depurando un proceso en vivo, también puede obtener/verificar esta información de cat /proc/<pid>/maps

    -Nathan Kidd

    25 de noviembre de 2013 a las 16:42

  • @phihag Eso se convirtió en una respuesta. Comentario redundante ahora.

    – usuario202729

    24 de junio de 2018 a las 5:38

  • info proc mappings trabajó para mi. La versión PWNDGB es vmmaps.

    – Lennihein

    8 de febrero de 2021 a las 22:22

Si tiene el programa y el archivo principal, puede realizar los siguientes pasos.

1) Ejecute el gdb en el programa junto con el archivo central

 $gdb ./test core

2) escriba archivos de información y vea qué diferentes segmentos hay en el archivo central.

    (gdb)info files

Una salida de muestra:

    (gdb)info files 

    Symbols from "/home/emntech/debugging/test".
    Local core dump file:
`/home/emntech/debugging/core', file type elf32-i386.
  0x0055f000 - 0x0055f000 is load1
  0x0057b000 - 0x0057c000 is load2
  0x0057c000 - 0x0057d000 is load3
  0x00746000 - 0x00747000 is load4
  0x00c86000 - 0x00c86000 is load5
  0x00de0000 - 0x00de0000 is load6
  0x00de1000 - 0x00de3000 is load7
  0x00de3000 - 0x00de4000 is load8
  0x00de4000 - 0x00de7000 is load9
  0x08048000 - 0x08048000 is load10
  0x08049000 - 0x0804a000 is load11
  0x0804a000 - 0x0804b000 is load12
  0xb77b9000 - 0xb77ba000 is load13
  0xb77cc000 - 0xb77ce000 is load14
  0xbf91d000 - 0xbf93f000 is load15

En mi caso tengo 15 segmentos. Cada segmento tiene el inicio de la dirección y el final de la dirección. Elija cualquier segmento para buscar datos. Por ejemplo, seleccionemos load11 y busquemos un patrón. Load11 tiene la dirección de inicio 0x08049000 y termina en 0x804a000.

3) Busque un patrón en el segmento.

(gdb) find /w 0x08049000 0x0804a000 0x8048034
 0x804903c
 0x8049040
 2 patterns found

Si no tiene un archivo ejecutable, debe usar un programa que imprima datos de todos los segmentos de un archivo central. Luego puede buscar un dato particular en una dirección. No encuentro ningún programa como tal, puede usar el programa en el siguiente enlace que imprime datos de todos los segmentos de un núcleo o un archivo ejecutable.

 http://emntech.com/programs/printseg.c

  • ¿Hay alguna forma de obtener gdb para buscar todos estos segmentos sin especificar manualmente cada uno?

    – microbio evolucionado

    17 de agosto de 2014 a las 14:31

  • Que printseg.c ya no está en ese sitio web. Tampoco está disponible en archive.org

    -Folkert van Heusden

    1 de diciembre de 2020 a las 15:43


(gdb) maintenance info sections 
Exec file:
    `/path/to/app.out', file type elf32-littlearm.
    0x0000->0x0360 at 0x00008000: .intvecs ALLOC LOAD READONLY DATA HAS_CONTENTS

Esto es del comentario de phihag anterior, merece una respuesta por separado. esto funciona pero info proc no en arm-none-eabi-gdb v7.4.1.20130913-cvs del paquete gcc-arm-none-eabi de Ubuntu.

También puedes usar info files para listar todas las secciones de todos los binarios cargados en el proceso binario.

Acabo de ver lo siguiente:

set mem inaccessible-by-default [on|off]

aquí

Podría permitirle buscar sin tener en cuenta si la memoria es accesible.

  • Hm, para mí en GDB 10.1 esto no funciona, desafortunadamente.

    – Gizmo

    23 de abril de 2021 a las 10:46

  • @Gizmo ¿Eso fue en x86? El enlace todavía describe esto como debería funcionar.

    – tothphu

    28 de abril de 2021 a las 4:30

  • Sí, depurando un objetivo x86.

    – Gizmo

    28 de abril de 2021 a las 7:59

el problema con maintenance info sections es que el comando intenta extraer información de la cabecera de la sección del binario. No funciona si el binario se dispara (por ejemplo, por sstrip) o da información incorrecta cuando el cargador puede cambiar el permiso de memoria después de la carga (por ejemplo, el caso de RELRO).

  • Hm, para mí en GDB 10.1 esto no funciona, desafortunadamente.

    – Gizmo

    23 de abril de 2021 a las 10:46

  • @Gizmo ¿Eso fue en x86? El enlace todavía describe esto como debería funcionar.

    – tothphu

    28 de abril de 2021 a las 4:30

  • Sí, depurando un objetivo x86.

    – Gizmo

    28 de abril de 2021 a las 7:59

¿Ha sido útil esta solución?

Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos y para mostrarte publicidad relacionada con sus preferencias en base a un perfil elaborado a partir de tus hábitos de navegación. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Configurar y más información
Privacidad