Por qué los "aspirantes a hackers" abandonan (y cómo evitarlo)

Abrís un tutorial sobre exploits porque viste un video llamativo o leíste una historia espectacular, y enseguida te encontrás con código en C, dumps hexadecimales y ensamblador que parecen otro idioma. 

Esa mezcla de fascinación y confusión es la escena más común: mucha gente llega directamente a la parte más vistosa del hacking sin que le hayan dado las herramientas para entenderla, y termina frustrada cuando no puede reproducir lo que vio o cuando los ejemplos no funcionan en su entorno.

El problema tiene dos caras: algunos se sienten sobrepasados porque les faltan las bases que sostienen lo avanzado; otros se paralizan al ver todo lo que “deberían” saber antes de empezar y abandonan de una. 

No es una cuestión de talento, sino de secuencia y método. En este post te voy a mostrar por qué la formación fundacional importa, cómo leer un mapa de aprendizaje que no intimide y qué pasos prácticos tomar si querés avanzar —por ejemplo hacia exploit dev— sin dejar los pedazos en el camino.

SANS, una de las instituciones más reconocidas (y ridículamente costosa) a nivel mundial en ciberseguridad, plantea de manera muy clara cómo deberían estructurarse las rutas de aprendizaje. En su roadmap se ve que antes de llegar a áreas avanzadas como el desarrollo de exploits, es necesario pasar por etapas previas: fundamentos técnicos, comprensión del sistema operativo, seguridad básica, y recién después avanzar hacia operaciones ofensivas y especializaciones. Esta visión ordenada sirve para entender que nadie empieza de la derecha del mapa; todo camino sólido se construye desde la base.

Te lo resumo en dos párrafos por si tenés síndrome de Tik-Tok.

Primero, lo qué conviene dominar antes de meterse en exploit dev: manejo práctico de C para entender cómo se gestionan buffers y punteros, un conocimiento funcional de la memoria (qué hace el stack y qué hace el heap), nociones básicas de ensamblador para reconocer lo que el compilador genera, y la capacidad para usar un debugger y observar el estado de un programa en ejecución. No hace falta ser un experto en todo esto desde el minuto uno, pero sí tener la habilidad de crear o modificar un pequeño programa en C y poder seguir su ejecución paso a paso en GDB.

Segundo, cómo hacerlo sin quemarse: priorizá la práctica sobre la teoría larga. Enfocate en ejercicios que te obliguen a ver el efecto real —compilar con y sin protecciones, ejecutar bajo GDB, observar la pila— y no en consumir más tutoriales pasivos. Armá una rutina corta y constante: media hora diaria resolviendo un pequeño reto o modificando un binario propio vale mucho más que horas de videos seguidos. Como estoy seguro que ya estas pensando que armar esa rutina es un viaje te la ofrezco pronta en los próximos párrafos.

Así que te voy a dejar la agenda que vamos a seguir de ahora en más en las próximas semanas para que aún sin todo el conocimiento puedas mantenerte motivado practicando lo básico. Te propongo 1 mes de entrenamiento no más de 3 horas al día, lo único que tenés que hacer es dejar pelotudear en tik-tok y en Instagram por un rato y dedicarle el tiempo a esto.

Semana 1 – Familiarizarse con el entorno

Instalá una VM con Linux (puede ser Ubuntu o Debian) y configurá gcc y gdb. Escribí un programa en C que imprima “Tik-tok apesta”, compilalo y corrélo. Luego abrilo en gdb, ejecutalo y usá un par de comandos básicos como run, break main e info registers. El objetivo de esta semana es simple: perderle el miedo al entorno y entender que podés controlar un programa en ejecución.

Semana 2 – Memoria y desbordamientos básicos

Escribí un programa en C con un buffer (char buff[16];) que lea datos con gets. Alimentalo con entradas cortas y largas para ver qué pasa. Volvé a gdb y fijate cómo cambia el contenido de la pila al pasar más datos de los que el buffer soporta. El objetivo es visualizar con tus propios ojos un desbordamiento y relacionarlo con la estructura de la memoria.

Semana 3 – Compilación con y sin protecciones

Tomá el programa de la semana anterior y compilalo de dos formas: normal, y con opciones que desactiven protecciones (-fno-stack-protector -z execstack -no-pie). Compará la ejecución en gdb en ambos casos. Buscá qué cambia: ¿se permite ejecutar código en la pila? ¿aparecen errores distintos? El objetivo es entender qué hacen las defensas modernas y por qué existen.

Semana 4 – Primer exploit mínimo

Creá un programa vulnerable (buffer overflow con gets) y escribí un payload sencillo que modifique el flujo (por ejemplo, forzar que imprima un mensaje secreto o salte a otra función en el mismo binario). Usá gdb para guiarte. No busques todavía un shell remoto: el objetivo es probar que con entradas controladas podés alterar el comportamiento del programa.

Así que si realmente te comprometés, volvé la semana que viene y vas a encontrar el primer ejercicio completo.

¿Te veo la próxima semana?