Pregunta:
¿Cómo predecir las diferencias de diseño del espacio de direcciones entre ejecuciones reales y controladas por gdb?
perror
2013-10-30 16:15:40 UTC
view on stackexchange narkive permalink

Es algo que me desconcierta durante mucho tiempo. Puedo observar que hay una diferencia entre la ejecución real de un programa y la controlada por gdb .

Pero aquí hay un ejemplo:

  1. Primero, aquí está el código de ejemplo (usamos una variable automática para obtener la ubicación de la pila): 

      #include <stdio.h> # include <stdlib.h>int main ( ) {char c = 0; printf ("Dirección de la pila:% p \ n", &c); return EXIT_SUCCESS;}

  2. Luego, deshabilitamos el ASLR (usamos los indicadores de personalidad del proceso y no el método de todo el sistema a través de / proc / sys / kernel / randomize_va_space ): 

      $ > setarch ʻuname -m` -R / bin / bash

  3. Luego, ejecute en el entorno de memoria real: 

      Dirección de pila: 0x7fffffffe1df

  4. Y, el mismo a través de gdb:

      (gdb) r Programa de inicio: ./gdb-against-reality Dirección de pila: 0x7fffffffe17f [Inferior 1 (proceso 5374) salió normalmente] ( gdb)

Entonces, aquí tenemos una diferencia de 96 bytes entre las dos ejecuciones. Pero, ¿cómo puedo predecir esta diferencia para un programa dado sin que se ejecute en el diseño de memoria real (solo conociendo el diseño de memoria gdb )?

Y, además, ¿de dónde / qué viene esta diferencia?

Dos respuestas:
devttys0
2013-10-30 23:38:44 UTC
view on stackexchange narkive permalink

Podría haber otros factores involucrados, pero supongo que los cambios en las variables de entorno del proceso, que se almacenan en la pila, son lo que está causando este problema.

Ejecutar un pequeño programa que solo imprime las variables de entorno revela un par de variaciones en las variables de entorno cuando se ejecuta dentro o fuera de gdb en mi sistema. 

  int main (int argc, char ** argv, char ** envp) {char ** env; para (env = envp; * env! = 0; env ++) {char * thisEnv = * env; printf ("% s \ n", thisEnv); }}

Primero, cuando se ejecuta bajo gdb, hay una variable LINES que no está presente cuando el proceso se inicia fuera de gdb: 

  LINES = 83

En segundo lugar, la variable de entorno de subrayado es diferente. Cuando se ejecuta fuera de gdb, se establece en el nombre del ejecutable: 

  _ =. / Gdbtest

Pero cuando se inicia desde dentro de gdb, se establece en la ruta del binario gdb: 

  _ = / usr / bin / gdb

Puede intentar ejecutar el programa normalmente, luego adjuntar a él con gdb / gdbserver, que debería evitar estas variaciones en las variables de entorno (asumiendo que eso es de hecho lo que está causando su problema).

Si su proceso es de corta duración, puede ser difícil pausar el proceso antes de salir. Quizás alguien más tenga algunas buenas sugerencias sobre cómo iniciar un proceso en un estado de pausa; Por lo general, uso un segundo programa como este para detectar el proceso mientras se inicia y pausarlo para poder adjuntarle un depurador.

Esta respuesta sobre stackoverflow muestra cómo ejecutar gdb con un entorno controlado https://stackoverflow.com/a/17775966. Simplemente puede usar su script (recuerde ejecutar los comandos `unset` dentro de` gdb`)
perror
2017-08-10 14:02:45 UTC
view on stackexchange narkive permalink

Solo para agregar a las respuestas, puedo decir cómo acercarme a un entorno limpio a pesar de gdb . De hecho, hay dos métodos para llegar a esto:

  1. Podemos deshacernos de las variables de entorno adicionales agregadas por gdb de la siguiente manera: 

      (gdb) unset environment LINES (gdb) unset environment COLUMNS

    Escriba estos comandos antes de ejecutar el programa, y ​​debe estar cerca del entorno normal. Tenga en cuenta que todavía tiene que cuidar la variable _ .

  2. También se puede generar un núcleo de memoria del programa vulnerable y analizarlo con gdb : 

      $ > gdb vuln_program core

    Debería mirar la memoria y nunca ejecutar , next , step , ... porque hacerlo te obligará a reiniciar el programa con una memoria nueva (con el cambio).

Esos eran dos métodos que puedes usar con gdb para seguir un programa sin demasiadas diferencias con la ejecución real. ¡Pero son muchos otros!



ⓘ
Esta pregunta y respuesta fue traducida automáticamente del idioma inglés.El contenido original está disponible en stackexchange, a quien agradecemos la licencia cc by-sa 3.0 bajo la que se distribuye.
Loading...