Skip to content
shellcodes

Los bytes nulos todavía rompen exploits en 2026

Por qué 0x00 corta entregas tipo strcpy, cómo aparece en structs reverse TCP y cómo comprobar codificadores.

Publicado el 3 min de lectura

restricciones 0x00, truncado estilo strcpy, escaneo de bad chars y efectos secundarios de encoders no son temas abstractos. Aparecen cuando un laboratorio autorizado deja la demo limpia y toca un binario real, con un parser real, una ruta de red real y un informe que alguien revisará dentro de dos meses.

El error común es confiar en un encoder porque quitó un nulo aunque introdujo un salto de línea o aumentó demasiado el tamaño. Es aburrido, y por eso sobrevive. Parece una hipótesis sin comprobar en el builder, un valor copiado de la VPN de ayer o una secuencia de bytes pegada a través de una herramienta que reescribe texto.

Por qué importa en un laboratorio real

El trabajo con shellcode es trabajo a nivel de byte. El exploit no sabe que la interfaz parecía correcta. Ejecuta los bytes que llegaron a memoria. Si el payload cruza una shell, un formulario web, un cuerpo JSON, el scrollback del terminal o un ticket, ya no tienes un solo problema. Tienes el payload más cada parser del camino.

Prefiero comprobaciones explícitas antes que confianza: tamaño esperado, bytes prohibidos, OS objetivo, arquitectura, familia de payload, formato de exportación y hash final. Cuando algo falla, las notas deben reducir la búsqueda, no abrir otra discusión.

Un flujo que aguanta el contacto con herramientas

Start from the smallest thing that proves the primitive. Then add constraints.


python3 check-null-bytes.py payload.bin

Ese comando no es todo el flujo. Es un ancla. Alrededor, conserva un blob conocido, su SHA-256 y la configuración exacta del builder. Si cambias LHOST, LPORT, orden de encoders, lista de bad chars o formato de exportación, trata el resultado como un artefacto nuevo.

Fallos que merece la pena probar

El patrón de fallo que busco es un payload que se ejecuta solo hasta el primer cero, una longitud mal documentada o un exploit que cambia tras pegarlo. Pruébalo antes de integrar si puedes. Un payload que falla en un harness pequeño cuesta menos que uno que falla dentro de un intento ruidoso contra un entorno monitorizado. No ignores la longitud. Los fallos de tamaño se camuflan bien: el payload sigue pareciendo shellcode, solo que ya no cabe en la primitiva disponible.

Qué deberían ver los defensores

Desde defensa, el generador rara vez es la señal importante. Lo es el comportamiento. Busca egress inesperado, genealogías raras de procesos, transiciones a memoria ejecutable, buffers de tamaño payload y crashes repetidos cerca del mismo offset.

Notas de runbook

Guarda la configuración separada de los bytes crudos cuando la política lo exija, pero conserva detalle suficiente para regenerar exactamente. Un runbook útil incluye referencia de alcance, contexto del objetivo, restricciones, hash y una nota corta sobre por qué se eligió esa familia de payload. Sin magia. Solo menos sitios donde esconder errores.

Artículos relacionados

Ejemplos de shellcode comentados para Linux x86 y x64 —execve /bin/sh y reverse TCP— con los bytes, el desensamblado y las trampas.
Cómo funciona el shellcode en Linux —syscalls, registros y código independiente de posición— y cómo ensamblarlo, codificarlo y probarlo de forma segura.
Shellcode explicado: qué es, por qué lo usan los exploits, cómo se escribe y codifica, y cómo generarlo y probarlo de forma segura en tu navegador.