Por que usar a NotHoly para CTFs e laboratórios

Um capture the flag ou um laboratório em casa é onde você aprende fazendo, e um modelo que recusa escrever o exploit para um desafio de pwn na sua própria máquina virtual não ajuda em nada. A NotHoly aceita o desafio, explica por que o bug é um bug, e escreve o script de solve que roda no seu lab. É um tutor que não para na parte interessante. A abliteration é a razão de a recusa não atrapalhar, e o resto disto é onde ela encaixa num CTF e num lab.

#O desafio, e o porquê por trás

Cole um trecho vulnerável, a descrição de um desafio ou uma requisição capturada, e o modelo nomeia a classe do bug, explica a primitiva, e traça uma abordagem: uma format string que vaza, um overflow além de um ponteiro salvo, um parâmetro web que chega a um template, um nonce fraco. Peça para ir além e ele escreve o solve: um script de pwntools, um exploit pequeno, um payload para a fase web, uma checagem em Python para a cripto. Como o modelo lê em busca da vulnerabilidade sem sermão, uma tarefa de rev, pwn, web ou cripto é trabalhada como qualquer outro código, e você pode pedir que ele explique cada passo para terminar o desafio sabendo por que funcionou. Ele guarda o desafio inteiro numa conversa, então o leak que você achou na fase um ainda está lá quando você precisa dele na fase três.

#Triar o binário, colar o web, scriptar o solve

Anexe o binário do desafio e as ferramentas estáticas te dão o SHA-256, a entropia, o formato, as seções, os imports, as strings e uma prévia de disassembly, o bastante para planejar antes de abrir o debugger. A base de conhecimento traz técnica do PayloadsAllTheThings, do GTFOBins e dos guias da OWASP com uma fonte em cada trecho, então um truque que você lembra pela metade vem com uma referência. Uma versão de serviço no desafio vai para um lookup de CVE com CVSS e referências. A referência de arquivos lista os formatos. Para um desafio web ou de cripto não há binário para anexar, então você cola o handler, o token ou o ciphertext e o modelo trabalha a partir disso, e um dicionário de CWE e CAPEC na base de conhecimento ajuda a nomear a classe de fraqueza que você está vendo em vez de chutar, com o aviso de copyright que a MITRE exige mantido no trecho.

notholy analyze ./challenge

#Roda no seu lab, não no nosso

O exploit roda onde o lab roda: a sua máquina, a sua máquina virtual, o seu container. Os servidores da NotHoly nunca executam nada nem mandam tráfego a lugar nenhum, então o script de solve que o modelo escreveu é seu para rodar contra o seu próprio alvo. Do terminal o agente lê os arquivos, roda o script e lê a saída, perguntando antes de cada comando, então você acompanha cada passo. A CLI e o chat compartilham a mesma conta, então você vai da leitura à execução sem trocar de ferramenta. Créditos que não expiram e uma promoção que às vezes deixa um modelo grátis encaixam no jeito que estudantes e jogadores solo trabalham, em rajadas em torno de um evento.

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

#Onde não encaixa

Ele pode errar e te mandar por um caminho sem saída, então um caminho sugerido é uma hipótese para testar, não a resposta. Deixar ele resolver tudo ensina menos do que ralar primeiro e perguntar depois, que é o ponto de um lab. Alguns CTFs proíbem ferramentas externas ou IA durante o evento, e essa é a regra do organizador para seguir, não nossa para passar por cima. Não há decompilador nem grafo de fluxo de controle do nosso lado, então reversing pesado ainda precisa das suas ferramentas. A conta precisa de um e-mail, e um chat salvo guarda o write-up a menos que você o torne efêmero.

Use para entender o desafio, não para pular. Créditos não expiram e um aporte em preços é pequeno, então um orçamento de estudante rende bastante.