O valor da soma de verificação do arquivo foi alterado após um longo período na unidade não utilizada

Question

Eu tenho uma unidade com dados armazenados que não uso há 3 anos ou mais. Eu tinha então checado vários arquivos com checksum corz.

Agora, estou fazendo o backup desses dados antigos em outra unidade e, para ter certeza, executei chkdsk com a varredura completa do setor, e isso ocorreu sem problemas.

Também verifiquei a soma de verificação de todos os arquivos e notei que um dos arquivos zip foi alterado, embora eu tenha certeza de que não alterei nada nele.

Eu testei o arquivo zip, extraí o conteúdo e está tudo bem, mas não consigo contornar o fato de que ele tem um valor de soma de verificação diferente agora.

O que poderia causar isso? E por que o teste e a extração não retornam um erro?

O arquivo zip armazenou apenas um item e tenho 100% de certeza de que não o alterei após a soma de verificação. Alguém pode explicar isso ou ajudar a encontrar a causa?

    

Answer 1

Why does the test and extraction don't return an error?

Porque o arquivo zip é certamente OK. O formato Zip usa o CRC-32 para detectar corrupção e é muito improvável que um arquivo alterado aleatoriamente passe este teste.

Por esse motivo, acho que é a velha soma de verificação que está errada. Foi erroneamente calculado anos atrás.

What could possibly cause this?

Você pode ter experimentado um bug de software. Pense que pode haver erros que se expressam apenas em determinadas circunstâncias. Por outro lado, calcular uma soma de verificação é relativamente simples. Não podemos descartar isso, mas prefiro culpar outra coisa.

Raio cósmico. Ou alguma outra coisa que tenha feito um único bit na sua memória RAM, mude seu estado. Não era um bit de soma de verificação final, pois os dois checksums diferem em muitos bits. Eu acho que um pouco invertido antes ou durante o cálculo, várias operações foram realizadas mais tarde e essa única alteração afetou todo o resultado. Posso ver md5 na sua captura de tela, acho que sua soma de verificação é MD5. É uma função hash; tais funções são deliberadamente criadas (ou seja, definidas, escolhidas) de uma maneira, de modo que quando você inverte um único bit na metade de entrada fornecida (em média) dos bits de saída, também inverte. O bit que invertido pode não ter sido um bit de entrada, pode ter sido algum bit intermitente; ainda assim, não admira que as duas somas sejam muito diferentes.

Eu mencionei o raio cósmico, mas também é possível que sua memória não tenha sido 100% confiável e um pouco invertida sem um motivo externo.

Essas coisas acontecem. Alguns exemplos:

1. Este autor escreve sobre um arquivo executável que começou a gerar erros. Descobriu-se que o arquivo em cache (RAM) era literalmente um pouco diferente do mesmo arquivo no disco.

2. Usando erros de memória para atacar uma máquina virtual por Sudhakar Govindavajhala e Andrew W. Appel.

   Our attack works by sending to the JVM [Java Virtual Machine] a Java program that is designed so that almost any memory error in its address space will allow it to take control of the JVM. All conventional Java and .NET virtual machines are vulnerable to this attack.

3. Artem Dinaburg nomes de domínio registrados são um pouco diferentes de vários domínios populares . Dispositivos de todo o mundo visitaram esses endereços.