Apostila Técnicas de Computação Forense

Fazer download em pdf ou txt
Fazer download em pdf ou txt
Você está na página 1de 104

509 | 4509

Técnicas de Computaçao Forense

www.4linux.com.br
Conteúdo

i
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
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.

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.

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

Página2 TécnicasdeComputaçaoForense
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.

TécnicasdeComputaçaoForense Página3
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 garantid a e é exatamente o que
acontece nesta etapa.

A ideia é que você não cause nenhuma alteração nas evidência s 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.

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

Página4 TécnicasdeComputaçaoForense
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 parece r 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, desconecta r 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 dispositi vos 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 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
srcinal a partir do hash, mas se o mesmo algoritmo é aplicado a uma cópia idêntica
do dado srcinal, o hash resultante será o mesmo.

TécnicasdeComputaçaoForense Página5
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 progr ama para real izar 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 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.

Página6 TécnicasdeComputaçaoForense
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 aplic am 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

TécnicasdeComputaçaoForense Página7
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 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.

Página8 TécnicasdeComputaçaoForense
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 prova r.

• 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 consulta do 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.

TécnicasdeComputaçaoForense Página9
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 util izada por
processos essenciais do sistema também é necessária, que veremos adiante.

11
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 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 princ ipal vive um computador. Existem ainda outr as
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.

Página12 TécnicasdeComputaçaoForense
4Linux – www.4linux.com.br 2.5 Mídias USB e ópticas

2.5 Mídias USB e ópti cas

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 leitur a. Qualquer software capaz de efetu ar
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çõe s, 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 par ticionamento, 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

TécnicasdeComputaçaoForense Página13
2.6 Partições 4Linux–www.4linux.com.br

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

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:

Página14 TécnicasdeComputaçaoForense
4Linux–www.4linux.com.br 2.7 Discosrígidos

Offset (hexa) Tamanho (bytes) Descrição


0 440 Áreadecódigo
1b8 4 Identificador/assinatura do disco
1be 64 Tabeladepartiçõ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 par tições na tabela


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

especial
uma novadeestrutura,
partição fora
chama da de conhecida
do MBR, extendida (tipo
como0x5)
EBR. (Extended
Esta partição
Bootaponta para
Record)
que também contém tabela de partições.

2.7 Discos rígidos

Uma outra possibilid ade é 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.

TécnicasdeComputaçaoForense Página15
Capítulo 3

Investigação em ambientes
GNU/Linux

3.1 Características dos kerne ls atuais

É mais que sabido por todos os profissionais da área de tecnologia que ela muda
muita. Na computação forense não é dife rente. Uma ferramenta ou abordag em
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 ferramen tas e técnicas às novas configurações . Um

17
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 ex terno, 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 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.

Página18 TécnicasdeComputaçaoForense
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 comprovad a.

3.2.1 Memória mapeadas por proce sso

Para obter uma cópia da memória mapeada por um processo no Linux, primeiro
é preciso sabe r qual a faixa de endereç os que o processo está uti lizando. Para
isto, você pode consultar um arquivo especial em /proc/<pid>/maps onde <pid> é o
PID (Proce ss IDentifi er) 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/178/maps
4-41 r-xp  8:5 764329
6-61 rw-p  8:5 764329
7fe6d5d29-7fe6d5ea6 r-xp glib/x86_64-linux-gnu/libc-2.13.so

7fe6d5ea6-7fe6d6a6 ---p glib/x86_64-linux-gnu/libc-2.13.so


7fe6d6a6-7fe6d6aa r--p glib/x86_64-linux-gnu/libc-2.13.so
7fe6d6aa-7fe6d6ab rw-p glib/x86_64-linux-gnu/libc-2.13.so
7fe6d6b-7fe6d6cf r-xp glib/x86_64-linux-gnu/ld-2.13.so

TécnicasdeComputaçaoForense Página19
3.2 Aquisição de memória RAM 4Linux – www.4linux.com.br

7fe6d62cf-7fe6d62d r--p glib/x86_64-linux-gnu/ld-2.13.so


7fe6d62d-7fe6d62d1 rw-p glib/x86_64-linux-gnu/ld-2.13.so
7fff9586f-7fff9589 rw-p [stack]
7fff959ff-7fff95a r-xp [vdso]
ffffffffff6-ffffffffff61 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 178


(gdb) dump memory 178.stack x7fff9586f x7fff9589
(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 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.

Página20 TécnicasdeComputaçaoForense
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ív el. 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
256+ registros de entrada
256+ registros de saída
152672 bytes (1,1 MB) copiados, ,362599 s,
29, MB/s

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

# grep DEVMEM /boot/config-$(uname -r)


CONFIG_STRICT_DEVMEM=y

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

TécnicasdeComputaçaoForense Página21
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ív el livremente na internet:

$ wget -c http://hysteria.sk/~niekt/foriana/fmem_current.tgz
$ tar xf fmem_current.tgz
$ cd fmem*
$ make
$ sudo ./run.sh

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ég ios de root). No entanto, o fmem exige

que vocêIsso
sistema. o informe quando
pode ser parar,antes
conferido ou seja,
comqual a quantidade
o comando free: de memória total do

$ free -m
total used free shared buffers cached
Mem: 391 3779 122  138 1466
-/+ buffers/cache: 2175 1726
Swap: 926  926

# dd if=/dev/fmem of=ramdump bs=1M count=391

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.

Página22 TécnicasdeComputaçaoForense
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): 36331d9f83f364726e55f4337bf36b3689e3

1+ records in
1+ 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 ferramen ta Unix-like que se preze. ;)

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

# fdisk -l

Disk /dev/sda: 32.1 GB, 3272933376 bytes


255 heads, 63 sectors/track, 38913 cylinders, total 625142448 sectors
Units = sectors of 1 * 512 = 512 bytes

TécnicasdeComputaçaoForense Página23
3.3 Aquisição de dados de filesystems ext4 4Linux – www.4linux.com.br

Sector size (logic al/physical): 512 bytes / 512 bytes


I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: x796db3a

Device Boot Start End Blocks Id System


/dev/sda1 * 248 78319615 39158784 83 Linux
/dev/sda3 78321662 625141759 2734149 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


2944 blocks (92Mb) written.Total (md5): a3b18f299fed1565c167a17b519355
Total (sha1): 99c32b3a6d98af2e18dc5fbf86bcc4ac23b69b

29664+ records in
29664+ 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ê enco ntre sistemas ext3, ZFS
(Sun/Oracle), JFS (IBM), dentr e outros em servidores Linux ou Unix. No entanto,
os conceitos expostos aqui servirão como base para estudo dos conceitos de outros
filesystems.

Página24 TécnicasdeComputaçaoForense
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 f oi 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 ferramenta s presentes na suíte e2fsprogs merecem destaque:

http://e2fsprogs.sourceforge.net

e2image Gera imagens com metadados crítico s de partições para arquivo s

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 inf ormaçõ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

TécnicasdeComputaçaoForense Página25
3.3 Aquisição de dados de filesystems ext4 4Linux – www.4linux.com.br

File: "mbr.img"
Size: 512 Blocks: 8 IO Block: 496 arquivo comum
Device: 85h/253d Inode: 764329 Links: 1
Access: (644/-rw-r--r--) Uid: ( 1/ nandu) Gid: ( 1/ nandu)
Access: 212-5-22 :6:14.49224942 -3
Modify: 212-5-22 :6:32.56336493 -3
Change: 212-5-22 :6:32.56336493 -3
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:

# debugfs -R ’stat <764329>’ /dev/sda5


Inode: 764329 Type: regular Mode: 644 Flags: x8
Generation: 3982433542 Version: x:1
User: 1 Group: 1 Size: 512
File ACL:  Directory ACL: 
Links: 1 Blockcount: 8
Fragment: Address:  Number:  Size: 
ctime: x4fbb2b8:d6e81b4 -- Tue May 22 :6:32 212
atime: x4fbb2a6:755c84e8 -- Tue May 22 :6:14 212
mtime: x4fbb2b8:d6e81b4 -- Tue May 22 :6:32 212
crtime: x4fbb1ac:be7fc6ac -- Tue May 22 :2:4 212
Size of extra inode fields: 28
EXTENTS:
():3154696

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á:

Página26 TécnicasdeComputaçaoForense
4Linux – www.4linux.com.br 3.3 Aquisição de dados de filesystems ext4

$ rm mbr.iso
# debugfs -R ’stat <764329>’ /dev/sda5
Inode: 764329 Type: regular Mode: 644 Flags: x8
Generation: 3982433542 Version: x:1
User: 1 Group: 1 Size: 
File ACL:  Directory ACL: 
Links:  Blockcount: 
Fragment: Address:  Number:  Size: 
ctime: x4fbb3ad4:dc6a9c -- Tue May 22 4:5:56 212
atime: x4fbb39fe:dce57df -- Tue May 22 4:2:22 212
mtime: x4fbb3ad4:dc6a9c -- Tue May 22 4:5:56 212
crtime: x4fbb1ac:be7fc6ac -- Tue May 22 :2:4 212
dtime: x4fbb3ad4 -- Tue May 22 4:5:56 212
Size of extra inode fields: 28
EXTENTS:

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

3.3.2 Como o ext4 grav a 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 -h /dev/sda5 | grep ’Block size’


dumpe2fs 1.42.2 (9-Apr-212)
Block size: 496

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


matada com ext4.

TécnicasdeComputaçaoForense Página27
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 <764329>’ /dev/sda5


debugfs 1.42.2 (9-Apr-212)
3447449

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 extr air tal bloco do disco com o dd:

dd if=/dev/sda5 of=bloco bs=496 count=1 skip=3447449


1+ registros de entrada
1+ registros de saída
496 bytes (4,1 kB) copiados, ,167189 s, 245 kB/s

No exemplo acima trabalhei com um tamanho de bloco de 4096 bytes (consultado

previamente dumpe2fs)
arquivo for menor e o extraí
que o bloco, apóspara um arquivo
o último byte dochamado bloco.osSe
arquivo, todos o tamanho
bytes do
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+ registros de entrada
1+ registros de saída
512 bytes (512 B) copiados, 4,5397e-5 s, 11,3 MB/s
$ md5sum mbr.*
d57d9e9521f756b88c1b728cd726a149 mbr.bin
d57d9e9521f756b88c1b728cd726a149 mbr.recuperado

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

Página28 TécnicasdeComputaçaoForense
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 tran sações no filesys tem. Neste caso, o
comando logdump do debugfs pode ser utilizado para checar em que bloco de dados
há uma cópia do arquivo represen tado pelo inode em questão, caso haja.

3.3.3 Outros itens na memóri a 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

TécnicasdeComputaçaoForense Página29
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 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 sabermo s 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:

Página30 TécnicasdeComputaçaoForense
4Linux – www.4linux.com.br 3.4 Análise de dumps de memória e disco

$ echo x46
x46
$ echo -e ’\x46’
F
$ str2hex -x 4Linux
\x34\x4c\x69\x6e\x75\x78

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 #incl ude <stdi o.h>
2 #incl ude <stdbo ol.h>
3
4 in t ma in(in t ar gc, ch ar *arg v[])
5 {
6 // p ont eir o par a o ar qui vo
7 FIL E *arquiv o;
8
9 // bu ff er de 1 by te ( a 25 5) par a ar ma ze na r o by te lid o
10 unsig ned cha r buff er;
11
12 // est a va riáve l va i con tro lar quan do vamo s pul ar linh a
13 bo ol no va_ str ing = f al se;
14
15 // se não for in fo rm ad o ne nh um ar qu iv o , em it e um er ro e sa i
16 if ( ar gc != 2 )

TécnicasdeComputaçaoForense Página31
3.4 Análise de dumps de memória e disco 4Linux – www.4linux.com.br

17 {
18 prin tf("Uso:\n\t%s <arq uiv o >\n", arg v[
19 retu rn 1;
20 }
21
22 // t en ta ab ri r o arq ui vo
23 arq uiv o = fop en(ar gv[1 ], "rb") ;
24

25 // cas o não con si ga , em it e um err o e sa i


26 if (ar qu iv o == N UL L)
27 {
28 pr int f("arq uiv o %s i nex ist ent e ou i le gível\ n", a rg v[1] );
29 retu rn 1;
30 }
31
32 // enqu ant o a fu nção fre ad() reto rna r 1, sig nif ica
33 // qu e 1 by te fo i li do no ar qu iv o e o loo p co nt in ua
34 whil e(fread(&buf fer , size of(buffer), 1, arqui vo) == 1)
35 {
36 // s e o b yt e est iv er en tr e a fa ix a des ej ad a
37 if (b uf fe r >= ’ ’ && bu ff er < = ’ ~’ )
38 {
39 // se f or u ma n ov a st ri ng , p ul a um a li nh a
40 if (nova _st rin g == tr ue)
41 putchar(’\n’);
42
43 // im pr im e n a t el a a re pr es en taçã o A SC II do b yt e
44 putchar(buffer);
45
46 // as su me qu e a st ri ng ai nd a não ac ab ou
47 nov a_s tri ng = fa lse;
48 }
49 else
50 {
51 // o by te at ua lm en te li do não pe rt en ce à
52 // fa ix a , en tão as su mi mo s qu e um a no va
53 // st ri ng ve m aí!

Página32 TécnicasdeComputaçaoForense
4Linux – www.4linux.com.br 3.4 Análise de dumps de memória e disco

54 nov a_s tri ng = tr ue;


55 }
56 }
57 putchar(’\n’);
58 fc los e(arqu ivo); / / fech a o arqu ivo
59
60 retu rn ;
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 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
18 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 impri míveis. A opção -t x faz com que ele imprima o offset da

TécnicasdeComputaçaoForense Página33
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 > ramdump_strings.txt

3.4.2 Carving

É 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


: 47 49 46
38 39 61 GIF89a Header
Logical Screen Descriptor

Página34 TécnicasdeComputaçaoForense
4Linux – www.4linux.com.br 3.4 Análise de dumps de memória e disco

6: 3  3 - logical screen width in pixels


8: 5  5 - logical screen height in pixels
A: F7 - GCT follows for 256 colors with resolution 3
x 8 bits/primary
B:   - background color #
C:  - default pixel aspect ratio
R G B Global Color Table
D:       - color # black
1: 8   128   - color #1
: :
85:       - color #4 black
: :
3A: FF FF FF 255 255 255 - color #255 white
3D: 21 F9 Graphic Control Extension
3F: 4 4 - 4 bytes of GCE data follow
31: 1 - there is a transparent background color
311:   - delay for animation: not used
313: 1 16 - color #16 is transparent
314:  - end of GCE block
315: 2C Image Descriptor
316:     (,) - NW corner position of image in logical screen
31A: 3  5  (3,5) - image width and height in pixels
31E:  - no local color table
31F: 8 8 Start of image - LZW minimum code size
32: B 11 - 11 bytes of LZW encoded image data follow
321:  5 1 F C 1 B 2 8 7  A  C 1 8 3  1  1
32C:  - 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 0x47confirmar,
Se quiser 0x49 0x46pode
0x38checar
0x39 0x61, queASCII.
na tabela representam em ASCII a string "GIF89a".

Então vamos ao grep:

TécnicasdeComputaçaoForense Página35
3.4 Análise de dumps de memória e disco 4Linux – www.4linux.com.br

$ strings -t x dump.bin | grep GIF89a


8 GIF89ae

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

$ hd -s x8 -n 64 dump.bin
8 47 49 46 38 39 61 65 1 1a  2 f7   bb 9c 91 |GIF89ae.........|
81 6e 5b 54 d9 ad 9c 6b 69 69 c a a4 94 e3 8c 7d 3f |n[T...kii.....}?|
82 1e e 33 d 9 f6 cb ba e1 b 4 a3 e3 bb aa eb ca |..3.............|
83 8a c8 44 39 b 5 4 6b 26 2 1 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 terminat or). 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 diz o tamanho completo do arquivo .

Página36 TécnicasdeComputaçaoForense
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 x8 dump.bin | grep --color " 3b"


82b6 3d 97 87 8   3b 55 d9 6  ab 23 eb 24 ac f1 |=.....;U.‘.#.$..|
ef4e 2b 61 8d 77  3b 7c 58 62 2 3 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 0x82 b65. Neste offs et está o 0x00 e em 0x82 b66 est á o 0x3b,
portanto o próximo byte (0x55) não faz par te do GIF.

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


do suposto GIF:

$ echo $((x82b67-x8 ))


11111

A resposta é em deci mal. Uma man eira mais fácil de fazer esta con ta e já ter a
resposta em hexadecima l seria usando a função hexcalc:

$ hexcalc 82b67 - 8


x2b67

É 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

TécnicasdeComputaçaoForense Página37
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 skip=$((x8))


11111+ registros de entrada
11111+ registros de saída
11111 bytes (11 kB) copiados, ,36675 s, 33 kB/s

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:

$ file possivel.gif
possivel.gif: GIF image data, version 89a, 357 x 538

$ wc -c possivel.gif
11111 possivel.gif

3.4.3 Usando o foremost

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-

Página38 TécnicasdeComputaçaoForense
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 -vi dump.bin


Foremost version 1.5.7 by Jesse Kornblum, Kris Kendall, and Nick Mikus
Audit File

Foremost started at Wed May 23 5:57:14 212


Invocation: foremost -vi dump.bin
Output directory: output
Configuration file: /etc/foremost.conf
Processing: dump.bin
|------------------------------------------------------------------
File: dump.bin
Start: Wed May 23 5:57:14 212
Length: 124 KB (148576 bytes)

Num Name (bs=512) Size File Offset Comment

: 124.gif 1 KB 524288 (357 x 538)


*|
Finish: Wed May 23 5:57:14 212

1 FILES EXTRACTED

gif:= 1
------------------------------------------------------------------

Foremost finished at Wed May 23 5:57:14 212

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.

TécnicasdeComputaçaoForense Página39
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 é checar seus hashe s. Para isso é essencial que os hashes ten ham 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 anali sá-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
$ md5sum sda.img && sha1sum sda.img
cebdd715d4ecaafee8f147c2e85e754 sda.img
ec3e661d7bc7bfbf5334e7dfad39f947dace5f7 sda.img
$ cp sda.img{,.1}
$ md5sum sda.img.1 && sha1sum sda.img .1
cebdd715d4ecaafee8f147c2e85e754 sda.img.1
ec3e661d7bc7bfbf5334e7dfad39f947dace5f7 sda.img.1

Usando o Sleuth Kit

O Sleuth Kit éouum


diretamente emconjunto
imagensde(cópias
ferramentas para As
perfeitas). analisar sistemas
ferramentas de arquivos,
disponíveis são:seja

blkcalc

Página40 TécnicasdeComputaçaoForense
4Linux – www.4linux.com.br 3.4 Análise de dumps de memória e disco

blkcat exibe o conteúdo de um bloco de uma imagem

blkls lista os blocos de uma imagem

blkstat exibe detalhes dos blocos de uma imagem

ffind busca arquivos por inode

fls lista arquivos numa imagem

fsstat exibe detalhes do filesystem de uma imagem

hfind busca um hash num banc o de dados

icat exibe o conteúdo de um arquivo por inode

ifind

ils lista os inodes de uma imagem

img_cat exibe os dados de uma imagem não bruta

img_stat exibe os detalhes de uma imagem não bruta

istat exibe detalhes de um inode

jcat exibe o conteúdo de um bloco do journal

jls exibe o conteúdo do journal

mactime cria uma linha do tempo de atividad es

mmcat exibe o conteúdo de uma partição dentro de uma imagem

mmls exibe a tabela de partições de uma imagem

TécnicasdeComputaçaoForense Página41
3.4 Análise de dumps de memória e disco 4Linux – www.4linux.com.br

mmstat exibe detalhes sobre a tabela de partição de uma imagem

sigfind busca um padrão (assinatura) num arquivo

sorter cria uma lista ordenada por tipo de arquivo de arquiv os numa imagem

srch_strings busca strings em arquivos

tsk_comparedir compara um diretório com uma imagem

tsk_gettimes coleta os MAC times de cada filesystem de uma imagem

tsk_loaddb grava os metadados de uma imagem num banco de dados SQLite

tsk_recover extrai arquivos de imagens

Basicamente, onde lê-se "imagem"na listagem acima, também se pode ler "disposi-
tivo", para usar as ferramentas em um dispositivo vivo (ex.: /dev/hda).

Algumas ferramentas do TSK são redundantes em relação ao Linux, no entanto, sua


existência se justifica quando pensamos na característica multiplataforma do projeto.
Daremos um foco maior nas ferramentas do TSK daqui em diante e usaremos menos
ferramentas nativas como dd, fdisk, debug2fs etc.

Obtendo a tabela de partições

Após checar os hashes, vamos listar a tabela de partições da imagem:

$ mmls -B sda.img

DOS Partition Table


Offset Sector: 
Units are in 512-byte sectors

Página42 TécnicasdeComputaçaoForense
4Linux – www.4linux.com.br 3.4 Análise de dumps de memória e disco

Slot S tart End Length Size D escription


: Meta   1 512B Primary Table (#)
1: -----  247 248 124K Unallocated
2: : 248 15988735 15986688 7G Linux (x83)
3: ----- 15988736 1599783 248 124K Unallocated
4: Meta 1599782 16775167 784386 383M DOS Extended (x5)
5: Meta 1599782 1599782 1 512B Extended Table (#1)
6: 1: 1599784 16775167 784384 383M Linux Swap / Solaris
x86 (x82)
7: ----- 16775168 16777215 248 124K Unallocated

A opção -B do mmls adiciona a coluna Size, com os tamanhos das partições encon-
tradas.

Esta listagem também poderia ser feito com outros programas como fdisk ou
parted, mas como combinamos anteriormente, vamos dar foco nas ferramentas do
TSK.

O mmls mostra a localização de cada item encontrado nas tabelas de partições da


imagem. Para exibir mais detalhes sobre um filesystem específico, usamos o fssat,
informando o offset de início do filesystem obtido com o mmls para a partiçao de-
sejada. Você deve ter percebido que o mmls mostr ou uma partição do tipo "Linux
(0x83)"começando no no offset 2048 (decimal). Vamos buscar agora detalhes sobre
ela com o fsstat:

$ fsstat -o 248 sda.img


FILE SYSTEM INFORMATION
--------------------------------------------

File System Type: Ext3


Volume Name:
Volume ID: 78b4e371a6a5439acf4a3c95b7dc3e75

TécnicasdeComputaçaoForense Página43
3.4 Análise de dumps de memória e disco 4Linux – www.4linux.com.br

Last Written at: Wed Mar 14 9:43:53 212


Last Checked at: Wed Mar 14 9:43:53 212

Last Mounted at: Wed May 23 18:24:41 212


Unmounted properly
Last mounte d on:

Source OS: Linux


Dynamic Structure
Compat Features: Journal, Ext Attributes, Resize Inode, Dir Index
InCompat Features: Filetype,
Read Only Compat Features: Sparse Super, Has Large Files,

Journal ID: 
Journal Inode: 8

METADATA INFORMATION
--------------------------------------------
Inode Range: 1 - 499713
Root Directory: 2
Free Inodes: 33871

CONTENT INFORMATION
--------------------------------------------
Block Range:  - 1998335
Block Size: 496
Free Blocks: 64775

BLOCK GROUP INFORMATION


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

Aqui cabe um questionamento: como é possível garantir que as ferramentas do


TSK trabalhem em modo somente leitura com as imagens informadas? Esperamos

Página44 TécnicasdeComputaçaoForense
4Linux – www.4linux.com.br 3.4 Análise de dumps de memória e disco

que sim, mas é possível verificar? Como você faria?

Buscando arquivos deletados

A ferramenta ils, do TSK, lista informações sobre os inodes de arquivos em uma


imagem, no entanto, por padrão ela só exibe os inodes de arquivos removidos já que
os arquivos não removidos podem ser obtidos facilmente montando a imagem já que
a tabela de partições deste sample não está corrompida.

$ ils -o 248 -m sda.img > deletados

Redirecionamos a saída para um arquivo chamado "deletados". Veja parte dele:

$ head deleta dos


md5|file|st_ino|st_ls|st_uid|st_gid|st_size|st_atime|st_mtime|st_ctime|st_crtime
|<sda.img-dead-8348>|8348|-/rrwxr-xr-x||||131488875|131625882|131625882|
|<sda.img-dead-8349>|8349|-/rrwxr-xr-x||||131488875|131625882|131625882|
|<sda.img-dead-9398>|9398|-/lrwxrwxrwx|||22|1317147975|131472373|131714988|
|<sda.img-dead-9413>|9413|-/rrw-r--r--||||131472392|131472392|131472392|
|<sda.img-dead-16562>|16562|-/rrw-r--r--|6|||1316191568|1316191568|1316191568|
|<sda.img-dead-3356>|3356|-/lrwxrwxrwx|||28|131626597|131472528|13162862|
|<sda.img-dead-33561>|33561|-/lrwxrwxrwx|||3|131626597|131472528|13162862|
|<sda.img-dead-33563>|33563|-/lrwxrwxrwx|||28|131626597|131472528|13162862|
|<sda.img-dead-33985>|33985|-/rrw-r--r--||||1388282|13147254|13147254|

Perceba que vários arquivos estão com os tamanhos (st_size) zerados e não adi-
anta tentar recupera-los pois não há nada dentro deles. Mesmo os que estão com
tamanho maior que zero, ainda dependerá se os blocos antigamente utilizados pelo
inode já foram reutilizado s ou não. Em caso positivo, a recuperação por software se
torna muito ineficiente.

TécnicasdeComputaçaoForense Página45
3.4 Análise de dumps de memória e disco 4Linux – www.4linux.com.br

Para recuperar um arquivo a partir de seu inode, use:

$ icat -ro 248 sda.img 16562 > arquivo

No exemplo acima usei a opção -r do icat para usar técnicas de recuperação de


arquivos deletados e a opção -o que viemos usando sempre, para setar o offset
da partição que estamos trabalhando dentro da imagem sda.img. Após o nome da
imagem, vem o número do inode que desejamos. Os nomes dos arquivos excluí dos
podem ser obtidos com:

$ fls -rd -o 248 sda.img > lista_excluidos

A opção -r faz o fls funcionar de maneira recursi va, já a -d pede que só liste arquivos
excluídos.

Montando as partições

Todo o trabalho até agora vem sido feito com o arquivo sda.img sem ser montado, no
entanto, é extremamente útil montar as partições desta imagem do disco para facilitar
a busca por arquivos, caso este recurso esteja disponív el. Então mãos à obra:

$ mount -o ro,loop sda.img /mnt


mount: you must specify the filesystem type

O que houve? Acertou se lembrou que o arquivo sda.img é uma imagem de um disco
inteiro e não só de uma partição, por isso é necessário montar somente a partição
no offset 2048 (lembra?) do arquivo e não ele inteiro.

Você está pensando em extrair a partição de dentro do arquivo de imagem? Bem,


isso funcionaria, mas por sorte o mount possui uma opção offset, então basta usá-
la:

Página46 TécnicasdeComputaçaoForense
4Linux – www.4linux.com.br 3.4 Análise de dumps de memória e disco

$ mount -o ro,loop,offset=248 sda.img /mnt


mount: you must specify the filesystem type

Ops. O que houve agora? Lembre-se que esse offset diz respeito a um dispositivo
em blocos (disco rígido) onde a menor unidade de armazenamento é um setor, de
normalmente 512 bytes. Já a opção offset do mount precisa da posição exata do
arquivo de onde começar, para chegar nela basta multiplicar o offset apresentado
pelo mmls pelo tamanho do setor, que o mmls também nos diz:

$ sudo mount -o ro,loop,offset=$((248*512)) sda.img /mnt


$ ls -l /mnt
total 18
drwxr-xr-x 2 root root 496 Ago 3 211 bin
drwxr-xr-x 3 root root 496 Set 14 211 boot
drwxr-xr-x 5 root root 496 Ago 3 211 dev
drwxr-xr-x 13 root root 12288 Mai 23 18:26 etc
drwxr-xr-x 3 root root 496 Set 14 211 home
drwxr-xr-x 4 www-data root 496 Set 14 211 infra_app

lrwxrwxrwx 1 root root 28 Ago 3 211 initrd.img ->


boot/initrd.img-2.6.32-5-686
drwxr-xr-x 12 root root 12288 Ago 3 211 lib
drwx------ 2 root root 16384 Ago 3 211 lost+found
drwxr-xr-x 3 root root 496 Ago 3 211 media
drwxr-xr-x 2 root root 496 Jun 19 211 mnt
drwxr-xr-x 3 root root 496 Set 26 211 opt
drwxr-xr-x 2 root root 496 Jun 19 211 proc
drwx------ 1 root root 496 Abr 7 1:19 root
drwxr-xr-x 2 root root 496 Set 14 211 sbin
drwxr-xr-x 2 root root 496 Jul 21 21 selinux
drwxr-xr-x 2 root root 496 Ago 3 211 srv

drwxr-xr-x 2 root root 496 Jan 1 211 sys


drwxrwxrwt 4 root root 496 Mai 23 18:25 tmp
drwxr-xr-x 11 root root 496 Ago 3 211 usr
drwxr-xr-x 15 root root 496 Set 1 211 var

TécnicasdeComputaçaoForense Página47
3.5 Identificação de binários ELF maliciosos 4Linux – www.4linux.com.br

lrwxrwxrwx 1 root root 25 Ago 3 211 vmlinuz ->


boot/vmlinuz-2.6.32-5-686

Now we’re talking. ;)

E se a tabela de partições estiver corrompida?

É possível que a tabela de partições do disco esteja corrompida, neste caso é bom
que você conheça o filesystem utilizado para tentar identificar os dados incosistentes
e consertá -los. Se a situação estiver muito ruim, o jeito é utiliz ar carving, como
fizemos com dumps de memória.

3.5 Identificação de binári os ELF malici osos

Após recuperar arquivos, deletados ou não, de um filesystem, dump de memória,


captura de tráfego de rede ou qualquer outra fonte de dados, pode ser preciso
analisá-lo. Cada tipo de arqui vo requer uma analise à parte mas em especial os
binários executáveis podem conter código malicioso e nesta seção vamos estudar
como fazer uma análise básica deles.

Supondo que você recuperou um arquivo chamado "suspeito", vamos rodar algumas
ferramentas para tentar documentar seu comportamento, começando pela file, que
tenta identificar o tipo de arquivo em questão:

$ file suspeito
suspeito: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically
linked (uses shared libs), for GNU/Linux 2.6.26,
BuildID[sha1]=x341dd4ba97cb5263efd9d1ede68e4a1f633bb7, not stripped

Página48 TécnicasdeComputaçaoForense
4Linux – www.4linux.com.br 3.5 Identificação de binários ELF maliciosos

Já deu pra saber que o arquivo é um ELF (formato de executáveis usado no Unix/Linux)
e foi compilado para 64-bits, dentre outras informações.

3.5.1 Enumerando funções

O readelf é um software presente no conjunto binutils para leitura de dados em exe-


cutáveis ELF. Ele tem muitas opções, mas podemos começar pela mais básica que
é a de exibir o cabeçalho do arquivo:

$ readelf -h suspeito
ELF Header:
Magic: 7f 45 4 c 46  2 1  1             
Class: ELF64
Data: 2’s complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABIVersion: 
Type: EXEC (Executable file)
Machine: Advanced Micro Devices X86-64
Version: x1
Entry point address: x449
Start of program headers: 64 (bytes into file)
Start of section headers: 7512 (bytes into file)
Flags: x
Size of this header: 64 (bytes)
Size of program headers: 56 (bytes)
Number of program headers: 8
Size of section headers: 64 (bytes)
Number of section headers: 29
Section header string table index: 28

O readelf apresenta uma série de informações úteis, dentre elas o endereço do en-
trypoint, que é onde o código do programa começa a ser executado. Neste nosso

TécnicasdeComputaçaoForense Página49
3.5 Identificação de binários ELF maliciosos 4Linux – www.4linux.com.br

exemplo, é em 0x400490.

Já que estamos lidando com um binário dinamicamente linkado (vide saída do file),
podemos pedir ao readelf que nos mostre a tabela de símbolos dinâmicos utilizados
pelo binário:

$ readelf --dyn-syms suspeito

Symbol table ’.dynsym’ contains 6 entries:


Num: Value Size Type Bind Vis Ndx Name
:   NOTYPE LOCAL DEFAULT UND
1:   FUNC GLOBAL DEFAULT UND write@GLIBC_2.2.5 (2)
2:   FUNC GLOBAL DEFAULT UND system@GLIBC_2.2.5
(2)
3:   FUNC GLOBAL DEFAULT UND
__libc_start_main@GLIBC_2.2.5 (2)
4:   NOTYPE WEAK DEFAULT UND __gmon_start__
5:   FUNC GLOBAL DEFAULT UND creat@GLIBC_2.2.5 (2)

De fato, trata-se de um binário compilado em C, visto que as funções que ele utiliza
estão na glibc (GNU C Library) e ele usa as funções write(), system() e creat(), para
checar o que tais funções fazem, basta checar as páginas de manual nas seções 2
e 3:

$ man -s 2,3 write


$ man -s 2,3 system
$ man -s 2,3 creat

Experimente também usar o comando strings para buscar por texto dentro do
binário suspeito. Isto pode adiantar muito trabalho . ;)

Página50 TécnicasdeComputaçaoForense
4Linux – www.4linux.com.br 3.5 Identificação de binários ELF maliciosos

3.5.2 Disassemblando a main( )

Como trata-se de um binário compilado em C (assim como a maioria dos binários no


mundo UNIX/Linux, seria particularmente interess ante olhar algum código da função
main() e das outras funções que são chamadas por ela. Para isso podemos usar o
objdump:

$ objdump -M intel-mnemonics -d suspeito | grep -C 4 ’call.*main’


449e: 54 push rsp
449f: 49 c7 c 4 6 4  mov r8,x464
44a6: 48 c7 c1 5 6 4  mov rcx,x465
44ad: 48 c7 c7 9c 5 4  mov rdi,x459c
44b4: e8 b7 ff ff ff call 447 <__libc_start_main@plt>
44b9: f4 hlt
44ba: 9 nop
44bb: 9 nop
44bc: 48 83 ec 8 sub rsp,x8

O objdump é capaz de disassemblar as seções de código do ELF muito bem. Usei a


opção -M intel-mnemonics para produzir a saída do disassembly na sintaxe Intel, -d
para disassemblar as seções de código. Já no grep, a opção -C 4 faz serem exibidas
4 linhas antes e 4 depois do casamento da expres são regular.

Eu busquei por ’call.*main’ porque normalmente o endereço da função main() do


programa é passado por último para a __libc_start_main(), que é responsável por
chamá-la, dentre outras coisas.

Ao contrário do que se aprende na faculdade, a main() não é a primeira função


a ser executada num programa feito em C. Muito código rola antes de o código que
o programador efetivamente inseriu possa ser executado.

TécnicasdeComputaçaoForense Página51
3.5 Identificação de binários ELF maliciosos 4Linux – www.4linux.com.br

Percebeu alguns endereços sendo copiado para alguns registrados antes da chamada
a __libc_start_main()? Vamos buscar o último (possi velmente a main do progra-
mador) com o objdump novamente:

$ objdump -M intel-mnemonics -d suspeito | grep -A 4 ’^ 459c’


459c: 55 push rbp
459d: 48 89 e5 mov rbp,rsp

45a: 48 81 ec f 11   sub rsp,x11f


45a7: 48 8d 95 1 ee ff ff lea rdx,[rbp-x11f]
45ae: b8 28 7 4  mov eax,x4728
45b3: b9 3c 2   mov ecx,x23c
45b8: 48 89 d7 mov rdi,rdx
45bb: 48 89 c6 mov rsi,rax
45be: f3 48 a5 rep movs QWORD PTR es:[rdi],QWORD PTR
ds:[rsi]
45c1: 48 89 f mov rax,rsi
45c4: 48 89 fa mov rdx,rdi
45c7: f b6 8 movzx e cx,BYTE PTR [rax]
45ca: 88 a mov BYTE PTR [rdx],cl

45cc: 48 83 c2 1 add rdx,x1


45d: 48 83 c 1 add rax,x1
45d4: be ff 1   mov esi,x1ff
45d9: bf f 6 4  mov edi,x46f
45de: e8 9d fe ff ff call 448 <creat@plt>
45e3: 89 45 fc mov DWORD PTR [rbp-x4],eax
45e6: c7 45 f 8       mov DWORD P TR [rbp-x8],x
45ed: 83 7d fc  cmp DWORD PTR [rbp-x4],x
45f1: 75 7 jne 45fa <creat@plt+x17a>
45f3: b8 1    mov eax,x1
45f8: eb 39 jmp 4633 <creat@plt+x1b3>
45fa: 48 8d 8d 1 ee ff ff lea rcx,[rbp-x11f]

461: 8b 45 fc mov eax,DWORD PTR [rbp-x4]


464: ba e1 11   mov edx,x11e1
469: 48 89 ce mov rsi,rcx
46c: 89 c7 mov edi,eax

Página52 TécnicasdeComputaçaoForense
4Linux – www.4linux.com.br 3.5 Identificação de binários ELF maliciosos

46e: e8 3d fe ff ff call 445 <write@plt>


4613: 89 45 f8 mov DWORD PTR [rbp-x8],eax
4616: 81 7d f 8 e1 1 1   cmp DWORD PTR [rbp-x8],x11e1
461d: 75 f jne 462e <creat@plt+x1ae>
461f: bf f8 6 4  mov edi,x46f8
4624: b8     mov eax,x
4629: e8 32 fe ff ff call 446 <system@plt>
462e: b8     mov eax,x
4633: c9 leave
4634: c3 ret
4635: 9 nop
4636: 9 nop

Estudar Assembly foge ao nosso foco, mas dá pra ter uma ideia do que o programa
faz. Ou não? Se ficar difícil, pode-se partir para uma análise dinâmica, como vere-
mos a seguir.

3.5.3 Rastreando com strace

O strace é um programa bastante poderoso , que faz uso da ptrace() - uma chamada
de sistema (syscall) para rastrear ações de um determinado processo, para logar
todas as chamadas de sistem a que um processo faz. Note que o processo faz o
que o ele quer fazer, portanto se tratando de um arquivo suspeito, este deve ser
executado num ambiente controlado (máquina virtual ou similares).

Suas principais opções são:

-f rastreia também processos filho

-e expr configura um filtros para capt ura

-o arquivo grava a captura num arquivo

TécnicasdeComputaçaoForense Página53
3.5 Identificação de binários ELF maliciosos 4Linux – www.4linux.com.br

Na seção anterior perguntei como poderíamos ter cer teza de que as ferramentas do
TSK abrem uma imagem em modo somente leitura. Uma das possibilidades é ras-
treando chamadas à syscall open (que abre arquivos e dispositivos) com o strace:

$ strace -o mmls.log -e open mmls sda.img


$ grep sda mmls.log
open("sda.img", O_RDONLY) =3
open("sda.img", O_RDONLY) =3
open("sda.img", O_RDONLY) =3
open("sda.img", O_RDONLY) =3

A syscall open foi chamada com a flag O_RDONLY, que garante que o arquivo será
aberto com permissão somente para leitura. ;)

Agora vamos olhar o suspeito:

$ strace ./suspeito

creat("/tmp/ls", 777) =3
write(3, "\177ELF\2\1\1\\\\\\\\\\2\>\\1\\\l\4@\\\\\"...,
4577) = 4577
clone(child_stack=, flags=CLONE_PARENT_SETTID|SIGCHLD,
parent_tidptr=x7ffff575568) = 18172
wait4(18172, [{WIFEXITED(s) && WEXITSTATUS(s) == }], , NULL) = 18172
--- SIGCHLD (Child exited) @  () ---
exit_group() =?

Deixarei como exercício para você dizer o que este suspeito faz. Como dica, use a
opção -f do strace para capturar as chamadas também do processo filho criado pela
chamada à syscall clone e o man do próprio Linux para consulta.
Para finalizar, segue uma lista de características geralmente encontradas em binários
suspeitos (mas não é regra):

Página54 TécnicasdeComputaçaoForense
4Linux – www.4linux.com.br 3.5 Identificação de binários ELF maliciosos

• Nomes longos ou diferentes do estilo Unix

• Tamanho grande (> 1 MB)

• Sem símbolos

• Sem strings legíveis dentro

• Fora dos diretórios bin ou sbin

E vale o bom senso. ;)

TécnicasdeComputaçaoForense Página55
Capítulo 4

Investigação em ambientes Windows

Até o momento só utilizamos softwa res livres em nossas análises e vamos continuar
dando preferências aos softwares de código aberto, por motivos óbvios.

A ideia aqui é analisar no GNU/Linux dumps provenientes de sistemas Windows, mas


para a captura, pelo menos de memória, vamos precisar rodar ferramentas no Win-
dows e desta vez não vamos optar por ferramentas livres devido à compatibilidade.
Ao invés disso, trabalharemos com ferramentas freeware.

Este capítulo será menor, visto que várias técnicas de análise já foram apresentadas
no capítulo anterior e utilizaremos das mesmas técnicas, com algumas peculiari-
dades, para análise de dumps Windows, portanto daremos maior foco nas difer-
enças.

4.1 Características de segurança dos Windo ws atuais

As versões recentes do Windows, como 8 e 2012 (server) possuem algumas difer-


enças no layout de memória e sistema de arquivos, a começar pelo novo filesystem
chamdo ReFS (Resilient File System) que não é de todo compatível com o NTFS,
apesar de ser similar na camada mais alta de sua imeplementação.

57
4.2 Aquisição e análise de RAM com win32dd 4Linux – www.4linux.com.br

O NTFS ainda é muito utilizado, portanto daremos um foco especial nele, mas tam-
bém falaremos do novo ReFS.

Os softwares de aquisição de memória que não foram atualizados também encon-


tram algumas dificuldades nas versões mais recentes do Windows, visto que difer-
entes métodos em kernel-land podem ser utilizados para aquisição de memória.
Falaremos mais adiante.

4.2 Aquisição e análi se de RAM com win3 2dd

Há poucas alternativas gratuitas para aquisição de memória às suítes pagas como


EnCase, WindowsSCOPE e Kntdd. Algumas desatualizadas como o mdd não fun-
cionam mais tão bem. Por sorte temos a suíte MoonSols, que contempla o win32dd.exe
e o win64dd.exe, para aquisição em sistemas Windows e 32 e 64-bits, respectiva-
mente. Apesar de também ser proprietária e paga, existe uma versão denominada
"Community Edition", que ainda é distribuida gratuitamente, mas sob uma licença
proprietária, infelizmente.

O win32dd possui muitas opções interessantes, dentre elas:

/f file configura o arquivo de saída do dump

/s valor já calcula um hash do dump gerado (2 par a MD5)

/l envia o dump para um servidor de rede

Para capturar um dump de toda a memória mapeada, basta executar um cmd.exe


com privilégios administrativos e comandar:

C:\> win64dd.exe /f ramdump


win64dd - 1.3.1.21417 - (Community Edition)
Kernel land physical memory acquisition

Página58 TécnicasdeComputaçaoForense
4Linux – www.4linux.com.br 4.2 Aquisição e análise de RAM com win32dd

Copyright (C) 27 - 21, Matthieu Suiche <http://www.msuiche.net>


Copyright (C) 29 - 21, MoonSols <http://www.moonsols.com>

Name Value
---- -----
File type: Raw memory dump file
Acquisition method: PFN Mapping
Content: Memory manager physical memory block

Destination path: ramdump

O.S. Version: Microsoft Windows Server 28 Server Standard wi


thout Hyper-V, 64-bit Service Pack 2 (build 62)
Computer name: SRV3

Physical memory in use: 33%


Physical memory size: 41844 Kb ( 486 Mb)
Physical memory available: 2764252 Kb ( 2699 Mb)

Paging file size: 8624352 Kb ( 8422 Mb)


Paging file available: 7168152 Kb ( 7 Mb)

Virtual memory size: 8589934464 Kb (838867 Mb)


Virtual memory available: 8589892868 Kb (83 88567 Mb)

Extented memory available:  Kb (  Mb)

Physical page size: 496 bytes


Minimum physical address: x1C
Maximum physical address: x13FFFF

Address space size: 53687912 bytes (524288 Kb)

--> Are you sure you want to continue? [y/n] y

TécnicasdeComputaçaoForense Página59
4.2 Aquisição e análise de RAM com win32dd 4Linux – www.4linux.com.br

Acquisition started at: [25/5/212 (DD/MM/YYYY) 6:9:48 (UTC)]

Processing....Done.

Acquisition finis hed at: [212-5-25 (YYYY- MM-DD) 6:1:4 (UTC)]


Time elapsed: :52 minutes:seconds (52 secs)

Created file size: 53687912 bytes ( 512 Mb)

NtStatus (troubleshooting): x


Total of written pages: 146332
Total of inacessible pages: 
Total of accessible pages: 146332

Physical memory in use: 33%


Physical memory size: 41844 Kb ( 486 Mb)
Physical memory available: 276972 Kb ( 274 Mb)

Paging file size: 8624352 Kb ( 8422 Mb)


Paging file available: 7175212 Kb ( 77 Mb)

Virtual memory size: 8589934464 Kb (838867 Mb)


Virtual memory available: 8589892868 Kb (83 88567 Mb)

Extented memory available:  Kb (  Mb)

Physical page size: 496 bytes


Minimum physical address: x1C
Maximum physical address: x13FFFF

Address space size: 53687912 bytes (524288 Kb)

O arquivo ramdump será criado no diretório atual com o conteúdo da memória RAM.

Página60 TécnicasdeComputaçaoForense
4Linux – www.4linux.com.br 4.3 Aquisição de dados de filesystems NTFS e ReFS

Existe também uma ferrament a chamda DumpIt, do mesmo autor do win32dd


e win64dd, que funciona para ambas as arquiteturas e pode ser usada para gerar
um dump rápido, apenas com um duplo-clique, já que não aceita nenhuma opção ou
argumento. Normalmente é suficiente para gerar um dump padrão e completo, como
se fosse o dd, no Linux.

4.3 Aquisição de dados de filesystems NTFS e ReF S

O NTFS se estabeleceu como filesystem padrão nas versões do Windows para servi-
dores desde o Windows NT e se mantém até o Windows 2008. Já nas versões para
estação de trabalho, sua popularização veio com o Windows XP e desde então vem
sido o padrão de instalação até o Windows 7. A última ver são da especificação é
a 3.1 (não confundir com a versão do driver, que é a 6.1 no Windows 7 e 2008 R2)
e basearemos nossos estud os nesta versã o. Claro que nosso estudo será válid o
também para entedimento de versões anteriore s à 3.1 ou mesmo posteriores, ou até
outros filesystems como o ReFS (Windows 8) que veremos mais adiante.

No Windows é possível saber qual a versão de uma partição NTFS com o seguinte
comando:

> fsutil fsinfo ntfsinfo c:

Você deve substituir c: pela letra associada à partição desejada.

4.3.1 Estrutura do NTFS 3.1

Após localizar a partição NTFS (0x7) depois de ler a tabela de partições no MBR,
a primeira estrutura é o setor de boot da partição , de 512 by tes. A existência

TécnicasdeComputaçaoForense Página61
4.4 Análise de dumps com Volatility 4Linux – www.4linux.com.br

deste setor é uma característica comum nos filesystems populares e nele há várias
informações importantes para forense, dentre elas um trecho conhecido como BPB
(Bios Parameter Block), que começa no byte 0xb do setor de boot da partição e vai
até o byte 0x54, resultan do em 0x49 bytes de tamanho.

O BPB é uma estrutura com vários campos, sendo o mais importante deles o campo
de 8 bytes que começa no byte 0x30 chamado LogicalClusterMFT. Este cara contém
o número do cluster onde está armazenada a MFT (Master File Table), a tabela que
referencia todos os arquivos presentes na partição. Em uma analogia simples, esta
tabela é para o filesystem o que um índice é para um livro.

Uma maneira fácil de identificar uma entrada na MFT é a string FILE, no início de
cada entrada de 1024 bytes (2 setores). Cada entrada representa um arquivo, mas
existem arquivos especiais chamados metafiles que contém informações sobre a
partição. Existe até mesmo uma entrada que representa a própria MFT.

Extraindo arquivos de partições NTFS

O Sleuth Kit possui suporte à partições NTFS, logo, é possível utilizá-lo sem prob-
lemas. As técnicas de carving apresentada s e ferramentas como foremos t e scalpel
também possuem suporte e podem ser utilizadas quando a partição estiver corromp-
ida e não puder ser montada.

4.4 Análise de dumps com Volatility

Para dumps de memória, a ferramenta livre mais utilizada é o Volatility, um framework


em Python para análise de dumps de memória com suporte a várias versões do
Windows. É possível realizar de forma rápida taref as que demorariam horas, por
exemplo, listar todos os processos abertos no instante do dump de memória:

$ volatility pslist -f Bob.vmem

Página62 TécnicasdeComputaçaoForense
4Linux – www.4linux.com.br 4.4 Análise de dumps com Volatility

Volatile Systems Volatility Framework 2.


Offset(V) Name PID PPID Thds Hnds Time
---------- -------------------- ------ ------ ------ ------ -------------------
x823c883 System 4  58 573 197-1-1 ::
x81f4228 smss.exe 548 4 3 21 21-2-26 3:34:2
x822eeda csrss.exe 612 548 12 423 21-2-26 3:34:4
x81e5b2e8 winlogon.exe 644 548 21 521 21-2-26 3:34:4
x82256da services.exe 688 644 16 293 21-2-26 3:34:5
x82129da lsass.exe 7 644 22 416 21-2-26 3:34:6
x81d3f2 vmacthlp.exe 852 688 1 35 21-2-26 3:34:6
x8226687 svchost.exe 88 688 28 34 21-2-26 3:34:7
x822e1da svchost.exe 948 688 1 276 21-2-26 3:34:7
x822ea2 svchost.exe 14 688 83 1515 21-2-26 3:34:7
x81dea2 svchost.exe 11 688 6 96 21-2-26 3:34:7
x81de55f svchost.exe 1244 688 19 239 21-2-26 3:34:8
x81dde568 spoolsv.exe 146 688 11 129 21-2-26 3:34:1
x82118b vmtoolsd.exe 1628 688 5 22 21-2-26 3:34:25
x81ddd8d VMUpgradeHelper 1836 688 4 18 21-2-26 3:34:34
x82d6b88 alg.exe 224 688 7 13 21-2-26 3:34:35
x81cdd79 explorer.exe 1756 166 14 345 21-2-26 3:34:38
x81ca96f VMwareTray.exe 118 1756 1 59 21-2-26 3:34:39
x82cd5c8 VMwareUser.exe 1116 1756 4 179 21-2-26 3:34:39
x81cee5f8 wscntfy.exe 1132 14 1 38 21-2-26 3:34:4
x8233362 msiexec.exe 244 688 5 181 21-2-26 3:46:6
x81ce1af8 msiexec.exe 452 244  ------ 21-2-26 3:46:7
x81c8c78 wuauclt.exe 44 14 8 188 21-2-27 19:48:49
x8221a2 wuauclt.exe 232 14 4 136 21-2-27 19:49:11
x82682 firefox.exe 888 1756 9 172 21-2-27 2:11:53
x82618c8 AcroRd32.exe 1752 888 8 184 21-2-27 2:12:23
x822964 svchost.exe 1384 688 9 11 21-2-27 2:12:36

Simples assim. O comando pslist faz o trabalho e a opção -f especifica o arquivo de


imagem a se trabalhar.

TécnicasdeComputaçaoForense Página63
4.4 Análise de dumps com Volatility 4Linux – www.4linux.com.br

Há comandos para listar conexões abertas, handles (identificadores de cada objeto


no Windows), extrair um processo (executável) inteiro do dump de memóra, extrair o
mapa de memória inteiro de um processo e muito mais. Você pode ver uma lista de
opções com a opção -h:

Supported Plugin Commands:

bioskbd Reads the keyboard buffer from Real Mode memory


connections Print list of open connections [Windows XP Only]
connscan Scan Physical memory for _TCPT_OBJECT objects (tcp connections)
crashinfo Dump crash-dump information
dlldump Dump DLLs from a process address space
dlllist Print list of loaded dlls for each process
driverscan Scan for driver objects _DRIVER_OBJECT
filescan Scan Physical memory for _FILE_OBJECT pool allocations
getsids Print the SIDs owning each process
handles Print list of open handles for each process
hashdump Dumps passwords hashes (LM/NTLM) from memory
hibinfo Dump hibernation file information

hivedump Prints out a hive


hivelist Print list of registry hives.
hivescan Scan Physical memory for _CMHIVE objects (registry hives)
imagecopy Copies a physical address space out as a raw DD image
imageinfo Identify information for the image
inspectcache Inspect the contents of a cache
kdbgscan Search for and dump potential KDBG values
kpcrscan Search for and dump potential KPCR values
lsadump Dump (decrypted) LSA secrets from the registry
memdump Dump the addressable memory for a process
memmap Print the memory map
moddump Dump a kernel driver to an executable file sample

modscan Scan Physical memory for _LDR_DATA_TABLE_ENTRY objects


modules Print list of loaded modules
mutantscan Scan for mutant objects _KMUTANT
netscan Scan a Vista, 28 or Windows 7 image for connections and sockets

Página64 TécnicasdeComputaçaoForense
4Linux – www.4linux.com.br 4.5 Identificação e análise de binários PE maliciosos

patcher Patches memory based on page scans


printkey Print a registry key, and its subkeys and values
procexedump Dump a p rocess to an e xecutable file sample
procmemdump Dump a p rocess to an e xecutable memory sample
pslist print all running processes by following the EPROCESS lists
psscan Scan Physical memory for _EPROCESS pool allocations
pstree Print process list as a tree
sockets Print list of open sockets
sockscan Scan Physical memory for _ADDRESS_OBJECT objects (tcp sockets)
ssdt Display SSDT entries
strings Match physical offsets to virtual addresses (may take a while, VERY ver
testsuite Run unit test suit using the Cache
thrdscan Scan physical memory for _ETHREAD objects
userassist Print userassist registry keys and information
vaddump Dumps out the vad sections to a file
vadinfo Dump the VAD info
vadtree Walk the VAD tree and display in tree format
vadwalk Walk the VAD tree
volshell Shell in the memory image

O Volatility é, de longe, a ferramenta livre mais completa para análise de dumps de


memória de sistemas Windows. Existe também um esforço, no repositório oficial do
projeto, com uma versão para trabalhar com dumps de Linux, mas está em desen-
volvimento.

4.5 Identificação e análise de binári os PE malicioso s

Existem milhares de pragas construídas para danificar sistemas e boa parte delas
são executáveis PE, que tem como sistema alvo os sistemas Windows . O tipo PE
(Portable Executable) é facilmente reconhecido por conta de uma herança do formato
MZ do MS-DOS que recebeu este nome de um dos desenvolvedores do MS-DOS
chamado Mark Zbikowski. Esta assinatura "MZ"está logo no início do arquivo e faz

TécnicasdeComputaçaoForense Página65
4.5 Identificação e análise de binários PE maliciosos 4Linux – www.4linux.com.br

parte do cabeçalho do DOS. Em hexadecimal, M e Z são os bytes 0x4d e 0x5a,


respectivamente. Qualquer dúvida, consulte a tabela ASCII.

Sabendo disso, é possível iniciar um processo de identificaçã o de binários PE (mali-


ciosos ou não) olhando os primeiros bytes do arquivo:

$ hd -n 64 putty.exe
 4d 5a 9  3    4     ff ff   |MZ..............|
1 b8        4         |........@.......|
2                  |................|
3               1   |................|
4

No exemplo acima pedi que o hexdump mostrasse os primeiros 64 bytes do arquivo


(que não por acaso é o tamanho do cabeçalho do DOS, o primeiro dos executáveis
PE). Perceba os bytes 0x4d e 0x5a logo no início e sua representação em ASCII à
direita.

O file também pode ajudar:

$ file putty. exe


/home/nandu/winapp/putty.exe: PE32 executable (GUI) Intel 8386, for MS Windows

4.5.1 Obtendo os cabeçalhos do PE

Para ver mais informações sobre o PE, pode-se utilizar o pev, um toolkit multiplataforma
que fornece uma série de binários para trabalha r com arquivos PE:

readpe exibecabeçalhos e seções

pesec busca features de segurança

Página66 TécnicasdeComputaçaoForense
4Linux – www.4linux.com.br 4.5 Identificação e análise de binários PE maliciosos

pedis disassembla seções inteiras ou endereços específicos

pescan busca itens suspeitos

pepack detecta de packers por assinatura

pehash calcula hashes

pestr busca strings ASCII e Unicode

rva2ofs converte RVA em offset de arquivo

ofs2rva converte offset em RVA

O readpe pode começar o processo de identificação exibindo os cabeçalhos e seções.


Vou mostrar duas saídas do readpe. A primeira de um executável putty.exe inofensivo
e a segunda, de um vírus. A opção -S/–sections do readpe exibe as seções de uma
PE:

$ readpe -S putty.exe

Sections
Name: .text
Virtual Address: x1
Physical Address: x53371
Size: x54 (34464 bytes)
Pointer To Data: x1
Relocations: 
Characteristics: x62
contains executable code

is executable
is readable
Name: .rdata
Virtual Address: x55

TécnicasdeComputaçaoForense Página67
4.5 Identificação e análise de binários PE maliciosos 4Linux – www.4linux.com.br

Physical Address: x1b23e


Size: x1c (114688 bytes)
Pointer To Data: x55
Relocations: 
Characteristics: x44
contains initialized data
is readable
Name: .data
Virtual Address: x71
Physical Address: x7e4
Size: x1 (496 bytes)
Pointer To Data: x71
Relocations: 
Characteristics: xc4
contains initialized data
is readable
is writable
Name: .rsrc
Virtual Address: x79
Physical Address: x3b9
Size: x4 (16384 bytes)
Pointer To Data: x72
Relocations: 
Characteristics: x44
contains initialized data
is readable

As seções .text, .rdata, .data e .rsrc são todas previstas na documentação do PE e


cada uma tem sua função. Não é obrigatório que tenham esse s nomes mas normal-
mente é assim em executáveis comuns.

E agora um vírus comprimido com um compressor de executáveis chamado MEW:

$ readpe -S mewpacker.exe

Página68 TécnicasdeComputaçaoForense
4Linux – www.4linux.com.br 4.5 Identificação e análise de binários PE maliciosos

Sections
Name: SBL
Virtual Address: x1
Physical Address: x23
Size: (bytes)
Pointer To Data: 
Relocations: 
Characteristics: xce
contains executable code
contains initialized data
contains uninitialize d data
is readable
is writable
Name: ?ug?
Virtual Address: x24
Physical Address: x19
Size: x9fa9 (4873 bytes)
Pointer To Data: x2
Relocations: 
Characteristics: xce
contains executable code
contains initialized data
contains uninitialize d data
is readable
is writable

Perceba uma seção chamada SBL (sem ponto na frente) de tamanho zerado e uma
outra com um nome bem estranho. Coisa boa não é. Outro recurso é buscar funções
de TLS callbacks (comumente exploradas por programadores de malware) e packers
em si:

$ pescan mewpacker.exe
entrypoint: normal

TécnicasdeComputaçaoForense Página69
4.5 Identificação e análise de binários PE maliciosos 4Linux – www.4linux.com.br

DOS stub: suspicious


TLS directory: not found
Sections: 2 - suspicious

$ pepack mewpacker.exe
packer: Mew 11 SE v1.2 (Eng) -> Northfox

No exemplo acima não havia funções TLS callbacks, mas o pescan acusou que o
DOS stub do PE é suspeito (foi modifi cado) e as seções também. Adicionalmente, o
pepack detectou o packer MEW. Vale a atenção!

Packers normalmente comprimem executáveis e acabam por embaralhá-los


de forma que um analisador de PE, um debugger ou outro software do gênero pode
não conseguir fornecer informações corretas sobre o executável. Apesar de existirem
softwares idôneos que são distribuidos packeados (para evitar engenharia reversa ),
é muito comum encontrarmos malwares com este recurso . Existem vários pack ers
gratuitos, proprietários e até livres como o o UPX. Outros exemplos são Themida,

Armadillo, MEW, y0da’s Cryptor e MPRESS.

4.5.2 Disassemblando o entrypoint

O entrypoint (EP) de um PE é onde seu código começa a ser executado, assim


como nos binários ELF. O EP fica no cabeçalho Optional, então podemos exibi-lo
com o readpe e fazer um filtro para achar mais rápido o valor que queremos:

$ readpe --header option al putty_upx.exe | grep point


Entrypoint: x7f2c

E a partir do valor do EP, você pode usar o pedis para obter o disassembly:

Página70 TécnicasdeComputaçaoForense
4Linux – www.4linux.com.br 4.5 Identificação e análise de binários PE maliciosos

$ pedis --rva x7f2c putty_upx.exe


1939c86e: 6 pushad
1939c86f: be  4 44  mov esi, x444
1939c874: 8d be  d fb ff lea edi, [esi+xfff
1939c87a: 57 push edi
1939c87b: 83 cd ff d fb ff or ebp, xff
1939c87e: eb 1 jmp x1931d5d
1939c88: 9 nop
1939c881: 9 nop
1939c882: 9 nop
1939c883: 9 nop
1939c884: 9 nop
1939c885: 9 nop
1939c886: 8a 6 mov al, [esi]
1939c888: 46 inc esi
1939c889: 88 7 mov [edi], al
1939c88b: 47 inc edi
1939c88c: 1 db add ebx, ebx
[cortado...]

Na versão mais recente do kit pev, é possível disassemblar o entrypoint diretamente,


sem conhecê-lo:

$ pedis --entrypoint putty_upx.exe

4.5.3 Análise comportamental com Process Explorer

Assim como usamos o strace para verificar as syscalls utilizadas por um ELF, pode-

mos
que ousar
PE ofaz.
Process Explorer
O software para obter
é gráfico as chamadas
e ao executá-lo, às funções
podemos criarda API pelo
filtros do Windows
nome
do processo ou PID para que ele mostre açõe s apenas de quem queremos. Esta
análise deve ser feita em um ambiente controlado, sempre.

TécnicasdeComputaçaoForense Página71
Capítulo 5

Análise de outros tipos de arquivo

Além de executáveis em si, é possível ser infectado com outros tipos de arquivos
ou pode ser preciso entender algum formato específico para concluir o trabalho da
perícia forense. Neste capítulo vamos analisar arquiv os PDF e imagens JPG.

5.1 Documentos PDF com pdfid e pdf- parser

Arquivos PDF (Portable Document Format) são verdadieros containers que podem
abrigar desde simples textos e imagens a poderosos programas em Flash ou JavaScript.
Dentro deles há tanto texto quando dados binários.

Basicamente um PDF é uma árvore de objetos. Ao olhar um PDF com um editor de


textos, você verá definições de objetos como esta:

$ head -2 pagina.pdf


%PDF-1.4

%äüöß
2  obj
<</Length 3  R/Filter/FlateDecode>>
stream

73
5.1 Documentos PDF com pdfid e pdf-parser 4Linux – www.4linux.com.br

[bytes]
endstream
endobj

3  obj
16
endobj

Os objetos podem ser de vários tipos e existem alguns nomes pré-definidos como
/JavaScript, /JS, /OpenAction, /RichMedia e /Launch. Estes particularmente são pre-
ocupantes pois podem conter código executável que o leitor de PDF tentará executar
ao ser aber to.

Objetos também podem referenciar outros objetos, neste caso a palavra "obj"é sub-
stituída pela letra maiúscula R. Com isso já dá para traçar uma linha investigativa
no sentido de observar os objetos de um documento PDF, principalmente se tiverem
esses nomes sugestivos apresentados.

Para facilitar o trabalho, a ferramenta pdfid já exibe os objetos interessantes:

$ ./pdfid.py teste.pdf
PDFiD ..11 teste.pdf
PDF Header: %PDF-1.4
obj 6
endobj 6
stream 1
endstream 1
xref 2
trailer 2
startxref 1

/Page 1
/Encrypt 
/ObjStm 
/JS 1

Página74 TécnicasdeComputaçaoForense
4Linux – www.4linux.com.br 5.1 Documentos PDF com pdfid e pdf-parser

/JavaScript 1
/AA 1
/OpenAction 
/AcroForm 
/JBIG2Decode 
/RichMedia 
/Launch 
/Colors > 2^24 

No exemplo acima, percebemos que há uma entrada de objeto nomeado /JavaScript.


Com o pdf-parser, podemos buscar tal objeto:

$ ./pdf-parser.py -s ’/JavaScript’ test.pdf


obj 11 
Type:
Referencing: 54  R
[(1, ’\r\n’), (2, ’<<’), (2, ’/S’), (2, ’/JavaScript’), (2, ’/JS’), (1, ’ ’),
(3, ’154’), (1, ’ ’), (3, ’’), (1, ’ ’), (3, ’R’), (2, ’>>’), (1, ’\r\n’)]

<<
/S /JavaScript
/JS 154  R
>>

A opção -s do define um texto a ser buscado e faz com que, se encontrado o


texto, o objeto ao qual o texto pert ence seja exibido. Nest e caso, é o objeto
11, que está incluindo (referenciando) o objeto 154. Vamos usar então a opção
-o do pdf-parse para exibir este objeto:

\begin{verbatim}

$ ./pdf-parser.py -o 54 test.pdf
obj 154 
Type:
Referencing:

TécnicasdeComputaçaoForense Página75
5.1 Documentos PDF com pdfid e pdf-parser 4Linux – www.4linux.com.br

Contains stream
[(1, ’\r\n’), (2, ’<<’), (2, ’/Length’), (1, ’ ’), (3, ’’), (2, ’/Filter’),
(1, ’ ’), (2, ’[’), (2, ’/F#6c#61#74e#44e#63#6fde’), (2,
’/#41#53#43II#38#35#44#65#63#6fd#65’), (2, ’]’), (2, ’>>’), (1, ’\r\n’)]

<<
/Length 
/Filter [
/FlateDecode /ASCII85Decode]
>>

O objeto con tém um stream (flu xo) de dados , ou seja, dados biná rios. Os dados
precisam passar por um filtro para serem revelados, pois ficam encodados no PDF.
O pdf-parser é capaz de filtrar esses dados com a opção -f:

$ python ./pdf-parser.py -f -o 54 test.pdf > stream.txt

O arquivo stream.txt conterá todo o fluxo de dados após passar pelos filtros e será
possível ver o código JavaScript nele.

Códigos maliciosos normalmente estão escondidos, encodados etc. O ata-


cante tenta ocultar ao máximo aos olhos do investigador um código malicioso, para
não ter sua praga inutilizada, incluind o futuros ataques em alguns casos. Por isso
é importante que você se acostume com certas técnicas como strings encodadas
com base64, uuencode, XOReadas com algum valor ou interpretadas de maneiras
diferentes. Se você se deparasse com o texto 4̈665726E616E646F ,̈ seria capaz de
descobrir o que significa? E se fosse R̈G8gbm90IGJlIGEgbGFtbWVyIQo=?¨

Página76 TécnicasdeComputaçaoForense
4Linux – www.4linux.com.br 5.2 Imagens com jhead

5.2 Imagens com jh ead

Imagens JPG e PNG podem conter informações valiosas numa estrutura conhecida
como EXIF (Exchangeab le Image File Format). Nem sempre essas informações são
visíveis ao SO. Avalie as capturas de tela abaixo. A primeira foi tirada no Gnome e a
segunda no Windows XP.

Percebemos que alguns campos existem numa captura e na outra não, mas estamos
visualizando os dados da mesma imagem.

O jhead é um software de linha de comando capaz de extrair todos os dados EXIF


de uma imagem:

$ jhead tracking.jpg
File name : tracking.jpg
File size : 31485 bytes
File date : 211:3:3 2:13:53
Camera make : SAMSUNG
Camera model : GT-I55B
Date/Time : 21-11-18 :46:23
Resolution : 16 x 12
Focal length : 2.7mm
Exposure tim e: .1 25 s (1/8)
Aperture : f/2.7
ISO equiv. : 2
Whitebalance : Auto
Metering Mode: center weight
Exposure : aperture priority (semi-auto)
GPS Latitude : ? 23d 19m 44.52s
GPS Longitude: ? 48d 29m 19.548s

Note que o jhead exibe até mesmo coordenadas GPS presentes na imagem, en-
quanto nem o Gnome nem o Windows XP o fazem. Essas informações podem ser
extremamente úteis numa perícia forense.

TécnicasdeComputaçaoForense Página77
5.3 Esteganografia 4Linux–www.4linux.com.br

5.3 Esteganografia

Esteganografia é a arte de esconder uma mensagem em algum objeto, ou arquivo,


em nosso caso. Existem várias técnicas para esteganografar uma mensagem, mas
vamos observar aqui apenas que elas existem e podem ser feitas em imagens com
softwares como steghide ou outguess:

$ echo mentebinaria > msg


$ outguess -d msg chess.jpg out.jpg
chess.jpg out.jpg
Reading chess.jpg....
JPEG compression quality set to 75
Extracting usable bits: 139977 bits
Correctable message size: -35176 bits, 1317841289332224.%
Encoded ’o’: 14 bits, 13 bytes
Finding best embedding...
: 6(44.4%)[57.7%], bias 29(.48), saved: -1, total: .4%
3: 62(45.6%)[59.6%], bias 26(.42), saved: -1, total: .4%
13: 62(45.6%)[59.6%], bias 2(.32), saved: -1, total: .4%
36: 59(44.%)[56.7%], bias 17(.29), saved: , total: .4%
117: 63(46.3%)[6.6%], bias 9(.14), saved: -1, total: .5%
117, 72: Embedding data: 14 in 139977
Bits embedded: 136, changed: 63(46.3%)[6.6%], bias: 9, tot: 139913, skip:
139777
Foiling statistics: corrections: 48, failed: , offset: 53.5 +- 58.2916
Total bits changed: 72 (change 63 + bias 9)
Storing bitmap into data...
Writing out.jpg....

No exemplo acima o conteúdo do arquivo msg.txt foi inserido na imagem chess.jpg e


a nova imagem out.jpg foi criada. As imagens não apresentam diferença visual, mas
tanto o tamanho quanto o hash do arquivo são diferem entre si:

Página78 TécnicasdeComputaçaoForense
4Linux–www.4linux.com.br 5.3 Esteganografia

$ wc -c *.jpg
145338 chess.jpg
16151 out.jpg

$ md5sum *.jpg
4c59e2956ba43e342a18ab4e855cbb4 chess.jpg
9e8dc2125a2d8adbab424167f62947fa out.jpg

Também é possível esconder mensagens em arquivos de áudio com ferramentas


como o mp3steg. Na realidade, basta estud ar o formato do arquivo e descobrir onde
você pode colocar sua mensagem.

TécnicasdeComputaçaoForense Página79
Capítulo 6

Análise tráfego TCP/IP

É importante para o pesquisador saber analisar um tráfego de rede (captura de pa-


cotes), principalm ente porque é um meio comum de vazamento de dados, infecções
por pragas, contém vestígios de ataques, enfim, as possibilidades são muitas.

6.1 Sniffers

Normalmente o driver de uma placa de rede descarta os pacotes que não são des-
tinados ao endereço dela. Este é o funcionamento normal, no entanto, é possível
alterar este comportamento utilizando softwares conhecidos como sniffers de rede.
Além de não descartar nenhum pacote, os sniffers capturam (salvam) os bytes dos
pacotes recebidos em disco. O formato mais conhecido para armazenar pacotes é o
PCAP, implementado pela libpcap e WinPcap.

Exemplos de sniffers populares são o tcpdump e o Wireshark, sendo que este último

é também um poderoso analisador de tráfego.


O comando abaixo fará uma captura na interface wlan0 por todo pacote que seja
destinado ou tenha como srcem a porta 80:

81
6.1 Sniffers 4Linux–www.4linux.com.br

# tcpdump -i wlan -w captura.pcap ’port 8’

O último parâmetro é a expressão, uma ou mais condições que devem ser satisfeitas
para o tcpdump salvar o pacote no arquivo info rmado pela opção -w. Caso nenhuma
expressão seja informada, todos os pacotes serão salvos.

Uma expressão para capturar todos os pacotes ICMP com tamanho maior que zero
seria:

# tcpdump -i wlan -w captura.pcap ’icmp and len > ’

Para visualizar a documentação completa da criação de filtros (expressões), veja o


manual da libpcap:

$ man 7 pcap-filter

6.1.1 Entendendo o modelo OSI com o Wiresha rk

O modelo OSI (Open Systems Interconnection) é um modelo teórico de cadamas


para comunicação entre dispositivos de rede. Ele especifica as famosas 7 camadas,
que mostraremos com uma descrição resumida abaixo:

1 - Física a camada de mais baixo nível, que trata dos meios físicos de conexã o.

2 - Enlace correção de erros, endereçamento físico/MAC, PPP.

3 - Rede endereçamento IP, roteamento.

4 - Transporte TCP/UDP.

5 - Sessão estabelecimento de sessões.

Página82 TécnicasdeComputaçaoForense
4Linux–www.4linux.com.br 6.1 Sniffers

6 - Apresentação tradução de dados.

7 - Aplicação protocolos de alto nível (HTTP, DNS, FTP etc).

Não vamos estudar teoria de redes aqui e por isso vamos entender como o Wireshark
nos apresenta informações sobre um pacote:

Ao expandir o primeiro item, temos informações básicas sobre a transmissão do


pacote como tamanho, hora em que foi transmitido e o número (frame) em relação
ao início da captur a. Podemos fazer uma analogi a com a cada 1 do modelo OSI
(física) aqui, mas não bate 100%.

Já o item seguinte, comparamos à camada 2 (enlace), que é onde estão os en-


dereços MAC de destino e srcem.

No terceiro item tem todas as informações sobre o protocolo IP (analóga à camada


3 - rede). Nele temos endereços IP de srcem e destino, TTL do pacote, checksum,
dentre outros.

O próximo item pode ser comparado à camada 4 (transporte), pois possui infor-
mações sobre o protocolo de transporte utilizado (TCP/UDP), portas utilizadas, flags
TCP.

E por último a interpretação do protocolo HTTP (neste caso, que é um pacote HTTP
mesmo), que pode ser comparado à soma das camadas 5, 6 e 7. É similar ao Modelo
TCP/IP de 4 camadas.

TécnicasdeComputaçaoForense Página83
Capítulo 7

Anti-forense

É previsíveil que criadores de pragas, atacantes e criminosos virtuais em geral não


queiram ter suas armas descobertas, por isso utilizam alguns artefatos para evitar,
comprometer ou dificultar a perícia, por exemplo:

• Um programa que se exclui após uma reini cialização da máquina

• Binários alterados para enganar o perito

• Formatação de mídias

• Esteganografia

• Criptografia

A lista acima contém somente alguns exemp los. Tais ações dependem da criativi-
dade do atacante e dos recursos disponíveis.

A
emtécnica de meio
qualquer evitar de
taisipedir
técnicas porações
essas vezesdeé atacantes,
chamada de poranti-anti-f
exemplo:orense e consiste

• Usar seus próprios binários , compilando-os estaticamente

85
7.1 Compilando seus próprios binários para alvos Linux 4Linux – www.4linux.com.br

• Obter um dump de memória rapidamente (de preferência via pen drive ao ser
inserido)

• Buscar por arquivos escondidos em imagens, músicas etc

• Saber detectar a presençã de mensagens estaganogr afadas e criptografadas

7.1 Compilando seus próprios binár ios para alv os


Linux

Compilar seu próprio binário estático para rodar na máquina alvo pode evitar que
você rode um binário malicioso na máquina e/ou dependa de versões de bibliotecas
específicas que a máquina alvo pode não ter. Para isso, a ideia é baixar o código-
fonte do software e, se for escrito em C, adicionar a opção -static ao gcc. Veremos
agora um exemplo de compilação do dcfldd. Para softwares escritos em outras lin-
guagens, consulte a documentação do compilador utilizado.

$ apt-get source dcfldd


$ cd dcfldd*
$ CFLAGS=-static ./configure
$ make

O arquivo binário dcfldd será criado e você pode conferir se realmente é um binário
estático com o ldd:

$ ldd dcfldd

not a dynamic executable

Página86 TécnicasdeComputaçaoForense
Capítulo 8

Anexo I - Códigos de tipos de


partições

01 FAT12

02 XENIX root

03 XENIX usr

04 FAT16 <32M

05 Extended

06 FAT16

07 HPFS/NTFS/exFAT

08 AIX

09 AIX bootable

0A OS/2 Boot Manager

87
4Linux – www.4linux.com.br

0B W95 FAT32

0C W95 FAT32 (LBA)

0E W95 FAT16 (LBA)

0F W95 Ext’d (LBA)

10 OPUS

11 Hidden FAT12

12 Compaq diagnostics

14 Hidden FAT16 <32M

16 Hidden FAT16

17 Hidden HPFS/NTFS

18 AST SmartSleep

1B Hidden W95 FAT32

1C Hidden W95 FAT32 (LB

1E Hidden W95 FAT16 (LB

24 NEC DOS

27 Hidden NTFS WinRE

39 Plan 9

3C PartitionMagic recov

Página88 TécnicasdeComputaçaoForense
4Linux – www.4linux.com.br

40 Venix 80286

41 PPC PReP Boot

42 SFS

4D QNX4.x

4E QNX4.x 2nd part

4F QNX4.x 3rd part

50 OnTrack DM

51 OnTrack DM6 Aux1

52 CP/M

53 OnTrack DM6 Aux3

54 OnTrackDM6

55 EZ-Drive

56 Golden Bow

5C Priam Edisk

61 SpeedStor

63 GNU HURD or SysV

64 Novell Netware 286

65 Novell Netware 386

TécnicasdeComputaçaoForense Página89
4Linux – www.4linux.com.br

70 DiskSecure Multi-Boo

75 PC/IX

80 Old Minix

81 Minix / old Linux

82 Linux swap / Solaris

83 Linux

84 OS/2 hidden C: drive

85 Linux extended

86 NTFS volume set

87 NTFS volume set

88 Linux plaintext

8E Linux LVM

93 Amoeba

94 Amoeba BBT

9F BSD/OS

A0 IBM Thinkpad hiberna

A5 FreeBSD

A6 OpenBSD

Página90 TécnicasdeComputaçaoForense
4Linux – www.4linux.com.br

A7 NeXTSTEP

A8 Darwin UFS

A9 NetBSD

AB Darwin boot

AF HFS / HFS+

B7 BSDI fs

B8 BSDI swap

BB Boot Wizard hidden

BE Solaris boot

BF Solaris

C1 DRDOS/sec (FAT-12)

C4 DRDOS/sec (FAT-16 <

C6 DRDOS/sec (FAT-16)

C7 Syrinx

DA Non-FS data

DB CP/M / CTOS / ...

DE Dell Utility

DF BootIt

TécnicasdeComputaçaoForense Página91
4Linux – www.4linux.com.br

E1 DOS access

E3 DOS R/O

E4 SpeedStor

EB BeOS fs

EE GPT

EF EFI (FAT-12/16/32)

F0 Linux/PA-RISC boot

F1 SpeedStor

F2 DOS secondary

F4 SpeedStor

FB VMware VMFS

FC VMware VMKCORE

FD Linux raid autodetec

FE LANstep

FF BBT

Página92 TécnicasdeComputaçaoForense
Capítulo 9

Anexo II - Tabela ASCII

Dec Hex Dec Hex Dec Hex Dec Hex Dec Hex Dec Hex Dec Hex Dec Hex
  NUL 16 1 DLE 32 2 48 3  64 4 @ 8 5 P 96 6 ‘ 112 7 p
1 1 SOH 17 11 DC1 33 21 ! 49 31 1 65 41 A 81 51 Q 97 61 a 113 71 q
2 2 STX 18 12 DC2 34 22 " 5 32 2 66 42 B 82 52 R 98 62 b 114 72 r
3 3 ETX 19 13 DC3 35 23 # 51 33 3 67 43 C 83 53 S 99 63 c 115 73 s
4 4 EOT 2 14 DC4 36 24 $ 52 34 4 68 44 D 84 54 T 1 64 d 116 74 t
5 5 ENQ 21 15 NAK 37 25 % 53 35 5 69 45 E 85 55 U 11 65 e 117 75 u
6 6 ACK 22 16 SYN 38 26 & 54 36 6 7 46 F 86 56 V 12 66 f 118 76 v
7 7 BEL 23 17 ETB 39 27 ’ 55 37 7 71 47 G 87 57 W 13 67 g 119 77 w
8 8 BS 24 18 CAN 4 28 ( 56 38 8 72 48 H 88 58 X 14 68 h 12 78 x
9 9 HT 25 19 EM 41 29 ) 57 39 9 73 49 I 89 59 Y 15 69 i 121 79 y
1 A LF 26 1A SUB 42 2A * 58 3A : 74 4A J 9 5A Z 16 6A j 122 7A z
11 B VT 27 1B ESC 43 2B + 59 3B ; 75 4B K 91 5B [ 17 6B k 123 7B {
12 C FF 28 1C FS 44 2C , 6 3C < 76 4C L 92 5C \ 18 6C l 124 7C |
13 D CR 29 1D GS 45 2D - 61 3D = 77 4D M 93 5D ] 19 6D m 125 7D }
14 E SO 3 1E RS 46 2E . 62 3E > 78 4E N 94 5E ^ 11 6E n 126 7E ~
15 F SI 31 1F US 47 2F / 63 3F ? 79 4F O 95 5F _ 111 6F o 127 7F DEL

93
Capítulo 10

Anexo III - Tabela de caracteres UTF-8

Hex Hex Hex Hex Hex Hex Hex Hex


c2 a c2 ac ¬ c2 b8 ¸ c3 84 Ä c3 9 Ð c3 9c Ü c3 a8 è c3 b4 ô
c2 a1 ¡ c2 ad c2 b9  c3 85 Å c3 91 Ñ c3 9d Ý c3 a9 é c3 b5 õ
c2 a2 ¢ c2 ae ® c2 ba º c3 86 Æ c3 92 Ò c3 9e Þ c3 aa ê c3 b6 ö
c2 a3 £ c2 af c2 bb » c3 87 Ç c3 93 Ó c3 9f ß c3 ab ë c3 b7 ÷
c2 a4 ¤ c2 b ° c2 bc ¼ c3 88 È c3 94 Ô c3 a à c3 ac ì c3 b8 ø
c2 a5 ¥ c2 b1 ± c2 bd ½ c3 89 É c3 95 Õ c3 a1 á c3 ad í c3 b9 ù
c2 a6 ¦ c2 b2  c2 be c3 8a Ê c3 96 Ö c3 a2 â c3 ae î c3 ba ú
c2 a7 § c2 b 3  c2 bf ¿ c3 8b Ë c3 97 × c3 a3 ã c3 af ï c3 bb û
c2 a8 \ c2 b4 \ c3 8 À c3 8c Ì c3 98 Ø c3 a4 ä c3 b ð c3 bc ü
c2 a9 © c2 b5  c3 81 Á c3 8d Í c3 99 Ù c3 a5 å c3 b1 ñ c3 bd ý
c2 aa ª c2 b6 ¶ c3 82 Â c3 8e Î c3 9a Ú c3 a6 æ c3 b2 ò c3 be þ
c2 ab « c2 b 7 · c3 83 Ã c3 8f Ï c3 9b Û c3 a7 ç c3 b3 ó c3 bf ÿ

95
Capítulo 11

Anexo IV - Laudo

O laudo deve ser escrito em três vias assinadas pelo perito . Segue exemplo:
Listing:
1 Perito resp onsável:
2 No me: Fern and o Me rcês
3 CPF: 987. 21.4 32-99
4 Ema il: fernan do@merc es.net

5 Telef one Comerc ial: (21) 8 -8


6 Te le fo ne Ce lu la r: (2 1) 3 - 3 
7
8 Da ta de iníci o da períci a:
9 1/4/212
10
11 Da ta da em is são do la ud o:
12 1/4/212
13
14 Sumário execu tivo:
15 Inf orm ações sig ilo sas fo ram cop iad as do ser vid or de dado s da
empr esa Dext er
16 Co ur ri er en vi ad as por e-ma il par a te rc ei ro s. O ob je ti vo é
des cob rir co mo es sa
17 info rmação vazo u.
18
19 Esc op o da pe rícia:

97
4Linux – www.4linux.com.br

20 Ser vid or de dad os


21 Hostn ame: s rv1
22 FQD N: srv 1.dexter.local
23 CP U: Int el Xeo n 2. 2 GH z
24 Me móri a: 8 GB D DR- 2
25 Pl ac a -mãe : Inte l 8DGP
26 Di sc os: 4 x Sa ms un g SG 2  25 , GB

Página98 TécnicasdeComputaçaoForense

Você também pode gostar