artigo felipe goi
TRANSCRIPT
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
dd if=/dev/zero of=ext3.img bs=1k
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
dd if=/dev/zero of=ext4.img bs=1k
count=100000
dd if=/dev/zero of=ext4.img bs=1k
count=200000
losetup /dev/loop1 ext4.img losetup /dev/loop1 ext4.img
mkfs.ext4 –c /dev/loop1 100000 mkfs.ext4 –c /dev/loop1 200000
mkdir /mnt/disco2 mkdir /mnt/disco2
mount –t ext4 /dev/loop1 /mnt/disco2 mount –t ext4 /dev/loop1 /mnt/disco2
NTFS
dd if=/dev/zero of=ntfs.img bs=1k
count=100000
dd if=/dev/zero of=ext3.img bs=1k
count=200000
losetup /dev/loop2 ntfs.img losetup /dev/loop2 ntfs.img
mkfs.ntfs –c /dev/loop2 100000 mkfs.ntfs –c /dev/loop2 200000
mkdir /mnt/disco3 mkdir /mnt/disco3
mount –t ext3 /dev/loop2 /mnt/disco3 mount –t ext3 /dev/loop2 /mnt/disco3
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/loop1 of=/home/goi/arquivostcc/cenario2/ext4_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;
Desmontagem e montagem;
Limpeza da partição;
Desmontagem e montagem.
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
# 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/loop1 of=/home/goi/arquivostcc/cenario2/ext4_02.dd
dd if=/dev/loop2 of=/home/goi/arquivostcc/cenario2/ntfs_02.dd
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
# 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/cenario3/ext3_03.dd
dd if=/dev/loop1 of=/home/goi/arquivostcc/cenario3/ext4_03.dd
dd if=/dev/loop2 of=/home/goi/arquivostcc/cenario3/ntfs_03.dd
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;
Desmontagem e montagem;
Limpeza da partição;
Desmontagem e montagem.
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.
dd if=/dev/loop0 of=/home/goi/arquivostcc/cenario4/ext3_04.dd
dd if=/dev/loop1 of=/home/goi/arquivostcc/cenario4/ext4_04.dd
dd if=/dev/loop2 of=/home/goi/arquivostcc/cenario4/ntfs_04.dd
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
Gráfico 2 – Comparativo das ferramentas nos diferentes sistemas de arquivos.
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
Fragmentos de Arquivos
Metadados
Nulo
Total
Fragmentos de Arquivos
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
Foremost Scalpel Autopsy - TSK FTK Imagem
15
Gráfico 3 – Comparativo das ferramentas nos diferentes sistemas de arquivos.
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.
Gráfico 4 – Comparativo das ferramentas nos diferentes sistemas de arquivos.
Total
Fragmentos de Arquivos
Metadados
Nulo
Total
Fragmentos de Arquivos
Metadados
Nulo
Total
Fragmentos de Arquivos
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
Foremost Scalpel Autopsy - TSK FTK Imagem
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
Foremost Scalpel Autopsy - TSK FTK Imagem
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.
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.