En algún momento de tu vida es probable que hayas visto una película que tiene esta escena tensa donde el personaje tiene que desactivar una bomba o que va a morir. O cuando estas jugado demasiado Counter Strike en una lucha contra el terrorismo y tuviste que hacer lo mismo en el juego.
Estas escenas son emocionantes verdad? Podría ser una buena experiencia tratar de desactivar una bomba, el unico problema es que podría matarte en la vida real si no lo logras. Nosotros tenemos la suerte de que podemos desactivar una bomba sin correr el riesgo de morir.
En esta serie de posts (solo si llega a gustar a un determinado numero de personas) te mostrare cómo podemos desactivar una bomba binaria. Pero para empezar, ¿qué es una bomba binaria?
Una "bomba binaria" es un programa de C ejecutable de Linux que consta de seis "fases". Cada fase espera que el estudiante entre en una cadena particular de caracteres. Si el estudiante teclea la cadena decaracteres esperada, entonces esa fase se considera "desactivada". De lo contrario la bomba "explota" imprimiendo "BOOM !!!". La meta para los estudiantes es desactivar tantas fases como sea posible.
He encontrado este tipo de bomba en el sitio web para el excelente libro "Sistemas informáticos: La perspectiva de un programador".
Las herramientas básicas necesarias para desactivar tales bombas son gdb y objdump. gdb es un depurador que vamos a utilizar para inspeccionar el programa como lo ejecutamos. objdump es una herramienta para desensamblar archivos executables que nos permite poder ver las instrucciones reales que el equipo está ejecutando.
Este post no pretende ser un tutorial sobre gdb porque esta es mi primera vez usandolo.
La "bomba" binaria la pueden descargar desde este
http://csapp.cs.cmu.edu/3e/bomb.tar
Una vez que hayamos descomprimido el archivo con tar (tar -xvf bomb.tar) nos queda lo siguiente:
En cuanto abrimos bomb.c (abrelo con less bomb.c) vemos muchos comentarios y cómo es que todo está configurado. Puedes pasar el archivo como argumento para evitar tener que escribir cada vez que la entrada correcta para las fases que ya estan desactivadas.
A continuación tenemos que echar un vistazo a el archivo ejecutable bomb que son datos binarios por lo que no se ve nada interesante si lo abrimos usando less o cualquier otro editor que utilices. Y es por eso que necesitamos objdump para desensamblar el archivo ejecutable.
Si echamos un vistazo a las primeras lineas del archivo veremos lo siguiente:
Asi es como un archivo ELF se ve desensamblado. Veamos como se ve la funcion main del archivo:
Antes de empezar el análisis de la función tenemos que entender la estructura de cada línea. Vamos a tomar la línea siguiente como ejemplo:
Podemos separar esta línea en tres secciones:
Las primeras líneas en la función principal corresponden al código C que comprueba si pasamos un archivo como argumento para el programa. Nos saltamos esas líneas y comenzamos a ver la parte interesante:
Esta línea dice que la function initialize_bomb debe ser llamada. La línea correspondiente en el archivo C es la siguiente:
Veamos ahora la funcion initialize_bomb
Inspeccionando los valores no nos revelan nada interesante. Sigamos avanzando. Las siguientes líneas después initialize_bomb en la función main corresponden a las siguientes líneas en el archivo C:
Estas son las lineas que imprimen los mensajes a la consola y leen lo que el usuario escriba. Entonces es el momento de desactivar la primera fase.
Otra ves, esta linea hace una llamada a la funcion phase_1 localizada en 0x400ee0. Vamos a ver como se ve la primera fase:
Ahora notemos que sobre 0x400ee4 que el valor en 0x402400 se copia en el registro esi. El registro esi se utiliza por lo general como el registro de el segundo argumento de una función a la cual se hara mas tarde. En nuestro caso, la función se llama inmediatamente después de la instrucción mov. Es posible que entonces nos preguntemos: ¿dónde está el primer argumento? El primer argumento se suele colocar en el Registro edi que en este caso será la frase o cadena de caracteres que proporcionamos como entrada. Si vemos ahora la function main:
El valor de retorno (almacenado en rax) de la función read_line se ha colocado en el registro rdi (edi es un registro de 32 bits y rdi es su equivalente pero de 64 bits) y se utilizará como primer argumento para la función que sera llamada despues, que en este caso es phase_1. Y eso es exactamente lo que el código C está haciendo:
Ok, de vuelta a la función phase_1. Ahora sabemos cuales son los argumentos dados a strings_not_equal y después de ejecutar esta función hay una prueba para comprobar el resultado:
La instrucción de prueba hara una comparacion AND bit a bit entre sus operandos y establecer a los indicadores apropiados en el registro eflags. La instrucción je es una instrucción de salto condicional que va a la ubicación especificada sólo si la comparación anterior establece el ZF (Zero Flag) a 1 en el registro eflags.
Así que la instrucción de prueba pondra ZF a 1 sólo cuando tenemos 0 en eax que pasara solo cuando strings_not_equal nos regresa un 0. (Examinando strings_not_equal revela nada interesante que es exactamente lo que esperas de una función con ese nombre. Nos devolvera 1 si ambos argumentos no son iguales y 0 en caso contrario).
Si las cadenas de caracteres no son iguales no se realizará el salto condicional y entonces la siguiente línea que se ejecutará sera la que va a explotar la bomba. Si las cadenas de caracteres son iguales saltamos a 0x400eef7 y regresara a la funcion main:
Bueno, ahora sabemos que la primera fase nos obliga a teclear una cadena de caracteres que no sabemos. ¿Cómo vamos a descubrir qué cadena es? Tenemos que comenzar a ejecutar el programa. Pero en este caso, en lugar de ejecutar como siempre lo hacemos, vamos a ejecutarlo con gdb. gdb nos ayudará a inspeccionar los valores y descubrir cual es esa misteriosa cadena de caracteres.
La línea anterior comienza gdb con el programa de la bomba, por lo que puede ejecutar el programa de la bomba e inspeccionar los valores, establecer puntos de interrupción, etc. En este caso, ya lo hemos hecho casi todo el trabajo al examinar únicamente el código ensamblador y sabemos que la misteriosa cadena se encuentra en la dirección 0x402400 (cuando fue cargado en el registro esi en la dirección 0x400ee4). Para ver cuál es el valor de la misma podemos simplemente pedirselo a gdb para imprimir el valor en la dirección deseada y tratarlo como secuencia de char (caracteres):
Y ahi la tenemos! Ahora ejecutamos el programa:
Y ahora copiamos la cadena de caracteres que vimos anteriormente .
Y eso es todo para la fase 1 de desactivar la bomba, quisiera seguir posteando las demas fases pero primero quisiera ver a cuanta gente le gusto mi post y ver si vale la pena el trabajo de explicar las siguientes fases.
Que tengan buen dia!
Estas escenas son emocionantes verdad? Podría ser una buena experiencia tratar de desactivar una bomba, el unico problema es que podría matarte en la vida real si no lo logras. Nosotros tenemos la suerte de que podemos desactivar una bomba sin correr el riesgo de morir.
En esta serie de posts (solo si llega a gustar a un determinado numero de personas) te mostrare cómo podemos desactivar una bomba binaria. Pero para empezar, ¿qué es una bomba binaria?
Una "bomba binaria" es un programa de C ejecutable de Linux que consta de seis "fases". Cada fase espera que el estudiante entre en una cadena particular de caracteres. Si el estudiante teclea la cadena decaracteres esperada, entonces esa fase se considera "desactivada". De lo contrario la bomba "explota" imprimiendo "BOOM !!!". La meta para los estudiantes es desactivar tantas fases como sea posible.
He encontrado este tipo de bomba en el sitio web para el excelente libro "Sistemas informáticos: La perspectiva de un programador".
Las herramientas básicas necesarias para desactivar tales bombas son gdb y objdump. gdb es un depurador que vamos a utilizar para inspeccionar el programa como lo ejecutamos. objdump es una herramienta para desensamblar archivos executables que nos permite poder ver las instrucciones reales que el equipo está ejecutando.
Este post no pretende ser un tutorial sobre gdb porque esta es mi primera vez usandolo.
La "bomba" binaria la pueden descargar desde este
http://csapp.cs.cmu.edu/3e/bomb.tar
Una vez que hayamos descomprimido el archivo con tar (tar -xvf bomb.tar) nos queda lo siguiente:
En cuanto abrimos bomb.c (abrelo con less bomb.c) vemos muchos comentarios y cómo es que todo está configurado. Puedes pasar el archivo como argumento para evitar tener que escribir cada vez que la entrada correcta para las fases que ya estan desactivadas.
A continuación tenemos que echar un vistazo a el archivo ejecutable bomb que son datos binarios por lo que no se ve nada interesante si lo abrimos usando less o cualquier otro editor que utilices. Y es por eso que necesitamos objdump para desensamblar el archivo ejecutable.
Si echamos un vistazo a las primeras lineas del archivo veremos lo siguiente:
Asi es como un archivo ELF se ve desensamblado. Veamos como se ve la funcion main del archivo:
Antes de empezar el análisis de la función tenemos que entender la estructura de cada línea. Vamos a tomar la línea siguiente como ejemplo:
Podemos separar esta línea en tres secciones:
- 400db6: la dirección del código que estamos viendo.
- 48 89 f3: la instrucción codificada.
- mov% rsi, rbx%: la instrucción descodificada.
Las primeras líneas en la función principal corresponden al código C que comprueba si pasamos un archivo como argumento para el programa. Nos saltamos esas líneas y comenzamos a ver la parte interesante:
Esta línea dice que la function initialize_bomb debe ser llamada. La línea correspondiente en el archivo C es la siguiente:
Veamos ahora la funcion initialize_bomb
Inspeccionando los valores no nos revelan nada interesante. Sigamos avanzando. Las siguientes líneas después initialize_bomb en la función main corresponden a las siguientes líneas en el archivo C:
Estas son las lineas que imprimen los mensajes a la consola y leen lo que el usuario escriba. Entonces es el momento de desactivar la primera fase.
Otra ves, esta linea hace una llamada a la funcion phase_1 localizada en 0x400ee0. Vamos a ver como se ve la primera fase:
Ahora notemos que sobre 0x400ee4 que el valor en 0x402400 se copia en el registro esi. El registro esi se utiliza por lo general como el registro de el segundo argumento de una función a la cual se hara mas tarde. En nuestro caso, la función se llama inmediatamente después de la instrucción mov. Es posible que entonces nos preguntemos: ¿dónde está el primer argumento? El primer argumento se suele colocar en el Registro edi que en este caso será la frase o cadena de caracteres que proporcionamos como entrada. Si vemos ahora la function main:
El valor de retorno (almacenado en rax) de la función read_line se ha colocado en el registro rdi (edi es un registro de 32 bits y rdi es su equivalente pero de 64 bits) y se utilizará como primer argumento para la función que sera llamada despues, que en este caso es phase_1. Y eso es exactamente lo que el código C está haciendo:
Ok, de vuelta a la función phase_1. Ahora sabemos cuales son los argumentos dados a strings_not_equal y después de ejecutar esta función hay una prueba para comprobar el resultado:
La instrucción de prueba hara una comparacion AND bit a bit entre sus operandos y establecer a los indicadores apropiados en el registro eflags. La instrucción je es una instrucción de salto condicional que va a la ubicación especificada sólo si la comparación anterior establece el ZF (Zero Flag) a 1 en el registro eflags.
Así que la instrucción de prueba pondra ZF a 1 sólo cuando tenemos 0 en eax que pasara solo cuando strings_not_equal nos regresa un 0. (Examinando strings_not_equal revela nada interesante que es exactamente lo que esperas de una función con ese nombre. Nos devolvera 1 si ambos argumentos no son iguales y 0 en caso contrario).
Si las cadenas de caracteres no son iguales no se realizará el salto condicional y entonces la siguiente línea que se ejecutará sera la que va a explotar la bomba. Si las cadenas de caracteres son iguales saltamos a 0x400eef7 y regresara a la funcion main:
Bueno, ahora sabemos que la primera fase nos obliga a teclear una cadena de caracteres que no sabemos. ¿Cómo vamos a descubrir qué cadena es? Tenemos que comenzar a ejecutar el programa. Pero en este caso, en lugar de ejecutar como siempre lo hacemos, vamos a ejecutarlo con gdb. gdb nos ayudará a inspeccionar los valores y descubrir cual es esa misteriosa cadena de caracteres.
La línea anterior comienza gdb con el programa de la bomba, por lo que puede ejecutar el programa de la bomba e inspeccionar los valores, establecer puntos de interrupción, etc. En este caso, ya lo hemos hecho casi todo el trabajo al examinar únicamente el código ensamblador y sabemos que la misteriosa cadena se encuentra en la dirección 0x402400 (cuando fue cargado en el registro esi en la dirección 0x400ee4). Para ver cuál es el valor de la misma podemos simplemente pedirselo a gdb para imprimir el valor en la dirección deseada y tratarlo como secuencia de char (caracteres):
Y ahi la tenemos! Ahora ejecutamos el programa:
Y ahora copiamos la cadena de caracteres que vimos anteriormente .
Y eso es todo para la fase 1 de desactivar la bomba, quisiera seguir posteando las demas fases pero primero quisiera ver a cuanta gente le gusto mi post y ver si vale la pena el trabajo de explicar las siguientes fases.
Que tengan buen dia!