O que o dd conv = sync, noerror faz?

Question

Então, o que é o caso quando adicionar conv=sync,noerror faz diferença ao fazer o backup de um disco rígido inteiro em um arquivo de imagem? É conv=sync,noerror um requisito ao fazer material forense? Em caso afirmativo, por que é o caso com referência ao Linux Fedora?

Editar:

OK, então se eu fizer dd sem conv=sync,noerror e dd encontrar erro de leitura ao ler o bloco (vamos dimensionar 100M), o dd simplesmente pula o bloco de 100M e lê o próximo bloco sem escrever algo ( dd conv=sync,noerror escreve zeros para 100M de saída - então e quanto a este caso?)?

E se o hash do disco rígido original e o arquivo de saída forem diferentes se forem feitos sem conv=sync,noerror ? Ou isso é somente quando ocorreu um erro de leitura?

    

Answer 1

conv=sync informa dd para preencher cada bloco à esquerda com nulos, de forma que, devido a erro, o bloco inteiro não pode ser lido, o comprimento total dos dados originais é preservado, embora nem todos os dados em si podem ser incluídos na imagem. Dessa forma, você pelo menos sabe o quanto os dados estão danificados, o que pode lhe fornecer pistas forenses, e se você não puder tirar uma imagem de qualquer maneira devido a blocos defeituosos ou qualquer outra coisa, você não poderá analisar nenhum dos dados. alguns é melhor que nenhum.

conv=sync,noerror é necessário para evitar que dd pare em erro e execute um dump. conv=sync é largamente sem sentido sem nenhum erro.

link

link

    

Answer 2

dd conv=sync,noerror (ou conv=noerror,sync ) corrompe seus dados.

Dependendo do erro de E / S encontrado e do tamanho de setor usado (maior que o físico?), os endereços de entrada e saída não ficam sincronizados, mas acabam nos deslocamentos errados, o que torna a cópia inútil para o sistema de arquivos imagens e outras coisas em que as compensações são importantes.

Muitos lugares recomendam o uso de conv=noerror,sync ao lidar com discos defeituosos. Eu costumava fazer a mesma recomendação, eu mesmo. Isso funcionou para mim, quando tive que recuperar um disco danificado há algum tempo.

No entanto, testes sugerem que isso não é realmente confiável de forma alguma.

Use losetup e dmsetup para criar um dispositivo A error B :

truncate -s 1M a.img b.img
A=$(losetup --find --show a.img)
B=$(losetup --find --show b.img)
i=0 ; while printf "A%06d\n" $i ; do i=$((i+1)) ; done > $A
i=0 ; while printf "B%06d\n" $i ; do i=$((i+1)) ; done > $B

Os dispositivos de loop A, B são assim:

# head -n 3 $A $B
==> /dev/loop0 <==
A000000
A000001
A000002

==> /dev/loop1 <==
B000000
B000001
B000002

Então é A, B com números incrementais que nos ajudarão a verificar os offsets mais tarde.

Agora, coloque um erro de leitura entre os dois, cortesia do mapeador de dispositivos Linux:

# dmsetup create AerrorB << EOF
0 2000 linear $A 0
2000 96 error
2096 2000 linear $B 48
EOF

Este exemplo cria AerrorB como 2000 setores de A , seguido por 2*48 setores de erro, seguidos por 2000 setores de B .

Apenas para verificar:

# blockdev --getsz /dev/mapper/AerrorB
4096
# hexdump -C /dev/mapper/AerrorB
00000000  41 30 30 30 30 30 30 0a  41 30 30 30 30 30 31 0a  |A000000.A000001.|
00000010  41 30 30 30 30 30 32 0a  41 30 30 30 30 30 33 0a  |A000002.A000003.|
[...]
000f9fe0  41 31 32 37 39 39 36 0a  41 31 32 37 39 39 37 0a  |A127996.A127997.|
000f9ff0  41 31 32 37 39 39 38 0a  41 31 32 37 39 39 39 0a  |A127998.A127999.|
000fa000
hexdump: /dev/mapper/AerrorB: Input/output error

Então, ele lê até A127999\n , pois cada linha tem 8 bytes que totalizam 1024000 bytes, que são nossos 2000 setores de 512 bytes. Tudo parece estar em ordem ...

Será que vai se misturar?

for bs in 1M 64K 16K 4K 512 42
do
    dd bs=$bs conv=noerror,sync if=/dev/mapper/AerrorB of=AerrorB.$bs.gnu-dd
    busybox dd bs=$bs conv=noerror,sync if=/dev/mapper/AerrorB of=AerrorB.$bs.bb-dd
done

ddrescue /dev/mapper/AerrorB AerrorB.ddrescue

Resultados:

# ls -l
-rw-r--r-- 1 root root 2113536 May 11 23:54 AerrorB.16K.bb-dd
-rw-r--r-- 1 root root 2064384 May 11 23:54 AerrorB.16K.gnu-dd
-rw-r--r-- 1 root root 3145728 May 11 23:54 AerrorB.1M.bb-dd
-rw-r--r-- 1 root root 2097152 May 11 23:54 AerrorB.1M.gnu-dd
-rw-r--r-- 1 root root 2097186 May 11 23:54 AerrorB.42.bb-dd
-rw-r--r-- 1 root root 2048004 May 11 23:54 AerrorB.42.gnu-dd
-rw-r--r-- 1 root root 2097152 May 11 23:54 AerrorB.4K.bb-dd
-rw-r--r-- 1 root root 2097152 May 11 23:54 AerrorB.4K.gnu-dd
-rw-r--r-- 1 root root 2097152 May 11 23:54 AerrorB.512.bb-dd
-rw-r--r-- 1 root root 2097152 May 11 23:54 AerrorB.512.gnu-dd
-rw-r--r-- 1 root root 2162688 May 11 23:54 AerrorB.64K.bb-dd
-rw-r--r-- 1 root root 2097152 May 11 23:54 AerrorB.64K.gnu-dd
-rw-r--r-- 1 root root 2097152 May 11 23:54 AerrorB.ddrescue

Apenas a partir dos tamanhos de arquivo, você pode dizer que as coisas estão erradas para alguns blocos.

Checksums:

# md5sum *
8972776e4bd29eb5a55aa4d1eb3b8a43  AerrorB.16K.bb-dd
4ee0b656ff9be862a7e96d37a2ebdeb0  AerrorB.16K.gnu-dd
7874ef3fe3426436f19ffa0635a53f63  AerrorB.1M.bb-dd
6f60e9d5ec06eb7721dbfddaaa625473  AerrorB.1M.gnu-dd
94abec9a526553c5aa063b0c917d8e8f  AerrorB.42.bb-dd
1413c824cd090cba5c33b2d7de330339  AerrorB.42.gnu-dd
b381efd87f17354cfb121dae49e3487a  AerrorB.4K.bb-dd
b381efd87f17354cfb121dae49e3487a  AerrorB.4K.gnu-dd
b381efd87f17354cfb121dae49e3487a  AerrorB.512.bb-dd
b381efd87f17354cfb121dae49e3487a  AerrorB.512.gnu-dd
3c101af5623fe8c6f3d764631582a18e  AerrorB.64K.bb-dd
6f60e9d5ec06eb7721dbfddaaa625473  AerrorB.64K.gnu-dd
b381efd87f17354cfb121dae49e3487a  AerrorB.ddrescue

dd concorda com ddrescue apenas para tamanhos de bloco que estejam alinhados à nossa zona de erro ( 512 , 4K ).

Vamos verificar os dados brutos.

# grep -a -b --only-matching B130000 *
AerrorB.16K.bb-dd:  2096768:B130000
AerrorB.16K.gnu-dd: 2047616:B130000
AerrorB.1M.bb-dd:   2113152:B130000
AerrorB.1M.gnu-dd:  2064000:B130000
AerrorB.42.bb-dd:   2088578:B130000
AerrorB.42.gnu-dd:  2039426:B130000
AerrorB.4K.bb-dd:   2088576:B130000
AerrorB.4K.gnu-dd:  2088576:B130000
AerrorB.512.bb-dd:  2088576:B130000
AerrorB.512.gnu-dd: 2088576:B130000
AerrorB.64K.bb-dd:  2113152:B130000
AerrorB.64K.gnu-dd: 2064000:B130000
AerrorB.ddrescue:   2088576:B130000

Enquanto os dados em si parecem estar presentes, obviamente não estão em sincronia; os offsets estão completamente fora de sintonia para bs = 16K, 1M, 42,64K ... apenas aqueles com offset 2088576 estão corretos, como pode ser verificado contra o dispositivo original.

# dd bs=1 skip=2088576 count=8 if=/dev/mapper/AerrorB 
B130000

Este comportamento esperado é de dd conv=noerror,sync ? Eu não sei e as duas implementações de dd que eu tinha disponíveis nem sequer concordam umas com as outras. O resultado é muito inútil se você usou dd com uma escolha de tamanho de bloco de desempenho.

O texto acima foi produzido usando dd (coreutils) 8.25 , BusyBox v1.24.2 , GNU ddrescue 1.21 .