Motores de segurança comuns costumam se concentrar em bloqueio de intrusão e isolamento, mas comecei este projeto ao refletir sobre um sistema de defesa assimétrico, no estilo tarpit, que no momento em que o hacker tenta atacar, reutiliza a própria lógica de ataque dele para exaurir seus recursos computacionais e levá-lo à autodestruição.
Com base em um motor central em C++, já defini a estrutura inicial do Physical Ghost, um motor de segurança ativo que atrai e rastreia o processo de ataque do hacker para, ao final, induzir um OOM (Out of Memory).
O conceito central e o endereço da aplicação estão aqui: https://zenodo.org/records/19988807
A prova matemática e o sistema axiomático estão organizados aqui: https://zenodo.org/records/20113591 (é uma interpretação da profundidade da informação usando a codificação p-ádica de coeficientes binomiais e o teorema de Kummer).
A arquitetura é composta assim:
Isolamento absoluto: no instante em que uma conexão com uma porta-isca (honeypot) é detectada, o motor se isola usando uma conta fantasma com privilégio mínimo, bloqueando na origem qualquer propagação para o sistema principal.
Rastreamento fantasma: extrai assinaturas de rede de forma assíncrona e, sem degradar o desempenho do motor, envia imediatamente para fora (Telegram/Discord) as informações do invasor.
Função principal (fusão do computador): no momento em que o hacker conecta um depurador aos dados-isca para análise/descriptografia, é ativada uma estrutura de tetraedro de Sierpinski baseada em dinâmica de carry p-ádico (p-adic Carry Dynamics). Os dados se expandem recursivamente dentro da memória do adversário e acabam exaurindo os recursos de CPU/RAM.
Autoaniquilação: se a integridade do motor central for distorcida em até 0,1 byte, ele encerra o próprio processo (Self-Destruct), evitando que o motor seja corrompido e transformado em um cavalo de Troia.
Estado atual: no momento, estou implementando a estrutura básica da lógica principal de defesa e o módulo de autenticação de licença, enquanto preparo o repositório no GitHub. Também estou fazendo em paralelo a validação matemática cruzada da lógica de expansão de memória fractal e o port do núcleo em C++.
Quero ouvir o feedback crítico de quem tem interesse em ir além dos padrões de segurança convencionais e explorar formas de reutilizar a intenção de ataque e os recursos computacionais do próprio atacante. Em especial, opiniões sobre o controle de complexidade computacional usando estruturas topológicas p-ádicas ajudariam muito no aprimoramento do motor. Obrigado.
34 comentários
Esses são mesmo termos técnicos realmente significativos?? Parece que há muitas expressões excessivamente rebuscadas sem necessidade.
Parece um pouco negativo, porque me lembra algo como Show GN: desenvolvi o VANI, que destrói matematicamente a estrutura vetorial dos dados para apagá-los permanentemente, que apareceu há algum tempo...
Eu também pensei exatamente nisso, então fui procurar o GitHub desse post e o desfecho foi um
not found/Obrigado pela opinião!
Sendo sincero, eu também toquei a pesquisa com ajuda de IA, então pode passar essa sensação de “clicadinha de IA”...
Por enquanto estou portando para C++, e quando terminar vou trazer de novo aqui.
Agradeço pela opinião!
A ideia foi tentar trazer a abordagem de tarpit da camada de rede para a memória e para a camada de aplicação.
No caso do tetraedro de Sierpinski e da estrutura fractal, eu realmente não tinha uma palavra exata para explicar, então acabei publicando do jeito que estava no white paper; peço desculpas. Também ficaria estranho escrever como loop infinito ou despejar dados inúteis...
Se você olhar, entre os white papers acima, o de prova matemática e sistema axiomático, isso realmente se expande recursivamente por causa do formato de árvore ultramétrica sempre que ultrapassa um certo valor limite. No entanto, eu agradeceria se você entendesse que a ideia é chamar de algoritmo de bomba de memória que se expande com auto-similaridade, como um tetraedro de Sierpinski, quando a ferramenta de engenharia reversa do hacker tenta se aprofundar na profundidade dos dados!
Você quer dizer que, independentemente do tipo de ferramenta de reversing, se ela tentar fazer debugging, passa a existir por conta própria um outro executável que entra em ação? Se você tentar fazer reversing, isso nem sequer pode funcionar como você disse em primeiro lugar, a menos que sejam informações de cabeçalho de arquivo em um formato predefinido...
Obrigado pela opinião.
Na verdade, eu nem tinha pensado nisso; muito obrigado mesmo pela excelente informação.
Perguntei para a IA e ela respondeu assim:
"O núcleo do anti-reversing (Anti-Reversing) da edição SW do Physical Ghost está na 'forma como o loader desenvolve a execução depois de carregar o código na memória'. Em programas convencionais, quando você os abre em um debugger (IDA, Ghidra etc.), é possível ver um fluxo linear de instruções em assembly, mas a arquitetura proposta tem o próprio fluxo de execução entrelaçado em uma estrutura de 'pirâmide de carry (topologia fractal multidimensional)'."
"Se uma ferramenta de reversing tentar fazer dump da memória ou colocar breakpoints e rastrear a execução (single-stepping), o fluxo dessa operação estrutural (dinâmica de carry p-ádica) é interrompido. Ou seja, o próprio 'ato de observação' de tentar desmontar a estrutura à força a partir de fora provoca uma fissura topológica em forma de tetraedro de Sierpinski, de modo que os dados ou o código originais colapsem em ruído sem sentido — um mecanismo intrínseco de ofuscação e defesa projetado dessa forma."
Graças a isso, aprendi mais uma coisa. Obrigado!
Então, você está dizendo que apenas tentar observar os dados codificados por esse mecanismo de segurança já faz com que ele se execute por conta própria, entre em autocolapso ou consuma os recursos do hacker? É justamente por isso que estou dizendo que isso é impossível....
Desculpe pela demora na resposta!(__)
Se você pensar em observação simplesmente como o ato de olhar com os olhos para dados estáticos e parados, é natural que isso pareça impossível. Mas, no mundo digital, a observação necessariamente envolve uma interação que estimula o sistema-alvo.
Este motor de segurança não é um arquivo estático, mas sim uma arquitetura dinâmica que opera em tempo real usando como valor de entrada — trigger — o próprio ato de o invasor tentar observar ou a própria requisição. No momento em que a observação é tentada, um loop interno é executado para inutilizar a continuidade lógica dos dados e forçar o hold da sessão do atacante, que fica esperando para concluir a observação, consumindo seus recursos.
Além disso, o acesso de usuários com permissões legítimas — sessões com o handshake concluído — passa diretamente pelo mecanismo de autenticação sem passar pelo filtro de tarpits. A área em que ocorrem autocolapso e consumo de recursos durante a observação é apenas o espaço virtualizado de dados-isca — Decoy — implantado para filtrar reconhecimento não autorizado e solicitações de varredura não permitidas. É uma arquitetura de defesa dinâmica precisa que não causa nem 1% de impacto nos recursos do serviço normal e isola apenas a sessão do atacante para aprisioná-la no pântano.
Você está respondendo entendendo como isso seria possível? Lá em cima eu disse que seria ao observar os dados criptografados, mas na sua resposta você afirmou que o mecanismo de segurança detecta isso e entra em ação, certo? Mas o hacker faria a descriptografia no servidor remoto onde esse mecanismo de segurança estaria em execução? Ele provavelmente exfiltraria os dados e tentaria descriptografá-los em um ambiente isolado; nesse ambiente, o mecanismo de segurança que você mencionou nem sequer estaria carregado na memória. Ainda assim, ele conseguiria entrar em ação tendo a observação como gatilho? Ou a ideia seria incluir, junto com todos os dados que forem criptografados, um mecanismo de segurança em formato executável?
Nem sei o que estou dizendo, o contexto é zero, desculpem..
Será que, em textos assim, o próprio ato de comentar seriamente não acaba prejudicando a comunidade..
A abordagem matemática é interessante, mas na arquitetura de computadores moderna é praticamente impossível não chegar a essa conclusão.
Parece muito com aquele clima de
code slop"feito" usando coisas do tipo Openclaw.Obrigado pela opinião!
Aff, kkk
Parece algo no estilo de uma fortaleza digital.
Mas, tecnicamente, não consigo entender.
Sou só eu ou a frase parece meio desconexa?
Agradeço a opinião. Vou tentar lapidar um pouco mais a frase!
Se a integridade foi comprometida, como isso é detectado..
Obrigado pela opinião
Enquanto a verificação de integridade convencional compara o hash dos dados de forma plana, em uma relação de 1 para 1, o Physical Ghost mapeia e processa os dados em um tetraedro de Sierpinski tridimensional. Por isso, ele faz o julgamento com base na estabilidade estrutural.
A resposta da IA diz: "Se um único bit dos dados dentro do sistema for adulterado, esse erro minúsculo é amplificado em cadeia por toda a estrutura tridimensional pela dinâmica de carry p-ádica. No momento em que um invasor altera os dados, a própria 'arquitetura matemática (topologia)' formada pelos dados sai do alinhamento e desmorona, tornando possível detectar imediatamente a violação de integridade por meio dessa fissura na topologia."
Eu também já mexi um pouco com análise da estrutura PE, RE, Ghidra e desenvolvimento de drivers, mas não estou entendendo.
Obrigado pela opinião
Isso provavelmente acontece porque, diferente de coisas como hooking de sistemas existentes, o próprio algoritmo foi feito com ofuscação ou criptografia.
Na verdade, não tenho certeza... desculpe.
Achei a abordagem interessante, então gostaria de fazer algumas perguntas sobre alguns pontos.
Parece que o gatilho de expansão de memória depende da premissa de que “o atacante realmente executa/depura o payload”, mas se a abordagem for principalmente por análise estática ou se ele rodar dentro de um sandbox com limitação de recursos, como
cgroups,FirejailougVisor, o OOM ocorreria apenas dentro do sandbox, e não no host. Gostaria de saber como vocês tratam esse caso.Se o gatilho de anti-debug também for uma detecção baseada em
ptrace, então diante de breakpoints de hardware ou depuração em nível de hipervisor não haveria rastros visíveis. Existe um desenho específico para lidar com cenários em que a análise ocorre nessas camadas?Vocês disseram que “se houver distorção de até 0,1 byte, ocorre autodestruição”, mas gostaria de entender como impedem caminhos de bypass, como aplicar patch na própria rotina de verificação de integridade ou fazer dump da memória para análise offline.
O comportamento de esgotar ativamente os recursos do atacante pode, na prática, ser interpretado como
hack-back. Como vocês estão organizando a fronteira jurídica da defesa ativa à luz da legislação de redes e telecomunicações? (Especialmente porque, se o tráfego de ataque vier por meio de uma botnet, pode haver uma vítima real separada do atacante.)O próprio core engine em C++ parece assumir parser de porta-isca, extrator de fingerprint e até canal de envio externo, então a superfície de ataque parece relativamente grande. De que forma vocês validam a estabilidade de memória do próprio engine? Também tenho curiosidade sobre a parte de segredos, como tokens de webhook, que provavelmente estariam no binário.
Achei a modelagem matemática em si interessante. Se eu puder entender como esses pontos estão sendo resolvidos, acho que isso ajudaria bastante a compreender melhor o conceito. Obrigado.
Obrigado pela opinião!
O objetivo principal do gatilho de expansão de memória do item 1 não é destruir o equipamento físico do host do atacante, mas forçar a ultrapassagem do limite crítico de recursos computacionais necessários para a análise. Se um processo morrer por OOM dentro de um sandbox como cgroups ou gVisor, isso por si só não seria uma defesa bem-sucedida? O objetivo é fazer com que, por meio da expansão infinita de carry nas operações p-adic, a ferramenta de análise não tenha margem temporal nem espacial para interpretar os dados, levando o próprio ambiente de análise a se desligar
No item 2, não monitoramos system calls nem APIs de depuração. Em vez disso, consideramos apenas a consistência temporal da computação dos dados dentro de uma topologia fractal multidimensional ou de uma estrutura de tetraedro de Sierpinski, bem como a continuidade da dinâmica de carry. Se alguém colocar um breakpoint no hypervisor e parar a execução, a janela de tempo da computação se desalinha, e as operações topológicas subsequentes ficam matematicamente entrelaçadas -Entangled- de modo a colapsarem em valores inválidos
No item 3, você apontou um dos pontos mais importantes. Neste sistema, não existe uma função independente de verificação de integridade que o atacante possa neutralizar com NOP (ou burlar com um
if). A lógica de verificação de integridade assume uma forma semelhante à de uma criptografia White-box, acoplada à lógica central e à geometria topológica.Além disso, mesmo que se faça um dump de memória para análise offline, os dados extraídos são apenas uma seção transversal 2D, em um momento específico, de uma estrutura topológica 3D em constante mutação. Sem conhecer a regra dinâmica completa — o modelo de pirâmide de carry — não deve ser possível reconstituir o payload original apenas com os dados do dump, certo? (matematicamente falando..)
O item 4 também é um ponto sobre o qual eu vinha refletindo. Como você disse, uma defesa ativa pode ter alta probabilidade de ilegalidade quando lança um contra-ataque contra servidores externos de C&C etc., mas o sistema proposto traça rigidamente o limite como uma armadilha de entrada. Em vez de enviar tráfego malicioso para fora, a ideia é que, quando o atacante leva o binário para o próprio ambiente e o executa por conta própria, apenas ali dentro ele passe a consumir recursos computacionais como se estivesse em um labirinto. Por isso, acredito que seja possível evitar questões relacionadas a danos externos. (esperança minha)
No item 5, eu também me preocupo com o risco de segurança de memória de uma estrutura monolítica baseada em C++. Talvez mais adiante seja necessário adotar Rust ou algo do tipo e continuar validando isso continuamente.
E valores secretos como tokens de Webhook não existem em texto puro nem em uma ofuscação simples. Como mencionei antes, quando a operação topológica multidimensional normal é concluída até o fim, o valor resultante é usado como chave de descriptografia e então montado temporariamente na memória. Se alguém distorcer a estrutura para analisá-la, a própria composição do token se torna impossível.
Aprendi muito graças a você, obrigado!
Antes de tudo, obrigado pela resposta. Mas ainda há alguns pontos que eu gostaria de destacar.
(Expansão de memória): no texto principal, vocês falaram em esgotamento dos recursos do atacante/autodestruição, mas na resposta o tom parece ter mudado um pouco para "defesa contra OOM mesmo dentro do sandbox". Então, qual é a diferença em relação a 42.zip ou billion laughs? E, em análise estática com Ghidra/IDA, o gatilho nem chegaria a ser ativado...
Anti-debug: não está claro se a expressão Entangled é uma metáfora ou um mecanismo, mas o conteúdo em si soa como uma variante de detecção de timing com RDTSC. É uma técnica que o VMProtect já usa desde os anos 90; faz mesmo sentido dar um nome novo a isso? E como isso funciona em ambientes com TSC scaling do HyperDbg?
Integridade: white-box AES é uma área que praticamente toda já foi quebrada depois do ataque BGE, então, se vocês transformaram isso em um white paper, isso por si só já daria um artigo à parte. A metáfora de que "o dump é uma seção 2D de um objeto 3D" também não se sustenta diante de WinDbg TTD ou Intel PT. No fim, a frase "apenas matematicamente..." acaba soando como um resumo da resposta inteira...
Desculpem pela demora na resposta (__) e muito obrigado, como sempre, pelas ótimas observações
Bombas clássicas como a 42.zip são apenas uma expansão simples de dados estáticos, então no máximo causam OOM (estouro de memória) e acabam aí. Mas esta arquitetura, como mostrado no white paper, não é sobre dados, e sim um pântano computacional (Computational Tarpit) que força um loop operacional de carry p-ádico (p-adic carry) da pirâmide de carry.
Se você fizer análise estática com Ghidra ou IDA, é normal que o gatilho não dispare. E tem que ser assim. Porque no binário estático não existe a lógica real. Só quando o atacante começa a interagir em ambiente de runtime (dinâmico) é que a ofuscação topológico-geométrica passa a se desenrolar em tempo real, então as ferramentas de análise estática acabam vendo apenas uma casca vazia.
Uma detecção simples de timing usando RDTSC realmente já é uma técnica antiga. Se você falsificar o tempo com o TSC Scaling do HyperDbg, claro que vai conseguir contornar isso.
Mas o entrelaçamento (Entangled) que mencionei no white paper não é uma checagem de tempo. É uma estrutura em que a própria fase operacional (Phase) da transformação topológica matemática que ocorre em runtime — a estrutura de carry que se expande em potências de 11 — fica matematicamente acoplada à carga do ambiente de execução. Se você enganar o ambiente com HyperDbg e distorcer artificialmente o timing da computação? O motor de defesa não reage com um “opa, é um debugger!” e bloqueia; em vez disso, a própria fórmula de expansão de fase da pirâmide de carry passa a se estender para uma dimensão equivocada e, como resultado, faz a autodescriptografia de dados totalmente inúteis, puro lixo. No momento em que tenta enganar, você mesmo cai na armadilha.
White-box AES esconde uma chave criptográfica matemática fixa, então é vulnerável a ataques BGE. Isso é fato. Mas esta arquitetura não esconde uma chave fixa; ela usa uma topologia dinâmica de runtime cuja fase muda a cada tentativa de acesso.
Se assumirmos que alguém grava 100% de todo o fluxo de instruções da CPU com WinDbg TTD ou Intel PT e depois o reproduz como uma máquina do tempo, o próprio caminho gravado já não passa de uma trajetória vagando por um pântano de lixo (tarpit) colapsado e distorcido pelo ato de observação do atacante. É como gravar com 100% de precisão as pegadas de alguém que se perdeu e ficou rodando dentro de um labirinto: isso não ajuda em nada a encontrar a saída do labirinto.
Desculpem por ser tão diferente dos paradigmas existentes..
Obrigado pela explicação detalhada. Acho que estou tão acostumado ao paradigma existente que não estou conseguindo acompanhar muito bem. Quando a PoC for divulgada, com certeza voltarei para ver de novo. Estou torcendo por vocês :)
Não dá nem para ter noção do quão hacker genial ele é
Obrigado pela opinião!
Não sou nenhum gênio, nem hacker, sou só uma pessoa que estuda matemática..
Autodestruição: se a integridade do motor central for distorcida em apenas 0,1 byte, ele encerra o próprio processo (Self-Destruct), prevenindo situações em que o motor seja transformado em um cavalo de Troia.
Existe algo como 0,1 byte em um computador?
1 byte são 8 bits, então 0,1 byte seriam 0,8 bit. Acho que é a primeira vez que ouço falar da existência de informação menor que 1 bit.
Eu também pensei nisso.
Agradeço pela opinião!
Peço desculpas, eu estava tentando enfatizar a extrema sensibilidade do core engine!
Vou ajustar a expressão! 0,1 byte realmente não faz sentido.