Desenvolvi o VANI, que destrói matematicamente a estrutura vetorial dos dados para apagamento permanente

Olá. Meu trabalho principal é desenvolver algoritmos e funções de IA.

Com o avanço acelerado recente da IA generativa e das tecnologias forenses, comecei a me perguntar: "é possível apagar completamente dados digitais?" Dizem que não só sobrescrita, restauração de fábrica e exclusão por firmware, mas até mesmo degaussing podem permitir recuperação por causa de carga residual. O método de descarte de chave de criptografia (Crypto-shredding) também não seria seguro diante da futura computação quântica. Especialmente em ambientes SSD (NVMe), havia uma limitação clara: por causa das características de wear leveling, o método tradicional de "sobrescrita (DoD 5220.22-M)" reduz a vida útil e também tem baixa eficiência de exclusão.

Por isso, em vez de sobrescrita física, criei o VANI (Vector-based Advanced Nullification), uma ferramenta de exclusão para Windows baseada em colapsar matematicamente os dados, e a disponibilizo no GitHub e no Gumroad.

A vantagem é que ele permite selecionar e apagar arquivos e dados de forma extremamente rápida em todos os dispositivos de armazenamento baseados em Windows; a desvantagem é que, uma vez apagado, acabou: não há possibilidade de perícia forense, é exclusão permanente, então deve ser usado com cuidado.

🛠 Processo de desenvolvimento e tecnologias principais
Se a "exclusão" tradicional é um trabalho de pintura que passa 0 e 1 por cima dos dados, o VANI se aproxima mais de derrubar o próprio espaço vetorial onde os dados existem. (Foi desenvolvido em Python e Rust. Como minha especialidade é algoritmo, acho que sofri muito mais com UI/design do que com a implementação do código... 😅)

• Vector State Collapse: os dados do arquivo são definidos não como uma simples sequência de bits, mas como um estado vetorial (State), e padrões ortogonais (Orthogonal) ao original são injetados para fazer o próprio padrão desaparecer.

• Entropy Maximization: em vez de números aleatórios simples, é injetado um "chaos buffer" com a entropia de Shannon (Shannon Entropy) maximizada ao extremo. Como a entropia, tal qual uma lei da termodinâmica, não pode matematicamente voltar a diminuir, o sistema foi projetado para impedir reconstrução reversa mesmo com o algoritmo de Grover da futura computação quântica.

• Hilbert Curve Optimization: para eficiência de I/O de disco, foi aplicada a curva de Hilbert, um algoritmo de curva de preenchimento de espaço (Space-filling curve). Graças a isso, em ambiente NVMe foi possível atingir velocidade inferior a 1 segundo para apagar 1 GB.

💾 Teste você mesmo
Esta é uma versão portable pronta para executar. Para uso pessoal, deixei no GitHub para que possa ser usada gratuitamente e sem limitações de funcionalidade.

GitHub (gratuito/pessoal): https://github.com/eterners-inc/VANI (suporte para exclusão de arquivo único, sem anúncios)

Gumroad (pago/empresarial): eterners.gumroad.com/l/vani-pro (exclusão em nível de pasta, geração de relatório de auditoria e outros recursos de negócios)

💬 Considerações finais
Espero que o VANI possa ser uma ferramenta útil para pessoas ou startups que, ao contrário de grandes grupos como o Grupo S, não podem descartar em um forno de fusão um disco rígido com informações confidenciais. Feedback sobre o algoritmo ou o tratamento de I/O em baixo nível, bem como relatos de bugs, serão sempre bem-vindos.

⚠️ Aviso adicional (Ghost Protocol) Como a tecnologia de apagamento completo de dados pode ser sujeita a uso indevido ou abusivo, desenvolvi e incorporei um algoritmo de autodefesa do código-fonte para impedir depuração (Ghost Protocol), de modo que haja lockdown em caso de uso indevido. Estou considerando futuramente abrir esse módulo de segurança como uma biblioteca separada para startups ou colegas desenvolvedores que precisem de segurança, antes do registro de patente.

[wedding]

Será que eu sou meio burro... preciso estudar de novo introdução à ciência da computação...

[bbulbum]

Hmm... a IA está fazendo uma suspeita razoável de que parece uma encenação.

[dydwls140]

Você não percebe que a solução que você mesmo propõe não resolve em nada a limitação que você apontou como problema. Parece haver uma enorme contradição em continuar carregando exatamente o mesmo problema de wear leveling de SSD.

[holywork]

Se a eliminação completa dos dados é importante, aplicar desde o início uma criptografia de disco completo suficientemente forte é mais prático do que esse tipo de algoritmo especial de exclusão. Basta destruir a chave para que todos os dados virem ruído.

[kunggom]

Qual é a diferença entre o método de exclusão de arquivos do produto que vocês apresentaram e simplesmente sobrescrever com dados aleatórios, incluindo pseudoaleatórios?
Pelo que dá para verificar no repositório, o código em free/main_free.py aparentemente acaba apenas sobrescrevendo os primeiros 4096 bytes do arquivo com novo ruído pseudoaleatório e, em seguida, chamando uma biblioteca baseada em Rust cujos detalhes não foram divulgados, alegando que ela faz alguma coisa. No entanto, não dá para entender em que isso difere qualitativamente de simplesmente sobrescrever o arquivo com números pseudoaleatórios, e o que foi publicado parece insuficiente para provar essa diferença.
Vocês poderiam explicar em que aspecto isso é qualitativamente diferente da sobrescrita com pseudoaleatórios e, de forma concreta, que mudança isso traz em termos de possibilidade de recuperação quando se tenta restaurar o arquivo ou fazer análise forense, em comparação com uma simples sobrescrita pseudoaleatória? Ou há algum ponto em que vocês possam afirmar que isso varia conforme o meio de armazenamento, como disco rígido ou SSD?

[terrydo]

Olá. É um comentário agradável e pelo qual sou grato. É a primeira vez que posto algo depois de só acompanhar em silêncio, então fiquei um pouco surpreso por haver até comentários escritos por IA.

Como você mencionou, o main_free.py da versão Free pública atua como ponto de entrada do sistema de arquivos (Entry Point), bloqueando o reconhecimento pelo SO ao colapsar o cabeçalho de 4 KB e depois repassando o processamento real ao núcleo em Rust (vani_core). A observação de que faltam detalhes é totalmente válida dentro do que foi tornado público até agora.

Sobre a pergunta a respeito da “diferença qualitativa em relação a uma sobrescrita simples com PRNG”, vou explicar a intenção do design e o direcionamento técnico que defini.

• Diferença de entropia entre Orthogonal Noise e Pseudo-Random
  Um random() simples ou /dev/urandom busca uma distribuição estatisticamente uniforme, mas, do ponto de vista da análise de padrões de dados, ainda pode haver periodicidade passível de rastreamento reverso. O VANI gera um “buffer caótico” que maximiza matematicamente a entropia de Shannon ao limite. Não se trata apenas de espalhar números aleatórios, mas de injetar ruído matematicamente ortogonal ao vetor de dados original, induzindo o campo magnético residual físico ou o estado de carga das células a convergir para um estado de equilíbrio irrecuperável. (Essa parte será divulgada em detalhes mais adiante em um white paper, após o depósito do pedido de patente.)

• Otimização de I/O em ambiente SSD (Legacy Linear vs Hilbert)
  Na verdade, esta é a diferença decisiva de acordo com o meio de armazenamento mencionada na sua pergunta. O método tradicional sobrescreve linearmente do setor 0 até o fim. Isso não combina com a estrutura de processamento paralelo dos SSDs e, por causa do wear leveling, há grande chance de que a sobrescrita não ocorra no endereço físico real.
  Mas, no método VANI, o núcleo em Rust explora os endereços lógicos de forma não linear por meio do algoritmo de curva de Hilbert (Hilbert Curve). Isso usa de forma eficiente a largura de banda de múltiplas filas (Multi-Queue) do NVMe, rompendo as ligações semânticas dos dados com muito menos passagens de escrita (passes) do que os métodos existentes.

• Next Action
  Como você apontou, é verdade que, apenas com o código da versão Free atualmente pública, é difícil para terceiros verificarem que a diferença é qualitativa. Como se trata de um modelo matemático, ele também ainda não passou pela etapa de certificação oficial por uma empresa forense especializada. Por isso, no futuro pretendo validar isso publicando dados de benchmark de antes/depois em ambiente SSD, comparando com PRNG simples por meio de uma ferramenta de benchmarking, ou então desenvolvendo isso em código Python para realizar experimentos comparativos e divulgar os resultados.

Na verdade, como era a primeira vez que eu publicava um texto, eu estava um pouco preocupado. Ainda bem que não foi uma pergunta feita por IA, como no exemplo abaixo. Esse tipo de pergunta afiada e verificação é exatamente o tipo de feedback que eu queria receber no Show GN. Continuem apontando bastante o que ainda falta para que eu possa melhorar. Obrigado!

[kunggom]

Há muitos pontos que eu gostaria de criticar em detalhes.
Começando pelo fato de que a semente do gerador pseudoaleatório usado para "colapsar" os primeiros 4 KiB do arquivo é uma combinação do caminho e do tamanho do arquivo, ou seja, algo totalmente determinístico, até o fato evidente de que o depósito de patente de algoritmos computacionais é extremamente rigoroso e, mesmo que venha a ser concedido, a patente por si só não permite afirmar que a segurança foi comprovada, já dá para ver muitos problemas apenas pelo que foi divulgado.

Mas o mais importante é isto: que utilidade adicional esse algoritmo secreto, que dizem que vão patentear, realmente oferece em comparação com a exclusão comum de arquivos?
Como parece que o cenário principal assumido é o de SSDs, vou limitar a discussão a SSDs. (Isso não significa que em HDDs haveria alguma utilidade relevante.)

Os SSDs modernos são feitos com memória flash NAND, cuja característica é que não se pode sobrescrever uma célula que já contém dados gravados. Como não é possível gravar novos dados diretamente em uma célula já usada, é obrigatório passar antes pelo processo de apagamento. Como esse número de apagamentos é limitado, na memória flash a operação de exclusão não é feita por célula individual nem por página, mas apenas em unidades de bloco, que são conjuntos de várias páginas. É por isso que existe a camada FTL (Flash Translation Layer) e que surgem problemas como write amplification.
Isso significa que, em um SSD, mesmo que você "sobrescreva" parte do conteúdo de um arquivo, fisicamente esse conteúdo tentado na sobrescrita será armazenado em células completamente diferentes. Seja uma sobrescrita simples com zeros, seja com números aleatórios gerados de alguma forma, não há diferença alguma no fato de que o conteúdo será gravado fisicamente em outras células. Do ponto de vista do software, além da abstração do hardware do SSD, só se enxerga o valor resultante da sobrescrita, mas nem o sistema operacional nem a aplicação conseguem controlar diretamente a memória flash NAND em nível explícito.

Isso não quer dizer, porém, que a exclusão de dados dentro do SSD nunca seja concluída de fato. Células que armazenam dados não utilizados precisam ser apagadas antecipadamente para evitar latência na próxima gravação. Por isso, o controlador interno do SSD executa continuamente GC (Garbage Collection) em segundo plano.
Desde a década de 2010, todos os principais sistemas operacionais oferecem suporte ao comando TRIM. O TRIM é a forma de o sistema operacional informar ao SSD que "estes blocos não são mais usados". Com isso, eles passam a ser alvo da coleta de lixo que o controlador do SSD executa continuamente em segundo plano. Não dá para saber exatamente quando a coleta de lixo fará a limpeza real, mas, uma vez que ela aconteça e o apagamento seja executado no bloco NAND, torna-se impossível recuperar a informação perdida mesmo que se desmonte fisicamente o chip individual. E, como hoje em dia os sistemas operacionais já deixam o TRIM ativado por padrão, mesmo uma exclusão de arquivo comum feita pelo próprio sistema operacional acaba tornando a recuperação de dados impossível depois de certo tempo.

Portanto, em ambiente de SSD, simplesmente executar o comando de exclusão de arquivos do próprio sistema operacional não permite afirmar com certeza quando os dados desaparecerão, mas em algum momento eles serão completamente apagados das células; já sobrescrever os dados do arquivo pode, ao contrário, fazer com que a informação original permaneça por algum tempo nas células físicas que a continham. Isso não é a própria ironia?
Claro, se no final você apenas chamar o comando de exclusão do próprio sistema operacional, o resultado será o mesmo: depois de algum tempo, os dados acabarão desaparecendo fisicamente das células. Mas, se o resultado é o mesmo, não seria melhor simplesmente apagar o arquivo de forma comum, sem recorrer a um algoritmo pomposo?

Existe um termo chamado purple hat therapy.
Vamos supor que alguém afirme: "Para tratar a doença X, é preciso tomar o remédio Y usando este chapéu roxo que contém uma misteriosa energia cósmica." Só que, na verdade, o remédio Y já vinha sendo usado há muito tempo no tratamento da doença X. É claro que o tratamento com o chapéu roxo parecia funcionar, mas o grau de eficácia era, na prática, exatamente o mesmo do tratamento já existente. Nesse caso, esse chapéu roxo é necessário ou não?

Na minha visão, esse tal de VANI se encaixa perfeitamente no termo "purple hat therapy". Pelo que foi divulgado, não parece haver absolutamente nenhuma base para considerar que ele ofereça segurança significativa ou qualquer outra utilidade em comparação com a exclusão básica de arquivos do sistema operacional. A menção a vários termos técnicos, como terminologia matemática e algoritmos de computação quântica, não passa de uma tática de marketing de má qualidade para justificar o preço da versão paga, que chega a 100 dólares. Eu não usaria esse programa nem mesmo se ele fosse totalmente gratuito.

[honglu]

Eu ia só deixar um joinha, mas achei que não seria educado, então estou deixando um comentário. Gostei muito da leitura.

[kunggom]

Obrigado.
Enquanto eu escrevia o comentário, ele acabou ficando muito mais longo do que eu imaginava, quase como um post de blog, então por um momento fiquei pensando se deveria mesmo publicar assim, mas como achei um desperdício o tempo que levei para escrever até ali, acabei postando mesmo. Ainda bem que você leu e gostou.

[ffdd270]

Fazia realmente muito tempo que eu não lia um texto tão bom, então li duas vezes. Muito obrigado mesmo por deixar um texto assim.

[redmi]

Até o texto de apresentação foi feito com LLM, haha..
Pessoalmente, acho muito desagradável usar LLM até para escrever o texto de apresentação

[nemorize]

Isso é sério mesmo? kkkkk

[v08zbv8fvlkjasdflkj]

---

Olá, sou PM da TF de Plataforma de Convergência Quântico-Termodinâmica do Instituto de Pesquisa em Tecnologias do Futuro da empresa S. (No momento estamos na fase de fechamento de uma rodada ponte Series C, então é difícil revelar minha identidade.)

Quando vi o post sobre o VANI, pulei da cama às 4 da manhã. Sinceramente, senti um arrepio.

No nosso instituto também pesquisamos, desde 2019, o "protocolo de extinção de informação baseado em distribuição anti-Boltzmann", e o gargalo central era justamente o vazamento de entalpia na interface Shannon-Gibbs. Mas saber que você contornou isso por meio do colapso ortogonal no espaço de Hilbert... nosso pesquisador-chefe, ao ver isso, disse: "deve ter sido assim que Einstein se sentiu quando resolveu o paradoxo EPR".

Em especial, a ideia de romper os links vetoriais do cabeçalho do arquivo com ortogonalização de Gram-Schmidt é algo a que não conseguimos chegar nem após 3 anos de pesquisa conjunta com o Departamento de Ciências Matemáticas do KAIST. Por acaso você também implementou internamente a transição de estado pseudo-qubit baseada em operadores não hermitianos? Se sim, isso não é apenas uma ferramenta de exclusão, mas o ponto de partida de um paradigma pós-quântico de incineração de informação.

Nossa controladora (Top 20 global em valor de mercado) está atualmente preparando a "iniciativa Data Thermal Death", e o motor de maximização de entropia do VANI coincide exatamente com o marco da Fase 2 do nosso roadmap.

~~Investimento~~ não, uma parceria estratégica de tecnologia seria algo que poderíamos discutir?

As condições do nosso lado são:

• investimento inicial de $2M (valuation a combinar)
• depósito do código-fonte do Ghost Protocol™ em escrow
• pedido conjunto de patente para o motor Hilbert-Euler

No entanto, nosso time jurídico diz que precisa de uma análise legal sobre a "força vinculante matemática da segunda lei da termodinâmica". Por acaso vocês têm algum peer review da Nature ou certificação ISO 27001 Anexo Q sobre a parte de que a entropia "nunca pode diminuir em hipótese alguma"?

E uma pergunta pessoal... como vocês definiram a unidade discretizada de exclusão baseada na constante de Planck? Nós assumimos um "quantum de exclusão quântica" na unidade de 6.626 × 10⁻³⁴ joule·segundo, com base em h-bar, mas na coherence-decoherence threshold com o cache do controlador NVMe a fase continua saindo do eixo.

Enfim, isso é realmente impressionante. Parece que Maxwell, Boltzmann e Shannon do século 21 desceram em uma só encarnação.

Aguardo seu contato o quanto antes. 🙏

P.S. Os dados excluídos pelo VANI não estão sendo transferidos para um universo paralelo, certo? Nosso CTO ficou repentinamente preocupado com isso.

[dongho42]

Não sei se só eu achei essa piada engraçada... kkk

[nordica]

Saiu mais um hoje... um repositório cheio de lixo de IA