Registros, la pila y por qué existe un desbordamiento de búfer

Dentro del procesador hay un puñado de casillas de memoria muy rápidas y muy pequeñas, con nombre fijo: en una muestra de 32 bits se llaman EAX, EBX, ECX... y en una de 64 bits, RAX, RBX, RCX... Cada una guarda un solo valor a la vez —un número, una dirección, un resultado— mientras el procesador trabaja. Cuando el listado de M-2411 dice que una función «mueve un valor a EAX y lo compara con cero», está describiendo exactamente eso: una casilla que recibe un dato para que la siguiente instrucción lo use.

No hace falta memorizar qué guarda cada registro. Para leer un informe basta con saber que son el escritorio de trabajo del procesador: chico, siempre a mano, y vacío de significado hasta que una instrucción lo llena.

La pila (stack) es una franja de memoria que un programa usa como una torre de bandejas: lo último que se pone es lo primero que se quita. Cuando una función llama a otra, apila ahí la dirección a la que debe volver al terminar, y suele apilar también sus datos de trabajo mientras dura esa llamada. El puntero de pila (ESP en 32 bits, RSP en 64 bits) es el registro que siempre apunta a la bandeja de arriba: la próxima que se va a usar o a quitar.

Esto explica una frase que aparece en informes de este tipo: «la función vuelve a la dirección equivocada». Si la dirección de retorno que estaba apilada cambia antes de que la función termine, el programa no vuelve a donde debía, vuelve a donde quedó escrito.

Un búfer es un espacio reservado de tamaño fijo para guardar un dato: por ejemplo, 50 casillas para un nombre. Un desbordamiento de búfer ocurre cuando un programa escribe en ese espacio más datos de los que reservó, y lo que sobra no desaparece: cae en la memoria de al lado, que puede ser otra variable o, si el búfer vive en la pila, la propia dirección de retorno que vimos en la tarea anterior.

Esto es el concepto, no la técnica para explotarlo: en esta ruta no se construye un programa vulnerable ni se escribe un dato pensado para pisar esa dirección. Lo que hace falta es reconocer la frase cuando aparece en un informe de un tercero y entender qué está describiendo: un programa que no comprobó el tamaño de lo que escribía, y una zona de memoria vecina que terminó con un valor que nadie puso ahí a propósito.

Cuando el búfer que se desborda vive en la pila, justo al lado puede estar la dirección de retorno que la tarea 2 explicó. Si el desbordamiento alcanza a pisarla con otro valor, el programa, al terminar esa función, no vuelve a donde debía: salta a la dirección que quedó escrita encima. Eso es lo que un informe quiere decir cuando habla de «control del flujo de ejecución»: no que alguien «hackeó mágicamente» el programa, sino que una escritura sin control cambió un dato muy concreto del que depende hacia dónde salta el procesador.

Esto es el límite de lo que esta ruta enseña: entender por qué una dirección de retorno pisada es grave. Construir ese dato a propósito, calcular direcciones o encadenar instrucciones para que el salto termine en un sitio útil para un atacante es trabajo de explotación, y queda fuera de una ruta defensiva.

Shellcode es el nombre que recibe un bloque pequeño de instrucciones de máquina, listo para ejecutarse directamente, que un atacante intenta meter en la memoria de un programa vulnerable —por ejemplo, aprovechando un desbordamiento como el de la tarea 3— para que el procesador termine saltando a él. El nombre viene de su objetivo clásico: abrir una consola de comandos (shell) en el equipo de la víctima, aunque hoy un shellcode puede hacer cualquier otra cosa.

Para este oficio, el shellcode no se escribe ni se analiza instrucción a instrucción: se reconoce como una pieza más del informe, con el mismo criterio de las salas anteriores de este módulo. Un informe que dice «se identificó shellcode en el volcado de memoria» está afirmando una observación concreta —un bloque de instrucciones ejecutables apareció donde no debería haber más que datos—, no un veredicto sobre toda la muestra. Y, como con las capacidades de la tarea anterior, conviene preguntar: ¿eso se observó ejecutándose, o solo está presente en el archivo?