Skip to content
KitploitKITPLOIT
FerramentasExploitsBlog
Log in
Enviar
FerramentasExploitsBlog
Enviar

Ferramentas de Hacking, PenTest e Cibersegurança para o seu Arsenal de Segurança!

Kitploit é um diretório de ferramentas de hacking, cibersegurança e pentesting. Descubra as últimas atualizações de projetos para encontrar vulnerabilidades, analisar sistemas, automatizar testes e fortalecer sua segurança.

··Feeds·Contato·Privacidade·© 2026 Kitploit

Diretório de Ferramentas

Categorias

Ver todas as categorias
Loading categories
VulnFanatic-NG — Plugin do BianryNinja para identificar vulnerabilidades em binários descompilados com varreduras programáticas e suporte a LLM. | Kitploit
Ferramentas/GitHubGitHub/martyx00/vulnfanatic-ng
Análise Estática de Código (SAST)Análise de VulnerabilidadesAnálise de CódigoExploraçãoEngenharia ReversaFuzzingTestes de PenetraçãoSegurança de HardwareAnálise de BináriosSegurança da Cadeia de SuprimentosAprendizado e EducaçãoEngenharia Reversa Assistida por IA
14115há 3 mesesAinda não revisado

Mais Populares

Ver todos →

Descubra as ferramentas mais usadas pela nossa comunidade.

Explore todas as ferramentas

Navegue pela nossa coleção de ferramentas

Ver todas as ferramentas →
Compartilhar
GitHubmartyx00/vulnfanatic-ng

VulnFanatic-NG

Plugin do BianryNinja para identificar vulnerabilidades em binários descompilados com varreduras programáticas e suporte a LLM.

Ver Repositório

VulnFanatic-NG

Pesquisa de vulnerabilidades assistida por LLM para Binary Ninja.

VulnFanatic-NG adiciona um painel lateral que analisa o binário atual e pergunta a uma LLM — um modelo compatível com OpenAI hospedado localmente por padrão, ou Anthropic Claude, Google Gemini, ou Azure OpenAI (veja Backends LLM) — para julgar se um código suspeito é realmente vulnerável. Funciona principalmente a partir da saída do descompilador (HLIL) do Binary Ninja, recorrendo ao assembly quando necessário, e relata apenas problemas confirmados com referências clicáveis de volta ao código.


Como funciona

Uma varredura é executada em até três fases (Fase 3 é opcional e somente online):

Fase 1 — chamadas de funções perigosas

Encontra locais de chamada de funções perigosas definidas em rules/phase1_rules.json — strcpy, memcpy, sprintf/strings de formato, system, alloca, scanf, APIs de comando/exec, RNG fraco, a família free/delete (use-after-free / double-free), leitura de entrada não confiável para buffers fixos (recv/read/fread/ReadFile), injeção SQL (sqlite3_exec/mysql_query/PQexec), verificação de certificado TLS desabilitada (SSL_CTX_set_verify/curl), SSRF, e gerenciamento inadequado de privilégios (setuid/setresgid), a família memset/bzero, e comparações com um comprimento controlado pelo atacante (memcmp/strncmp → bypass de autenticação), em C/C++, Win32, e (melhor esforço) Rust FFI. A cobertura inclui variantes fortificadas _chk (FORTIFY) e _s (Anexo-K). Funções de saída formatada com limite (snprintf e variantes) têm sua própria regra segura padrão para que um argumento de tamanho correto não seja relatado como estouro. Os locais de chamada são encontrados de três maneiras: chamadas diretas para os símbolos nomeados; chamadas roteadas através de thunks de encaminhamento / stubs PLT (os chamadores reais são recuperados, para que uma importação alcançada apenas através de um stub não seja perdida); e — a menos que vulnfanatic.scanIndirectCalls esteja desligado — chamadas indiretas despachadas através de um ponteiro de função ou vtable que o Binary Ninja resolveu para uma função perigosa. Para cada local de chamada, ele constrói um contexto interprocedural, centrado no descompilador, orçado para um limite de tokens (padrão 100k):

  • a expressão de chamada e seus argumentos,
  • o protótipo declarado da função chamada (das informações de tipo do Binary Ninja, caso contrário de uma tabela interna) para que o modelo mapeie argumentos para parâmetros corretamente — variantes fortificadas __*_chk e *_s com verificação de limites recebem argumentos iniciais extras, deslocando a posição do formato/tamanho/destino,
  • o tipo e tamanho em bytes de cada argumento da chamada (capacidades do buffer), derivados do tipo da expressão HLIL do argumento, de modo que um campo de struct como s->buf resolva para o tamanho real do array do campo em vez do tamanho do ponteiro de s; definições de struct na seção de tipos também carregam tamanhos de campo em bytes,
  • o valor concreto / intervalo de cada argumento resolvido pela propagação de constantes e análise de conjunto de valores do Binary Ninja (por exemplo, um comprimento provado constante 0x40 ou limitado a [0, 0xff]), que o modelo usa como verdade ao comparar um tamanho com a capacidade do buffer em vez de adivinhar,
  • o layout do quadro de pilha da função chamadora (offsets de variáveis e tamanhos em bytes) quando ela contém um buffer de tamanho fixo, para que um estouro de pilha possa ser julgado em relação às variáveis adjacentes e ao endereço de retorno salvo (vulnfanatic.includeStackLayout),
  • as restrições de caminho (as condições if/loop/switch que protegem a chamada),
  • um sumário de fluxo de dados dos argumentos — onde cada argumento da chamada é definido e usado dentro da função,
  • resolução de parâmetros entre chamadores — quando um argumento perigoso é um parâmetro da função chamadora, o contexto informa o que cada chamador realmente passa para ele (por exemplo, "todos os chamadores passam uma string literal"), para que um parâmetro de formato/tamanho que é sempre constante não seja confundido como controlado pelo atacante,
  • o corpo descompilado completo da função chamadora,
  • definições de tipos de dados (struct/union/enum) para os tipos referenciados ao longo da cadeia de chamadas e das variáveis de argumento, para que o modelo conheça os tamanhos reais de buffer/campo e larguras de inteiro,
  • os corpos descompilados das funções que produzem ou consomem as variáveis de argumento da chamada (rastreadas via def/uso HLIL), que é o que torna possível o raciocínio de use-after-free / double-free e tamanho contaminado,
  • caminhos de chamada desde pontos de entrada / funções exportadas até a chamada,
  • o corpo descompilado de cada função ao longo desses caminhos de chamada (primeiro a chamada perigosa), cada um anotado com o local da chamada e as condições que protegem o próximo salto,
  • os corpos de outras funções que essas funções de caminho chamam (por exemplo, para MAIN→ABCD→strcpy, também as funções que MAIN e ABCD chamam em outros lugares), pois podem conter as verificações de limites/validação que protegem o valor perigoso (vulnfanatic.includeCallPathSiblings, preenchido enquanto o orçamento permitir), e
  • dicas de fonte contaminada (funções de entrada como recv/read/getenv chamadas na mesma função).

Esse contexto mais um prompt específico para a regra é enviado ao modelo, que retorna um veredito estruturado. Não-problemas são descartados. Os prompts são ajustados para um modelo de código local forte (por exemplo, Qwen2.5-Coder) e instruem o modelo a analisar todo o fluxo e emitir apenas JSON.

Raciocínio, rascunho e confiança

O modelo é instruído a favorecer recall — relatar problemas plausíveis e relevantes para segurança e expressar incerteza através de uma Confiança em vez de descartar algo que não pode provar completamente. Ele mostra seu trabalho em um rascunho que cita os trechos de código textuais nos quais se baseou (a fonte de entrada, cada guarda, o tamanho/comprimento, o tipo relevante e o sumidouro), que é armazenado no achado para que você possa auditar o raciocínio.

Cada achado carrega uma Confiança (alta/média/baixa): alta = toda a cadeia é mostrada no contexto; média = provável, com um ou dois elos inferidos; baixa = uma pista que merece revisão manual. Esta é a métrica principal (a estimativa de severidade do modelo é um campo secundário). Defina vulnfanatic.minConfidence para descartar qualquer coisa abaixo de um limite.

Ajustando precisão vs. recall

Por padrão, o VulnFanatic-NG favorece recall (capturar problemas reais). Se obtiver muitos falsos positivos, restrinja com qualquer um destes:

Baixar ferramenta