Qué te dice el visor hex antes de copiar shellcode

revisión hex, offsets, bad chars visibles, longitud, datos embebidos y diffs entre payloads 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 usar el botón copiar como control de calidad sin mirar offsets, ceros obvios o islas ASCII sospechosas. 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.

xxd -g1 payload.bin | less

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 una cola truncada, datos embebidos desplazados o un payload cambiado por un byte tras una edición inocente. 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.