> For the complete documentation index, see [llms.txt](https://stacked-rwx.gitbook.io/public/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://stacked-rwx.gitbook.io/public/reverse-engineering/tecnica-de-binary-diffing-comparacao-de-binarios.md). # Técnica de Binary Diffing (Comparação de Binários) O objetivo do Binary Diffing é sinalizar novos patches de segurança como meio de localizar e identificar as vulnerabilidades correspondentes. Os pesquisadores de segurança, pentesters e os red teamers podem usar essas informações para lançar exploits de Ndays em sistemas sem patches. Embora a teoria seja simples, a técnica de Binary Diffing é complexa na prática. Em resposta ao crescimento lucrativo da pesquisa de vulnerabilidades, o nível de interesse na comparação binária de vulnerabilidades corrigidas continua a aumentar. Vulnerabilidades divulgadas em particular e descobertas internamente geralmente oferecem detalhes técnicos limitados publicamente. Quanto mais detalhes forem divulgados, mais fácil será para outras pessoas localizarem a vulnerabilidade. Sem esses detalhes, o patch diffing permite que um pesquisador identifique rapidamente as alterações de código relacionadas à mitigação de uma vulnerabilidade, que às vezes pode levar a uma criação bem-sucedida de um método de exploração. ### Introdução ao Binary Diffing Quando são feitas alterações no código compilado, como bibliotecas, aplicativos e drivers, o delta entre as versões corrigidas e não corrigidas pode oferecer uma oportunidade para descobrir vulnerabilidades. Em seu nível mais básico, a comparação binária é o processo de identificação das diferenças entre duas versões do mesmo arquivo, como as versões 1.2 e 1.3. ### Application Diffing O raciocínio por trás do lançamento pode incluir a introdução de novos recursos, alterações de código para oferecer suporte a novas plataformas ou versões de kernel, alavancando novos controles de segurança em tempo de compilação, como canaries ou Coontrol Flow Guard (CFG) e a correção de vulnerabilidades. Frequentemente, a nova versão pode incluir uma combinação do raciocínio mencionado acima. Quanto mais alterações no código do aplicativo, mais difícil pode ser identificar aquelas relacionadas a uma vulnerabilidade corrigida. Um exemplo simples de um trecho de código C que inclui uma vulnerabilidade é mostrado aqui:
E aqui está o código corrigido:
O problema com o primeiro snippet é o uso da função **gets()**, que não oferece verificação de limites, resultando em uma oportunidade de [**buffer overflow**](https://resources.infosecinstitute.com/topics/secure-coding/how-to-exploit-buffer-overflow/). No código corrigido, a função **fgets()** é usada, o que requer um argumento de tamanho, ajudando assim a evitar um [**buffer overflow**](https://resources.infosecinstitute.com/topics/secure-coding/how-to-exploit-buffer-overflow/). A função **fgets()** é considerada obsoleta e provavelmente não é a melhor escolha devido à sua incapacidade de lidar adequadamente com bytes nulos, como em dados binários; no entanto, é uma escolha melhor do que **gets()** se usado corretamente. ### Patch Diffing Os patches de segurança, como os da Microsoft e da Oracle, são alguns dos alvos mais lucrativos para o Patch Diffing. A Microsoft historicamente tem um processo de gerenciamento de patches bem planejado que segue uma programação mensal, onde os patches são lançados na segunda terça-feira de cada mês. Os arquivos corrigidos geralmente são bibliotecas de vínculo dinâmico (DLLs) e arquivos de driver, embora muitos outros tipos de arquivo também recebam atualizações, como arquivos .exe. Muitas organizações não corrigem seus sistemas rapidamente, deixando aberta uma oportunidade para invasores e pentesters comprometerem esses sistemas com exploits divulgados publicamente ou desenvolvidos em particular por meio da ajuda do Patch Diffing. A partir do Windows 10, a Microsoft se tornou muito mais agressiva com os requisitos de correção, tornando desafiador o adiamento das atualizações. Dependendo da complexidade da vulnerabilidade corrigida e da dificuldade em localizar o código relevante, um exploit funcional às vezes pode ser desenvolvido rapidamente nos dias ou semanas após o lançamento do patch. Exploits desenvolvidos após patches de segurança de engenharia reversa são comumente referidos como Exploits de dia 1 (1day) ou dia N (Nday). Isso é diferente dos exploits de dia 0 (0day), em que um patch não está disponível no momento em que é descoberto na natureza. ### FINAL Vou deixar com vocês um livro ótimo em formato pdf para que vocês possam se aprofundar muito mais do que a minha explicação. Eu fico super feliz por contar com a participação de vocês, cada dia me deixa mais motivado a postar novos artigos e compartilhar com vocês meu conhecimento! [**Gray Hat Hacking — The Ethical Hacker’s Handbook**](https://cdn.ttgtmedia.com/rms/pdf/bookshelf_gray_hat_hacking_excerpt.pdf)