Como corromper um arquivo morto de maneira controlada?

22

Eu escrevi uma função que verifica um arquivo corrompido usando uma soma de verificação de CRC.

Para testar, acabei de abrir o arquivo e embaralhei o conteúdo com um editor hexadecimal. O problema é que eu não acredito que esta seja a maneira correta de gerar um arquivo corrompido.

Existe alguma outra maneira de criar uma "corrupção controlada", por isso não será totalmente aleatória, mas simulará o que acontece com arquivos corrompidos reais? Eu nunca tive que corromper algo de propósito, então não tenho certeza de como fazê-lo, além do embaralhamento aleatório de dados em um arquivo.

    
por rataplan 10.08.2015 / 20:29

6 respostas

21

Também não fiz muito testes de fuzz , mas aqui estão duas ideias:

Escreva alguns zeros no meio do arquivo. Use dd com conv=notrunc . Isto escreve um único byte (tamanho do bloco = 1 contador = 1):

dd if=/dev/zero of=file_to_fuzz.zip bs=1 count=1 seek=N conv=notrunc

Usar /dev/urandom como uma fonte também é uma opção.

Alternativamente, perfure vários furos de 4k com fallocate --punch-hole . Você pode até mesmo fallocate --collapse-range cortar uma página sem sair de um buraco preenchido com zero. (Isso irá alterar o tamanho do arquivo).

Um download retomado no local errado corresponderia ao cenário --collapse-range . Um torrent incompleto corresponderá ao cenário punch-hole . (Arquivo esparso ou extensões pré-alocadas, lidas como zero em qualquer lugar que ainda não tenha sido escrito.)

RAM ruim (no sistema do qual você fez o download do arquivo) pode causar danos, e unidades ópticas também podem corromper arquivos (seu ECC nem sempre é strong o suficiente para se recuperar perfeitamente de arranhões ou desbotamento do corante).

Os setores de DVD (blocos ECC) são 2048B , mas erros de byte único ou mesmo de bit único podem acontecer. Algumas unidades provavelmente fornecerão os dados incorretos incorretos em vez de um erro de leitura para o setor, especialmente se você ler no modo raw ou se for chamado.

    
por 10.08.2015 / 22:05
10

As outras respostas parecem mais preocupadas com erros de hardware. Deixe-me listar algumas corrupções causadas pelo software:

  • LF substituído por CRLF.
  • CR removido. (Mesmo que não seja seguido por LF)
  • Bytes extras nulos inseridos.
  • "Marca de pedido de bytes" extra Unicode inserida.
  • Conjunto de caracteres convertido de UTF-8 para Latin-1 ou vice-versa.
  • O caractere DOS EOF (# 1A) foi excluído, mesmo quando não está no fim do arquivo.

Essas coisas são bastante inofensivas quando ocorrem em arquivos de texto, mas geralmente são mortais quando aplicadas a arquivos binários.

    
por 11.08.2015 / 13:06
7

Use dd para truncar o arquivo ou tente um editor binário como hexer para editar e introduzir algumas corrupções.

Exemplo de truncar arquivo usando dd

Crie um arquivo de 5MB

# dd if=/dev/zero of=foo bs=1M count=5
5+0 records in
5+0 records out
5242880 bytes (5.2 MB) copied, 0.0243189 s, 216 MB/s
# ls -l foo
-rw-r--r-- 1 root root 5242880 Aug 12 20:13 foo
#

Truncar 10 bytes no final

# dd if=foo of=foo-corrupted bs=1 count=5242870
5242870+0 records in
5242870+0 records out
5242870 bytes (5.2 MB) copied, 23.7826 s, 220 kB/s
# ls -l foo foo-corrupted
-rw-r--r-- 1 root root 5242880 Aug 12 20:13 foo
-rw-r--r-- 1 root root 5242870 Aug 12 20:14 foo-corrupted
#

Página de manual do Hexer

HEXER(1)                              General Commands Manual                             HEXER(1)

NAME
   hexer - binary file editor

SYNOPSIS
   hexer [options] [file [...]]

DESCRIPTION
   hexer  is  a  multi-buffer  editor  for  viewing  and  manipulating binary files.  It can't
   (shouldn't) be used for editing block devices, because it tries to load the whole file into
   a  buffer (it should work for diskettes).  The most important features of hexer are:  multi
   buffers, multi level undo, command line editing with completion, binary regular expressions
   (see  below).   The  user  interface  is  kept similar to vi, so if you know how to use vi,
   you'll get started easily.
    
por 10.08.2015 / 20:34
2

Sugestão:

Comece a escrever em um arquivo e interrompa a gravação antes de terminar. Isso pode ocorrer durante cortes de energia e outros cenários.

Cenário da vida real:

Eu uma vez corrompi um arquivo zip tentando copiar mais dados para ele do que caberia no meio. O Windows (este era o Windows 7 no modo de segurança ftr) tentou concluir a ação antes de descobrir se havia espaço suficiente e, quando descobriu, o arquivo estava meio completo e, portanto, corrompido. Espero que eles tenham corrigido esse problema em versões posteriores do Windows ou que seja apenas uma coisa do modo de segurança.

    
por 11.08.2015 / 05:52
2

Outro tipo comum de distorção é o bit-twiddling: onde um único bit (ou múltiplos bits) são alternados em um fluxo de dados.

Então, um byte 1111 0000 pode se tornar, digamos, 1111 0010 ou 1011 0000 ou 1110 1100 ou qualquer outra coisa.

Os sistemas de soma de verificação de paridade e contagem-os-unidos têm problemas com coisas como 1110 1000 onde há um número igual de conjuntos e não definidos, uma vez que a paridade e o número de uns permanecem os mesmos.

Portanto, a substituição de todas as ocorrências de um caractere aleatório por seu inverso, digamos 0x57 a 0x75 ('9' a 'K') ou vice-versa, pode não ser detectável. Para sistemas que possuem mysql, o comando "replace" existe apenas para tal propósito:

replace K 9 < goodInputFile > corruptedOutputFile

Você também pode tentar trocar a letra K e 9 por volta, o que será um teste particularmente bom se ambos aparecerem no mesmo número de vezes no arquivo:

replace K 9 9 K < goodInputFile > corruptedOutputFile

Use man replace para mais informações.

    
por 11.08.2015 / 02:12
0

Alterações aleatórias em dados de teste corrompidos não são uma boa abordagem, já que você não pode reproduzir a amostra para executar novamente os testes.

Eu ficaria feliz com apenas 3 amostras, alterando apenas 1 bit no primeiro byte, no último byte e em qualquer byte médio. Mas apenas 1 bit, não o byte inteiro.

Mas o melhor exemplo de teste seria aquele em que você poderia gerar amostras alterando cada bit do arquivo do primeiro ao último byte. Isso não pode ser (normalmente) obtido com ferramentas usuais, você precisa construir um (eu acho).

Com essa abordagem, você isola muitas possibilidades, incluindo endianess, se seu algoritmo é baseado em um tipo de endianess. Em outras mãos, uma grande amostra pode consumir muito tempo para processar.

Por fim, alguns exemplos truncando ou adicionando bytes completarão seus testes.

    
por 11.08.2015 / 23:03