Sunteți pe pagina 1din 104
509 | 4509 Técnicas de Computaçao Forense www.4linux.com.br

509 | 4509

Técnicas de Computaçao Forense

www.4linux.com.br

Projetos na sua empresa com a qualidade dos treinamentos

Business Inteligence http://va.mu/Flx8
Business
Inteligence
http://va.mu/Flx8
GED - ECM http://va.mu/Flx3 BPM http://va.mu/EuiT Servidor Java EE http://va.mu/FlyB
GED - ECM
http://va.mu/Flx3
BPM
http://va.mu/EuiT
Servidor Java EE
http://va.mu/FlyB
Integração Continua http://va.mu/FlyD
Integração
Continua
http://va.mu/FlyD
PostgreSQL http://va.mu/EuhV
PostgreSQL
http://va.mu/EuhV
Monitoramento http://va.mu/EukN Alta Disponibilidade http://va.mu/FNbL
Monitoramento
http://va.mu/EukN
Alta
Disponibilidade
http://va.mu/FNbL
Backup http://va.mu/Flxr Infraestrutura Web http://va.mu/Flxi Virtualização http://va.mu/Flxl Groupware
Backup
http://va.mu/Flxr
Infraestrutura
Web
http://va.mu/Flxi
Virtualização
http://va.mu/Flxl
Groupware
http://va.mu/FNYj
Auditoria e Análise http://va.mu/Flxu Segurança http://va.mu/Flxy
Auditoria
e Análise
http://va.mu/Flxu
Segurança
http://va.mu/Flxy
Ensino à Distância http://va.mu/Flxc Implantação garantida http://va.mu/GcFv
Ensino
à Distância
http://va.mu/Flxc
Implantação
garantida
http://va.mu/GcFv
Segurança http://va.mu/Flxy Ensino à Distância http://va.mu/Flxc Implantação garantida http://va.mu/GcFv

Conteúdo

Capítulo 1

Computação Forense

1.1 Introdução e terminologia

A computação forense é a ciência de identificar, preservar, coletar, analisar o e ap- resentar informações obtidas a partir de computadores e mídias de armazenamento. Ela foi criada para suprir a necessidade da lei de colher evidências de meios digitais, devido à óbvia utilização de meios digitais e índices crescentes de incidentes que utilizam estes meios.

As técnicas utilizadas na computação forense são muitas e exigem um profundo conhecimento da tecnologia analisada.

Numa linguagem simples, é uma grande análise de acontecimentos passados num ambiente computacional, geralmente envolvendo aspectos jurídicos como crimes, desrespeito às normas corporativas, mal comportamento, dentre outros.

Um bom exemplo de necessidade de um especialista em computação forense é o vazamento de dados. Imagine uma situação fictícia em que João, diretor da em- presa Dexter, se depara com a planilha de salários de sua empresa divulgada pub- licamente na internet. Além de tomar as providências para remover a planilha da internet, é preciso descobrir como, quando e quem foi o responsável por esta atitude antiética e passível de punição. Para isso, João pode contratar um especialista em

1.2 Estratégias de investigação

4Linux – www.4linux.com.br

computação forense, que vai fazer análises no parque computacional da empresa para chegar à máquina que iniciou o vazamento de dados e, consequentemente, à pessoa responsável por tal ação.

Todas as informações serão colocadas em um relatório, que será o objeto fim da investigação.

É importante frizar que nem sempre a necessidade é na esfera crminalística.O exemplo acima não é um crime, mas exige atenção de um especialista.

O exemplo acima não é um crime, mas exige atenção de um especialista.

Infelizmente, por falta de padronização, há vários termos que podem gerar confusão como: perícia forense, forense computação, investigação digital, forense digital, perí- cia digital, dentre outros usados comumente para descrever a mesma ciência. Nor- malmente o termo forense digital ou investigação digital é empregado quando o escopo não abrange somente computadores, mas também smartphones, tablets e outros dispositivos digitais.

Já o trabalho de perícia, tem a ver com o adjetivo perito, usado para descrever pessoa extremamente hábil e conhecedora de algum assunto.

Acostume-se também com os termos em inglês: computer forensics, computer forensic science, digital research e digital forensic science . computer forensics, computer forensic science, digital research e digital forensic science.

1.2 Estratégias de investigação

A estratégia adequada para a investigação vai depender do tipo de caso mas normal-

mente segue uma sequência lógica que envolve indetificação da evidência, preser- vação, coleta, análise e apresentação. Alguns autores e investigadores subdividem

4Linux – www.4linux.com.br

1.2 Estratégias de investigação

estes cinco estágios ou alteram sensivelmente sua ordem. Tudo depende da exper- iência do especialista, do tipo de caso e de como a situação se apresenta.

Estudaremos a seguir as cinco macro etapas da computação forense:

1.2.1 Identificação

Nesta etapa todas as fontes de prováveis evidências devem ser consideradas e reg- istradas. Desde câmeras de vigilância até pen drives soltos sobre a mesa, todos os aparelhos envolvidos no caso devem ser considerados. Segue uma lista parcial de itens a serem considerados:

• Drives ópticos e magnéticos

• Teclado

• Mouse/Touchpad

• Scanners

• Discos externos

• KVMs (switches de video, teclado e mouse)

• Documentos impressos

Tudo deve ser anotado por você. É essencial fotografar também. Nesta etapa que você define o que será preservado, ou seja, o que é importante para a investigação, além de registrar o estado de todas as evidências antes de você manipulá-las. Isso vai ajudar a provar a integridade das fontes de informação, se necessário.

1.2 Estratégias de investigação

4Linux – www.4linux.com.br

1.2.2 Preservação

Os dados que estão presentes nas fontes de informações que você enumerou na etapa anterior também precisam ter sua integridade garantida e é exatamente o que acontece nesta etapa.

A ideia é que você não cause nenhuma alteração nas evidências quando começar a

coletá-las.

Um bom exemplo é a descarga elétrica estática (do inglês ESD: Eletrical Static Dis- charge) que o contato físico com um hardware sensível pode causar e fazer com que os dados tenham sua integridade comprometida. A ocorrência de uma ESD depende de fatores como nível de carga no corpo, umidade relativa do ar no ambiente den- tre outros fatores físicos, mas é possível até mesmo danificar uma placa de circuito simplesmente ao enconstar nela. Para evitar esta desagradável surpresa, existem pulseiras antiestáticas como a da foto abaixo.

existem pulseiras antiestáticas como a da foto abaixo. Nesta etapa você também vai decidir se desliga

Nesta etapa você também vai decidir se desliga ou não os aparelhos que contém as evidências. Existe um ditado que diz: Se está ligado, não desligue e se está desligado, não ligue. No entanto, nem sempre ele é válido. Pode haver casos onde o ambiente está sob ataque e desligar (ou desconectá-lo da rede, se for o caso) pode ajudar a minimizar os prejuízos. Você deve estudar as vantagens e desvantagens de cada ação para o seu caso a fim de tomar a medida mais viável.

É possível também que você tenha que decidir entre desligar os computadores de

maneira tradicional, solicitando ao sistema operacional que inicie o processo de

4Linux – www.4linux.com.br

1.2 Estratégias de investigação

desligamento, ou se você vai simplesmente desconectar a energia da fonte de al- imentação. Esta última ação pode parecer muito bruta, mas evita que o sistema altere arquivos, escreva em logs e mude significativamente o estado dos dados. In- clusive um malware pode se apagar ou tomar outra ação antiforense (estudaremos este assunto no capítulo 7) ao detectar que a máquina está sendo desligada.

Em contrapartida, desconectar a energia do computador pode corromper dados. Os especialistas em banco de dados provavelmente ficarão muito preocupados se você disser que vai fazer isso num servidor de banco em produção, portanto avalie sem- pre!

Bloquear dispositivos contra gravação, seja por hardware ou por software também é uma boa ideia nesta etapa.

Antes de coletar os dados, é essencial criar um hash das mídias envolvidas no pro- cesso, tentando ser o menos intrusivo possível e com bloqueios contra escrita.

Após a coleta dos dados (que veremos com detalhes no capítulo 2), estes hashes devem ser checados e precisam ser idênticos, salvas exceções onde não é possível bloquear a mídia contra escrita e haja escrita constante. Neste caso, cada cópia da mídia terá um hash diferente e uma cópia acompanhada deve ser validada individ- ualmente.

O hash é utilizado para checagem de integridade. MD5, SHA-1, SHA-256 e SHA-512 são exemplos de algoritmos usados atualmente com este propósito (CRC32 e MD4 estão em desuso).

Algoritmos de hashing são algoritmos matemáticos que realizam operações com todos os dados de uma

Algoritmos de hashing são algoritmos matemáticos que realizam operações com todos os dados de uma entrada (um texto, um arquivo etc) e geram um resultado (normalmente um número) de tamanho fixo chamado de hash. São conhecidos por sua característica one-way (numa só direção), ou seja, não é possível obter o dado original a partir do hash, mas se o mesmo algoritmo é aplicado a uma cópia idêntica do dado original, o hash resultante será o mesmo.

1.2 Estratégias de investigação

4Linux – www.4linux.com.br

1.2.3 Coleta

A etapa mais importante do processo é realizar a coleta de forma adequada. Nesta

etapa o especialista precisa extrair dados do parque de máquinas onde o incidente ocorreu, que pode incluir dados em memórias voláteis ou não voláteis, além de outras informações úteis para a próxima etapa da análise.

Todo o trabalho aqui deve ser feito para gerar o menor impacto possível na máquina, ou seja, quanto menos alterações em memória e em disco o especialista causar para coletar os dados, menos dados são perdidos na coleta. A este impacto dá-se

o nome de footprint. Instalar um programa para realizar a coleta é uma ação que

normalmente gera um footprint considerável uma vez que o programa de instalação precisa ser carregado em memória e vários arquivos são criado e/ou alterados du- rante a instalação, por isso na coleta recomenda-se utilizar ferramentas existentes em um pen drive ou mídia similar, funcionais para o SO alvo e evitar qualquer alter- ação no disco rígido das máquinas onde a coleta será realizada.

Logicamente não há como evitar alterações na memória RAM das máquinas que farão parte da investigação, uma vez que os softwares utilizados para a coleta pre- cisam ser carregados. No entanto, deve ser dada preferência aos softwars com menor footprint, ou seja, os executáveis otimizados que não utilizam muita RAM para funcionarem.

Nesta etapa também se precisa calcular os hashes dos arquivos coletados e imagens geradas, para que sejam incluídos no relatório da etapa de apresentação.

Lembre-se que uma análise em dados coletados pode ser refeita várias vezes, mas a coleta

Lembre-se que uma análise em dados coletados pode ser refeita várias vezes, mas a coleta em si normalmente não. Portanto, esta etapa de coleta deve ser min- uciosa e muito bem estudada. Qualquer perda de dados pode ser irrecuperável e comprometer a abrangência da análise com consequências diretas na qualidade da investigação como um todo.

4Linux – www.4linux.com.br

1.2 Estratégias de investigação

1.2.4 Análise

Esta é a parte mais engenhosa e demorada do trabalho do especialista em com- putação forense. Aqui é onde se aplicam as técnicas e o maior conhecimento é exigido. Nesta etapa você vai procurar evidências que tenham a ver com seu caso, em lugares prováveis primeiramente mas sem excluir os locais de menor probabil- idade. Por exemplo, se estiver investigando um caso de invasão de um servidor, provavelmente um bom local para começar é o log do firewall ou da aplicação com- prometida.

O importante é definir o que está sendo procurado. Sem saber o que se procura, a análise pode demorar muito ou mesmo nunca terminar e o trabalho do perito será ineficiente.

Normalente o esforço é concentrado em imagens (cópias perfeitas) de mídias de armazenamento e dumps de memória mas pode haver outros itens para serem anal- isados, como captura de tráfego de dados num firewall.

Nesta etapa várias ferramentas podem ser utilizadas, assim como técnicas de análise manual, que aprenderemos mais à frente. Abaixo uma lista de distribuições Linux que agregam várias ferramentas específicas para computação forense. Seu uso não é obrigatório, mas é importante conhecê-las:

BackBox Linux distribuição para pen tests e testes de segurança que objetiva ser rápida e com o mínimo de pacotes possíveis.

BackTrack famosa distribuição com uma grande coleção de ferramentas se segu- rança, incluindo o nacional T50.

CAINE (Computer Aided INvestigative Environment) é uma das principais distribuições de auxílio ao especialista em computação forense, com softwares para todas as etapdas de uma investigação, inclusive geração de relatórios semiautomática.

DEFT Linux (Digital Evidence and Forensic Toolkit) distribuição fácil de usar que

1.2 Estratégias de investigação

4Linux – www.4linux.com.br

reúne algumas das melhoras aplicações de código aberto para resposta à inci- dentes e computação forense.

FDTK distribuição brasileira para computação forense, com muitos programas e de fácil utilização.

Helix uma das mais antigas distribuições focadas em computação forense, com muitas aplicações da área.

Matriux distribuição para pen test e computação forense baseada em Debian, com cerca de 300 aplicações da área e até kernel personalizado.

NetSecL distro com foco em segurança baseada no OpenSUSE. É instalada com portas de entrada fechadas, sem serviços (daemons) de rede rodando e com várias outras configurações hardcore de segurança.

STD - Security Tools Distribution foco em segurança de rede e informação com muitas ferramentas.

Swift Linux leve distribuição baseada com ferramentas para computação forense e recuperação de dados.

Não se esptante com o número de distribuições diferentes para o mesmo propósito. Em geral

Não se esptante com o número de distribuições diferentes para o mesmo propósito. Em geral elas são muito similares entre si e você deve escolher a que melhor se adaptar, sendo que o especialista não deve ser limitar à uma distribuição, nem mesmo à um SO. É preciso conhecer variadas tecnologias como Linux (baseados em Debian, em Red Hat, Slackware etc), Windows (ver- sões desktop e família Server), BSDs, Mac OS, embarcados, enfim, a lista é inacabável. A ideia é não se limitar a uma só tecnologia, distribuição ou apli- cação. Não devemos depender disto.

4Linux – www.4linux.com.br

1.2 Estratégias de investigação

1.2.5 Apresentação

Após a conclusão da análise, chega a hora de apresentar os resultados ao seu cliente, seu chefe, ao júri ou a qualquer outra pessoa ou grupo de pessoas aplicáveis. Normalmente isto é alcançado com um relatório, mas também pode envolver uma apresentação. É importante não esquecer de documentar:

• As evidências que você pode provar.

• O que você fez para descobri-las.

• Por que você foi atrás delas.

• Como você fez para revelá-las.

O relatório deve ser bem explicativo, de preferência com uso de imagens para tornar fácil o suficiente para um público não técnico entender, mesmo que sem profundi- dade. Um modelo de relatório pode ser consultado no Anexo I.

Você deve entregar junto ao relatório uma tabela com todos os hashes calculados durante a investigação e uma mídia (um DVD-R por exemplo) com os arquivos en- contrados.

Capítulo 2

Aquisição de dados

2.1 Memória mapeada por processos

Quando um processo entra em execução no sistema, uma região de memória é ma- peada (endereçada) para ele. É possível obter, num sistema em execução, somente esta região de memória para análise posterior. Isto é muito útil quando trata-se de um processo suspeito, peça-chave para uma investigação. Por exemplo, no caso de um acesso a sites proibidos, é interessante obter a memória mapeada para o processo do navegador.

2.2 Memória no espaço do usuário

Os aplicativos executados pelo usuário, em geral, trabalham no espaço de usuário, também conhecido como ring3 ou usermode. Quando o foco da investigação for processos utilizados pelo usuário, provavelmente a aquisição de memória deste es- paço bastará. No entanto, há casos em que a aquisição da memória utilizada por processos essenciais do sistema também é necessária, que veremos adiante.

2.3 Memória no espaço do kernel

4Linux – www.4linux.com.br

2.3 Memória no espaço do kernel

O kernel, drivers e afins rodam no sistema de forma privilegiada e com sua própria área de memória. Este modo de execução é conhecido como kernelmode, espaço de kernel ou ring0. A memória mapeada neste modo pode também ser obtida através de um dump de memória.

Na verdade, na maioria dos casos, um dump de memória completo é realizado, o que

Na verdade, na maioria dos casos, um dump de memória completo é realizado, o que inclui todas as regiões de memória citadas anteriormente. No entanto, saber dividi-las é importante para agilizar a investigação.

2.4 Outras memórias

Nem só da memória RAM principal vive um computador. Existem ainda outras memórias que podem fazer parte de um processo de investigação como:

• VRAM das placas de vídeo

• BIOS ROM

• Buffer de periféricos

Obter dados destas memórias pode exigir hardware especializado.

Com tantas fontes de dados, é importante conhecer um pouco da arquitetura dos sistemas, a fim de filtrar o que é e o que não é importante para a investigação.

4Linux – www.4linux.com.br

2.5 Mídias USB e ópticas

2.5 Mídias USB e ópticas

Mídias ópticas como CD-R, DVD-R e BD-R são simples de serem copiadas e natu- ralmente já são memórias somente de leitura. Qualquer software capaz de efetuar uma cópia idêntica de um fluxo de dados será suficiente para obter o conteúdo de uma mídia óptica, sem complicações.

Já dispositivos USB funcionam, na forma lógica, como discos rígidos e podem con-

ter uma ou várias partições, com diferentes sistemas de arquivos. Neste caso a cópia também pode ser feita um software de cópia bit a bit, porém deve-se prestar

a atenção ao que se está copiando, inclusive nas permissões de acesso à mídia (é interessante montar a mídia como somente leitura, assim como as mídias ópticas são montadas).

Para dar um exemplo mais claro, um pen drive pode ter duas partições: uma NTFS

e uma ext4. Copiar a mídia inteira para um arquivo de imagem pode ser mais com-

plicado de analisar que copiar as partições separadamente para dois arquivos de imagem distinhos.

2.6 Partições

As partições são delimitações lógicas em discos e mídias de armazenamento. Nor- malmente as mídias USB têm uma partição com o tamanho todo o espaço livre disponível, mas isso não é, nem de longe, uma regra. Pode haver várias partições, incluindo algumas ocultas (o sistema operacional não a exibe).

A tabela de partições pode estar no MBR (Master Boot Record - Setor Mestre de Ini-

cialização), que é a forma tradicional de particionamento, ou no GPT (GUID Partition

Table). Neste último caso, o MBR ainda é usado mas apenas indicará onde está o GPT.

O MBR é o primeiro setor do disco rígido e por ser um setor, tem 512 bytes de

2.6 Partições

4Linux – www.4linux.com.br

tamanho. Vamos dar uma olhada no dump de um MBR:

tamanho. Vamos dar uma olhada no dump de um MBR: Perceba que nos referimos ao MBR
Perceba que nos referimos ao MBR no gênero masculino. É importante definir os termos corretamente

Perceba que nos referimos ao MBR no gênero masculino. É importante definir os termos corretamente e se o MBR é um Registro (record) Mestre de Inicializa- ção, dizemos o MBR e não a MBR. O mesmo acontece com o BIOS, que é o Sis- tema(system) Básico de Entrada e Saída.

O MBR é estruturado da seguinte maneira:

4Linux – www.4linux.com.br

2.7 Discos rígidos

Offset (hexa)

Tamanho (bytes)

Descrição

0

440

Área de código

1b8

4

Identificador/assinatura do disco

1be

64

Tabela de partições

1fe

2

Identificador/assinatura do MBR

Sabendo disso, você é capaz de dizer qual é o identificador do disco na imagem do MBR apresentada? Lembre-se que os bytes estão organizados em little-endian (da direita para a esquerda).

O anexo 1 da apostila lista os tipos de partições conhecidos e seus respectivos códi-

gos em hexa.

Cada entrada de partição na tabela de partições ocupa 16 bytes, por isso o número máximo de partições na tabela é 4.

Você deve estar se perguntando: se o número máximo de partições na tabela é 4,

Você deve estar se perguntando: se o número máximo de partições na tabela

é 4, como existem discos com mais de 4 partições? Acontece que existe um tipo

especial de partição chamada de extendida (tipo 0x5). Esta partição aponta para uma nova estrutura, fora do MBR, conhecida como EBR (Extended Boot Record)

que também contém tabela de partições.

2.7 Discos rígidos

Uma outra possibilidade é copiar todo o conteúdo de um disco, do primeiro ao último setor, sem discriminar partições. Esta costuma ser uma boa tática, visto que o MBR

e todos os EBR são copiados e é possível analisá-los depois com softwares como fdisk ou cfdisk.

Capítulo 3

Investigação em ambientes GNU/Linux

3.1 Características dos kernels atuais

É mais que sabido por todos os profissionais da área de tecnologia que ela muda muita. Na computação forense não é diferente. Uma ferramenta ou abordagem pode se tornar ultrapassada em questão de dias, por isso é importante se manter atualizado a todo momento.

Em relação ao kernel Linux temos importantes mudanças nas versões recentes que precisam ser levadas em consideração:

• Novos filesystems como Btrfs e ext4

• /dev/kmem em desuso

• Proteção no /dev/mem

As mudanças não param e é importante para o profissional estar em dia com tais atualizações para adaptar suas ferramentas e técnicas às novas configurações. Um

3.2 Aquisição de memória RAM

4Linux – www.4linux.com.br

bom site para se manter atualizado sobre isso é o kernelnewbies.org.

Quando um novo filesystem começa a ganhar espaço, é bem possível que você se depare com ele numa investigação e por isso é recomendado que você estude suas especificações para não ficar perdido caso precise analisá-lo.

O /dev/kmem provia acesso à memória do sistema do ponto de vista do kernel. Se

precisar deste recurso, dê uma olhda no /proc/kcore. Este é um arquivo virtual no formato de core file que pode ser aberto num debugger como o gdb.

O /dev/mem provê acesso a toda a memória do sistema, no entanto, existe uma

proteção contra acesso não autorizado no /dev/mem que impede um dump completo, mesmo com privilégios de root. Uma solução é utilizar um módulo externo, que

veremos adiante.

3.2 Aquisição de memória RAM

Obter uma cópia da memória é uma parte importante do processo de investigação forense. Claro que para tal feito, a máquina em questão deve estar ainda ligada, do contrário os dados na memória do sistema serão perdidos, visto que ela é uma memória RAM dinâmica (DRAM - Dynamic Random Access Memory ).

As memórias RAM dinâmicas são construídas com base em matrizes capaci- tivas, que abrigam componentes

As memórias RAM dinâmicas são construídas com base em matrizes capaci- tivas, que abrigam componentes eletrônicos capazes de armazenar energia por um determinado período de tempo. Para que o dado seja mantido em memória, é pre- ciso que haja um circuito de realimentação, em tempo normalmente constante, que impede que a matriz de se descarregue e perca a engergia armazenada, no nosso caso, nossos bits. Este é o conhecido refresh circuit, ou circuito de realimentação. É graças a ele que os dados na memória não são perdidos a todo momento enquanto a máquina está ligada. No entanto, quando a máquina é desligada, o cirtuito de real- imentação pára de funcionar e as matrizes da memória começam a se descarregar.

4Linux – www.4linux.com.br

3.2 Aquisição de memória RAM

Sem energia para realimentar a matriz, os dados são perdidos.

Existe ainda uma hipótese baseada na recuperação dos dados imediatamente após o desligamento da máquina, quando os capacitores ainda estão se descarregando e que pode envolver até o congelamento por resfriamento dos módulos de memória, mas é algo que ainda não teve sua eficiência comprovada.

3.2.1 Memória mapeadas por processo

Para obter uma cópia da memória mapeada por um processo no Linux, primeiro é preciso saber qual a faixa de endereços que o processo está utilizando. Para isto, você pode consultar um arquivo especial em /proc/<pid>/maps onde <pid> é o PID (Process IDentifier) do processo em questão. São várias regiões de memória mapeadas para um processo, dentre elas a heap e a stack, também conhecida como pilha. Por isso é importante saber o que se procura e conhecer as regiões de memória onde os dados procurados costumam ser armazenados.

Após escolher a região, o gdb (GNU Debugger), pode ser utilizado para dumpar a faixa de memória escolhida.

No exemplo abaixo, algumas linhas e colunas foram removidas para facilitar a visu- alização:

$

cat

/proc/17008/maps

00400000-00401000

r-xp

00000000

08:05

7604329

00600000-00601000

rw-p

00000000

08:05

7604329

7fe6d5d29000-7fe6d5ea6000

r-xp

glib/x86_64-linux-gnu/libc-2.13.so

7fe6d5ea6000-7fe6d60a6000

---p

glib/x86_64-linux-gnu/libc-2.13.so

7fe6d60a6000-7fe6d60aa000

r--p

glib/x86_64-linux-gnu/libc-2.13.so

7fe6d60aa000-7fe6d60ab000

rw-p

glib/x86_64-linux-gnu/libc-2.13.so

7fe6d60b0000-7fe6d60cf000

r-xp

glib/x86_64-linux-gnu/ld-2.13.so

3.2 Aquisição de memória RAM

4Linux – www.4linux.com.br

7fe6d62cf000-7fe6d62d0000

r--p

glib/x86_64-linux-gnu/ld-2.13.so

7fe6d62d0000-7fe6d62d1000

rw-p

glib/x86_64-linux-gnu/ld-2.13.so

7fff9586f000-7fff95890000

rw-p

[stack]

7fff959ff000-7fff95a00000

r-xp

[vdso]

ffffffffff600000-ffffffffff601000

r-xp

[vsyscall]

No mapa de memória do processo de PID 17008 podemos observar várias regiões mapeadas para a libc (o que indica que este processo foi escrito em C) e também a região da stack, dentre outras. Para fazer o dump de uma delas, precisamos attachar

o

processo ao gdb e informar qual a faixa desejada. Em nosso exemplo, vou dumpar

a

stack:

 

$

gdb

-q

--pid

17008

(gdb)

dump

memory

17008.stack

0x7fff9586f000

0x7fff95890000

(gdb)

quit

O arquivo 17008.stack será criado em disco, com o conteúdo da pilha do processo. Veremos mais adiante como analisá-lo.

Para facilitar o dump do conteúdo da stack, você pode utilizar o hack-functions, um conjunto

Para facilitar o dump do conteúdo da stack, você pode utilizar o hack-functions, um conjunto de funções úteis para bash que inclui a função dumpstack e você poderia ter feito o dump anterior com uma só linha de comando.

3.2.2 Memória do sistema

Também pode ser útil para o investigador colher uma cópia de todo o conteúdo da memória RAM. Apesar de ser mais difícil analisar, alguns softwares tentam com- preender a organização dos dados na RAM e provêem uma saída bem interes- sante.

4Linux – www.4linux.com.br

3.2 Aquisição de memória RAM

Em teoria, basta utilizar o dd, parte integrante do binutils do projeto GNU:

dd

if=/dev/mem

of=ramdump

O arquivo ramdump será criado com todo o conteúdo da memória RAM. No entanto,

conforme consta na introdução deste capítulo, pode ser que o /dev/mem esteja prote- gido e somente o primeiro megabyte de memória esteja acessível. Se esta proteção estiver ativa, o dd não conseguirá copiar mais que 1 MB da memória:

# dd

if=/dev/mem

of=ramdump

 

dd:

lendo

"/dev/mem":

Operação

não

permitida

2056+0

registros

de

entrada

 

2056+0

registros

de

saída

1052672

bytes

(1,1

MB)

copiados,

0,0362599

s,

29,0

MB/s

Você também descrobriria se essa proteção está ativa checando a configuração do kernel em execução:

#

CONFIG_STRICT_DEVMEM=y

grep

DEVMEM

/boot/config-$(uname

-r)

Se você ficou curioso sobre o fato de apenas o primeiro megabyte de memória estar

Se você ficou curioso sobre o fato de apenas o primeiro megabyte de memória estar liberado para acesso, segue comentário do próprio código fonte do kernel:

/* * devmem_is_allowed() checks to see if /dev/mem access to a certain address * is

valid. The argument is a physical page number. * * * On x86, access has to be given

to the first megabyte of ram because that area * contains bios code and data regions

used by X and dosemu and similar apps. * Access has to be given to non-kernel-ram

3.2 Aquisição de memória RAM

4Linux – www.4linux.com.br

areas as well, these contain the PCI * mmio resources as well as potential bios/acpi data regions. */

Fonte: https://github.com/torvalds/linux/blob/master/arch/x86/mm/init.c#L304

Uma saída é utilizar o módulo fmem, disponível livremente na internet:

wget

$

$

$ make

$

-c

xf

fmem*

http://hysteria.sk/~niekt0/foriana/fmem_current.tgz

fmem_current.tgz

tar

cd

$ ./run.sh

sudo

Após a instalação do módulo, fica disponível o dispositivo /dev/fmem, com acesso total a memória (para usuários com privilégios de root). No entanto, o fmem exige que você o informe quando parar, ou seja, qual a quantidade de memória total do sistema. Isso pode ser conferido antes com o comando free:

$

free

-m

 

total

used

free

shared

buffers

cached

Mem:

3901

3779

122

0

138

1466

-/+

buffers/cache:

2175

1726

Swap:

926

0

926

#

dd

if=/dev/fmem

of=ramdump

bs=1M

count=3901

Como eu usei a opção -m do free para exibir o resultado em megabyes, usei a opção bs (block size) do dd para configurá-lo a copiar 3901 (opção count) blocos, ou seja, o total da RAM, para o arquivo ramdump.

4Linux – www.4linux.com.br

3.3 Aquisição de dados de filesystems ext4

3.3 Aquisição de dados de filesystems ext4

Adquirir dados de discos não é muito diferente de adquirir dados da memória, com exceção é claro de sua característica não volátil, então mesmo com a máquina desli- gada, os dados do disco permanecem (com algumas exceções pois pode haver ar- madilhas que apagam rastros caso a máquina seja desligada - inclusive-se recomenda- se desligar a máquina na tomada em alguns casos).

O dcfldd é um software baseado no dd, mas com um foco em computação forense, então existem alguns recursos no dcfldd que facilitam a vida e nos fazem digitar menos. Vejamos como seria a cópia do MBR de um disco para um arquivo com o dcfldd:

#

dcfldd

if=/dev/sda

of=mbr.img

bs=512

count=1

hash=sha1,md5

Total

(md5):

d57d9e9521f756b88c1b728cd726a149

Total

(sha1):

306331d9f0083f3647260e55f4337bf36b3689e3

1+0

records

in

1+0

records

out

Você deve ter percebido que a sintaxe é muito parecida com a do dd, mas no co- mando acima usamos a opção hash, que já calcula os hashes desejados da imagem gerada, um dos recursos do dcfldd. Para mais informações, basta consultar o manual da ferramenta, como com qualquer ferramenta Unix-like que se preze. ;)

Com o fdisk podemos listar todas as partições de todos os discos conectados:

# fdisk

-l

 

Disk

/dev/sda:

320.1

GB,

320072933376

bytes

255

heads,

63

sectors/track,

38913

cylinders,

total

625142448

sectors

Units

=

sectors

of

1

*

512

=

512

bytes

3.3 Aquisição de dados de filesystems ext4

4Linux – www.4linux.com.br

Sector

size

(logical/physical):

512

bytes

/

512

bytes

I/O

size

(minimum/optimal):

512

bytes

/

512

bytes

Disk

identifier:

0x7096db3a

Device

Boot

Start

End

Blocks

Id

System

/dev/sda1

*

2048

78319615

 

39158784

83

Linux

/dev/sda3

78321662

625141759

273410049

5

Extended

 

/dev/sda5

78321664

623241215

272459776

83

Linux

/dev/sda6

623243264

625141759

 

949248

82

Linux

swap

/

Solaris

É possível fazer imagens de todo o disco e de cada partição e é recomendável que as duas sejam feitas, para evitar deixar algum dado para trás. Segue um exemplo de cópia da partição sda6 (swap em nosso exemplo):

#

dcfldd

if=/dev/sda6

of=sda6-swap.img

hash=sha1,md5

29440

blocks

(920Mb)

written.Total

(md5):

a3b18f299fed1565c167a170b5193055

Total

(sha1):

99c32b3a6d98af20e18dc5fbf86bc0c4ac23b69b

29664+0

records

in

29664+0

records

out

3.3.1 Estrutura do ext4

Conhecer o sistema de arquivos a ser analisado é um requisito quando se trata de partições problemáticas ou com técnicas de anti-forense (veremos algumas adiante). Nesta seção abordaremos conceitos sobre o ext4, o sistema de arquivos padrão das distribuições GNU/Linux atuais, mas é importante notar que nem sempre você irá se deparar com ext4. É bem possível que você encontre sistemas ext3, ZFS (Sun/Oracle), JFS (IBM), dentre outros em servidores Linux ou Unix. No entanto, os conceitos expostos aqui servirão como base para estudo dos conceitos de outros filesystems.

4Linux – www.4linux.com.br

3.3 Aquisição de dados de filesystems ext4

O ext4 mantém os seguintes registros de data para cada arquivo:

mtime data em que o arquivo foi modificado

atime data em que o arquivo foi acessado

ctime data em que o arquivo teve um atributo modificado

dtime data em que o arquivo foi excluído

crtime data em que o arquivo foi criado

Em seu antecessor, o ext3, somente os três primeiros atributos estão presentes, algo que a comunidade de segurança já se incomodava. A resolução de tempo passou a ser de nanosegundos, contra segundos do ext3.

As seguintes ferramentas presentes na suíte e2fsprogs merecem destaque:

http://e2fsprogs.sourceforge.net

e2image Gera imagens com metadados críticos de partições para arquivos

dumpe2fs Exibe informações sobre uma partição. Pode ser usado com uma im- agem gerada pelo e2image

debugfs Um debugger interativo que também pode ser usado com imagens do

e2image

Para cada arquivo existente no filesystem, existe uma estrutura responsável por representá-lo chamada inode. O inode também armazena todas as informações sobre um arquivo, com exceão de seu nome e conteúdo. Para verificar tais infor- mações, podemos usar o comando stat:

#

stat

mbr.img

3.3 Aquisição de dados de filesystems ext4

4Linux – www.4linux.com.br

File:

"mbr.img"

Size:

512

Blocks:

8

IO

Block:

4096

arquivo

comum

Device:

805h/2053d

Inode:

7604329

Links:

1

 

Access:

(0644/-rw-r--r--)

Uid:

(

1000/

nandu)

Gid:

(

1000/

nandu)

Access:

2012-05-22

00:06:14.492249402

-0300

Modify:

2012-05-22

00:06:32.056336493

-0300

Change:

2012-05-22

00:06:32.056336493

-0300

Birth:

-

No entanto, conforme você deve ter percebido, a data de criação do arquivo não apareceu. Acontece que nem todas as ferramentas já estão adaptadas ao ext4, mas por sorte o debugfs resolve:

#

Inode: 7604329

debugfs

-R

’stat

<7604329>’

regular

Type:

/dev/sda5

Mode:

0644

Flags:

0x80000

Generation: 3982433542

Version:

0x00000000:00000001

User:

1000

Group:

1000

Size:

512

File

ACL:

0

Directory

ACL:

0

Links:

1

Blockcount:

8

Fragment:

Address:

0

Number:

0

Size:

0

 

ctime:

0x4fbb02b8:0d6e81b4

--

Tue

May

22

00:06:32

2012

atime:

0x4fbb02a6:755c84e8

--

Tue

May

22

00:06:14

2012

mtime:

0x4fbb02b8:0d6e81b4

--

Tue

May

22

00:06:32

2012

crtime: 0x4fbb01ac:be7fc6ac -- Tue May 22 00:02:04 2012

Size

EXTENTS:

of

extra

inode

fields:

28

(0):30154696

Este comando stat passado para o debugfs é um comando interno do debug- ger e

Este comando stat passado para o debugfs é um comando interno do debug- ger e não o stat do coreutils usado anteriormente.

Se o arquivo for excluído, o atributo dtime aparecerá:

4Linux – www.4linux.com.br

3.3 Aquisição de dados de filesystems ext4

$

#

Inode: 7604329 Type: regular Mode: 0644 Flags: 0x80000

Generation: 3982433542 Version: 0x00000000:00000001

rm

debugfs

mbr.iso

-R

’stat

<7604329>’

/dev/sda5

User:

1000

Group:

1000

Size:

0

File

ACL:

0

Directory

ACL:

0

Links:

0

Blockcount:

0

Fragment:

Address:

0

Number:

0

Size:

0

 

ctime:

0x4fbb3ad4:d0c06a9c

--

Tue

May

22

04:05:56

2012

atime:

0x4fbb39fe:dce57df0

--

Tue

May

22

04:02:22

2012

mtime:

0x4fbb3ad4:d0c06a9c

--

Tue

May

22

04:05:56

2012

crtime: 0x4fbb01ac:be7fc6ac -- Tue May 22 00:02:04 2012 --

Size

dtime:

0x4fbb3ad4

extra

Tue

May

22

28

04:05:56

2012

of

inode

fields:

EXTENTS:

O debugfs também pode atuar com imagens de disco, como faremos nos exercí-

cios.

3.3.2 Como o ext4 grava os arquivos?

O conteúdo dos arquivos é gravado em blocos contínuos de tamanho pré-definido no

disco (geralmente 4096 bytes, mas você pode consultar com o comando:

#

dumpe2fs

Block

dumpe2fs

size:

-h

1.42.2

/dev/sda5

|

grep

(9-Apr-2012)

4096

’Block

size’

No exemplo acima consultei o tamanho do bloco de uma partição /dev/sda5, for- matada com ext4.

3.3 Aquisição de dados de filesystems ext4

4Linux – www.4linux.com.br

É possível ver quais os blocos utilizados por um determinado inode com o comando dessa forma:

#

debugfs

-R

’blocks

<7604329>’

/dev/sda5

debugfs

1.42.2

(9-Apr-2012)

30447449

Um inode pode utilizar mais de um bloco por conta do tamanho do arquivo repre- sentado por ele, mas em nosso exemplo ele utiliza apenas um bloco, de número 30447449. Podemos extrair tal bloco do disco com o dd:

dd

if=/dev/sda5

of=bloco

bs=4096

count=1

skip=30447449

1+0

registros

de

entrada

1+0

registros

de

saída

4096

bytes

(4,1

kB)

copiados,

0,0167189

s,

245

kB/s

No exemplo acima trabalhei com um tamanho de bloco de 4096 bytes (consultado previamente dumpe2fs) e o extraí para um arquivo chamado bloco. Se o tamanho do arquivo for menor que o bloco, após o último byte do arquivo, todos os bytes seguintes serão nulos (0x00) e podem ser removidos facilmente. No exemplo o arquivo tem 512 bytes, então vou extrair 512 bytes do bloco capturado:

$

dd

if=bloco

of=mbr.recuperado

bs=512

count=1

 

1+0

registros

de

entrada

1+0

registros

de

saída

512

bytes

(512

B)

copiados,

4,5397e-05

s,

11,3

MB/s

$

md5sum

mbr.*

d57d9e9521f756b88c1b728cd726a149

d57d9e9521f756b88c1b728cd726a149 mbr.recuperado

mbr.bin

O hash MD5 comprova que não há qualquer diferença entre o arquivo original e o recuperado.

4Linux – www.4linux.com.br

3.3 Aquisição de dados de filesystems ext4

Recuperações de arquivos excluídos em sistemas ext4 são geralmente baseadas no conteúdo do journal, um log de todas as transações no filesystem. Neste caso, o comando logdump do debugfs pode ser utilizado para checar em que bloco de dados há uma cópia do arquivo representado pelo inode em questão, caso haja.

3.3.3 Outros itens na memória a serem coletados

Existem alguns itens que estão em memória e, apesar de permanecerem no dump, pode ser difícil extraí-los, por isso recomenda-se sua extração na própria máquina. A lista abaixo exibe alguns mas o investigador pode avaliar o que é mais importante para cada caso:

• Processos em execução

• Sockets abertos

• Usuários logados

• Arquivos abertos

• Tabela de rotas

• Tabela ARP

• Variáveis de ambiente

• Dispotivos montados

• Itens conectados à USB

3.4 Análise de dumps de memória e disco

4Linux – www.4linux.com.br

O script pelicano.sh cria um relatório com a maioria dessas informações, com base nos comandos

O script pelicano.sh cria um relatório com a maioria dessas informações, com base nos comandos do próprio Linux. Não deixe de checar. ;)

3.4 Análise de dumps de memória e disco

Após obter de forma segura dumps de memória e de disco, é preciso começar o trabalho de análise. Veremos agora algumas técnicas para obter informações sobre os dumps que colhemos.

3.4.1 Busca de strings

As strings (textos) dentro de um dump pode ajudar bastante a análise, principalmente ao sabermos em que lugar do dump ela está. Para entendermos o que é, efetiva- mente, uma string, primeiro é preciso saber como os caracteres são de texto são representados.

Você provavelmente já ouviu falar na tabela ASCII (American Standard Code for In- formation Interchange), certo? É uma tabela que relaciona cada caractere com um número, de 0 a 255, totalizando 256 caracteres possíveis. Para visualizá-la, você pode conferir o Anexo II, mas se tiver o hack-functions instalado, basta comandar asciitable no terminal.

Através da tablea ASCII é possível perceber que a letra maiúscula F, por exemplo, possui o código 0x46 (70 decimal).

Na verdade o número 0x46 é representado como F, quando você pede. Por exem- plo:

4Linux – www.4linux.com.br

3.4 Análise de dumps de memória e disco

$

0x46

$

F

$

\x34\x4c\x69\x6e\x75\x78

echo

echo

0x46

-e

’\x46’

-x

str2hex

4Linux

No exemplo acima exibi o texto 0x46, o equivalente em ASCII do número 0x46, com o comando echo. Em seguida, usei a função str2hex das hack-fuctions para exibir o byte correspondente de cada caractere da string 4Linux. Que tal conferir na tabela ASCII se a função está mostrando os bytes corretamente?

Sendo assim, devemos concordar que para procurar strings dentro de um arquivo, seja ele qual for, é só procurar uma sequência de bytes (digamos, com no mínimo três) que estejam na faixa de 0x20 até 0x7e, correto? Se olhar na table ASCII, verá que estes são os caracteres imprimíveis.

Uma implementação simples, em C, seria:

strings.c

1

# < stdio .h >

include

 

2

# < stdbool .h >

include

 

3

 

4

int

main ( int

argc ,

char

* argv [])

 

5

{

6

//

ponteiro

para

o

arquivo

 

7

FILE

* arquivo ;

 

8

 

9

//

buffer

de

1

byte

(0

a

255)

para

armazenar

o

byte

lido

 

10

unsigned

char

buffer ;

 

11

 

12

//

esta

vari á vel

vai

controlar

quando

vamos

pular

linha

 

13

bool

nova_string

=

false ;

 

14

 

15

//

se

n ã o

for

informado

 

nenhum

arquivo ,

emite

um

erro

e

sai

16

if

( argc

!=

2)

3.4 Análise de dumps de memória e disco

4Linux – www.4linux.com.br

17

{

18

 

printf ( " Uso :\ n \ t % s

< arquivo >\ n " ,

argv [0]) ;

 

19

return

1;

20

}

21

22

//

tenta

abrir

o

arquivo

 

23

arquivo

=

fopen ( argv [1] ,

" rb " ) ;

 

24

 

25

//

caso

n ã o

consiga ,

emite

um

 

erro

e

sai

 

26

if

( arquivo

==

NULL )

 

27

{

28

 

printf ( " arquivo

% s

inexistente

ou

ileg í vel \ n " ,

argv [1]) ;

29

return

1;

30

}

31

32

// enquanto a fun ç ã o fread () retornar 1 , significa

 

33

//

que

1

byte

foi

lido

no

arquivo

e

o

loop

continua

34

while ( fread (& buffer ,

sizeof ( buffer ) ,

 

1

,

arquivo ) ==

1)

35

{

36

 

//

se

o

byte

estiver

entre

a

faixa

 

desejada

 

37

if

( buffer

>=

&&

buffer

<=

’~ ’)

 

38

{

39

 

//

se

for

uma

nova

string ,

pula

 

uma

linha

 

40

if

( nova_string

==

true )

 

41

putchar ( ’\ n ’) ;

 

42

 

43

 

//

imprime

na

tela

a

representa ç ã o

ASCII

do

byte

44

putchar ( buffer ) ;

 

45

 

46

 

//

assume

que

a

string

ainda

n ã o

 

acabou

 

47

nova_string

=

false ;

 

48

 

}

49

else

 

50

{

51

 

//

o

byte

atualmente

lido

n ã o que

pertence

à

52

//

faixa ,

ent ã o

assumimos

 

uma

 

nova

53

//

string

vem

a í !

 

4Linux – www.4linux.com.br

3.4 Análise de dumps de memória e disco

54

 

nova_string

=

true ;

 

55

}

56

}

57

putchar ( ’\ n ’) ;

 

58

fclose ( arquivo ) ;

 

//

fecha

o

arquivo

59

 

60

 

return

0;

61

}

O

programa acima vai imprimir na tela todos os bytes de um arquivo passado por

argumento que possuam representação em ASCII e sejam imprimíveis.

Para desafiar seus conhecimentos em programação, veja se consegue imple- mentar neste programa a impressão

Para desafiar seus conhecimentos em programação, veja se consegue imple- mentar neste programa a impressão na tela do offset (posição no arquivo) onde a string se encontra.

Mas não precisamos escrever nosso próprio programa de busca de strings se es- tivermos no Linux pois o projeto GNU já fornece um programa chamado strings que faz exatamente isto:

$

strings

-t

x

mbr.img

 

9d

ZRr=

116

‘|f

11f

\|f1

180

GRUB

186

Geom

18b

Hard

Disk

195

Read

19a

Error

 

O

comando strings adimite que, para ser uma string, a sequência precisa ter pelo

menos 3 caracteres imprimíveis. A opção -t x faz com que ele imprima o offset da

3.4 Análise de dumps de memória e disco

4Linux – www.4linux.com.br

string em hexadecimal. Assim, numa análise, você pode copiar todas as strings num dump de memória para um arquivo:

$

strings

-t

x

ramdump

>

3.4.2 Carving

ramdump_strings.txt

É possível também procurar por formatos de arquivo conhecidos dentro de um ar- quivo binário, técnica conhecida como carving. Para entender como essa extração funciona, primeiro temos que entender o que é um formato de arquivo.

Um formato de arquivo normalmente é um padrão, um documento, que define como um determinado arquivo deve ser criado. Por exemplo, para arquivos do tipo PE (Portable Executable), o formato especifica que os dois primeiros bytes do arquivo devem ser 0x4d e 0x5a, além de várias outras obrigações da aplicação que cria tais arquivos, que no caso do executável PE, são os compiladores. Sabendo disso nós podemos procurar dentro de um arquivo binário por um tipo de arquivo específico e se consguirmos saber em qual byte termina o arquivo, podemos extraí-lo por inteiro com o dd, por exemplo.

Buscando a string que identifica um GIF

Neste exemplo vamos buscar por arquivos GIF dentro do dump. Para isso pre- cisamos conhecer a especificação do GIF, como mostra a tabela abaixo (fonte: Wikipedia):

byte#

hexadecimal

text

or

(hex)

value

Meaning

0:

47

49

46

38

39

61

GIF89a

Header

 

Logical

Screen

Descriptor

4Linux – www.4linux.com.br

3.4 Análise de dumps de memória e disco

6:

03

00

3

-

logical

screen

width

in

pixels

 

8:

05

00

5

-

logical

screen

height

in

pixels

A:

F7

-

GCT

follows

for

256

colors

with

resolution

3

x

8

bits/primary

 

B:

00

0

-

background

color

#0

C:

00

-

default

pixel

aspect

ratio

 
 

R

G

B

Global

Color

Table

 

D:

00

00

00

0

0

0

-

color

#0

black

10:

80

00

00

128

0

0

-

color

#1

:

:

85:

00

00

00

0

0

0

-

color

#40

black

 

:

:

30A:

FF

FF

FF

255

255

255

-

color

#255

white

 

30D:

21

F9

Graphic

Control

Extension

 

30F:

04

4

-

4

bytes

of

GCE

data

follow

 

310:

01

-

there

is

a

transparent

background

color

311:

00

00

-

delay

for

animation:

not

used

313:

10

16

-

color

#16

is

transparent

314:

00

-

end

of

GCE

block

 

315:

2C

Image

Descriptor

316:

00

00

00

00

(0,0)

 

-

NW

corner

position

of

image

in

logical

screen

31A:

03

00

05

00

(3,5)

-

image

width

and

height

in

pixels

31E:

00

-

no

local

color

table

 

31F:

08

8

Start

of

image

-

LZW

minimum

code

size

320:

0B

11

-

11

bytes

of

LZW

encoded

image

data

follow

321:

00

51

FC

1B

28

70

A0

C1

83

01

01

32C:

00

-

end

of

image

data

32D:

3B

GIF

file

terminator

 

De cara, vemos o header da última versão do formato, que deve ser composto pelos bytes 0x47 0x49 0x46 0x38 0x39 0x61, que representam em ASCII a string "GIF89a". Se quiser confirmar, pode checar na tabela ASCII.

Então vamos ao grep:

3.4 Análise de dumps de memória e disco

4Linux – www.4linux.com.br

$

strings

80000

-t

x

GIF89ae

dump.bin

|

grep

GIF89a

Casamos com a string inteira. Seria muita coincidência esses 6 caracteres casarem se isso não for o início de um GIF? É o que veremos:

$

hd

-s

0x80000

-n

64

dump.bin

 

00080000

47

49

46

38

39

61

65

01

1a

02

f7

00

00

bb

9c

91

|GIF89ae

|

00080010

6e

5b

54

d9

ad

9c

6b

69

69

ca

a4

94

e3

8c

7d

3f

|n[T

kii

}?|

00080020

1e

0e

33

0d

09

f6

cb

ba

e1

b4

a3

e3

bb

aa

eb

ca

|

3

|

00080030

8a

c8

44

39

0b

05

04

6b

26

21

44

27

19

fa

f2

e4

|

D9

k&!D’

|

A documentação diz que depois do header de 6 bytes, temos 2 bytes identificando

a largura (0x165) e mais 2 para a altura (0x21a), o que definiria um GIF de 357x538 pixels e parece aceitável.

O próximo byte, segundo o exemplo na documentação, quando é 0xf7, diz que o GIF

tem 256 cores, dentre outras informações. Este byte bate com o nosso 0xf7.

Não precisamos ir até o final checando todos os campos para chegar ao fim do

arquivo. A maioria dos formatos de arquivo definem um ou mais bytes para marcar

o fim do arquivo. No caso do GIF, veja na documentação que os últimos bytes são

0x00 (end) e 0x3b (GIF terminator). Lembre-se que isso é específico do formato

GIF e não é regra para qualquer tipo de arquivo. Cada um tem seu formato.

Os formatos que não possuem bytes que marcam o fim, geralmente possuem um campo que

Os formatos que não possuem bytes que marcam o fim, geralmente possuem um campo que diz o tamanho completo do arquivo.

4Linux – www.4linux.com.br

3.4 Análise de dumps de memória e disco

Estratégia para extrair o possível GIF do dump

Podemos usar a estratégia de extrair os bytes desde o ’G’ do "GIF89a"até a primeira sequência 0x00 0x3b. Se for um GIF real, deveria funcionar.

Vamos à busca:

$

hd

-s

0x80000

dump.bin

|

grep

--color

"00

3b"

00082b60

3d

97

87

80

00

00

3b

55

d9

60

ab

23

eb

24

ac

f1

|=

;U.‘.#.$

|

000ef4e0

2b

61

8d

77

00

3b

7c

58

62

23

4a

dc

4c

15

42

da

|+a.w.;|Xb#J.L.B.|

A primeira sequência que "00 3b"que o grep encontrou após o offset 0x80000 (início

do GIF) está em 0x82b65. Neste offset está o 0x00 e em 0x82b66 está o 0x3b, portanto o próximo byte (0x55) não faz parte do GIF.

Se diminuirmos a posição do último byte + 1 de 0x80000, teremos o tamanho total do suposto GIF:

$ echo

11111

$((0x82b67-0x80000))

A resposta é em decimal. Uma maneira mais fácil de fazer esta conta e já ter a

resposta em hexadecimal seria usando a função hexcalc:

$

0x2b67

hexcalc

82b67

-

80000

É preciso somar mais um pois o primeiro byte, na posição 0x80000, já conta. Vamos

relembrar o que temos:

Tipo: GIF Resolução: 357x538 pixels

3.4 Análise de dumps de memória e disco

4Linux – www.4linux.com.br

Tamanho: 11111 bytes (11 KB)

Extração com o dd

Vamos tentar extrair o suposto GIF do arquivo de dump:

$

dd

if=dump.bin

of=possivel.gif

bs=1

count=11111

11111+0

registros

de

entrada

11111+0

registros

de

saída

11111

bytes

(11

kB)

copiados,

0,036675

s,

303

kB/s

skip=$((0x80000))

A opção bs (block size) informa ao dd para assumir blocos de 1 byte. A opção count

diz quantos blocos ele vai ler, então vão dar exatamente 11111 bytes. E por fim, a opção skip, que só aceita números em decimal (por isso a conversão com o bash) informa quantos bytes o dd vai pular para começar a ler, assim como a opção -s"do hd. Temos que começar a extração do byte 0x80000, que é onde começa o GIF.

Vamos conferir:

$

possivel.gif:

file

possivel.gif

GIF

image

$

11111 possivel.gif

wc

-c

possivel.gif

data,

version

89a,

3.4.3 Usando o foremost

357

x

538

O foremost é uma ferramenta de código aberto que automatiza o trabalho manual de

busca de arquivos em arquivos binários ou diretamente em um dispositivo. Ele tam-

4Linux – www.4linux.com.br

3.4 Análise de dumps de memória e disco

bém se baseia no formato de arquivos para realizar sua busca. Seu uso é bastante simples:

$

Foremost

Audit

foremost

File

-vi

version

dump.bin

1.5.7

by

Jesse

Kornblum,

Kris

Foremost

Invocation:

Output

Configuration

Processing:

started

at

Wed

May

23

dump.bin

05:57:14

foremost

-vi

output

directory:

file:

/etc/foremost.conf

dump.bin

2012

Kendall,

and

Nick

Mikus

|------------------------------------------------------------------

File:

dump.bin

 

Start:

Wed

May

23

05:57:14

2012

Length:

1024

KB

(1048576

bytes)

 

Num

Name

(bs=512)

 

Size

File

Offset

Comment

 

0:

00001024.gif

 

10

KB

524288

(357

x

538)

*|

Finish:

Wed

May

23

05:57:14

2012

 

1

FILES

EXTRACTED

 

gif:=

1

 

------------------------------------------------------------------

Foremost

finished

at

Wed

May

23

05:57:14

2012

A opção -v faz o foremost operar em modo verbose (detalhado), enquanto a oção -i especifica um arquivo de entrada, no caso, nosso dump. Conforme pode ser visto, um GIF foi extraído e era exatamente o que esperávamos.

3.4 Análise de dumps de memória e disco

4Linux – www.4linux.com.br

3.4.4 Trabalhando com imagens de disco

Trabalhar com imagens de disco geralmente envolve montá-las como somente leitura e buscar por arquivos de log, configuração e afins.

O primeiro passo antes de iniciar o trabalho de análise numa imagem cap- turada é

O primeiro passo antes de iniciar o trabalho de análise numa imagem cap- turada é checar seus hashes. Para isso é essencial que os hashes tenham sido calculados quando a imagem foi obtida (vimos na seção anterior que o dcfldd já faz isso).

No exemplo abaixo, temos uma imagem de um disco inteiro, chamada sda.img. Como não podemos simplesmente montar um disco inteiro e sim suas partições, precisaremos analisá-la. Para isso, faremos uso do Sleuth Kit, mas antes vamos tomar algumas medidas preventivas para não comprometermos a imagem:

chmod

$ -w

sda.img

$ sda.img

md5sum

&&

sha1sum

sda.img

cebdd715d4ecaafee8f147c2e85e0754

ec3e661d7bc7bfbf5334e7dfad309f947dace5f7

$

$