extrair o bloco de dados apontado por um inode não corresponde aos dados no arquivo [closed]

8

Esta questão é um derivado do seguinte: Como extrair dados brutos ext3 inode do disco?

Eu tenho um arquivo / tmp / foo, cujo conteúdo é uma simples cadeia de texto "AAA". Eu gostaria de localizar o bloco de disco # em que esses dados residem, extrair os dados neste bloco e certificar-se de que ele realmente contenha "AAA". Então eu faço o seguinte:

  1. stat foo que me diz que seu número de inode é 318903
  2. debugfs -R 'imap <318903>' /dev/vda3 que me diz que este inode está localizado no bloco 1277956, offset 0x0600
  3. dumpe2fs /dev/vda3 que informa que o tamanho do bloco é 4096 (bytes) e o tamanho do inode é 256 (bytes)
  4. calcula o deslocamento do inode a partir do início do disco em pedaços de 256 bytes (torna mais simples usar o dd para extrair um bloco de 256 bytes): (1277956 x 4096) + (1536) / 256 = 20447302
  5. extrai o inode do disco (dados brutos): dd if = / dev / sda3 de = / tmp / inode.0 bs = 256 count = 1 skip = 20447302
  6. Veja a estrutura da tabela inode ext2 (o inode ext3 tem estrutura idêntica): link
  7. Execute alguns testes para determinar se extraí o bloco de inode correto: %código%. A saída do cmp é a seguinte:
13 217 362
14 225 222
25   1   0
Referenciando a estrutura do inode, vemos que o byte 25 corresponde a i_gid, portanto, isso confirma que realmente extraímos o bloco de inode correto do disco (o grupo anterior era 0, agora é 1). Também pode realizar testes semelhantes, como alterar a propriedade, alterar o tamanho do arquivo adicionando dados, extrair novamente o inode do disco e esses testes continuam a confirmar que temos o bloco de inode correto.

  1. Agora, de acordo com a documentação, os bytes 41-44 da tabela de inodes contêm um ponteiro para o bloco de dados (o bloco # do conteúdo real do arquivo - os dados do arquivo). Se fizermos uma comparação byte-by-byte do nosso inode com um arquivo zero, poderemos ver o valor dos bytes 41-44: chgrp 1 /tmp/foo; dd if=/dev/sda3 of=/tmp/inode.1 bs=256 count=1 skip=20447302; cmp -l /tmp/inode.1 /tmp/inode.0
 25   1   0
 27   1   0
 29  10   0
 41  56   0
 42 220   0
 43  23   0
101 275   0
102  53   0
103 240   0
104 374   0

"cmp" fornece valores em octal. Então, assumindo que o byte 44 é o byte de alta ordem, então o valor do ponteiro em octal é 23 | 220 | 56. convertendo isso para binário = 10011 | 10010000 | 00101110, ou 100111001000000101110. Convertendo isto para decimal = 1282094

  1. agora, "1282094" é um número de bloco razoável para nossos dados? Se olharmos novamente para a saída dos dumpefs, vemos que tanto o nosso inode (bloco 1277956) quanto os nossos dados (bloco 1282094) estão dentro do intervalo coberto dentro do grupo de blocos 39, então parece que temos um número razoável:

Group 39: (Blocks 1277952-1310719) Inode table at 1277954-1278464 (+2)

  1. Então, devemos usar o dd para extrair o bloco de dados do disco, examinar seu conteúdo e eles devem corresponder ao conteúdo do nosso arquivo ("AAA"). Mas isso não é o que acontece. O que acontece é que o bloco de dados contém outras coisas e não há "AAA" em nenhum lugar: cmp -l /tmp/inode.1 /tmp/zero.256
   1 333   0
   2 335   0
   3   4   0
   5  14   0
   7   1   0
   8   2   0
   9  56   0
  13 221   0
  14 335   0
  15   4   0
  17 364   0
  18  17   0
  19   2   0
  20   2   0
  21  56   0
  22  56   0

Isto não se parece com o conteúdo de / tmp / foo. Eu estava pensando que talvez estivesse em um bloco, então eu também extraí os blocos ao redor (1282093 e 1282095), mas ainda não encontrei o que estava procurando.

O que está acontecendo aqui? O que é esse material extra e por que não há "AAA"?

11/14. RESOLVIDO Acontece que o sistema de arquivos tinha alguns problemas (inodes órfãos e outros enfeites) que eu corrigi com fsck e agora tudo está se comportando como esperado. Quero agradecer muito a Wumpus e Derobert (ver comentários) que ofereceram muitos insights e sugestões valiosos. Impressionante.

    
por Michael Martinez 12.11.2014 / 18:55

0 respostas

Tags