Grep deleted I

Semana passada, um colega questionou-me a respeito da existência de uma ferramenta para recuperação de arquivos deletados em Linux (ext2/ext3), falei-lhe sobre o velho truque do GREP, mas não convenci. Assim, resolvi mostrá-lo aqui.

Este método não é novidade para o ‘old school’, mas pode ser útil nos casos em que não há possibilidade de instalação de ferramentas específicas para a prática forense, entretando é mais um método quick and dirty, para ser mais claro. No próprio TSK existem diversas maneiras de fazer o mesmo, algo sobre o qual tentarei escrever futuramente.

No caso do colega, tratava-se de um arquivo ‘texto’, o arquivo crontab, utilizado para configuração do serviço cron que trata da execução de comandos agendados no Linux. Dessa forma, basta que o usuário conheça, pelo menos, o conteúdo de uma linha do arquivo bem como a partição na qual ele se encontrava.

Aqui, fiz uma simulação. Abaixo está o conteúdo do arquivo /etc/crontab na VM que utilizo (SIFT Workstation):

SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/
# run-parts
01 * * * * root run-parts /etc/cron.hourly
02 4 * * * root run-parts /etc/cron.daily
22 4 * * 0 root run-parts /etc/cron.weekly
42 4 1 * * root run-parts /etc/cron.monthly

Para remover o arquivo e forçar as mudanças no disco, utilizamos os seguintes comandos:

[tmp]# rm -f /etc/crontab
[tmp]# sync

Para saber em que partição estava localizado o arquivo, executamos o comando abaixo:

[tmp]# df /etc/
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda2             15283028   4959296   9547392  35% /

Assim, verificou-se que a partição /dev/sda2 continha o arquivo, logo, essa partição pode conter os dados relativos ao conteúdo do arquivo deletado (crontab). Mais informações sobre o processo – nominal – de remoção de arquivos, podem ser encontradas aqui.

Vale lembrar que, para obter sucesso neste procedimento, assume-se como condições essenciais: o conteúdo do arquivo foi gravado em blocos contíguos; tais blocos ainda não foram sobrescritos; e os buffers de disco foram atualizados após a remoção (comando sync).

A fragmentação do disco pode implicar na ausência da primeira condição, ou seja, o conteúdo do arquivo pode não ter sido gravado em blocos imediatos, adjacentes. Dificilmente, será percebida esta situação em nosso caso, dado que o arquivo é pequeno; a partição é grande suficiente para alocar blocos contíguos para o arquivo; e o índice de fragmentação é muito pequeno em sistemas de arquivos modernos, como é o caso do ext2/ext3. No momento do teste, o índice de fragmentação da partição estava em menos de 3% (man e2fsck para detalhes).

Enfim, podemos tentar encontrar o conteúdo do arquivo com o comando abaixo:

[tmp]# grep -a -A10 -B10 '42 4 1 \* \* root run-parts /etc/cron.monthly' /dev/sda2

Segue abaixo um screenshot referente ao retorno do comando:

Saída do comando GREP - clique para ampliar

Perceba que aparecem vários caracteres estranhos (binários), além do conteúdo de outros arquivos (/etc/group, configuração do pam, etc). Isso acontece porque os parâmetros “-B” e “-A” do comando grep indicam o número de linhas que deverão retornar antes e após o match, respectivamente. Ou seja, a saída contém exatamente 10 linhas antes e 10 linhas depois da própria linha passada como referência de busca, incluindo esta última. O parâmetro “-a” força o tratamento do dispositivo sda2 como um “arquivão” de texto.

Neste caso, facilmente podemos copiar da saída do comando o conteúdo que nos interessa. Para ficar mais claro, redirecionei a saída do comando para um arquivo e, em seguida,abri-o com um editor hexadecimal. Veja que as linhas do arquivo contrab são delimitadas pelo valor 0x0A que representa o caracetere ‘\n’ ou line-feed, no Linux, de acordo com a notação ASCII.

Saída em hexadecimal

Fica aqui um questionamento: a mesma abordagem pode ser aplicada na recuperação de arquivos binários?

No próximo post, tentarei mostrar como o arquivo crontab poderia ser recuperado por meio da utilização de outras ferramentas, como é caso dos comandos contidos no Sleuthkit.

5 thoughts on “Grep deleted I

  1. Bem legal a explicação…realmente bem didática, já postou esse mesmo caso com o sleuthkit, procurei mas não achei, estou ancioso por esse post. Parabéns pelo blog.

    Inté

  2. E tentando responder a pergunta do binário: Acho que não, pois analisando o conteudo de um binário vejo que o mesmo não é legível, até mesmo pela compilação do mesmo.
    Mas vale sua explicação.

    Enjoy

  3. Oi Alexandre gostei desse tópico e da pergunta no final, em minha humilde opinão acho que para procurar por arquivos binários tem que se usar algoritimos de verificação de contéudo(hash), com essa técnica acho que não daria, estou certo ou errado?

    1. Fala Mauro!

      A busca por hash é válida quando os arquivos ainda estão alocados no FS. No contexto aplicado ao post estamos falando de recuperação de arquivos – não – alocados.

      Neste caso a utilização de magic numbers ou simplesmente assinaturas de arquivos é o mais aplicável (vide foremost). Estou preparando um post a respeito!

      Valeu pela visita!

Comments are closed.