Artigo Felipe Goi

1

ANÁLISE E RECUPERAÇÃO DE DADOS COM

FERRAMENTAS FORENSES

Felipe Goi Guidolin <[email protected]>

Luiz Gustavo Galves Mählmann <[email protected]> – Orientador

Universidade Luterana do Brasil (Ulbra) – Curso Superior de Tecnologia em Redes de Computadores – Campus Canoas

Av. Farroupilha, 8.001 – Bairro São José – CEP 92.425-900 – Canoas – RS.

30 de novembro de 2012

RESUMO

O presente artigo faz uma análise de ferramentas de recuperação de dados forenses com o objetivo de

conhecer como e em que cenários elas podem ser empregadas. O tipo de análise escolhida foi a “Post Mortem”, com

imagens de discos sendo utilizadas para os testes. Dentre as diversas ferramentas disponíveis no mercado, foram

eleitas quatro delas para que sejam efetuadas as análises: Foremost, Scalpel, The Sleuth Kit (TSK)/Autopsy e FIK

Imager, sendo uma delas proprietária e as demais de código livre. Assim como nas ferramentas foram elencadas

algumas, os sistemas de arquivos também foram elencados em três tipos, para a criação das imagens: ext3, ext4 e

NTFS. Os dados foram sabatinados em quatro cenários diferentes. No primeiro, os arquivos são excluídos de forma

simples de partições de 100MB. No cenário 2, as partições que tiveram seus arquivos apagados têm seu espaço

completamente preenchido por outros arquivos, que não possuem qualquer relação com os primeiros. No terceiro

cenário, os arquivos são excluídos de partições com espaço de armazenamento de 200MB. No quarto, e último

cenário, um arquivo que ocupe 40% do disco é copiado para as partições de 200MB, que tiverem seus dados

apagados. O emprego das ferramentas de recuperação das informações serve ao propósito principal: da recuperação

dos dados perdidos e análise dos diferentes comportamentos ocorridos, conforme o tipo de sistema que é analisado,

bem como do cenário no qual está inserido.

Palavras-chave: Recuperação de Dados; Imagens; Partição; Sistema de Arquivos; “Post Mortem”.

ABSTRACT

Title: “Analysis and Data Recovery Tools with Forensic”

This article is an analysis tool for forensic data recovery in order to know how and in what scenarios they

can be employed. The type of analysis chosen was the "Post Mortem" with disk images being used for testing. Among

the various tools available on the market, four of them were elected to be performed analyzes: Foremost, Scalpel,

The Sleuth Kit (TSK) / Autopsy Imager and FIK. Being one proprietary and the other open source. As with some tools

were listed, file systems were also listed three types, the creation of images: ext3, ext4 and NTFS. Data were

sabatinados in four different scenarios. In the first files are simply deleted partition of 100MB. In scenario 2, the

partitions that have their files deleted, its space is completely filled by other files, which have no relation to the first.

In the third scenario, files are deleted partition with 200MB of storage space. In the fourth and last scenario, a file

that occupies 40% of the disk is copied to the partition of 200MB, which have their data deleted. The use of recovery

tools the information serves the primary purpose of which is the recovery of lost data and analysis of different

behaviors occurring, depending on the type of system is examined as well as the setting in which it is inserted.

Key-words: Data recovery; Images; Partition; File System; “Post Mortem”.

1 INTRODUÇÃO

Nos dias atuais, manter os dados comuns ou mesmo confidenciais a salvo é um grande desafio.

Infelizmente, nem todos os gestores de Tecnologia da Informação (TI) estão preparados para isso. Ademais,

devemos nos preocupar, também, com a perda do maior ativo das corporações, a informação. Esta pode ser

perdida de forma acidental ou provocada, quando os servidores da empresa são invadidos. Tal recuperação

pode ser efetuada por usuários comuns, os que apagam acidentalmente suas informações ou, ainda, por

cibercriminosos, o que acaba implicando uma série de investigações comandadas por peritos forenses. Com

o intuito de levantar evidências que os levem até os culpados.

Grande parte dos dados e documentos utilizados no desenvolvimento das atividades laborais,

escolares ou mesmo domiciliares estão guardadas em algum dispositivo digital de armazenamento. Junto

com a popularização dos computadores, veio a da Internet. Esse fato contribuiu significativamente para

melhoria das comunicações e para a troca de arquivos e informações. Uma terceira etapa dessa evolução foi

o aumento significativo da capacidade de armazenamento dos discos rígidos (HD), e que são

disponibilizados ao mercado consumidor por preços muito atraentes. Não satisfeitas com os três passos

2

anteriores, as pessoas aumentaram o consumo de bens responsáveis pela geração de conteúdos digitais, como

gravador de voz, câmera digital, celulares, filmadoras digitais, entre outros. Com toda essa carga de

informação armazenada nos computadores, esses se tornam um verdadeiro dossiê acerca das atividades de

uma pessoa – seja ela de natureza física ou jurídica.

É através dos equipamentos digitais e vestígios encontrados em uma cena de crime, que podemos

traçar um perfil do criminoso. Apesar da grande importância das evidências aparentes, os dados que foram

excluídos com o intuito de dificultar as investigações ou mesmo por não serem mais pertinentes a seus

proprietários podem trazer uma carga de informações elucidativas para a investigação. Para dificultar ainda

mais o processo investigativo, muitos invasores de computadores utilizam-se de técnicas antiforenses,

apagando os arquivos utilizados para esconder os seus registros de atividades.

Objetiva-se, com o presente artigo, efetuar uma análise qualitativa de quatro ferramentas forenses

mais utilizadas para a recuperação de dados dentro de um sistema de arquivos.

Serão utilizados, para o desenvolvimento deste, métodos de pesquisa bibliográfica e experimental,

em que serão testadas as ferramentas dentro de um ambiente controlado.

2 DEFINIÇÕES E CONCEITOS

Ao longo deste capítulo, serão apresentadas as definições e conceitos acerca da análise forense

computacional com o intuito de facilitar a compreensão global e seu contexto.

2.1 Sistema Invadido

Para que as evidências apuradas sejam aceitas como válidas, devem ser observadas algumas

peculiaridades. Segundo Ieong (2006), são elas:

Reconhecimento: o investigador deve exaurir todos os recursos em mãos para descobrir, coletar,

extrair preservar e analisar os dados de forma que estes se tornem uma evidência válida.

Confiança: para que o dado coletado não seja repudiado, deve-se garantir que ele seja copiado tal

qual o é na realidade, ou seja, deve-se manter tanto sua integridade no conteúdo como a data e

hora do último acesso, seus donos e permissões, etc.

Relevância: deve-se garantir que apenas os dados relevantes, ou seja, que possam ser realmente

aproveitados para a resolução do caso em questão sejam gastos da melhor forma possível.

Segundo Eleutério e Machado (2011), “a computação forense tem como objetivo principal

determinar a dinâmica, a materialidade e autoria de ilícitos ligados à área de informática tendo como

questão principal a identificação e o processamento de evidências digitais em provas materiais de crime,

por meio de métodos técnico-científicos, conferindo-lhe validade probatória em juízo.”

A computação forense digital é utilizada por peritos, quando o crime a ser investigado envolva

informações digitais que estejam armazenadas, em equipamentos para esta finalidade, ou em computadores

de usuários. Podem utilizar-se das técnicas de análise forense computacional administradores de rede que

suspeitem que seus dados estejam sendo apropriados por pessoas mal–intencionadas e que ensejam o

prejuízo da corporação. Entretanto, caso as evidências sejam coletadas por esse segundo nicho de

profissionais, elas servirão apenas para apresentação à diretoria da empresa porque não poderão ser utilizadas

em uma ação judicial.

O primeiro passo a ser adotado antes do início da coleta de dados é o planejamento, a fim de que

nenhum dado que seja volátil se perca.

Após concluída a etapa de planejamento, inicia-se a coleta de dados críticos. Esses dados somente

podem ser obtidos ainda com o equipamento ligado e ainda conectado à rede. A essa etapa dá-se o nome de

análise viva (“Live Analysis”). Concluído o levantamento, anteriormente referido, o equipamento já pode ser

desligado para que tenha início a segunda etapa de coleta de evidências denominada análise morta (“Post

Mortem”).

A análise morta somente poderá ser executada se o equipamento a ser analisado puder ser desligado

e a unidade de armazenamento retirada. Essa unidade será copiada bit a bit para outro local e toda a análise

será desencadeada em cima da cópia preservando os dados originais. Só a partir desse momento o perito irá

iniciar a coleta de evidências que servirão de provas materiais.

3

Muitas vezes, o perito não pode realizar a análise anterior porque o equipamento em questão é um

servidor – muitas vezes o único da empresa – e do qual toda a atividade econômica desempenhada depende

de seu funcionamento. Outra questão, segundo Melo (2009), é o atual tamanho das unidades de

armazenamento, que já estão na grandeza dos Terabytes, fazendo com que uma cópia bit a bit torne-se

laboriosa pela questão tempo e custo envolvidos.

2.2 Preservação

Devem ser tomados alguns cuidados ao utilizar o equipamento investigado, porque uma ação trivial,

como a abertura de uma pasta, irá efetuar mudança nos dados e acabará prejudicando o processo

investigativo. Se o equipamento em questão encontrar-se desligado, jamais deve-se ligá-lo novamente

porque esta simples ação irá alterar algumas evidências, tais como: datas de último acesso a arquivos do

sistema operacional e a geração de novos arquivos temporários de sistema – mesmo que não seja executada

nenhuma ação.

A técnica de espelhamento é a mais utilizada, visto que consiste em uma cópia fiel dos dados. Para

isso, o disco de destino deverá ter, no mínimo, capacidade igual ao de origem. Deve-se redobrar o cuidado

quanto à capacidade de armazenamento, pois muitos HDs disponíveis para venda possuem a mesma

capacidade nominal, mas, se for observada a capacidade real, serão encontradas algumas discrepâncias muito

significativas.

Se o dispositivo de destino tiver sua capacidade real maior que o de origem, é necessário garantir que

o espaço restante esteja realmente limpo, sem nenhum dado, para que não haja interferência no resultado

final da análise. Para isso, deve-se utilizar um processo chamado “wipe”, que nada mais é que a exclusão de

um arquivo ou de uma partição inteira e a gravação de bytes na área que anteriormente estava ocupada. Com

isso, um software que execute uma leitura binária no disco rígido encontrará apenas os dados que foram

gravados através do processo de duplicação e não os que estavam armazenados anteriormente.

De nada adianta, também, utilizar um HD de destino que contenha setores defeituosos, pois os dados

de origem que estiverem alocados na mesma posição da falha não serão copiados e, com isso, a duplicação

fica incompleta e perdem-se evidências muitas vezes cruciais à investigação. Estudos recentes indicam,

ainda, que esses setores tendem a aumentar e, com isso, aumentar a perda de dados e evidências.

2.3 Sistema de Arquivos

“Usando uma definição simples, pode-se dizer que Sistema de Arquivos são estruturas lógicas que

permitem que um sistema operacional consiga escrever, acessar e organizar dados dentro de um disco

rígido. Ou seja, é a forma utilizada pelo sistema para encontrar um dado ou um arquivo necessário no disco

depois de gravado. Basicamente, todos os sistemas fazem uso de uma tabela onde são associados os

metadados de um arquivo e o espaço ocupado por ele no disco.” (JOSILENE, 2010, p. 24)

Para que os dados possam ser gravados e acessados, o HD é dividido em setores. Os blocos ou

clusters é o agrupamento desses setores, e o nome pelo qual é chamado e o tamanho são determinados pelo

sistema. Na Figura 1, pode-se verificar um exemplo da localização dos clusters.

FIGURA 1 – Divisão do disco em clusters, setores e trilhas (SIMÃO, 2012).

4

Cada sistema operacional utilizado tem um sistema de arquivos próprio. No Windows, sistema

operacional da Microsoft, atualmente o utilizado é o NTFS. Nas distribuições Linux, são o Ext3 e o Ext4,

mas existem ainda outros.

2.3.1 Sistema de Arquivos NTFS

O NTFS (New Tecnology File System) foi desenvolvido pela Microsoft quando ela resolveu criar o

Windows NT, e é utilizado por esse sistema operacional e todos os que dele derivaram. Ele já foi concebido

com suporte a endereçamentos de cluster na ordem de 64bits e com 512bytes de tamanho para cada um

destes – independente do tamanho da partição. Neste conceito, o que seria vantajoso em termos de espaço,

seria extremamente desvantajoso em termos de processamento de informação, uma vez que o processador

teria muito mais trabalho para encontrar os dados em meio à grande quantidade de clusters. Desse modo,

ficou estabelecido que, para as partições maiores que 2GB, o tamanho dos clusters foi fixado em 4KB por

default e este valor poderia ser alterado pelo usuário (MARIMOTO 2007).

Outra vantagem do NTFS é a gravação inteligente dos arquivos, na qual esses são salvos de forma

sequencial no HD. Para alocação de novos arquivos, esse sistema tenta gravar os dados na menor área que

ele consiga se encaixar totalmente. Dessa forma, ele otimiza o processo de ocupação da partição e diminui a

fragmentação dos dados.

2.3.2 Sistema de Arquivos Ext

No sistema Linux, o formato de arquivos utilizados é o Ext (Extended File System). Atualmente, o

Ext3 é o mais utilizado pelas distribuições existentes, sendo que em algumas já é utilizado o sistema de

arquivos Ext4, a última versão dos sistemas de arquivos Linux. A primeira versão do formato Ext suportava

partições de, no máximo, 2GB – o que já era muito pouco quando lançado. Isso sem falar que os arquivos

eram facilmente fragmentados, demorando mais tempo que o necessário quando fosse solicitada a abertura

destes.

Depois de transcorridos, aproximadamente, 9 anos do lançamento do Ext, surgiu o Ext3 com um

recurso chamado journaling, uma espécie de log que é preservado durante todo o processamento dos dados e

quando os arquivos são alterados. Esse recurso é muito útil quando o sistema é desligado de forma incorreta,

pois são observadas apenas as informações contidas no log e, com isso, é efetuada a recuperação do mesmo.

Além disso, o Ext3 possui entradas de 32bits, o que significa que podem existir partições de até 32GB.

A gravação dos dados inicia buscando o primeiro bloco disponível no início do sistema de arquivos.

Com o intuito de minimizar a fragmentação dos dados e a movimentação da cabeça de leitura do disco

rígido, esse sistema de arquivos trabalha de forma pró-ativa, reservando conjuntos de blocos para pastas e

arquivos que estejam em franco crescimento.

Em 21 de agosto de 2008, foi lançado o sistema de arquivos Ext4. Com endereçamento de 48bits, as

partições podem ser de, até, 1EB (Exabyte1), sendo ilimitada a quantidade de subdiretórios enquanto, no

Ext3, a quantidade máxima estava na ordem de 32000.

Com o Ext4, foi reduzida, ainda mais, a fragmentação de arquivos em relação ao seu antecessor. Isso

se deve ao fato de serem utilizados diversos recursos de forma simultânea que, segundo Jones (2009), são:

Pré-Alocação de Arquivos: blocos adjacentes aos utilizados por um arquivo que esteja em

edição são reservados, de forma estimada, para serem utilizados após a finalização e

gravação das alterações sofridas por este.

Atraso na Alocação de Blocos: os dados apenas são gravados fisicamente no disco, quando

estritamente necessário. Quanto mais adiado o processo de gravação puder ocorrer, mais

blocos serão disponibilizados e, com isso, a probabilidade de as partes do arquivo serem

gravadas de maneira sequencial aumenta significativamente.

Múltipla Alocação de Blocos: através da utilização deste recurso, o processamento e a

fragmentação de dados sã reduzidos, pois quanto mais blocos forem alocados ao mesmo

tempo, um número menor de chamadas do algoritmo de alocação é necessário e,

consequentemente, as chances de os arquivos serem fragmentados também são reduzidas.

1 1EB=1024PB, 1PB=1024TB e 1TB=1024GB.

5

Mesmo com todos esses recursos simultâneos sendo utilizados, com o passar do tempo, os arquivos

acabam sendo fragmentados. Então, entra em cena o recurso de desfragmentação online – sem a necessidade

de que sejam adquiridas ou mesmo instaladas novas ferramentas – que faz a realocação dos arquivos.

A ferramenta de FSCK, presente no Ext4, possui um recurso muito interessante, que é a marcação de

blocos não utilizados com o intuito de que esses não sejam verificados durante o processo de correção. Com

isso, acelera-se todo o processo de verificação.

2.4 Alguns Exames Forenses Computacionais

Conforme Eleutério e Machado (2011), embasados em suas experiências profissionais, os principais

exames forenses são:

Exames e procedimentos em locais de crime de informática: têm como principais

objetivos o mapeamento, identificação e correta preservação dos equipamentos, a fim de que

passem por uma refinada seleção do que deve ser apreendido para ser analisado em

laboratório posteriormente.

Exames em dispositivos de armazenamento computacional: esses exames possuem

quatro fases bem distintas, mas interdependentes, que são a preservação, extração, análise e

formalização. Para que isso ocorra, muitas vezes, faz-se necessário recuperar arquivos

apagados, quebrar senhas ou mesmo virtualizar as informações contidas na mídia de

armazenamento que está sendo investigada. Tais mídias de armazenamento podem ser HDs,

DVDs, CDs, Blu Ray, pen drives ou outra mídia onde os dados possam ser armazenados.

Exames em aparelhos de telefone celular: é o simples processo de extração de

informações, como fotos, mensagens, listas de contato e ligações que ficam armazenadas na

memória do aparelho e, com isso, formalizar as informações.

Exames em sites da internet: é o processo de aquisição de informações, verificação e

cópia, de conteúdos disponíveis na rede nos mais diversos sites e servidores de diferentes

finalidades e empresas. E, com isso, chega-se ao responsável pela divulgação através do

endereçamento IP.

Exames em e-mails: é a análise da mensagem com a finalidade de obter alguns dados que

levem ao verdadeiro remetente do e-mail. Os dados analisados consistem na data, hora e no

endereço IP que enviou tal correspondência.

3 EXAMES

Realizaram-se os testes, tendo como sistema operacional base para o cenário Linux a distribuição

Mandriva Linux 2011, Kernel 2.6.38.7-desktop-lmnb2. Foram utilizadas as ferramentas Foremost, Scalpel e

TSK/Autopsy. No ambiente Microsoft, os testes foram realizados tendo como base o Windows 7

Professional e a ferramenta a ser analisada foi a FTK Imager. Os sistemas operacionais do ambiente de testes

são de 32bits.

3.1 Montagem do Sistema de Arquivos

Foi realizada a instalação dos sistemas de arquivos para os testes, criando em arquivos dentro do

sistema utilizado e posteriormente montados como partições. A ordem de instalação e montagem de cada um

deles é descrito na Tabela 1, conforme o modelo de Jones (2007). Foram estabelecidas partições de

diferentes tamanhos, 100MB e 200MB para facilitar a manipulação de arquivos e a análise dos dados, na

sequência.

Com a limitação de o dispositivo de “loopback” não poder ser ocupado de forma total e

concomitante por dois ou mais sistemas de arquivos, a montagem dos sistemas de 100MB e 200MB foi

executada em diferentes momentos.

6

Formato Imagens 100MB Imagens 200MB

ext3

dd if=/dev/zero of=ext3.img bs=1k

count=100000


count=200000

losetup /dev/loop0 ext3.img losetup /dev/loop0 ext3.img

mkfs.ext3 –c /dev/loop0 100000 mkfs.ext4 –c /dev/loop0 200000

mkdir /mnt/disco1 mkdir /mnt/disco1

mount –t ext3 /dev/loop0 /mnt/disco1 mount –t ext3 /dev/loop0 /mnt/disco1

ext4


count=100000


count=200000

losetup /dev/loop1 ext4.img losetup /dev/loop1 ext4.img

mkfs.ext4 –c /dev/loop1 100000 mkfs.ext4 –c /dev/loop1 200000



NTFS

dd if=/dev/zero of=ntfs.img bs=1k

count=100000


count=200000

losetup /dev/loop2 ntfs.img losetup /dev/loop2 ntfs.img

mkfs.ntfs –c /dev/loop2 100000 mkfs.ntfs –c /dev/loop2 200000



Tabela 1 – Ordem de montagem das partições utilizadas no processo de testagem.

As partições têm por objetivo serem a base das imagens analisadas pelas ferramentas forenses. Essas

imagens nada mais são que uma cópia fiel do sistema a ser analisado.

Os comandos apresentados na Tabela 1 para cada um dos sistemas de arquivos apresentados e

tamanhos de imagem realizam as seguintes ações:

Criação de um arquivo inicializado;

Simulação de um dispositivo em bloco;

Criação do sistema de arquivos com o “dispositivo de bloco”;

Criação do ponto de montagem;

Montagem do sistema de arquivos.

Abaixo, na Figura 2, pode-se verificar a criação da imagem de 100MB com o sistema de arquivos

ext3. Na Figura 3, pode-se verificar a criação da imagem de 200MB, com o mesmo sistema de arquivos

anterior.

7

Figura 2 – Criação da imagem de 100MB com sistema de arquivos ext3.

Figura 3 - Criação da imagem de 200MB com sistema de arquivos ext4.

8

As imagens foram preparadas executando-se diversos processos de escrita, exclusão, inclusão e

alteração de dados. Todas essas ações formam as imagens e foram organizadas em cenários, que serão

apresentados em seguida.

3.2 Cenários

Foram escolhidos vinte e cinco (25) arquivos – os mesmos para todos os testes – de extensões

diferentes, os quais foram copiados para as partições montadas. Todos foram relacionados na Tabela 2 e

perfazem um tamanho de 28,1MB.

Objetiva-se, neste trabalho, recuperar arquivos apagados do disco. Para tal, foram preparados quatro

cenários onde foram aplicados diversos testes. Sendo que cada uma das simulações representa uma situação

de exposição dos mesmos dentro de um sistema de arquivos.

TIPO TAMANHO

Imagens JPG 19KB e 549KB

Imagens GIF 197KB, 149KB, 12KB e 169KB

Imagens BMP 5.626KB E 901KB

Imagens PNG 1315KB

Áudio MP3 4.949KB e 7.824KB

Vídeo FLV 755KB

PDF 638KB

Apresentação

(Power Point) 184KB, 371KB e 1.586KB

Planilhas (Excel) 67KB e 103KB

Documento

(Word) 16KB, 67KB e 21KB

Arquivos zip 54KB e 27KB

Arquivos exe 2.519KB e 723

Tabela 2 – Arquivos copiados para as imagens que as ferramentas tentaram recuperar.

3.2.1 Sistema de Arquivos NTFS

Neste primeiro teste, exemplifica-se o caso de exclusão de arquivo do disco e o início da tentativa de

recuperação, sem que o sistema tenha sofrido quaisquer alterações. Tem-se por objetivo a testagem do

desempenho das ferramentas e o comportamento dos sistemas durante o processo de recuperação dos

arquivos que foram excluídos recentemente.

Nas partições de 100MB, formatadas conforme a Tabela 1, foram seguidos os seguintes passos:

Cópia dos 25 arquivos;

Desmontagem e montagem;

Exclusão dos arquivos;

Desmontagem e montagem.

Nota-se que o processo de desmontagem e montagem repete-se em diferentes momentos com o

intuito de excluir quaisquer pedaços que informação que, por ventura, tenham restado no “buffer” dos

sistemas. Caso isso não seja seguido, os resultados podem ser invalidados, visto que estariam

“contaminados” com as informações na memória do sistema.

Foi executado o “script” “<sistema_arquivos>_01.dd” Figura 4, a fim de gerar as imagens para

execução dos testes do primeiro cenário.

9

#!/bin/bash

# Imagens com os arquivos deletados e sobrescritos com as partições totalmente populadas de dados.

Os arquivos utilizados para sobrescrever os do Cenário 1 foram igualmente deletados.

dd if=/dev/loop0 of=/home/goi/arquivostcc/cenario2/ext3_02.dd


dd if=/dev/loop2 of=/home/goi/arquivostcc/cenario2/ntfs_02.dd

Figura 4 – “Script” de criação das imagens do primeiro cenário.

3.2.2 Cenário 2

Nesta etapa do processo, as partições das quais os arquivos foram apagados terão seu espaço

disponível totalmente ocupado por novos arquivos, sem qualquer vínculo com os primeiros. Por sua vez,

também esses foram apagados da partição antes da criação da imagem a ser analisada.

A probabilidade de os arquivos do Cenário 1 terem sido completamente apagados é grande. Utiliza-

se, então, as ferramentas para testar sua capacidade de recuperação com o intuito de encontrar algum arquivo

ou mesmo fragmentos desses.

Utilizaram-se, neste cenário, as mesmas partições de 100MB do Cenário 1. E foram executados os

seguintes processos:

Cópia de arquivos que não possuíam nenhuma relação com os existentes no Cenário 1, para

preenchimento de todo espaço disponível;


Limpeza da partição;


Para gerar a imagem deste cenário e que será utilizada posteriormente, foi executado o “script”

apresentado na Figura 5, “<sistema_arquivos>_02.dd”.

#!/bin/bash






Figura 5 - “Script” de criação das imagens do segundo cenário.

3.2.3 Cenário 3

Neste terceiro cenário, repete-se o processo do primeiro. Entretanto deve-se atentar ao fato de que o

tamanho desta partição é o dobro da primeira, 200MB. Criou-se essa diferenciação com o propósito de

sobrar bastante espaço livre. O comportamento do terceiro cenário é o mesmo apresentado no primeiro, com

a diferença do espaço de armazenamento disponível, que é maior, permitindo, assim, que os arquivos sejam

distribuídos em mais áreas do disco.

O “script” apresentado na Figura 6, “<sistema_arquivos>_03.dd”, gera a imagem para posterior

análise das ferramentas de recuperação.

10

#!/bin/bash






Figura 6 - “Script” de criação das imagens do terceiro cenário.

3.2.4 Cenário 4

Para a execução dos testes neste quarto cenário, foi utilizado um único arquivo com um tamanho de

80MB, o qual ocupa quase a metade do espaço disponível e excede o tamanho dos arquivos a serem

recuperados. Conforme a manipulação e a formatação do sistema em teste, os arquivos que devem sofrer o

processo de recuperação podem ou não ter sido sobrescritos, dificultando ou facilitando o trabalho das

ferramentas testadas. O arquivo adicionado no segundo momento também foi removido antes da geração das

imagens.

A partição utilizada foi a mesma de 200MB, empregada para a geração de imagem do Cenário 3. Os

processos adotados são:

Cópia de um arquivo qualquer de 80MB;


Limpeza da partição;


Conforme indicado na figura abaixo, Figura 7, geraram-se as imagens de acordo com o “script”

“<sistema_arquivos>_04.dd” para análise em um segundo momento.

#!/bin/bash

# Imagens com os arquivos deletados e sobrescritos para que restem espaços vazios, com seu próprio

tamanho. O arquivo de sobrescrição utilizado também foi deletado.




Figura 7 - “Script” de criação das imagens do quarto cenário.

Na tabela abaixo, Tabela 3, estão listados os arquivos de imagens de cada cenário.

CENÁRIO 1 CENÁRIO 2 CENÁRIO 3 CENÁRIO 4

ext3 ext3_01.dd ext3_02.dd ext3_03.dd ext3_04.dd

ext4 ext4_01.dd ext4_02.dd ext4_03.dd ext4_04.dd

ntfs ntfs_01.dd ntfs_02.dd ntfs_03.dd ntfs_04.dd

Tabela 3 – Lista dos arquivos de imagem a serem analisados, de cada um dos cenários.

3.3 Realização dos Exames

Após todo o processo de geração das imagens, terá início a realização das análises. Ao longo desta

seção, será detalhado todo o processo de testagem e comportamento de cada ferramenta.

11

3.3.1 Foremost

A ferramenta foi instalada de forma padrão, sem que tenha sido executada nenhuma configuração

adicional. As análises foram realizadas individualmente, sendo iniciados os testes através de uma linha de

comando.

A execução da ferramenta e a inicialização do teste tiveram início ao ser digitada a seguinte linha de

comando;

foremost –i <nome_da_imagem> -o <pasta_de_destino>

Tal comando deverá ser repetido para cada um dos sistemas de arquivo e cenários testados.

Iniciada a busca, todos os tipos de arquivos suportados pelo Foremost seriam buscados dentro da

imagem especificada. Um exemplo de teste da ferramenta é realizar o teste da imagem da partição ext4 do

cenário 1. O retorno da ferramenta deu-se na pasta de nome resultados_cenario1, onde o comando foi

executado. Como exemplo prático da linha de comando, cita-se:

foremost –i ext3_01.dd ext3_01

Para cada cenário testado, a ferramenta gerava uma pasta com os arquivos separados por pastas,

segregados de acordo com as extensões.

3.3.2 Scalpel

Os testes realizados pelo Scalpel, bem como suas saídas, são semelhantes ao Foremost. Entretanto,

diferentemente da ferramenta anterior, foram necessários alguns ajustes na mesma para que funcionasse

conforme o desejado - diferentemente do software anterior, em que as opções eram chamadas através de

linha de comando e sim através da edição de um arquivo chamado “scalpel.conf”. Na Figura 8, pode-se

observar um trecho do arquivo “scalpel.conf”.

#---------------------------------------------------------------------------------------------------

# HTML

#---------------------------------------------------------------------------------------------------

#

# htm n 50000 <html> </html>

#

#---------------------------------------------------------------------------------------------------

# ADOBE PDF

#---------------------------------------------------------------------------------------------------

#

pdf y 5000000 %PDF %EOF\x0d REVERSE

pdf y 5000000 %PDF %EOF\x0a REVERSE

Figura 8 – Trecho do arquivo scalpel.conf

A fim de que sejam recuperados os arquivos de determinadas extensões, deve-se retirar o sinal de #

que a precede. Após concluído o processo de seleção das extensões, deve-se salvar o arquivo e iniciar o

processo de testagem de todos os cenários e sistemas, conforme o exemplo, Cenário 1 e uma imagem de

sistema ext 3, da linha de comando abaixo:

scalpel ext3_01.dd –c /etc/scalpel/scalpel.conf –o ext3_01

Para receber o resultado da ferramenta, é criada uma pasta com o nome “ext02_2”, e os arquivos são

divididos em subpastas de acordo com suas extensões.

3.3.3 TSK/Autopsy

Os exames realizados pela ferramenta TSK são executados através de uma ferramenta gráfica via

“web”, o Autopsy.

Para ativar o Autopsy, utiliza-se, dentro da pasta onde a ferramenta foi compilada, a linha de

12

comando:

/usr/bin/autopsy [-c] [-C] [-d evid_locker] [-i device filesystem mnt] [-p port] [remoteaddr]

Os argumentos utilizados acima ativam as seguintes opções:

-c: forçar um “cookie” na URL;

-C: não forçar “cookies” na URL;

-d dir: especificar o diretório de evidências;

-i device filesystem mnt: especifica informações para análise viva;

-p port: especifica a porta do servidor;

remoteaddr: especifica o host do navegador (padrão: localhost).

A imagem que deve ser analisada será incluída através do navegador. Entretanto deve-se

previamente ter criado e configurado o novo caso – utilizando o botão “New Case” Figura 9 – e o “host”

(equipamento que irá sofrer o processo de análise).

Figura 9 – Tela de abertura da ferramenta Autopsy.

Ao clicar sobre o botão “Analyze”, terá início o processo de verificação da imagem que foi

selecionada. Após o término do processo anterior, terá início a fase de análise da imagem. Concluído o

processo de análise, deve-se clicar sobre o botão “File Analysis” para verificar uma lista de arquivos

passíveis de recuperação.

Para recuperar um arquivo, neste tipo de análise, basta selecioná-lo e clicar no botão “Export”,

indicando o local onde o mesmo deve ser salvo. Alguns dados de determinados tipos, podem, inclusive, ser

visualizados sem a necessidade do salvamento em disco. Esses dois procedimentos só serão realmente

válidos em caso de recuperação real. A ferramenta permite, ainda, a recuperação de fragmentos e/ou

metadados de arquivos, mas não autoriza a visualização do conteúdo.

3.3.4 FTK Imager

A presente ferramenta inicia seu funcionamento apenas com um duplo clique sobre seu executável,

“FTK Imager.exe”. Através de sua interface gráfica amigável, é possível a inclusão das imagens a serem

analisadas, clicando em “Add Evidence Item” e na sequência escolher o item “Image File”, pressionar o

botão avançar, efetuar a escolha da imagem e, por fim, pressionar o botão concluir.

13

O procedimento acima citado incluiu a imagem dentro do software e este, por sua vez, tenta

recuperar o maior número de dados possíveis da partição ou dispositivo ao qual pertence à imagem.

3.4 Resultados

Para facilitar o entendimento, os resultados foram separados em quatro grupos:

Total: somente quando o conteúdo puder ser visualizado de forma completa. Encaixam-se

inclusive nesse grupo os resultados das ferramentas que não foram capazes de recuperar os metadados dos

arquivos. Os softwares Scalpel e Foremost não conseguem recuperar os nomes dos arquivos para nenhum

sistema, enquanto as demais não foram capazes de recuperar esses metadados em alguns sistemas e cenários.

Parcial – Fragmentos de arquivos: quando a recuperação do arquivo foi possível, mas é

visualizado em pedaços como, por exemplo, pedaços de uma figura.

Parcial – Metadados: quando apenas os atributos dos arquivos diferentes do conteúdo, tais

como nome, extensão, tamanho, datas de criação e última alteração – nenhum fragmento do arquivo pode ser

visualizado.

Nulo: quando as informações recuperadas forem inválidas, ou seja, não é possível a

visualização dos metadados ou de nenhum fragmento.

3.4.1 Cenário 1

Os resultados obtidos pelas ferramentas ao tentar recuperar os arquivos apresentados na Tabela 2,

que foram apagados das partições com os sistemas ext3, ext4 e NTFS são apresentados, no Gráfico 1.

Gráfico 1 – Comparativo das ferramentas nos diferentes sistemas de arquivos.

3.4.2 Cenário 2

No Cenário 2, foram copiados diversos arquivos para as partições já anteriormente utilizadas para os

testes do primeiro cenário de forma que todo espaço disponível fosse ocupado. O que está em jogo neste

cenário é a capacidade de recuperação de arquivos, das ferramentas, quando esses tiverem sido sobrescritos

por outros.

Como se pode notar no Gráfico 2, o desempenho das ferramentas foi quase sempre nulo. As

ferramentas FTK Imager e Autopsy tiveram desempenhos muito próximos para todas imagens, exceto ext4,

o qual não é reconhecido pelo FTK Imager.

Total

Metadados

Total

Metadados

Total

Metadados

ext3

ext4

NTF

S

0 10 20 30 40 50 60

3 7

0 15

17 3

0 5

16 1

0 6

3 6

0 16 13

2 0

10 13

2 0

10

0 0

25 0

0

24 0

1 0

0 0

25 0

0 0

0 25

0 0

1 24

CENÁRIO 1

Foremost Scalpel Autopsy - TSK FTK Imagem

14


Neste cenário, onde os arquivos foram apagados e sobrescritos com dados que preencham todo o

tamanho da partição, esperava-se que o conteúdo de todos os arquivos fosse sobrescrito, o que de fato foi

comprovado.

Foi possível observar, ainda, que duas das ferramentas Autopsy e FTK Imager ainda são capazes de

recuperar algumas informações da maioria dos dados nos sistemas de arquivos que eesas ferramentas

reconheciam, excetuando-se o NTFS, onde a recuperação dos metadados foi quase nula. A recuperação dos

arquivos pode ter ocorrido devido ao tamanho dos arquivos apagados, porque esses foram sobrescritos por

uma quantidade menor de dados, com um tamanho maior.

3.4.3 Cenário 3

Neste cenário, não houve mudanças nos resultados, quando comparados ao Cenário 1. No entanto

uma pequena diferença em relação ao primeiro cenário é notada nos resultados obtidos pelas ferramentas

Foremost e Scalpel, que sofreram um rápido declínio no desempenho para o sistema de arquivos ext3. Por

outro lado, houve uma melhora nos resultados obtidos pelo sistema ext4 e NTFS, recuperando um número

maior de dados no cenário atual que no cenário 1.

Total

Fragmentos de Arquivos

Metadados

Nulo

Total


Metadados

Nulo

Total


Metadados

Nulo

ext3

ext4

NTF

S

0 10 20 30 40 50 60 70 80 90 100

0

0

0

25

0

0

0

25

0

0

0

25

0

0

0

25

0

0

0

25

0

0

0

25

0

0

23

2

0

0

21

5

0

0

1

24

0

0

22

3

0

0

0

25

0

0

1

24

CENÁRIO 2


15


Os resultados dos testes para este cenário são semelhantes aos verificados no primeiro cenário, o que

já estava previsto, uma vez que o processo de criação das imagens foi praticamente o mesmo, apenas

diferindo no tamanho das partições.

Como para todos os cenários anteriores, o ideal para este cenário é usar mais de uma ferramenta para

obter a maior quantidade de conteúdo recuperado e das informações sobre os arquivos (metadados).

3.4.4 Cenário 4

No Cenário 4, foram utilizadas as mesmas imagens do Cenário 3, onde após os arquivos serem

apagados, apenas um arquivos de 80MB foi copiado para sobrescrever a partição. A intenção foi deixar

espaço suficiente para que, dependendo do modo de operar do sistema de arquivos usado, os arquivos a

serem recuperados não sejam todos sobrescritos.


Total


Metadados

Nulo

Total


Metadados

Nulo

Total


Metadados

Nulo

ext3

ext4

NTF

S

0 10 20 30 40 50 60

2

8

0

14

16

4

0

5

19

1

0

5

2

7

0

16

12

3

0

10

13

2

0

10

0

0

25

0

0

0

25

0

25

0

0

0

0

0

25

0

0

0

0

25

0

0

1

24

CENÁRIO 3


Total

Metadados

Total

Metadados

Total

Metadados

ext3

ext4

NTF

S

0 10 20 30 40 50 60 70 80

0 0 0

25 14

2 0

9 8

0 0

17

0 0 0

25 11

2 0

25 4

2 0

19

0 0

24 1

0 0

24 1

5 0

1 19

0 0

24 1

0 0

0 25

0 0 1

24

CENÁRIO 4


16

Para o cenário atual, a utilização de mais de uma ferramenta com o intuito de aperfeiçoar os

resultados funcionaria apenas no que diz respeito ao sistema ext4. Para os demais, a utilização da ferramenta

que apresentou o melhor resultado já é o suficiente.

Com a comparação entre os diferentes cenários e sistemas de arquivos, foi possível concluir que o

comportamento das ferramentas é alterado de acordo com o sistema em que os dados são alocados.

Na próxima seção, há um resumo dos resultados obtidos pelas ferramentas forenses em cada um dos

sistemas de arquivo.

3.4.5 Resumo dos Resultados

Revendo os resultados de todas as imagens para todos os cenários, pode-se ter uma ideia de qual

abordagem utilizar para cada sistema de arquivos a ser analisado. Este breve resumo de quais procedimentos

devem ser adotados é apresentado a seguir.

Sistema ext3: As ferramentas Autopsy e FTK Imager obtiveram desempenhos muito parecidos,

independente do Cenário, ou seja, apenas recuperam metadados. Assim, a melhor abordagem para este

sistema é usar mais de uma ferramenta, incluindo também o Foremost ou Scalpel, e buscar realizar

associações entre nomes e conteúdos. Mesmo assim, poucos arquivos são recuperados.

Sistema ext4: Apesar da ferramenta FTK Imager não reconhecer este sistema e o Autopsy recuperar

apenas metadados, as ferramentas Foremost e Scalpel conseguiram recuperar uma quantidade maior de

arquivos ao comparar estes resultados com o do outro sistema Linux. Logo essas duas ferramentas –

Foremost e Scalpel – são recomendadas quando se tratar de recuperar arquivos no sistema ext4.

Sistema NTFS: Nenhuma ferramenta conseguiu ter sucesso ao recuperar metadados. Apenas um

arquivo teve os seus metadados recuperados para todos os cenários. Com relação ao conteúdo dos arquivos,

estes são recuperados quase totalmente quando não há indícios de terem sido sobrescritos. Quando

totalmente sobrescritos, nada é recuperado e com os dados parcialmente sobrescritos, a ferramenta Foremost

foi a que apresentou melhor resultado ao recuperar a maior quantidade de arquivos. A ferramenta FTK

Imager, para todos cenários, conseguiu recuperar apenas os metadados de um arquivo, sem recupear o

conteúdo de nenhum deles.

4 CONCLUSÃO

Atualmente, três fatores contribuem com o aumento da quantidade de dados perdidos, que são o

aumento da capacidade de armazenamento de informações em equipamentos eletrônicos, a queda vertiginosa

nos preços e, atrelado a isso, a massificação do uso. Tais motivos levaram a um crescimento alarmante nos

crimes digitais.

Com o intuito de recuperar os dados que, apesar de excluídos do disco – talvez por este motivo –,

possam ser importantes, são desenvolvidas várias ferramentas de recuperação de dados.

Foram utilizadas quatro destas ferramentas, cada uma a quatro cenários diferentes, de perda de

dados. Com a experiência prática adquirida, durante os testes controlados, pôde-se notar o quão simples é

recuperar os dados que tenham sido apagados imediatamente do disco. Entretanto, se a intervenção demorar

muito para ocorrer, fica mais difícil a recuperação e os métodos mais sofisticados, visto que novos dados

serão acrescidos.

Durante o desenvolvimento das atividades e conforme os relatos existentes ao longo deste artigo,

pôde-se observar que nenhuma ferramenta é totalmente eficiente. Para todos os sistemas de arquivos ou

cenários em que os dados possam estar inseridos, o melhor é, antes de iniciar o processo de recuperação,

verificar qual o sistema de arquivos está em uso e descobrir se o sistema teve utilização após o

desaparecimento do primeiro arquivo apagado.

Foi possível concluir o quão complexo é excluir, definitivamente, uma informação de um disco.

Informações confidenciais existem aos milhares, assim como milhares de discos ultrapassados têm seu uso

suspenso diariamente, em grandes corporações. A fim de que esses dados sigilosos tenham sua

confidencialidade respeitada, rigorosos procedimentos devem ser seguidos para que tais discos rígidos sejam

descartados com segurança, e as informações sensíveis não corram o risco de serem divulgadas, sem a

devida autorização de seus proprietários.

17

Além do já exposto acima, durante os levantamentos bibliográficos foram encontradas informações

conflitantes e que não transmitiam segurança de sua veracidade. Tais informações mereceram um tempo

maior de estudo e testagem a fim de se obter o resultado correto. Um dos principais conflitos encontrados

foi, o fato, de alguns autores afirmarem que mesmo executando o processo de “wipe” em um disco seria

possível recuperar todas as informações, visto que a agulha do disco rígido jamais passa no mesmo lugar

duas vezes. Ao longo dos testes foi possível demonstrar que alguns arquivos e/ou parte deles é passível de

recuperação e outros não. Tal recuperação depende muito mais da ferramenta empregada, visto que nos

quatro cenários apresentados, cada uma teve um resultado diferente – sendo os dados foram recuperados em

maior ou menor grau.

Indica-se para trabalhos futuros a ampliação da gama de ferramentas utilizadas – sejam elas

proprietárias ou livres. A inclusão da métrica do tempo de exame e recuperação dos dados, para que se possa

decidir qual ferramenta utilizar – baseando-se no tempo gasto versus quantidade de informação recuperada.

É interessante, ainda, incluir algumas ferramentas de “wipe” e informar qual o nível de eficácia na limpeza, e

até qual camada a mesma atinge, e posterior recuperação de dados.

AGRADECIMENTO(S)

Agradeço especial e carinhosamente aos meus pais, Helena Nair Goi Guidolin e Luiz Carlos da Silva

Guidolin, pelo amor incondicional, pela confiança depositada, pelo respeito e por terem feito o possível e

impossível para me oferecerem a oportunidade de estudar;

Aos meus familiares, pelo incentivo, por compreenderem a importância dessa conquista e aceitar a

minha ausência quando necessário;

Aos meus amigos, pela torcida positiva, pela amizade e por ajudarem a tornar a vida muito mais

divertida;

Aos meus colegas do SENAC Passo D’Areia, docentes como eu ou administrativos, pela torcida

positiva, pela amizade e por ajudarem a tornar a vida muito mais significativa.

REFERÊNCIAS

CARRIER, Brian. File System Forensic Analysis. Addison-Wesley, 2005.

CHISUM, W.J.; Turvey, B. Evidence Dynamics: Locard's Exchange Principle & Crime Reconstruction.

Journal of Behavioral Profiling, v1, n 1, jan. 2000.

COURTNEY, Scott. An In-Depth Look at Reiserfs. Disponível em:

<http://www.linuxplanet.com/linuxplanet/tutorials/2926/4/>. Acesso em: 26 ago. 2012.

DFLABS. PTK an alternative computer forensic framework. Disponível em:

<http://ptk.dflabs.com/> Acesso em: 28 ago. 2012.

FOREMOST. Disponível em:

<http://foremost.sourceforge.net/>. Acesso em: 2 set. 2012.

IEONG, Ricci S.C. FORZA – Digital forensics investigation framework that incorporate legal issues.

Digital Investigation, Amsterdam, v. 3, s.1, p. 29-36, set. 2006.

JONES, M. Tim. Anatomia do Sistema de Arquivos do Linux. Disponível em:

<http://www.ibm.com/developerworks/br/library/l-linux-filesystem/index.html>. Acesso em: 30 ago. 2012.

JONES, Tim M. Anatomia do Ext4. Disponível em:

<http://www.ibm.com/developerworks/br/library/l-anatomy-ext4/index.html>. Acesso em: 30 ago. 2012.

MELO, Sandro. Computação Forense com Software Livre: Conceitos, Técnicas, Ferramentas e Estudos

de Casos. 1a ed. Rio de Janeiro: Alta Books, 2009.

http://www.linuxplanet.com/linuxplanet/tutorials/2926/4/

http://ptk.dflabs.com/

http://foremost.sourceforge.net/

http://www.ibm.com/developerworks/br/library/l-linux-filesystem/index.html

http://www.ibm.com/developerworks/br/library/l-anatomy-ext4/index.html

18

MORIMOTO, Carlos E. Hardware, o Guia Definitivo. Disponível em:

<http://www.gdhpress.com.br/hardware/>. Acesso em: 25 set. 2012.

MOURA, M. Curso de Administração – Computação I. 2009. Disponível em:

<http://computacao.web44.net/adm_comp/tutoriais/hard3.html>. Acesso em: 10 ago.2012.

SCALPEL: A Frugal, High Performance File Carver. Disponível em:

<http://www.digitalforensicssolutions.com/Scalpel/>. Acesso em: 2 set. 2012.

THE SLEUTH KIT (TSK) & Autopsy: Open Source Digital Investigation Tools. Disponível em:

<http://www.sleuthkit.org/>. Acesso em: 2 out. 2012.

SILVERSTONE, Professor André. Conhecendo o HD do Computador. Disponível em:

<http://professorsilvertone.blogspot.com.br/2012/05/conhecendo-o-hd-do-computador.html> Acesso em: 10

out. 2012

ELEUTÉRIO, Pedro Monteiro da Silva; MACHADO, Marcio Pereira. Desvendando a Computação

Forense. São Paulo: Novatec Editora, 2010.

FARMER, Dam; VENEMA, Wietse. Perícia Forense Computacional: Teoria e Prática. São Paulo:

Pearson, 2006.

http://www.gdhpress.com.br/hardware/

http://computacao.web44.net/adm_comp/tutoriais/hard3.html

http://www.digitalforensicssolutions.com/Scalpel/

http://www.sleuthkit.org/

Documents

Artigo Felipe Goi