Por qué usar NotHoly para CTFs y laboratorios

Un capture the flag o un laboratorio en casa es donde aprendes haciendo, y un modelo que se niega a escribir el exploit para un reto de pwn en tu propia máquina virtual no ayuda en nada. NotHoly acepta el reto, explica por qué el bug es un bug, y escribe el script de solve que corre en tu lab. Es un tutor que no para en la parte interesante. La abliteración es por qué el rechazo no estorba, y el resto de esto es dónde encaja en un CTF y un lab.

#El reto, y el porqué detrás

Pega un fragmento vulnerable, la descripción de un reto o una petición capturada, y el modelo nombra la clase del bug, explica la primitiva, y traza un enfoque: un format string que filtra, un overflow más allá de un puntero guardado, un parámetro web que llega a un template, un nonce débil. Pídele ir más allá y escribe el solve: un script de pwntools, un exploit pequeño, un payload para la fase web, una comprobación en Python para la cripto. Como el modelo lee en busca de la vulnerabilidad sin sermón, una tarea de rev, pwn, web o cripto se trabaja como cualquier otro código, y puedes pedirle que explique cada paso para terminar el reto sabiendo por qué funcionó. Guarda el reto entero en una conversación, así que el leak que encontraste en la fase uno sigue ahí cuando lo necesitas en la fase tres.

#Triar el binario, pegar el web, scriptar el solve

Adjunta el binario del reto y las herramientas estáticas te dan el SHA-256, la entropía, el formato, las secciones, los imports, las strings y una vista previa de disassembly, lo bastante para planear antes de abrir el debugger. La base de conocimiento trae técnica de PayloadsAllTheThings, GTFOBins y las guías de OWASP con una fuente en cada pasaje, así que un truco que recuerdas a medias viene con una referencia. Una versión de servicio en el reto va a un lookup de CVE con CVSS y referencias. La referencia de archivos lista los formatos. Para un reto web o de cripto no hay binario que adjuntar, así que pegas el handler, el token o el ciphertext y el modelo trabaja desde eso, y un diccionario de CWE y CAPEC en la base de conocimiento ayuda a nombrar la clase de debilidad que estás viendo en vez de adivinar, con el aviso de copyright que MITRE exige mantenido en el pasaje.

notholy analyze ./challenge

#Corre en tu lab, no en el nuestro

El exploit corre donde corre el lab: tu máquina, tu máquina virtual, tu contenedor. Los servidores de NotHoly nunca ejecutan nada ni envían tráfico a ningún lado, así que el script de solve que escribió el modelo es tuyo para correr contra tu propio objetivo. Desde la terminal el agente lee los archivos, corre el script y lee la salida, preguntando antes de cada comando, así que ves cada paso. La CLI y el chat comparten la misma cuenta, así que pasas de leer a correr sin cambiar de herramienta. Créditos que no caducan y una promoción que a veces deja un modelo gratis encajan en cómo trabajan estudiantes y jugadores solos, en ráfagas alrededor de un evento.

checksec ./challenge | notholy "explain each protection and sketch a solve approach for the overflow"

#Dónde no encaja

Puede equivocarse y mandarte por un callejón sin salida, así que un camino sugerido es una hipótesis por probar, no la respuesta. Dejar que resuelva todo enseña menos que pelear primero y preguntar después, que es el punto de un lab. Algunos CTFs prohíben herramientas externas o IA durante el evento, y esa es la regla del organizador que seguir, no nuestra para pasar por alto. No hay decompilador ni grafo de flujo de control de nuestro lado, así que el reversing pesado aún necesita tus herramientas. La cuenta necesita un correo, y un chat guardado conserva el write-up salvo que lo hagas efímero.

Úsalo para entender el reto, no para saltarlo. Los créditos no caducan y una recarga en precios es pequeña, así que un presupuesto de estudiante rinde mucho.