Slack de arquivo / Slack de RAM: por que o Windows grava bytes de RAM arbitrários em disco? O Linux também?

Question

Acabei de ler sobre a folga de arquivo em um livro sobre o Windows 7. O que eu já sei (acho) saber:

• O Windows armazena dados no disco em clusters. Um cluster geralmente contém 8 setores de 512 bytes cada, então 4096 bytes ou 4kiB.
• Arquivos grandes são divididos em vários clusters, quando o restante de um arquivo não preenche um cluster inteiro, esse espaço não utilizado restante no final do cluster é chamado de "folga do arquivo".
• O Windows sempre grava blocos de 512 bytes de uma vez, portanto, o primeiro setor usado apenas parcialmente deve ser preenchido antes de ser gravado no disco.
• Por alguma razão, o Windows decide escolher uma sequência aleatória da RAM para preencher esse setor.
• Os setores não utilizados restantes no cluster usado parcialmente permanecem inalterados e mantêm os bytes que tinham antes, que podem ser partes de um arquivo excluído anteriormente nesse local. É chamado de folga da unidade.

Essas suposições estão corretas?

E por que o Windows escreve pedaços aleatórios de memória (que podem conter senhas, etc.) em meu disco simplesmente para ocupar espaço - e não apenas zera esses bytes?

E esse comportamento é específico do Windows (quais versões?) ou é específico do sistema de arquivos NTFS? Os sistemas de arquivos Linux ou ext4 farão o mesmo?

    

Answer 1

"File Slack" refere-se aos dados entre o último byte do arquivo e o final do cluster. Em geral, contém qualquer padrão de bits que o sistema operacional usa para representar a memória não alocada.

"Slack da unidade" refere-se a clusters que foram desalocados, mas não substituídos. Também pode se referir a um espaço não alocado que não está mais dentro de um limite de partição.

"RAM Slack" - Eu nunca ouvi esse termo antes. Pesquisando isso, todos os recursos que encontro parecem estar citando ou derivando de um livro intitulado "Cyber Forensics: Um Manual de Campo para Coletar, Examinar e Preservar Evidências de Crimes de Computador" por Albert J. Marcella, Jr. e Doug Menendez. / p>

Eu li o capítulo onde o termo é usado. Embora tenha sido protegido por direitos autorais em 2010, faz referência à maneira como o DOS e o Windows 95/98 fizeram as coisas. Isso não é relevante há mais de uma década. Eu poderia estar lendo fora de contexto embora. De qualquer forma, este livro parece ser a fonte do termo.

Windows stores data on the disk in clusters. A cluster usually contains 8 sectors of 512 bytes each, so 4096 bytes or 4kiB.

Isso está correto no caso de unidades legadas e unidades de "formato avançado" 4K. O tamanho do setor é verdadeiramente 4KB em unidades "nativas" de 4K, portanto, há uma correlação de 1: 1 entre setores e clusters para essas unidades.

Large files get split over multiple clusters, when the remainder of a file does not fill an entire cluster, this remaining unused space at the end of the cluster is called "file slack".

Também correto.

Windows always writes 512 byte blocks at once, so the first only partially used sector must get filled up before being written to disk.

Isso está incorreto. O Windows não escreve em blocos; apenas clusters. Ele irá gravar dados em qualquer tamanho arbitrário, mas eles serão em múltiplos do tamanho do cluster (geralmente 4KB). A única vez que o Windows se preocupa com setores / blocos é quando um endereço LBA deve ser calculado. O driver de disco de baixo nível faz isso, não o driver do sistema de arquivos. Na verdade, é muito ineficiente fazer leituras / gravações em blocos de 512 bytes. Ele funciona contra os caches de hardware internos da unidade. Fazer um dd no Linux com um tamanho de bloco de 512 bytes confirmará isso. É uma ordem de magnitude mais lenta em leituras e gravações.

For whatever reason, Windows decides to pick a random sequence from RAM to fill this sector.

Também incorreto. O Windows irá escrever o que estiver no buffer. Quase todos os aplicativos (incluindo o driver do sistema de arquivos) alocam a memória nova do heap ao gravar no buffer de saída. Quando um aplicativo aloca memória, ele faz isso em páginas, que são (adivinha o quê!) Em tamanho 4KB. A memória não alocada é geralmente representada por um padrão de bits de repetição (não 00 ou FF), de modo que é o que será gravado no final do cluster, se não estiver cheio. Nos casos em que o buffer de saída do aplicativo é uma cópia modificada de seu buffer de entrada, a folga conterá todos os dados que o buffer de entrada continha.

The remaining unused sectors in the partially used cluster remain unchanged and keep the bytes they had before, which can be parts of a previously deleted file in this location. It's called drive slack.

Também incorreto. O Windows sempre fará um commit de cluster completo mesmo se houver apenas 1 byte de dados alterados. É verdadeiro que os clusters desalocados possuem quaisquer dados antes. O Windows não se preocupa em zerar clusters desalocados. Mas nada disso acontece no nível do setor.

4KB é um número mágico. Páginas de memória são 4KB. Buffers de E / S são 4KB. Os setores são 4KB agora. Até mesmo o hardware da unidade é otimizado para solicitações de E / S que são 4KB (ou várias delas).

Todos os sistemas operacionais modernos funcionam dessa maneira (Windows, Linux e OS X). As únicas exceções às regras acima são aplicativos que têm o disco aberto para acesso bruto. Eles ignoram completamente as chamadas da API do sistema operacional para fazer gravações. Você só vê isso com ferramentas de recuperação e forense de baixo nível, porque esses aplicativos não se beneficiam de todas as otimizações que você obtém com E / S armazenada em buffer.

    

Answer 2

A folga da RAM é, na verdade, um artefato forense digital bem conhecido.

De fato, versões mais antigas (ou seja, Win 95/98) do Windows escreveram blocos de memória de 512 bytes. Por favor, não confunda a gravação em cluster para a mídia. Quando escrevo 512 bytes de memória, refiro-me à memória alocada / capturada pelo Windows para gravar em blocos de 512 bytes, totalizando o cluster de mídia de armazenamento.

Exemplo - clusters de 4096 bytes em mídia de armazenamento e um arquivo de 2049 bytes de comprimento. O Windows mais antigo alocava e armazenava armazenamento em buffer / cache / memória em blocos de 512 bytes na memória para esse arquivo de 2049 bytes.

Isso requer 5 x 512 bytes de memória . Isso deixa 511 bytes agarrados que não faziam parte do arquivo de 2049 bytes. (5 x 512 = 2560, mas 2049/512 = 4,002).

Então, o que há na memória de 511 bytes (2560 - 2049 = 511)? Nas versões anteriores, o Windows não limpava a parte de 511 bytes e escrevia-a com todo o 4KB. Isso é o que é chamado de folga de RAM nos círculos forenses digitais.