Orden de encoders: por qué la segunda pasada rompe la primera

orden de encoders, stubs de decodificación, presupuesto de tamaño, presión de registros y formato de exportación 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 apilar encoders hasta que el decoder supera el buffer y después culpar al binario objetivo. 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.

sha256sum 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 bucle de decode que no termina, un payload que ya no cabe o un bad char reintroducido al exportar. 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.