UNIVERSIDADE PRESBITERIANA MACKENZIE FACULDADE DE COMPUTAÇÃO E INFORMÁTICA

CIÊNCIA DA COMPUTAÇÃO

VALDEMIR VIEIRA JUNIOR

FORENSE DIGITAL EM DISPOSITIVOS MÓVEIS COM SISTEMA

OPERACIONAL ANDROID

São Paulo

2013

VALDEMIR VIEIRA JUNIOR

FORENSE DIGITAL EM DISPOSITIVOS MÓVEIS COM SISTEMA

OPERACIONAL ANDROID

ORIENTADORA: Professora Drª Maria Ines Lopes Brosso Pioltine

São Paulo

2013

Trabalho de Graduação Interdisciplinar apresentado ao curso de Ciência da Computação, da Faculdade de Computação e Informática da Universidade Presbiteriana Mackenzie, como requisito parcial à obtenção do grau de Bacharel em Ciência da Computação.

AGRADECIMENTOS

Aos meus pais que mesmo não podendo me ajudar diretamente contribuíram

com o que puderam durante a minha jornada.

A minha orientadora, Professora Dra. Maria Inês Lopes Brosso Pioltine, que me

guiou durante todo o desenvolvimento deste trabalho, me ajudando a manter o

foco na pesquisa proposta desde o seu início.

Aos meus colegas de trabalho pelo tempo dedicado a me ouvir falar da

pesquisa e pelas sugestões acrescentadas a este trabalho.

“Não devemos parar de explorar. E o fim de toda a nossa exploração será chegar ao ponto de partida e ver o lugar pela primeira vez”

T. S. Eliot

RESUMO

Existem diversas técnicas para perícia forense em desktops e estas já estão

bastante difundidas. No entanto, no que se refere a computação pessoal o

cenário mundial está em plena mudança. Cada vez mais pessoas deixam de

utilizar os tradicionais computadores pessoais e concentram suas atividades

em smartphones e tablets. Dentre os sistemas operacionais para dispositivos

móveis, o que vem mostrando o maior crescimento é o Android, e por isso ele é

o foco desta pesquisa. As técnicas de forense digital conhecidas para telefones

celulares e desktops não são suficientemente específicas e detalhadas para

realização de exames em dispositivos controlados pelo Android. O objetivo do

trabalho é apresentar técnicas de perícia forense com métodos específicos

para o sistema operacional Android. Para a apresentação destes métodos de

perícia forense, foram mapeadas situações reais em que os peritos se

encontram durante os processos de extração de dados. Ao final do trabalho foi

proposto um estudo de caso, no qual um smartphone com Android é

propositalmente infectado com um trojan e este identificado através do uso de

algumas das técnicas forenses apresentadas.

Palavras-chave: Android, Análise Forense, Segurança, Mobile, Aquisição de

Dados, Smartphones.

ABSTRACT

There are several techniques for forensics on desktops and these are already

quite widespread. However, in regard to personal computers in the world

scenario is full change. More and more people stop using traditional personal

computers and focus their activities on smartphones and tablets. Among the

operating systems for mobile devices, which has shown the greatest growth is

Android, so it is the focus of this research. The digital forensic techniques

known for mobile phones and desktops are not sufficiently specific and detailed

examinations on devices controlled by Android. The objective is to present

forensic techniques with methods specific to the operating system Android. For

the presentation of these methods forensics were mapped actual situations in

which the experts are in the process of data extraction. At the end of the work

we propose a case study in which a smartphone with Android is purposely

infected with a trojan and this identified through the use of some of forensic

techniques presented.

Keywords: Android, Forensics, Security, Mobile, Data Acquisition,

Smartphones.

SUMÁRIO

CAPÍTULO 1. INTRODUÇÃO ....................................................................... 14

1.1 INTRODUÇÃO ........................................................................................ 14

1.2 OBJETIVO .......................................................................................... 15

1.3 MOTIVAÇÃO ....................................................................................... 15

1.4 JUSTIFICATIVA .................................................................................. 16

1.5 TRABALHOS RELEVANTES .............................................................. 16

1.6 METODOLOGIA DE PESQUISA ........................................................ 16

1.7 ORGANIZAÇÃO DO TRABALHO ....................................................... 16

CAPÍTULO 2. O SISTEMA OPERACIONAL ANDROID ............................... 18

2.1 INTRODUÇÃO .................................................................................... 18

2.2 A PLATAFORMA................................................................................. 19

2.3 A MÁQUINA VIRTUAL DALVIK .......................................................... 21

2.3.1 Comparação entre a Sun JVM e a Dalvik VM ............................... 22

2.3.2 O formato dex ............................................................................... 23

2.4 ANDROID SOFTWARE DEVELOPMENT KIT .................................... 24

2.4.1 Android NDK ............................................................................. 25

2.4.2 Android Virtual Devices (AVD) .................................................. 25

2.4.3 Android Debug Bridge - ADB Tools ........................................... 28

2.5 SISTEMAS DE ARQUIVOS ................................................................ 30

2.5.1 FAT32 ........................................................................................ 30

2.5.2 YAFFS2 ..................................................................................... 31

2.5.3 Partições do Sistema de Arquivos ............................................. 32

2.5.4 Formas de Persistência de Dados ............................................ 33

2.6 LOGS DO SISTEMA E DAS APLICAÇÕES ........................................ 35

2.6.1 Log do Kernel do Linux.............................................................. 35

2.6.2 Logs dos Apps ........................................................................... 40

2.7 GOOGLE PLAY .................................................................................. 41

CAPÍTULO 3. SEGURANÇA NO SISTEMA OPERACIONAL ANDROID ..... 42

3.1 INTRODUÇÃO .................................................................................... 42

3.2 PERMISSÃO POR APLICAÇÃO ......................................................... 42

3.3 VULNERABILIDADES NO ARMAZENAMENTO DE INFORMAÇÕES 47

3.4 PROTEÇÃO DOS DADOS NO ANDROID .......................................... 48

3.4.1 Bloqueio de Tela ....................................................................... 48

3.4.2 Criptografia de Dados................................................................ 50

3.5 SEGURANÇA NA TRANSMISSÃO DE INFORMAÇÕES ................... 51

3.5.1 Autenticação no protocolo SSL/TLS .......................................... 52

3.5.2 Transmissão dos Dados ............................................................ 52

3.6 AMEAÇAS NA TRANSMISSÃO DE DADOS ...................................... 53

3.7 MALWARE .......................................................................................... 53

CAPÍTULO 4. FORENSE DIGITAL NO ANDROID ....................................... 55

4.1 INTRODUÇÃO .................................................................................... 55

4.2 TIPOS DE INVESTIGAÇÃO ................................................................ 56

4.3 AMBIENTE DE TESTES ..................................................................... 57

4.4 PRESERVANDO O ESTADO DO DISPOSITIVEL MÓVEL ................ 59

4.4.1 Passando pelo Bloqueio de Tela ............................................... 59

4.4.2 Isolando o Dispositivo Móvel da Rede ...................................... 62

4.4.3 Conhecendo o Dispositivo ......................................................... 64

4.5 EXTRAINDO INFORMAÇÕES DO DISPOSITIVO.............................. 64

4.5.1 Extração Via Software ............................................................... 64

4.5.2 Extração Via Hardware.............................................................. 66

4.6 ANÁLISE DAS INFORMAÇÕES OBTIDAS ........................................ 66

4.6.1 Ferramentas e Técnicas de Análise de Dados .......................... 66

4.6.2 Análise Forense das Partições SDCard e eMMC ...................... 69

4.6.3 Análise Forense no Sistema de Arquivos YAFFS2 ................... 72

CAPÍTULO 5. ESTUDO DE CASO ............................................................... 73

5.1 INTRODUÇÃO .................................................................................... 73

5.2 METODOLOGIA DE ANÁLISE PROPOSTA ....................................... 73

5.2.1 O Malware Zitmo ....................................................................... 75

5.2.2 Identificação do Malware ........................................................... 75

5.2.3 Engenharia Reversa e Análise do Arquivo APK ........................ 77

5.3 CONCLUSÃO ..................................................................................... 80

CAPÍTULO 6. CONCLUSÃO ........................................................................ 81

6.1 TRABALHOS FUTUROS .................................................................... 81

REFERENCIAS ................................................................................................ 83

LISTA DE TABELAS

Tabela 1 – Vendas de Smartphones por SO no mundo (em milhares de

unidades).......................................................................................................... 19

Tabela 2 – Distribuição das versões do Android .............................................. 21

Tabela 3 – Comparação entre os tamanhos dos arquivos JAR e DEX ............ 24

Tabela 4 – Data de disponibilização do Android SDK ...................................... 24

Tabela 5 – Localização dos arquivos criados pelo AVD ................................... 27

Tabela 6 – Estrutura do diretório /data/data/<ApplicationPackageName> ....... 33

Tabela 7 – Níveis de log ................................................................................... 37

Tabela 8 – Opções de comando de linha do logcat ......................................... 38

Tabela 9 – Técnicas para isolar um dispositivo móvel da rede ........................ 63

Tabela 10 – Partições e sistemas de arquivos ................................................. 67

LISTA DE FIGURAS

Figura 1 – Assinantes da telefonia celular por ano no mundo. ......................... 14

Figura 2 – Visão da arquitetura do SO Android ................................................ 19

Figura 3 – Relação entre versão do Android em aparelhos em uso ................. 21

Figura 4 - Java vs Dalvik .................................................................................. 23

Figura 5 – AVD em execução ........................................................................... 26

Figura 6 – Estrutura de diretórios criados pelo AVD ........................................ 27

Figura 7 – Instalação do Android ADB Tools.................................................... 28

Figura 8 – Ativação do modo de depuração no Android .................................. 29

Figura 9 – Comando adb devices ..................................................................... 29

Figura 10 – Comando adb shell ....................................................................... 30

Figura 11 – Listagem do diretório shared_prefs do aplicativo Phone ............... 33

Figura 12 – Arquivo XML do tipo chave-valor................................................... 34

Figura 13 – Listagem do diretório data/data ..................................................... 34

Figura 14 – Saída do comando dmesg ............................................................ 36

Figura 15 – Saída do comando logcat .............................................................. 37

Figura 16 – Saída do comando dumpsys ......................................................... 39

Figura 17 – Saída do comando dumpstate ...................................................... 40

Figura 18 – Listagem do diretório do app Dropbox .......................................... 41

Figura 19 – Visualização do arquivo de logs do app Dropbox ......................... 41

Figura 20 – Instalação dos Apps Google Maps e Gmail respectivamente ....... 44

Figura 21 – Visualização da permissão de acesso no Manifest.xml ................ 44

Figura 22 – Restrição de acesso no Manifest.xml ............................................ 46

Figura 23 – Aviso do Android sobre fontes desconhecidas .............................. 47

Figura 24 – Tela de configuração de bloqueio do Android ............................... 49

Figura 25 – Bloqueio de tela por código pin, desenho de padrão e senha

alfanumérica respectivamente. ......................................................................... 49

Figura 26 – Tela de opção para criptografar os dados do dispositivo .............. 50

Figura 27 – Criptografia dos dados: telas de aviso e confirmação

respectivamente ............................................................................................... 51

Figura 28 – Exemplo de configuração de conexão SSL/TLS ........................... 53

Figura 29 – Foto mostrando a marca do pattern desenhado. .......................... 60

Figura 30 – Saída do comando lsub ................................................................. 64

Figura 31 – Extração de dados via adb pull sem acesso de root ..................... 65

Figura 32 – Extração de dados via adb pull como root .................................... 65

Figura 33 – Saída do comando mount ............................................................. 67

Figura 34 – Saída do comando strings sobre uma base SQLite ...................... 68

Figura 35 – Visualização de uma base SQLite no hexeditor ............................ 69

Figura 36 – Visualização das tabelas de uma base SQLite ............................. 69

Figura 37 – Opção Mover para o cartão de memória ....................................... 70

Figura 38 – Listagem do diretório /mnt ............................................................. 71

Figura 39 – Diagrama de identificação e análise de malware .......................... 74

Figura 40 – Instalação do APP Trusteer Rapport ............................................. 76

Figura 41 – Visualização dos processos em execução .................................... 76

Figura 42 – Extração do arquivo apk do app suspeito ..................................... 77

Figura 43 – Analise do tráfego de rede do AVD pelo software Wireshark ........ 77

Figura 44 – Visualização do conteúdo do apk do app Zitmo ............................ 77

Figura 45 – Execução da ferramenta APKTools .............................................. 78

Figura 46 – Execução da ferramenta dex2jar................................................... 79

Figura 47 – Visualização do código do Zitmo no JD-GUI ................................. 79

LISTA DE SIGLAS E ABREVIAÇÕES

ADB Android Debug Bridge

API Application Programing Interface

APP Application Software

AVD Android Virtual Device

DVM Dalvik Virtual Machine

DiD Defense in Depth

GC Garbage Collection

GPL GNU Public License

GPS Global Positioning System

GSM Global System for Mobile

HTML HyperText Markup Language

IDE Integrated Development Environment

JVM Java Virtual Machine

MMC MultiMedia Card

MMS Multimedia Messaging Service

NDK Native Code Development

PC Personal Computer

RAM Random Access Memory

SDK Software Development Kit

SIM Subscriber Identity Module

SMS Short Message Service

SO Sistema Operacional

SQL Structured Query Language

SSL Security Sockets Layer

TLS Transport Layer Security

VM Virtual Machine

UI User Interface

USB Universal Serial BUS

XML Extensible Markup Language

YAFFS2 Yet Another Flash File System

14

CAPÍTULO 1. INTRODUÇÃO

1.1 INTRODUÇÃO

No mundo da telefonia pode-se dizer que os dez últimos anos foram da

telefonia celular. O número de assinantes de telefones móveis no mundo inteiro

aumentou de 738 milhões em 2000 para quase seis bilhões em 2011, como

mostra o gráfico da figura 1, e agora o número de assinantes da telefonia

celular ultrapassa o número de linhas telefônicas convencionais (ITU Statistics,

2011).

Figura 1 – Assinantes da telefonia celular por ano no mundo.

Fonte: (ITC Statistics, 2013).

Somente no Brasil, em agosto 2013, o número de assinantes de telefonia

móvel totalizava 268.4 milhões (Anatel, 2013), uma média de 135.45 celulares

para cada 100 habitantes. Com o advento de laptops, palmtops, PDAs e mais

recentemente dos smartphones, a promessa de acesso desimpedido à Internet

global, a qualquer hora, a qualquer lugar (internet ubíqua) já é uma realidade

por meio de equipamentos leves e totalmente portáteis. (Redes de

Computadores e a Internet, 2010).

0

1.000.000.000

2.000.000.000

3.000.000.000

4.000.000.000

5.000.000.000

6.000.000.000

7.000.000.000

Nú

me

ro d

e A

ssin

ante

s

Ano

Assinantes de telefonia celular

Assinantes

15

Dentre esses dispositivos móveis, hoje, a maior parte deles vem com o sistema

operacional Android, do Google, instalado. E a cada nova versão, o sistema

adiciona novas funcionalidades para tirar proveito do hardware dos

dispositivos, que aumenta o poder de processamento a cada poucos meses. O

ultimo smartphone oficial do Google, Nexus 4, por exemplo, tem 2GB de

memória RAM integrada, processador quad-core de 1,5GHz e 16GB de

armazenamento interno. Isso somado a itens como: câmera, acelerômetro,

GPS e suporte a conexões de rede sem fio, fazem do dispositivo muito mais do

que um celular, mas sim uma enorme fonte de informações onde seus usuários

podem armazenar não apenas contatos telefônicos, mas também documentos

importantes através de serviço de cloud computing, traçar rotas com o serviço

de GPS e publicar fotos de viagens família e outros.

Neste cenário, a comunidade forense se depara com um grande desafio já que

as técnicas de extração de dados, já consolidadas para os desktops, não

funcionam para dispositivos com hardware específico para o Android. Numa

análise forense, à medida que o nível de compreensão sobre o sistema

operacional e seu hardware aumentam, novas técnicas de manuseio e

extração de informações relevantes são desenvolvidas. Assim, um profundo

conhecimento do sistema operacional Android, onde as informações nele são

salvas e quais informações buscar, pode trazer dados muito úteis e até

decisivos sobre o seu usuário.

1.2 OBJETIVO

O objetivo da pesquisa é apresentar métodos de perícia forense para

dispositivos móveis com sistema operacional Android.

1.3 MOTIVAÇÃO

Descrever técnicas de análise forense em dispositivos móveis com Android. As

técnicas de perícia forense para desktops já são bastante difundidas e sua

aplicação a smartphones e tablets requer técnicas diferentes. A extração dos

dados será feita de forma a obter todas as informações possíveis do

equipamento.

16

1.4 JUSTIFICATIVA

Nos últimos 4 anos houve um aumento substancial no número de dispositivos

móveis com Android, a tal ponto que este se tornou a plataforma móvel mais

utilizada do mercado.

1.5 TRABALHOS RELEVANTES

A tese de mestrado “Proposta de Método para Análise Pericial em Smatphone

com Sistema Operacional Android”, de André Morum de Lima Simão publicada

em 2011 serviu como guia para este trabalho, nela são abordadas as

dificuldades técnicas para a extração de dados de smartphones Android além

da proposta de uma metodologia para realizar essa recuperação de

informações, onde são abordadas situações reais encontradas pelos analistas

forenses.

O artigo publicado pela Digital Investigation, Android anti-forensics through a

local paradigma, publicado em 2010 por Alessandro Distefano, Gianluigi Mea e

Francesco Pace, onde algumas técnicas para dificultar o acesso às

informações dos dispositivos Android são apresentadas.

Android Forensics: Simplifying Cell Phone Examinations, artigo publicado pela

Edith Cowan University, de autoria de Jeff Lessard e Gary Kessler, publicado

em 2010, onde mais técnicas para obtenção de dados são apresentadas e

utilizadas de forma complementar neste trabalho.

1.6 METODOLOGIA DE PESQUISA

Para o desenvolvimento desta pesquisa optou-se, para uma primeira parte, por

uma pesquisa bibliográfica sobre a plataforma Android.

1.7 ORGANIZAÇÃO DO TRABALHO

A pesquisa foi dividida em 6 (seis) capítulos.

O capítulo 1 apresenta o problema e a justificativa para o trabalho.

O capítulo 2 mostra uma visão sobre o sistema operacional Android. Sua

história, arquitetura, versões e funcionalidades.

17

O capítulo 3 se dedica a mecanismos de segurança no sistema operacional

Android.

O capítulo 4 apresenta as técnicas de perícia forense no Android para extração

e análise de informações.

O capítulo 5 desenvolve o estudo de caso. Um smartphone propositalmente

infectado com um spyware é submetido para análise utilizando as ferramentas

e técnicas apresentadas no capítulo anterior.

O capítulo 6 conclui a pesquisa descrevendo sua relevância a partir dos

resultados obtidos no estudo de caso e apresentando novos temas para

continuidade do trabalho.

18

CAPÍTULO 2. O SISTEMA OPERACIONAL ANDROID

2.1 INTRODUÇÃO

O Google planejando entrar no mercado de celulares com seus serviços de

internet encontrou-se no impasse de não possuir uma plataforma para isso.

Então em agosto de 2005 adquiriu a Android Inc³. Após um tempo sem notícias

é anunciada, em 2007, a Open Handset Alliance, que coloca o Android

oficialmente no mundo Open Source. Em 2008 a versão 1.0 do SDK é lançada,

assim como o primeiro celular com o sistema, o G1 da HTC. Em 2009, com o

lançamento das versões 1.5, 1.6 e 2.x, viu-se uma proliferação de dispositivos

que rodam o sistema. Em 2010, o Android já era o segundo sistema mais

utilizado em smartphones, atrás apenas do então bem sucedido Blackberry

(Learning Android, 2011).

Quando o Google comprou a Android Inc, em 2005, o CEO na época, Eric

Schmidt, deixou claro que a ambição do Google era muito maior do que ver o

sistema rodando em um simples telefone. A intenção da empresa e ver o

sistema rodando em todos os lugares e fazendo tudo, como o Google é uma

empresa de media, quanto mais pessoas utilizarem os seus produtos, mais

fácil adicionar novos serviços e propagandas junto com eles(Learning Android,

2011).

Atualmente o Google licencia alguns aplicativos proprietários como Gmail e

Maps, e ganha algum dinheiro com o Google Play (Learning Android, 2011).

Desde o primeiro telefone com o sistema, lançado em 2008, até torna-se o SO

para dispositivos móveis mais utilizado, o número de usuários do sistema

Android continua a aumentar a cada ano.

A tabela 1 mostra os números de vendas de smatphones a usuários finais por

sistema operacional em 2013. Por ela é possível ver a dominância do sistema

da Google além de um crescimento em relação ao ano anterior.

19

Tabela 1 – Vendas de Smartphones por SO no mundo (em milhares de unidades)

Sistema Operacional

Unidades vendidas em 2013

Participação no mercado em 2013 (%)

Unidades vendidas em 2012

Participação no mercado em 2012 (%)

Android 177,898.2 79.0 98,664.0 64.2

iOS 31,899.7 14.2 28,935.0 18.8

Microsoft 7,407.6 3.3 4,039.1 2.6

BlackBerry 6,180.0 2.7 5.2

Bada 838.2 0.4 7,991.2 2.7

Symbian 630.8 0.3 4,208.8 5.9

Outros 471.7 0.2 9,071.5 0.6

Total 225,326.2 100.0 153,772.9 100.0 Fonte: (Gartner, Agosto de 2013).

2.2 A PLATAFORMA

O Android é um SO (sistema operacional) construído especificamente para

dispositivos móveis, ele tem como base o kernel do Linux. Ele inclui interface

gráfica rica, aplicações para o usuário final, bibliotecas, frameworks, suporte

multimídia entre outros. A figura 2 apresenta uma visão da arquitetura do SO.

Figura 2 – Visão da arquitetura do SO Android

Fonte: (Android Developers, 2013).

20

Abaixo uma breve descrição de cada camada da arquitetura do sistema:

Kernel: o Android, a partir da versão 4.0.4, utiliza a versão 3.0 do Kernel

do Linux. O Kernel é responsável pelo gerenciamento dos processos, da

memória e do hardware do dispositivo, agindo como uma camada de

abstração entre hardware e software (Linux Command Line and Shell

Scripting Bible, 2008).

Bibliotecas: escritas em C/C++, fazem parte de todo sistema Linux. No

Android, são invocadas através de uma interface Java. Dentre essas

bibliotecas estão disponíveis gerenciadores de janela (window

manager), base de dados SQLite, suporte a gráficos 2D e 3D entre

outros (Learning Android, 2011).

Ambiente de execução do Android: é a camada de execução da Dalvik

VM que fornece as aplicações funcionalidades disponíveis na biblioteca

Java (Learning Android).

Framework de aplicações: aberto e de desenvolvimento colaborativo,

promove a reutilização de funções entre as aplicações. A mesma API

(Application Program Interface) disponível para as aplicações nativas do

Android está, também, disponível aos desenvolvedores.

Camada de aplicação: conjunto básico de aplicativos que são

distribuídos com a plataforma Android.

Uma característica do Android que fica evidenciada pela figura acima é que,

não existe diferença entre aplicações nativas e as criadas por outros

desenvolvedores, já que os dois tipos utilizam as bibliotecas providas pela

Dalvik VM. Esse fato evidencia que qualquer desenvolvedor pode criar

aplicações poderosas para o Android.

A tabela 2 e o gráfico de pizza da figura 3 são baseados no número de

dispositivos com Android que acessaram o Google Play, em um período de 14

dias terminando em 4 de Março de 2013.

21

Tabela 2 – Distribuição das versões do Android

Versão Codenome Data de Lançamento API Level

Distribuição

1.0 23 de setembro de 2008

1

1.1 9 de fevereiro de 2009

2

1.5 Cupcake 30 de abril de 2009 3

1.6 Donut 15 setembro 2009 4

2.1 Eclair 30 de outubro 2009 7

2.2 Froyo 20 de maio 2010 8 1.7%

2.3 – 2.3.2 Gingerbread 6 de dezembro 2010 9

2.3.3 - 2.3.7

10 26.3%

3.1 Honeycomb 22 de fevereiro de 2011

12

3.2 13 0.1%

4.0.3 – 4.0.4

Ice Cream Sandwich

19 de outubro de 2011

15 19.8%

4.1 Jelly Beans 9 de julho de 2012 16 37.3%

4.2 Jelly Beans 13 de Novembro de 2012

17 12.5%

4.3 Jelly Beans 24 de Julho de 2013 18 2.3%

4.4 Kit Kat 31 de Outubro de 2013

19

Fonte: (Android Developers, 2013).

Figura 3 – Relação entre versão do Android em aparelhos em uso

Fonte: (Android Developers, 2013).

2.3 A MÁQUINA VIRTUAL DALVIK

A Dalvik é uma máquina virtual especialmente projetada para a plataforma

Android. Ela foi desenvolvida por Dan Borntein em parceria com a equipe do

Google. Embora seja possível desenvolver aplicativos para o Android em

22

qualquer linguagem que compile para o Java bytecode, a linguagem

predominante é Java. Vale lembrar que a Dalvik Virtual Machine (DVM) utiliza

uma implementação limitada das bibliotecas padrões do Java.

Ao contrário da Java Virtual Machine (JVM), a Dalvik foi projetada para

dispositivos móveis, assim, restrições como memória e duração da bateria,

fizeram parte de sua arquitetura desde o início.

Um outro motivo para o desenvolvimento da Dalvik foi o fato de que, ao

contrário da linguagem Java e de suas bibliotecas, a própria JVM não é livre. A

título de curiosidade: existem algumas iniciativas opensource como o openJDK

e o Apache Harmony. Assim, com uma VM livre, os fabricantes de hardware se

sentiriam mais seguros em adotar a plataforma, pois não teriam que se

preocupar com licenças. (Learning Android, 2011)

2.3.1 Comparação entre a Sun JVM e a Dalvik VM

Em Java o processo segue a seguinte ordem: o arquivo contendo o código

fonte é escrito, depois ele é compilado gerando o arquivo “.class” contendo os

bytecodes (linguagem compreendida pela JVM) e então o código é interpretado

pela JVM. No caso da Dalvik existe uma etapa a mais após a compilação do

arquivo contendo o código fonte em .class. Esse .class sofre uma nova

compilação pelo Dalvik Compiler para gerar o arquivo “.dex” que contém os

bytecodes interpretados pela Dalvik VM. A figura 4 diagrama as fases

envolvidas no processo de compilação pela JVM e pela Dalvik VM (Learning

Android, 2011).

23

Figura 4 - Java vs Dalvik

Fonte: (Learning Android, 2011).

O porquê de não compilar diretamente o código fonte para o Dalvik bytecode

está no fato de que, quando o desenvolvimento da Dalvik começou, a

linguagem Java ainda sofria muitas mudanças, mas os bytecodes da JVM não,

por isso a equipe da Dalvik achou melhor basear-se nos bytecodes ao invés de

a própria linguagem Java. Assim, é possível escrever apps para o Android em

qualquer linguagem que compilada para os bytecodes da JVM.

Outra particularidade da DVM é o sistema de coleta de lixo (Garbage Collection

- GC). Para cada aplicativo é criada uma nova instancia da Dalvik VM, ela é

otimizada para esse comportamento, e o sistema de GC também. E para evitar

que um processo de GC limpe um objeto compartilhado em memória são

utilizados bits de marcação, que indicam que um objeto é alcançável por outro

processo e não deve ser excluído da memória (Bornstein, 2008).

2.3.2 O formato dex

O formato .dex ocupa cerca de metade do espaço em disco que um arquivo

.class, logo, esse formato é otimizado para lidar com a pouca memória dos

dispositivos móveis.

O arquivo .class, produto da compilação do código fonte, é compilado em um

.dex pela ferramenta dx (Ehringer, 2008).

24

Tabela 3 – Comparação entre os tamanhos dos arquivos JAR e DEX

Código Arquivo Jar sem Compressão(bytes)

Arquivo Jar com Compressão

Arquivo DEX sem compressão

Bibliotecas do Sistema

21,445,320 (100%) 10,662,048 (50%) 10,311,972 (48%)

App de navegador web

470,312 (100%) 232,065 (49%) 209,248 (44%)

App de alarme relógio

119,200 (100%) 61,658 (52%) 53,020 (44%)

Fonte: (Ehringer, 2008).

A formato “.dex” usa um pool de constantes de tipo específico como

mecanismo primário para conservar memória. Ao invés de salvar essas

constantes no arquivo class, elas são buscadas no pool de constantes

referenciada pelo seu índice no mesmo. Assim as duplicações existentes no

.class são eliminadas no .dex (Ehringer, 2008, tradução nossa).

2.4 ANDROID SOFTWARE DEVELOPMENT KIT

O Android Software Development Kit (SDK) é um conjunto de ferramentas

utilizadas no desenvolvimento de aplicativos para a plataforma. A cada nova

versão do sistema Android lançada, um no conjunto de ferramentas (API Level)

é disponibilizado aos desenvolvedores para que eles possam utilizar os novos

recursos que são implementados. A tabela 4 mostra a versão do Android alvo

da API Level e o seu ano de lançamento:

Tabela 4 – Data de disponibilização do Android SDK

Plataforma Android API Level Data de Lançamento

4.4 19 31 de Outubro de 2013

4.3.1 18 24 de Julho de 2013

4.2.2 17 11 de Fevereiro de 2013

4.1.2 16 9 de Outubro de 2012

4.0.4 15 29 de Março de 2012

Fonte: (Learning Android, 2011).

No caso do Android, os apps são disponibilizados através do Google Play (visto

em sessão posterior), onde são validados. É possível habilitar o Android para

que seja possível instalar apps de outras fontes mas um aviso de segurança

será exibido para alertar o usuário sobre os riscos.

25

2.4.1 Android NDK

A maioria do apps para Android é escrita na linguagem Java e posteriormente

executada na máquina virtual Dalvik. Porém, há casos em que, por questões

de performance, a aplicação teria um desempenho melhor se partes dela fosse

escrita em uma linguagem compilada diretamente para código nativo. Para

esses casos existe o NDK (Native Code Development). O NDK permite aos

desenvolvedores escrever código em C/C++ que, dependendo da tarefa

executada, pode resultar em ganho de performance como nos casos do uso

intensivo da CPU para cálculos, processamento de sinal e simulação de física

(Android Developers, 2013).

O NDK surgiu em Junho de 2009 e teve cinco revisões até seu lançamento em

Novembro de 2010. Hoje, o NDK suporta as arquiteturas ARMv5TE e ARMv7-A

e futuramente, através de uma parceria entre Google e Intel, suportará a

arquitetura x86 da Intel. Um ponto importante é que não é possível criar

aplicações completas com o NDK, apenas módulos que serão chamados pela

aplicação principal que é executada na Dalvik VM. Seu uso é restrito a otimizar

algumas partes da aplicação, inclusive, os módulos escrito em C/C++ usando o

NDK, são empacotados com o resto da aplicação no arquivo apk (Learning

Android, 2011).

Do ponto de vista da forense e da segurança, a ferramenta de cross-compiling

(compilar um código em uma plataforma tendo como alvo outra) é um

importante ponto de estudo, uma vez que seus componentes podem ser

reutilizados. Por exemplo, na versão 1.5 do Android, o root exploit utilizava um

bug no kernel do Linux para ganhar privilégios de super usuário. Este era

distribuído como código fonte e requeria cross-compiling (Android Forensics,

2011).

2.4.2 Android Virtual Devices (AVD)

Junto com o SDK do Android existe um emulador da plataforma, com ele é

possível criar VM de versões diferentes do Android e observar o

comportamento de uma aplicação em cada uma delas.

26

Antes de criar as VM Android para cada versão do SO é preciso fazer o

download de cada versão da API. Isso é feito no SDK Manager que faz parte

do SDK. Nele são assinaladas as versões do Android com as quais se deseja

trabalhar.

Este emulador tem grande importância para os desenvolvedores que precisam

validar suas aplicações com versões específicas do sistema, mas também tem

grande valor para a investigação forense no que tange personalizar como a

aplicação executará no sistema.

Figura 5 – AVD em execução Fonte: O Autor (utilizando o AVD versão para Windows).

Quando um AVD é executado, os arquivos criados por ela são de grande valor

para a perícia forense e para a área de pesquisa de segurança. Os arquivos

referentes ao armazenamento interno e SD Card são criados no diretório do

usuário.

27

Tabela 5 – Localização dos arquivos criados pelo AVD

Sistema Operacional

Diretório da AVD

Ubuntu Linux /Users/<username>/.android

Windows 7 C:\Users\<username>\.android\avd\android422.avd

A estrutura criada pelo AVD é como a seguir:

Figura 6 – Estrutura de diretórios criados pelo AVD Fonte: O Autor (utilizando o prompt de comando do Windows 7).

Os arquivos que interessam a forense são:

sdcard: imagem do cartão SD (se criado durante a configuração do

AVD)

userdata.img: imagem da partição /data

cache.img: imagem da partição /cache

As partições representadas pelo cache.img e userdata.img são do formato

YAFFS2 que ainda não é suportado pelas ferramentas de analise forense. O

C:. | adbkey | adbkey.pub | adb_usb.ini | androidtool.cfg | androidwin.cfg | ddms.cfg | default.keyset | modem-nv-ram-5554 | repositories.cfg | sites-settings.cfg | +---avd | | Android-422.ini | | | \---Android-422.avd | cache.img | config.ini | emulator-user.ini | hardware-qemu.ini | sdcard.img | userdata-qemu.img | userdata.img | \---cache sdkbin-1_0873bf78-repository-8_xml sdkbin-1_172100de-addons_list-2_xml sdkbin-1_2bfc99d2-sys-img_xml sdkbin-1_9c35fc9e-addon_xml sdkbin-1_e9f1c86d-sys-img_xml sdkbin-1_f30bfa4f-addon_xml sdkbin-1_f9d1c322-sys-img_xml sdkinf-1_0873bf78-repository-8_xml sdkinf-1_172100de-addons_list-2_xml sdkinf-1_2bfc99d2-sys-img_xml sdkinf-1_9c35fc9e-addon_xml sdkinf-1_e9f1c86d-sys-img_xml sdkinf-1_f30bfa4f-addon_xml sdkinf-1_f9d1c322-sys-img_xml

28

sdcard utiliza o formato FAT32 no qual as ferramentas de forense trabalham

muito bem.

É possível aprender muito sobre o SO com a ajuda de um AVD. Como

examinar as conexões de rede, sistema de arquivos e outros artefatos (Android

Forensics, 2011).

2.4.3 Android Debug Bridge - ADB Tools

Uma ferramenta extremamente útil para uma perícia em dispositivos com

Android é o ADB (Android Debug Bridge) Tools. Através dela é possível se

comunicar, controlar e acessar a memória interna de um dispositivo Android e,

se o modo root estiver disponível além de ver as informações salvas pelos

aplicativos no diretório /data/data, que por padrão não estão acessíveis(Android

Developers, 2013).

No Ubuntu 13.04, a ferramenta pode ser instalada com o comando:

Figura 7 – Instalação do Android ADB Tools Fonte: O Autor.

O ADB é composto de três componentes:

Cliente: serviço ADB cliente em execução na estação que tentará a

comunicação com o Android.

Servidor: serviço ADBD (Android Debug Bridge Daemon) em execução

também na estação que tentará a comunicação com o Android.

Serviço (daemon): serviço ADBD em execução no dispositivo Android.

Como descrito acima, o serviço ADBD precisa estar em execução no

dispositivo Android, a figura 8 mostra como é feita a inicialização (Android

Developers, 2013):

sudo apt-get install android-tools-adb

29

Figura 8 – Ativação do modo de depuração no Android Fonte: O Autor (utilizando o AVD versão para Windows).

O primeiro comando após conectar o dispositivo Android ao computador via

cabo USB é o ADB devices. Esse comando lista todos os dispositivos

conectados ao PC.

Figura 9 – Comando adb devices Fonte: O Autor.

A saída do comando acima mostra os identificadores dos dispositivos

conectados no momento.

Para navegar pela estrutura de diretórios da memória interna é utilizado o

comando adb shell. Que permite abrir uma shell no dispositivo Android e

interagir com ele, segue exemplo de sua utilização (Android Forensics, 2011):

luffy@ubuntu:~$ adb devices List of devices attached 7DF600229FFC0000016395910A01600F device

30

Figura 10 – Comando adb shell Fonte: O Autor.

As funcionalidades do ADB evoluem a cada versão do Android, algumas delas

são apresentadas neste capítulo.

2.5 SISTEMAS DE ARQUIVOS

As informações que podem ser recuperadas do Android são uma combinação

dos já conhecidos artefatos encontrados no Linux mais outros novos como os

apps que executam sobre a Dalvik VM e o sistema de arquivos YAFFS2 (Yet

Another Flash File System). Nisso, a variedade de informações que são

armazenadas diretamente pelo usuário do dispositivo móvel, ou pelos apps que

executam no sistema é enorme. Exemplos desses dados são: Mensagens de

texto (SMS/MMS), Contatos telefônicos, Logs de chamadas telefônicas,

mensagens de e-mail (Gmail, Yahoo, Exchange), Mensagens instantâneas

(Whats app, Facebook Messenger), fotos, vídeos, histórico de navegação,

coordenadas GPS, histórico de buscas, rotas de direção, arquivos diversos,

músicas, eventos de calendário, informações financeiras, informações pessoais

salvas por clientes de redes sociais(Facebook, Twitter) e etc (Android

Forensics, 2011).

2.5.1 FAT32

O formato FAT32, muito conhecido pelas partições dos sistemas da Microsoft,

é utilizado como sistemas de arquivos no Android para os seus cartões de

memória e eMMC (MultiMediaCard). Existem algumas razões para o sistema

de arquivos da partição do usuário ser diferente da utilizada pelo Android, uma

delas é a compatibilidade com outros sistemas operacionais. Sistemas

luffy@ubuntu:~$ adb shell shell@android:/ $ ll drwxr-xr-x root root 2013-10-13 13:50 acct drwxr-xr-x root root 1969-12-31 21:00 bootimages drwxrwx--- system cache 2013-10-13 14:53 cache drwxr-xr-x root root 1969-12-31 21:00 chargerimages dr-x------ root root 2013-10-13 13:50 config lrwxrwxrwx root root 2013-10-13 13:50 d -> /sys/kernel/debug drwxrwx--x system system 2013-10-13 20:28 data -rw-r--r-- root root 121 1969-12-31 21:00 default.prop drwxr-xr-x root root 2013-10-13 13:50 dev drwxrwx--- drm system 2013-10-13 13:50 drm drwxrwx--x system system 2013-10-13 13:50 dvp lrwxrwxrwx root root 2013-10-13 13:50 etc -> /system/etc -rwxr-x--- root root 125024 1969-12-31 21:00 init -rwxr-x--- root root 39349 1969-12-31 21:00 init.blackg.rc -rwxr-x--- root root 10031 1969-12-31 21:00 init.blackg.usb.rc

31

Windows da Microsoft, distribuições Linux e o MAC OS X trabalham bem com

esse sistema de arquivos (Android Forensics, 2011).

No Linux partições FAT32 são chamadas de VFAT e se tratando do Android

existem três lugares que usam esse sistema de arquivos (Android Forensics,

2011):

/mnt/sdcard

/mnt/secure/asec

/mnt/emmc

A partição /mnt/secure/asec é criptografada pois nela podem ser gravados os

apps do sistema. Quando a funcionalidade de armazenar um app no SDCard

foi introduzida ao Android adotaram esta solução de encriptação porque as

permissões dos arquivos não são mantidas no FAT32, e isso implica na

possibilidade de acessar os dados da aplicação (Android Forensics, 2011).

A partição SDCard é a partição do usuário. Contém geralmente fotos, vídeos,

arquivos baixados, arquivos temporários e dados de navegação do Google

Maps.

A partição /mnt/emmc é uma parte da memória interna formatada com o

sistema de arquivos FAT32. Alguns dispositivos não tem suporte a cartões de

memória, como o Google Nexus 4 por exemplo. Então contam com uma

memória interna de maior capacidade e a dividem entre sistema operacional,

aplicativos e dados do usuário.

2.5.2 YAFFS2

O YAFFS2 (Yet Another Flash File System) é um sistema de arquivos

opensource desenvolvido especialmente para memórias flash NAND licenciado

sob a GPL (GNU Plublic License). Sendo um sistema desenvolvido para

memórias flash, algumas das importantes características que o YAFFS2 possui

são (Android Forensics, 2011):

Sistema de arquivos de log estruturado (prevenção contra interrupção de

energia)

32

Correção de erros

Capacidade para lidar com setores defeituosos

Rápido e utiliza pouco da memória RAM

Como o seu uso é limitado ao SO Android, não existem ferramentas

(comerciais ou opensource) que suportem esse sistema de arquivos.

Uma particularidade das memórias do tipo NAND flash é que, quando um

arquivo é atualizado sua versão anterior não é imediatamente apagada porque

a memória não permite reescrita (primeiro é preciso apagar todos os blocos de

memória – como num processo de preparação), assim, enquanto não for

executado o garbage collector, o arquivo permanecerá num diretório oculto e

será possível recuperá-lo, apenas não será apresentado pelo sistema (Android

Forensics, 2011).

2.5.3 Partições do Sistema de Arquivos

O sistema de arquivos do Android é dividido em três partes principais:

A partição do sistema /system/: onde ficam as aplicações pré-

instaladas, bibliotecas, Linux kernel, Android framework e etc.

A partição SDCard /sdcard/: que é uma partição livre, onde todos os

aplicativos podem gravar dados e ler dela, bastando ter a permissão

WRITE_TO_EXTERNAL_STORANGE.

A partição de dados do usuário /data/: onde podem estar aplicações,

arquivos do usuário como músicas, vídeos e documentos. Para um

perito, um dos diretórios mais importantes desta partição é o

(/data/data/), onde ficam as bases de dados das aplicações. Neste

diretório as aplicações são separadas pelo nome do pacote e passam

ter a estrutura descrita na tabela abaixo (Learning Android, 2011):

33

Tabela 6 – Estrutura do diretório /data/data/<ApplicationPackageName>

Nome do diretório Descrição do conteúdo

shared_prefs Dados compartilhados da aplicação

lib Bibliotecas requeridas pela aplicação

files Arquivos salvos pelo desenvolvedor

cache Arquivos de cache da aplicação. Como os utilizados

pelos navegadores web

databases Banco de dados SQLite

Fonte: (Android Forensics, 2011).

Na tabela 6 estão listados os diretórios principais que todo App passa a ter

após a sua instalação.

2.5.4 Formas de Persistência de Dados

O Android provê aos desenvolvedores cinco formas de armazenar informação:

Preferencias compartilhadas

Armazenamento interno

Armazenamento externo

SQLite

Network

Preferencia Compartilhadas permitem o desenvolvedor armazenar um par

chave-valor de tipos primitivos (boolean, float, int, long e cadeias de caracteres

- strings) em um formato simplificado do XML (Android Forensics, 2011).

Figura 11 – Listagem do diretório shared_prefs do aplicativo Phone Fonte: O Autor (utilizando o Android ABD Tools para Linux Ubuntu).

A figura 11 mostra a listagem do diretório shared_prefs do app Phone, nativo

do próprio Android. Nos arquivos XML é possível ver o sistema de chave-valor

adotado:

shell@android:/ # ll /data/data/com.android.phone/shared_prefs/ -rw-rw---- radio radio 139 2013-10-12 09:26 PrefCallDuration.xml -rw-rw---- radio radio 126 2013-10-11 20:36 _has_set_default_values.xml -rw-rw---- radio radio 135 2013-10-11 20:36 com.android.phone_preferences.xml -rw-rw---- radio radio 827 2013-10-11 20:36 featureset.xml -rw-rw---- radio radio 230 2013-10-11 20:37 siminfo.xml -rw-rw---- radio radio 482 2013-10-11 20:37 telephony.xml

34

Figura 12 – Arquivo XML do tipo chave-valor Fonte: O Autor.

O Armazenamento Interno é feito no subdiretório de cada app na partição

/data/data e nele pode ser salvo arquivo de qualquer tipo. Por questões de

segurança, abordada em um capítulo posterior, o Android, por padrão, apenas

permite que a própria aplicação acesse seus dados, a seguir uma amostra dos

primeiros resultados da listagem deste diretório em um LG Optimus Black

(P970) (Android Forensics, 2011):

Figura 13 – Listagem do diretório data/data Fonte: O Autor (utilizando o Android ABD Tools para Linux Ubuntu).

O Armazenamento Externo trata dos dados que são salvos no SD Card do

dispositivo móvel. Por se tratar de um cartão removível, as restrições de

segurança são menos severas, por padrão, não é preciso permissão para

acessar os arquivos do cartão de memória. O formato do sistema de arquivos é

o FAT32 por ser um sistema já bastante difundido e facilitar a transferência de

dados do cartão para outro meio ou dispositivo (Android Forensics, 2011).

Além das informações salvas pelo próprio desenvolvedor do app, o Kernel do

Linux e o Android armazenam um registro de logs das atividades das

aplicações e do próprio sistema operacional (Android Forensics, 2011).

O SQLite é uma forma de fazer consultas a dados utilizando a linguagem SQL

mas em um arquivo local. Toda a base SQLite é tratada como um único

arquivo. Ele é de grande utilidade para os desenvolvedores de aplicativos

armazenarem informações de maneira estruturada localmente sem precisar

shell@android:/ # android.phone_preferences.xml < <?xml version='1.0' encoding='utf-8' standalone='yes' ?> <map> <string name="sim_iccid_value_key">89550311000182749434</string> </map> android.phone_preferences.xml < <?xml version='1.0' encoding='utf-8' standalone='yes' ?> <map> <string name="sim_iccid_value_key">89550311000182749434</string> </map>

shell@android:/ # ll /data/data/ drwxr-x--x app_87 app_87 2013-10-12 02:09 br.com.jr3 drwxr-x--x app_88 app_88 2013-10-12 02:09 ch.smalltech.ledflashlight.free drwxr-x--x app_76 app_76 2013-10-12 01:54 com.adobe.reader drwxr-x--x app_36 app_36 2013-10-11 20:36 com.android.LGSetupWizard drwxr-x--x app_4 app_4 2013-10-11 20:35 com.android.backupconfirm drwxr-x--x app_5 app_5 2013-10-13 00:34 com.android.bluetooth drwxr-x--x app_27 app_27 2013-10-11 20:37 com.android.browser drwxr-x--x app_7 app_7 2013-10-11 20:35 com.android.calculator2 drwxr-x--x app_9 app_9 2013-10-11 20:37 com.android.calendar drwxr-x--x app_28 app_28 2013-10-11 20:37 com.android.cellbroadcastreceiver drwxr-x--x app_11 app_11 2013-10-11 20:35 com.android.certinstaller drwxr-x--x app_12 app_12 2013-10-11 20:37 com.android.chrome drwxr-x--x app_2 app_2 2013-10-11 20:37 com.android.contacts drwxr-x--x app_13 app_13 2013-10-11 20:37 com.android.defcontainer

35

recorrer aos tradicionais RDBMS. Em geral, os bancos SQLite são

armazenados no diretório do aplicativo que o utiliza /data/data/<app name>,

mas não existe ,de fato, uma restrição que obrigue o desenvolvedor a cria-lo

neste local (Android Forensics, 2011).

Poucos apps utilizam este recurso, mas Armazenamento na Rede (Network)

está disponível via API do SDK do Android. Se uma conexão com a internet

está disponível, o app pode armazenar seus dados em um serviço web (SQLite

Documentation, 2013).

Em termos de desenvolvimento, para adicionar a capacidade de comunicação

a uma rede ao aplicativo Android, o desenvolvedor de fazer uso das classes

dos pacotes seguir:

java.net.*

android.net.*

Como referenciado na documentação, esses pacotes oferecem API de baixo

nível para interagir com redes, web services e outros (Android Forensics,

2011).

2.6 LOGS DO SISTEMA E DAS APLICAÇÕES

Arquivos de logs e depuração são dois métodos muito utilizados por

desenvolvedores para manter o controle de suas aplicações e tornar sua

manutenção mais efetiva. Os arquivos de logs guardam informações sobre as

atividades das aplicações enquanto executam e, embora nem sempre, é

possível extrair informações muito uteis destes arquivos. Para analista forenses

e especialistas em segurança é possível obter informações importantes de um

dispositivo Android, analisando os arquivos de logs e depuração dos aplicativos

e do próprio sistema (Android Forensics, 2011).

2.6.1 Log do Kernel do Linux

O Kernel do Linux controla todo o hardware e software de um computador,

alocando memória quando necessário e executando aplicativos quando

solicitado. Também é função do Kernel prover uma API de baixo nível para o

36

acesso ao hardware de um computador pelas aplicações do sistema. As quatro

responsabilidades primárias do Kernel Linux são (Linux Command Line and

Shell Script Bible, 2008):

Gerenciar a memoria do sistema

Gerenciar as aplicações do sistema

Gerenciar o hardware do dispositivo

Gerenciar o sistema de arquivos

Sendo o Kernel o centro de todas as atividades de um dispositivo, sua

capacidade de registrar eventos chaves é altamente desenvolvida. Os logs do

Kernel são acessíveis em um sistema Linux e também no Android pelo

comando dmesg. A seguir uma amostra das atividades registrada em log pelo

Kernel do Linux (Android Forensics, 2011):

Figura 14 – Saída do comando dmesg Fonte: O Autor (utilizando o Android ADB Tools para Linux Ubuntu).

Como pode ser visto na figura 14, as informações registradas no LG Optimus

Black (P970) são bastante detalhadas e de baixo nível, como a capacidade

momentânea da bateria.

127|shell@android:/ # dmesg 0:42.960] [wm9093.c] func:[wm9093_configure_path()], line:(1249), mode( 0) <4>[13:10:13 13:50:42.976] [wm9093.c] func:[wm9093_configure_path()], line:(1249), mode( 0) <6>[13:10:13 13:50:42.976] voice_configure_path(at twl4030).....path = 0, cur_twl_mode = 0 <4>[13:10:13 13:50:42.976] [wm9093.c] func:[wm9093_configure_path()], line:(1249), mode( 0) <4>[13:10:13 13:50:42.976] [wm9093.c] func:[wm9093_configure_path()], line:(1249), mode( 0) <4>[13:10:13 13:50:44.546] STA connect received 1 <4>[13:10:13 13:50:45.992] [BATTERY] +++ vol:4028, chr:1, muic:8, temp:280, cap:85 <4>[13:10:13 13:50:45.992] [BATTER] cap:85 , muic:8 <4>[13:10:13 13:50:45.992] [BATTER] cap:85 , muic:8 <4>[13:10:13 13:50:45.992] [BATTERY] +++ vol:4028, chr:1, muic:8, temp:279, cap:85 <4>[13:10:13 13:50:46.000] [BATTER] cap:85 , muic:8 <4>[13:10:13 13:50:46.140] [BATTER] cap:85 , muic:8 <4>[13:10:13 13:50:47.976] [wm9093.c] func:[wm9093_configure_path()], line:(1249), mode( 0) <7>[13:10:13 13:50:52.039] wlan0: no IPv6 routers present <4>[13:10:13 13:50:56.025] [BATTERY] +++ vol:4033, chr:1, muic:8, temp:281, cap:85 <4>[13:10:13 13:50:56.025] [BATTER] cap:85 , muic:8 <4>[13:10:13 13:50:56.025] [BATTER] cap:85 , muic:8 <4>[13:10:13 13:50:56.025] [BATTERY] +++ vol:4033, chr:1, muic:8, temp:281, cap:85 <4>[13:10:13 13:50:56.033] [BATTER] cap:85 , muic:8 <4>[13:10:13 13:50:56.049] [BATTER] cap:85 , muic:8 <4>[13:10:13 13:50:58.150] [bd2802_store_led_onoff] value = 0 <4>[13:10:13 13:50:58.158] LED OFF

37

logcat

Uma ferramenta bastante útil para análise das atividades do Android é logcat.

Com ela é possível visualizar os logs de atividades num fluxo constante, uma

pequena amostra das informações providas pela ferramenta pode ser vista a

seguir (Android Forensics, 2011):

Figura 15 – Saída do comando logcat Fonte: (Android Forensics, 2011).

Nesta saída, exibida na figura 15, é possível obter informações como longitude

e latitude, informações de data e hora e detalhes dos apps em execução. Cada

linha de log começa com uma letra que descreve seu nível. A tabela abaixo

mostra a relação entre as letras e os níveis de log:

Tabela 7 – Níveis de log

Nível de Log Descrição

V Verboso

D Debug

I Informação

W Aviso

E Erro

F Fatal

S Silent Fonte (Android Forensics, 2011).

A ferramenta logcat também suporta alguns parâmetros de linha de comando

que filtram e auxiliam a obtenção de logs específicos. O parâmetro –b, por

exemplo, faz a filtragem do log principal de acordo com o filtro passado depois

dele. É possível utilizar outros filtros ou mesmo fazer um dump do arquivo de

log naquele momento. A tabela 8 mostra os comandos e opções que podem

ser utilizados com o logcat:

ahoog@ubuntu:~$ adb shell logcat I/HtcLocationService( 308): agent - search location by name: oak park, country: united states, state: illinois I/HtcLocationService( 308): agent - no location was found, total: 0 D/AutoSetting( 308): service - CALLBACK - onGetTimeZoneOffset, result: failed, zoneId: , offset: 0 D/LocationManager( 308): removeUpdates: listener = com.htc.htclocationservice.HtcLocationServiceAgent$7@45dfc770 V/AlarmManager( 97): Adding Alarm{463aea28 type 2 com.google.android.location} Jan 05 05:05:25 pm I/HtcLocationService( 308): agent - send current location notify intent, name: Oak Park, state: Illinois, country: United States, lat: 41.8786, lng: -87.6359,tzid:

38

Tabela 8 – Opções de comando de linha do logcat

Opção Descrição

-b <buffer Carrega um buffer alternativo para visualização de logs de evento e radio.

-c Limpa e descarrega todo o log.

-d Faz o dump do log no instante atual

-f <filename> Escreve a saída do log no arquivo passado como parâmetro. O padrão é o prompt

-g Imprime o tamanho do log

-n <count> Configura o número máximo de mudança do log.

-r <kbytes> Muda o buffer de log a cada <kbytes>

-s Configura o filtro padrão para silente

-v <format> Configura o formato da saída do log. O padrão é o formato brief.

Fonte: (Android Developers, 2013).

Combinado o logcat com os comandos da tabela acima pode fornecer

informações importantes como:

Momento de ocorrência dos eventos

Endereço IP do celular, rede e informações de localização

Tipo de encode utilizado nas mensagens SMS

dumpsys

Outra ferramenta de análise de logs é a dumpsys. Com ela é possível obter

informações a cerca de serviços em execução, utilização da memória e outros

detalhes do sistema. A figura 16 mostra a saída (editada por questões de

espaço) do comando dumpsys executada em um LG Optimus Black (P970)

com a versão 4.0.4 do Android (Android Forensics, 2011):

39

Figura 16 – Saída do comando dumpsys Fonte: O Autor (utilizando o Android ADB Tools para Linux Ubuntu).

A saída de log acima revela informações importantes como:

Serviços em execução

Dump de cada serviço

Informações como memoria, ID e database de cada processo

O que é útil para determinar não apenas qual serviço está executando mas

também qual database ele usa.

dumpstate

O comando de debug dumpstate combina partes dos comandos apresentados

com informações do sistema. A sintaxe e a saída (editada por questões de

espaço) do comando executado em um LG Optimus Black (P970) com a

versão 4.0.4 do Android são apresentadas na figura 17:

luffy@ubuntu:~$ adb shell dumpsys Currently running services: Bridges SUPL_SERVICE SurfaceFlinger WifiExtHMService accessibility account ------------------------------------------------------------------------------- DUMP OF SERVICE accessibility: ------------------------------------------------------------------------------- DUMP OF SERVICE account: Accounts: 4 Account {name=Phone, type=com.lge.sync} Account {name=valdemirvjr@gmail.com, type=com.facebook.auth.login} Account {name=valdemirvjr@gmail.com, type=com.dropbox.android.account} Account {name=valdemirvjr@gmail.com, type=com.google} Active Sessions: 0 ** MEMINFO in pid 1716 [com.gtp.nextlauncher.liverpaper.honeycomb] ** Shared Private Heap Heap Heap Pss Dirty Dirty Size Alloc Free ------ ------ ------ ------ ------ ------ Native 1900 1296 1852 16812 14599 248 Dalvik 2758 11460 2364 13447 10078 3369 Cursor 0 0 0 Ashmem 2 4 0 Other dev 10321 376 780 .so mmap 670 2148 416 .jar mmap 0 0 0 .apk mmap 0 0 0 .ttf mmap 0 0 0 .dex mmap 176 0 0 Other mmap 221 8 28 Unknown 6758 4532 6604 TOTAL 22806 19824 12044 30259 24677 3617

40

Figura 17 – Saída do comando dumpstate Fonte: O Autor (utilizando o Android ADB Tools para Linux Ubuntu).

O comando precisa ser executado ser executado como root, caso contrário

não mostrará todas as saídas possíveis. A saída do comando é dividida em

várias sessões, como registro de atividades das aplicações, informações sobre

o dispositivo, rede, kernel e outros.

2.6.2 Logs dos Apps

Além dos logs gerados pelo Kernel do Linux e pelo próprio Android, os

desenvolvedores de aplicativos também costumam adicionar a suas aplicações

a capacidade de gerar os seus próprios arquivos de logs. Esses arquivos são

bastante úteis quando há necessidade de obter informações sobre um app

específico.

Um dos serviços de armazenamento de dados em uma plataforma de Cloud

Computing mais utilizados é Dropbox. A estrutura de seu diretório é

apresentada na figura 18:

shell@android:/ # dumpstate ======================================================== == dumpstate: 2013-10-13 20:45:20 ======================================================== Build: IMM76L.P970h30a-SCA-XXX.4DAB73BC Bootloader: unknown Radio: unknown Network: TIM 11 Kernel: Linux version 3.0.8 (elisandro.vidotto@openos-ubuntu) (gcc version 4.4.1 (Sourcery G++ Lite 2010q1-202) ) #1 PREEMPT Fri Mar 8 19:45:35 BRT 2013 Command line: rs=s mem=512M init=/init videoout=omap24xxvout omap_vout.video1_numbuffers=6 omap_vout.vid1_static_vrfb_alloc=y vram=16M omapfb.vram=0:5M lpj=2334720 fuelgauge=g androidboot.hardware=blackg muic_state=0 thermal_fakemode=0 CRC=0x8dd118f7 ------ UPTIME (uptime) ------ up time: 06:55:22, idle time: 06:25:10, sleep time: 00:00:00 [uptime: 0.1s elapsed] ------ MEMORY INFO (/proc/meminfo) ------ MemTotal: 447856 kB MemFree: 11760 kB Buffers: 2372 kB Cached: 60876 kB SwapCached: 0 kB Active: 317140 kB Inactive: 32636 kB Active(anon): 289284 kB Inactive(anon): 360 kB Active(file): 27856 kB Inactive(file): 32276 kB ------ CPU INFO (top -n 1 -d 1 -m 30 -t) ------

41

Figura 18 – Listagem do diretório do app Dropbox Fonte: (Android Forensics, 2011).

É possível ver a existência do arquivo log.txt abaixo do diretório files.

Visualizando o conteúdo do arquivo tem-se:

Figura 19 – Visualização do arquivo de logs do app Dropbox Fonte: (Android Forensics, 2011).

A partir do seu conteúdo é possível concluir que houve uma tentativa bem

sucedida de autenticação e pelo resto do log (não mostrado acima), é possível

ver que o serviço foi interrompido por uma chamada telefônica (Android

Forensics, 2011).

2.7 GOOGLE PLAY

O Google Play nasceu da unificação entre Google Music, Google Books Store

e o Android Marketplace. Este último, tinha o objetivo de prover um canal

seguro para os usuários do sistema instalarem seus aplicativos (Learning

Android, 2011).

O Google Play (Android Marketplace) em si é um aplicativo. Por ele é possível

obter informações e atualizações dos aplicativos. O Google tornou o processo

de publicação de apps bastante simples. Para disponibilizar um aplicativo no

Google Play, sendo uma empresa ou desenvolvedor autônomo, é preciso: criar

uma conta de desenvolvedor no Google, pagar uma taxa e concordar com os

termos de serviço (Hashimi, Komatineni, 2010).

ahoog@ubuntu:~/htc-inc/data/data$ tree com.dropbox.android/ com.dropbox.android/ ├── databases │ └── db.db ├── files │ └── log.txt ├── lib └── shared_prefs └── DropboxAccountPrefs.xml

ahoog@ubuntu:~/com.dropbox.android$ cat ./files/log.txt 5 1296055108427 com.dropbox.android.provider.DatabaseHelper Creating new Dropbox database. 4 1296055108459 com.dropbox.android.DropboxApplication Not authenticated, so authenticating 4 1296055108466 com.dropbox.android.DropboxApplication No stored login token. 4 1296055108702 com.dropbox.android.DropboxApplication Not authenticated, so authenticating 4 1296055108704 com.dropbox.android.DropboxApplication No stored login token. 4 1296055108704 com.dropbox.android.activity.SimpleDropboxBrowser Didn't authenticate, redirecting to login 4 1296055108713 com.dropbox.android.DropboxApplication Not authenticated, so authenticating 4 1296055108714 com.dropbox.android.DropboxApplication No stored login token. 4 1296055134550 com.dropbox.android.DropboxApplication Authenticating username: book@viaforensics.com 4 1296055136507 com.dropbox.android.DropboxApplication Successfully authenticated 6 1296055137501 com.dropbox.android.activity.LoginActivity Dismissed nonexistent dialog box 4 1296055137525 com.dropbox.android.activity.LoginOrNewAcctActivity Successful account login 4 1296055137549 com.dropbox.android.activity.delegate.MenuDelegate Successful Login

42

CAPÍTULO 3. SEGURANÇA NO SISTEMA OPERACIONAL ANDROID

3.1 INTRODUÇÃO

Nas iterações entre aplicações clientes e servidoras a segurança não fica

restrita apenas a rede como configuração de firewall, detecção de intrusos,

antivírus e outros. Os desenvolvedores de aplicativos também devem tomar

todas as medidas para tornar os seus aplicativos seguros na transmissão e

armazenamento local de informações de seus usuários (Applications Security

for the Android Platform Processes, 2012).

A arquitetura do Android já promove um modelo de segurança mais forte do

que o convencional (que atribui a aplicação o mesmo nível de acesso do

usuário que a instalou) e, no campo da análise forense, conhecer os

mecanismos de segurança existentes e os que precisam ser implementados,

bem como os métodos para “burlar” esses bloqueios são de grande

importância para a obtenção de dados e posterior análise.

3.2 PERMISSÃO POR APLICAÇÃO

Nos sistemas operacionais para desktops as aplicações executam sob a conta

do usuário que as iniciou, e recebe o mesmo nível de acesso daquela conta de

usuário. Outra característica é que todos os aplicativos executados por uma

conta de usuário tem o mesmo nível de acesso as APIs do sistema, assim um

editor de texto e um aplicativo de mensagens instantâneas terão o mesmo nível

de acesso a uma conexão internet porque executam sob o mesmo UID. Se o

usuário tem acesso total ao sistema, seus aplicativos também o terão. Esta é a

principal características dos SOs para desktops: aplicativos recebem o mesmo

nível de acesso ao sistema que o usuário que os executou (Applications

Security for the Android Platform Processes, 2012).

No Android, visando à segurança do usuário a modelo de permissões é

diferente. Antes de uma aplicação ser instalada é verificada a assinatura digital

do desenvolvedor que, diferente do SSL, não precisa de uma Autoridade

Certificadora, mas o desenvolvedor precisa manter a chave segura,

principalmente nos casos de apps bancários. Nesses casos, se chave fosse

publicada, um update do aplicativo, feito por uma pessoa mal intencionada e de

43

posse da chave, poderia comprometer os dados do usuário (Android

Forensics).

Em seguida, o arquivo .apk é validado e o arquivo que especifica quais os

acessos que aplicação precisa (contatos telefônicos, mensagens SMS,

conexão internet e outros) é verificado e apresentado ao usuário que deve

aprovar cada uma das solicitações, caso contrário o aplicativo não é instalado.

A diferença no modelo de segurança do Android está em que, após a

instalação do App, é atribuído um usuário e grupo Linux único para a aplicação

e esta executa em seu próprio processo e instância da Dalvik VM (que é

otimizada para este comportamento). Esse modelo assegura o não

compartilhamento de memória, permissões e dados gravados em disco. Assim,

as aplicações acessam apenas os dados e memória de sua própria Dalvik VM

(Android Forensics, 2011).

No caso de aplicações de um mesmo desenvolvedor que precisam

compartilhar informações (Facebook e Facebook Messenger, por exemplo)

este modelo pode ser alterado. O desenvolvedor pode assinar os dois

aplicativos com a mesma assinatura. Neste caso, o processo, a instância da

Dalvik VM, a memória e as informações salvas serão compartilhadas entre os

aplicativos (Android Forensics, 2011).

44

Figura 20 – Instalação dos Apps Google Maps e Gmail respectivamente Fonte: (Android Developers, 2013).

A vantagem do modelo de permissão do Android sobre os dektops fica

evidente no caso de um ataque a um app do sistema, pois nesse caso o

atacante apenas poderia fazer o que o app tem permissão para fazer, diferente

do caso de um ataque a um browser de um sistema desktop onde o atacante

teria todos os privilégios do usuário que iniciou o ataque (Applications Security

for the Android Platform Processes, 2012).

Claro, a maioria dos usuários não lê a requisição de acesso que app faz e

aprova tudo o que é pedido, ainda mais se for um jogo. Por isso grande parte

dos malwares existentes para Android se aproveitam deste ponto fraco, o

usuário, para conseguir diversas permissões.

Todas as permissões que uma aplicação precisa devem ser especificadas no

arquivo Manifest.xml. Por exemplo, uma aplicação que precise monitorar as

mensagens SMS recebidas o faria desta forma:

Figura 21 – Visualização da permissão de acesso no Manifest.xml Fonte: (Android Developers, 2013).

<manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.android.app.myapp" > <uses-permission android:name="android.permission.RECEIVE_SMS" /> ... </manifest>

45

O Android possui uma série de Strings para permissões do sistema (todas

começam com android.permission, além das que podem ser criadas pelo

próprio desenvolvedor), no momento da instalação o arquivo Manifest.xml é

lido e uma lista de requisições é gerada e apresentada ao usuário, se o usuário

recusar uma, todo o processo de instalação falha (Android Developer, 2013).

O sistema de permissões do Android é dividido em quatro categorias

principais:

O grupo Normal compreende as permissões que não precisam da

intervenção do usuário para serem atribuídas ao app.

As do grupo Dangerous são as que representam algum tipo de risco ao

usuário e ao sistema em si, como acesso a internet e dados pessoais do

usuário. Estes permissões são explicitamente solicitadas ao usuário no

momento da instalação do app.

A categoria de permissão Signature é um modo de identificar o autor do

código, verificar se o app foi alterado e estabelecer a confiança entre os

aplicativos. Um certificado digital é gerado e o app é assinado com ele,

desta forma dois apps com o mesmo certificado digital podem

compartilhar informações de forma segura, e não há necessidade de

intervenção do usuário para autorizar o acesso de um app ao outro.

SignatureOrSystem que se diferencia da Signature pela permissão ser

adicionada ao Android. Este modo é utilizado por fabricantes para

permitir que apps desenvolvidos por diferentes empresas trabalhem em

conjunto com o fabricante. Este tipo de permissão não é recomendada

(Applications Security for the Android Platform Processes, 2011).

Caso um app forneça algum tipo de serviço a outros apps e o desenvolvedor

deseje restringir o acesso e este serviço, ele precisa declara esta permissão no

Manifest.xml desta forma:

46

Figura 22 – Restrição de acesso no Manifest.xml Fonte: (Android Developers, 2013).

O bloco de XML acima define a permissão DEADLY_ACTIVITY como

pertencente ao pacote com.me.app.myapp.permission. O atributo

protectionLevel foi configurado como DANGEROUS que é o tipo de permissão

apropriada (Application Security for the Android Platform Processes, 2012).

O resultado de todas essas barreiras é que o Android possui um sistema

seguro para isolar as informações de seus aplicativos e não há uma maneira

simples para os analistas forenses extraírem as informações (Android

Forensics, 2011).

Por ultimo, os usuários do Android tem a opção de instalar apps de fontes que

não o Google Play. Essa opção pode ser acessada pelo menu de opções da

aplicação nas configurações do sistema (Android Forensics, 2011).

<manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.me.app.myapp" > <permission android:name="com.me.app.myapp.permission.DEADLY_ACTIVITY" android:label="@string/permlab_deadlyActivity" android:description="@string/permdesc_deadlyActivity" android:permissionGroup="android.permission-group.COST_MONEY" android:protectionLevel="dangerous" /> ... </manifest>

47

Figura 23 – Aviso do Android sobre fontes desconhecidas Fonte: O Autor (utilizando o AVD versão para Windows).

Após assinalar a opção para permitir a instalação de apps de outras fontes, o

Android exibe um aviso sobre os riscos envolvidos na operação como na figura

anterior. Instalar Apps de uma fonte que não seja o Google Play faz com que o

Android pule a etapa de validação da assinatura digital (Android Forensics,

2011).

3.3 VULNERABILIDADES NO ARMAZENAMENTO DE INFORMAÇÕES

Os apps podem trocar informações ente eles, e com as APIs de acesso é

possível dizer quais informações podem ser acessadas. Assim é aceitável

esperar que todo o tráfego de informações ocorra pelos canais controlados

pelo sistema mas existem outras formas de acessar informações

sensíveis(Applications Security for the Android Platform Processes, 2011).

Algumas informações são armazenadas na memória interna do dispositivo,

estes dispositivos frequentemente oferecem suporte para cartões de memória

onde também é possível instalar apps. Esses meios de armazenamento podem

ser acessados de um PC bastando retirá-los do dispositivo e plugar no

48

computador(o acesso à memória interna do aparelho também é simples), e

assim ter acesso às informações de um determinado app sem que o controle

de segurança do sistema interfira. Outra forma de acessar a informação

desejada é conseguir acesso de root (tarefa não muito difícil). Esse modo provê

acesso irrestrito ao sistema e a memória.

Com base no exposto acima, seguir o Princípio do Privilégio Mínimo

(armazenando apenas as informações necessárias para o funcionamento do

app), configurando as permissões corretamente (assim outros apps não terão

acesso as informações em tempo de execução do sistema), e criptografando

os dados (em caso de acesso off line as informações, o atacante não poderá

fazer nada) são conhecido como Defense in Depth (DiD) (Applications Security

for the Android Platform Processes, 2011).

3.4 PROTEÇÃO DOS DADOS NO ANDROID

Como foi visto antes, cada app no Android executa sob sua própria conta de

usuário. Isto evita que uma aplicação tenha acesso às informações de outra.

Esta proteção oferecida pelo sistema geralmente não suficiente, de modo que,

as informação de autenticação de um app de sistema bancário, que estão

armazenadas, precisam estar criptografadas para oferecer uma proteção

adicional.

3.4.1 Bloqueio de Tela

O Android oferece algumas proteções básicas contra o acesso não autorizado

as informações do sistema, a primeira barreira é o bloqueio de tela. O sistema

oferece algumas opções para isso como: reconhecimento facial, desenho de

um padrão, código PIN (código numérico de4 dígitos) ou senha alfanumérica. A

segurança aumenta nesta ordem.

49

Figura 24 – Tela de configuração de bloqueio do Android

Fonte: (ghacks, 2012).

Figura 25 – Bloqueio de tela por código pin, desenho de padrão e senha alfanumérica respectivamente. Fonte: O Autor (utilizando o AVD versão para Windows).

Pela figura 25 vemos que o código pin se trata de uma combinação numérica

de quatro números (de 0 a 9) que podem se repetir, em um total de 10.000

combinações possíveis, um bloqueio muito fraco. O pattern lock se trata de

desenho onde é possível uma combinação de até nove posições, sendo que

50

cada elemento da combinação pode aparecer apenas uma vez na sequência.

O que gera um total de 9! combinações possíveis, ou 362 880 combinações,

algo não muito difícil de ser quebrado com um computador de mesa. Logo, o

método mais efetivo para bloqueio de tela é a senha alfanumérica.

3.4.2 Criptografia de Dados

Caso as informações contidas no dispositivo sejam muito sensíveis é possível

criptografá-los. É possível criptografar contas de usuário, configurações, apps,

arquivos de media ou qualquer outro tipo de arquivo, uma vez que os dados

sejam criptografados não será possível acessá-los sem entrar com a chave de

criptografia, que é solicitada toda vez que o Android é ligado.

Figura 26 – Tela de opção para criptografar os dados do dispositivo

Fonte: (ghacks, 2012).

51

Um dos riscos envolvidos nesta operação é o fato dela ser irreversível, assim

se o processo for interrompido na metade ou por falta de bateria ou porque o

usuário mudou de ideia os dados serão perdidos.

Figura 27 – Criptografia dos dados: telas de aviso e confirmação respectivamente

Fonte: (ghacks, 2012).

Assim que o processo terminar, será solicitada a senha utilizada na operação.

3.5 SEGURANÇA NA TRANSMISSÃO DE INFORMAÇÕES

No item anterior foi abordada a segurança dos dados no próprio dispositivo,

neste tópico será discutida a segurança dos dados transmitidos pela rede para

outras partes como uma aplicação servidora com quem frequentemente um

app do Android interage. Os dois princípios básicos a considerar quando uma

informação é transmitida de um sistema a outro são: Autenticação e

Confidencialidade. A Autenticação serve para assegurar que a parte que irá

receber os dados é quem realmente diz ser. Já a confidencialidade trata de

prevenir que uma terceira entidade intercepte os dados transmitidos

(Applications Security for the Android Platform Processes, 2011).

52

O padrão utilizado pela indústria para o transporte de dados de maneira segura

pela Internet é o SSL (Secure Sockets Layer) e TLS (Transport Layer Secure).

Esses protocolos foram desenvolvidos para proteger os dados transportados e

permitir que o cliente autentique o servidor com quem ele conversa. A maioria

das aplicações exige que o login e senha do usuário sejam enviados a cada

requisição e, mesmo que seja por um canal criptografado, esta não é a melhor

solução. A classe AccountManager permite que a aplicação envie um token

junto com as requisições, este token muda periodicamente o que passa a ser

uma forma mais segura de autenticação (Applications Security for the Android

Platform Processes, 2012).

3.5.1 Autenticação no protocolo SSL/TLS

O objetivo do protocolo SSL é permitir que o cliente verifique a autenticidade do

servidor com o qual se comunica. Uma aplicação cliente não pode apenas

confiar no IP (hostname) que requisita e esperar que o servidor que atenda

seja verdadeiro pois existem técnicas para desviar uma chamada de um

hostname para outro. Para contornar essa situação, o SSL/TSL usa uma chave

de criptografia assimétrica para promover a autenticação. No primeiro passo, o

servidor envia o seu certificado digital ao cliente, neste certificado estão o nome

do servidor e da autoridade certificadora (CA). O cliente prossegue com a

validação do certificado e após esta é gerado pelo cliente um número aleatório

que é criptografado pelo cliente com a chave publica descrita no certificado

digital e enviada ao servidor durante o handshake. A partir deste momento a

comunicação entre as duas partes ocorre usando este número como chave

simétrica de criptografia para as informações transitadas. Para a validação dos

certificados o Android possui uma lista de autoridades certificadoras e iniciar

uma comunicação segura com uma delas exige muito pouca codificação

(Applications Security for the Android Platform Processes, 2012).

3.5.2 Transmissão dos Dados

O Android possui uma configuração para conexões SSL/TLS bastando fazer a

chamada openConnection() da classe HttpsUrlConnection como mostrado na

figura 28:

53

Figura 28 – Exemplo de configuração de conexão SSL/TLS Fonte (Applications Security for the Android Platform Processes, 2012).

Após obter a conexão segura com o servidor é possível examinar algumas

informações sobre ela através de alguns métodos uteis da classe

HttpsURLConnection como:

getCypherSuite() que retorna o algoritmo criptográfico utilizado na

conexão. Pode ser usado para medir a segurança da conexão.

getServerCertificates() que retorna um vetor com todos os certificados

fornecidos pelo servidor. Permite ao desenvolvedor checar a validade

destes junto a um CA (que o Android reconhece).

3.6 AMEAÇAS NA TRANSMISSÃO DE DADOS

Aplicações Web precisam de muito cuidado com os dados enviados a elas pois

aceitar dados que não fazem parte do conjunto esperado configura uma brecha

de segurança e pode trazer diversos danos à aplicação servidora, como SQL

injection, cross-site scripting attacks e exploração de buffer overflow, por

exemplo. Aplicações cliente como as do Android não suscetíveis a estas falhas

mas não estão imunes a elas. Assim, um dos princípios de um

desenvolvimento seguro é validar os dados fornecidos pela aplicação e

enviados a ela, pois um App que esta sujeito a receber informações de fontes

externas pode acabar sendo manipulado por um atacante (Applications

Security for the Android Platform Processes, 2012).

3.7 MALWARE

Os malwares que tem como alvo o SO Android são similares e ao mesmo

tempo muito diferentes dos malwares que atacam o Windows. Desde o seu

lançamento em 2008, o Android vem crescendo rapidamente como uma

plataforma open source para smartphones, com rápido aumento no poder de

processamento e memória além da adição de componentes como câmera,

URL url = new URL("https://clientaccess.example.com"); HttpsURLConnection urlConn = (HttpsURLConnection)url.openConnection();

ou

HttpsURLConnection urlConn = new HttpsURLConnection("https://clientaccess.example.com");

54

internet e GPS. Com isso, era apenas uma questão de tempo para que os

hackers dirigissem sua atenção para esses dispositivos(Android Malware

Exposed, 2012).

Outra razão para atacar smartphones Android é que o fato dos usuários terem

mais informações pessoais salvas nele do que em um PC. Quando um usuário

se autentica no serviço de e-mail ou no Facebook através do smartphone ele

não precisará mais repetir o processo porque sua senha está salva no

dispositivo. Essa funcionalidade é conveniente não apenas para os usuários

mas também para os hackers que estarão atrás desta informação (Android

Malware Exposed, 2012).

O primeiro malware para Android foi descoberto em 2010, desde então a

empresa de segurança Webroot já identificou mais de 13000 exemplos de

malware para o Android. Sendo o Android desenvolvido sobre o kernel do

Linux, ele cria um usuário e grupo Linux para cada aplicação, como já

explicado, a fim de impedir o acesso dos dados de uma aplicação por outra.

Sendo assim, a forma de uma aplicação ter acesso às informações de login do

usuário no Facebook ou ao serviço de SMS do dispositivo é se o usuário

permitir no momento da instalação, e é nesse iteração com o usuário que a

maior parte dos malwares ataca (Android Malware Exposed, 2012).

55

CAPÍTULO 4. FORENSE DIGITAL NO ANDROID

4.1 INTRODUÇÃO

A plataforma móvel Android cresceu rapidamente desde o lançamento, em

Outubro de 2008, até torna-se o sistema operacional móvel mais popular no

inicio de 2011. Contudo, os analistas forenses e engenheiros de segurança têm

lutado contra a falta de ferramentas e técnicas para investigar os dispositivos

com esse sistema (Android Forensics, 2011). Existem técnicas e abordagens

muito bem documentadas e difundidas para telefones celulares e desktops,

mas essas técnicas não se aplicam em sua totalidade quando associadas a

exames de smatphones, uma vez que nesses dispositivos, as soluções de

hardware e software são minimalistas e o sistema operacional possui suporte à

utilização de memórias internas cuja remoção ou espelhamento são

procedimentos considerados invasivos e com maior grau de complexidade,

devido às dificuldades de acesso direto ao hardware. Além disso, os

dispositivos possuem características específicas para cada versão e fabricante

do hardware (Aquisição de Evidências Digitais em Smatphones Android, 2011).

Conforme a capacidade de armazenamento de dados dos dispositivos

aumentou, a quantidade de informações salvas neles também aumentou e,

muito dessa informação interessa a organizações criminais que promovem

ataques a plataforma com o intuito de obter as informações pessoais de seus

usuários e empresas. Solucionar este impasse requer um profundo

entendimento da plataforma, não só dos desenvolvedores do sistema ou dos

fabricantes mas, também, dos desenvolvedores de apps e das agências de

segurança. Apps mais seguros junto com politicas de segurança mais fortes

irão prevenir a perda ou roubo de dados sensíveis de seus usuários (Android

Forensics, 2011).

Isso mostra a necessidade da forense no Android. A maioria das pessoas está

sempre muito próxima de sues smatphones, mesmo quando estão dormindo. O

dispositivo armazena tanto informações pessoais como corporativas salvas na

forma de mensagens de texto, e-mails, localização de GPS, imagens, vídeos e

outros. E há uma tendência das pessoas serem mais honestas com o próprio

56

dispositivo do que com outras pessoas. Simplesmente por acreditarem que ele

é seguro (Android Forensics, 2011).

Mesmo o Android sendo lembrado pelos smartphones e tablets, atualmente

existem vários dispositivos que rodam o sistema ou irão fazê-lo em um futuro

próximo. E tanto a forense de dispositivos móveis como do próprio Android tem

diversos desafios: na forense digital um princípio fundamental é prevenir

qualquer modificação no dispositivo pelo examinador. Isso é simples em discos

rígidos que podem ser desligados, conectados a outro equipamento e então

fazer uma imagem do mesmo. Mas no caso dos smartphones qualquer iteração

com o dispositivo irá alterá-lo de alguma forma e, nesse caso, os examinadores

deverão explicar como ele foi modificado e por que. Este capítulo apresenta

técnicas forenses para aquisição de dados de dispositivos com Android.

4.2 TIPOS DE INVESTIGAÇÃO

A primeira situação é a julgada num tribunal criminal. Nesta situação existem

algumas considerações:

Cadeia de custodia

Detalhamento e relatório final

Possível validação dos resultados usando ferramentas diferentes

Fato ou opinião baseada em testemunha

Outra situação é a das investigações corporativas. Elas também podem acabar

sendo julgadas em um tribunal mas frequentemente são utilizadas para

determinar a causa raiz de um problema (como um sistema, ataque externo ou

empregado interno - o que pode resultar em uma ação contra o empregado).

As áreas mais comuns nas investigações internas corporativas são:

Propriedade intelectual e roubo de dados

Uso inadequado dos recursos da empresa

Ataque ou tentativa bem sucedida contra os sistemas da empresa

Investigações sobre um empregado, incluindo a discriminação, assédio

sexual, etc.

Auditoria de segurança

Existe a situação envolvendo relações familiares:

57

Divorcio

Custódia de crianças

Disputa de propriedades

A ultima situação se refere a segurança governamental, onde a pericia forense

pode exercer um papel chave. Governos são os maiores empregadores nos

países, chegando a vários milhões em países como o Brasil.

Além das questões relacionadas aos empregados, governos são alvos de

ataques e roubo de dados por criminosos e governos estrangeiros. A perícia

forense pode ajudar na investigação dos ataques bem sucedidos e na

prestação de informações valiosas para a frustação de futuros ataques

(tradução nossa).

4.3 AMBIENTE DE TESTES

Os experimentos desta pesquisa utilizam ferramenta e scripts do mundo Unix,

assim, será utilizando a distribuição Linux Ubuntu 13.04 64 bit para Desktop.

Como já mencionado nesta pesquisa, para a análise forense, é necessário que

as configurações do dispositivo móvel que será analisado sejam mantidas

intactas, ou na pior hipótese, sejam modificadas ao mínimo possível e que essa

modificação seja devidamente justificada. Com base nisso, é importante que o

SO utilizado tenha a função automount desabilitada. No Ubuntu esta opção é

feita por usuário e pode ser modificada através do gconf com o comando

gconf-editor executado no terminal. Navegando até a opção

apps>nautilus>preference e desmarcando as opções “media_automount” e

“media_automount_open”.

O principio básico da investigação forense é evitar qualquer modificação do

dispositivo alvo. Em muitos casos isso é inviável. Nos caso de um computador

Desktop que está desligado, o perito vai simplesmente documentar o

computador, remover o disco rígido, conectá-lo a um write blocker e obterá

uma imagem bit-a-bit do disco. Nessa investigação o dispositivo original

permanece intacto. Continuando nos computadores Desktops, no caso do

equipamento estar ligado a situação começa a complicar: qualquer iteração

como desliga-lo irá modificar o dispositivo de alguma forma. Simplesmente

58

desligar o computador modifica o conteúdo de sua memória RAM, conexões de

rede abertas e outras informações serão perdidas.

No caso de dispositivos móveis é impossível realizar uma análise forense sem

modifica-lo. Ao contrário de desktops e notebooks, dispositivos Android

possuem partes de armazenamento que não podem ser facilmente removidas.

E iterações simples como ligar, desligar e recolocar a bateria modificam o

dispositivo.

Na primeira vez que os celulares apareceram nas investigações, havia uma

pequena quantidade de dados armazenada que podia ser extraída deles.

Muitos investigadores usavam técnicas tradicionais como uma permissão para

obter os dados de chamadas telefônicas na operadora de celular. Era possível

também remover o subscriber identity module (SIM) card de telefones GSM e

extrair algumas informações dele. Conforme os celulares foram evoluindo,

chegando ao categoria de smartphones, e consequentemente sua capacidade

de armazenamento, houve uma divisão entre os peritos sobre quais técnicas

utilizar durante a analise: os que defendiam a continuidade do uso da técnicas

tradicionais (com pequeno impacto no dispositivo e consequente menor

aquisição de informação) e os que defendiam uma analise mais completa mas

que ocasiona mudanças no dispositivo (Android Forensics, 2011).

A Association of Chief Police Officers (ACPO) do Reino Unido estabelece um

guia (Good Pratice for Computer-Based-Eletronic Evidence) com quatro

princípios que São listado abaixo(ACPO, 2013, tradução nossa):

1. Nenhuma ação realizada por policiais ou seus agentes deve modificar os

dados em um computador ou media de armazenamento que podem,

posteriormente, serem pedidos em um tribunal.

2. No caso em que um examinador julga necessário acessar os dados

originais de um computador ou media de armazenamento, esse

examinador deve ser competente para fazê-lo e capaz de explicar a

relevância e implicações de suas ações.

3. Um rastreamento da auditoria ou outra forma de registro de todos os

processos de análise aplicados a um computador para obter evidência

deve ser criado e preservado. Uma terceira parte independente deve ser

59

capaz de examinar os processos e arquivos e chegar a mesma

conclusão.

4. A pessoa encarregada da investigação tem a responsabilidade de

garantir que a lei e esses princípios serão respeitados.

4.4 PRESERVANDO O ESTADO DO DISPOSITIVEL MÓVEL

No caso de dispositivos móveis, que são relativamente novos, não existe ainda

um protocolo de ações que devem ser tomadas para preservar o estado

original do aparelho, uma das premissas da perícia forense. O que existe hoje

é uma tendência a partir diretamente para a análise dos dados, o que

frequentemente resulta em alteração das informações e potencial risco de

perdê-las. O que segue são alguns procedimentos para garantir a segurança

das informações contidas no dispositivo móvel (Android Forensics, 2011).

4.4.1 Passando pelo Bloqueio de Tela

Bloqueio de tela é um recurso de segurança muito popular no Android graças a

uma conscientização sobre a importância da segurança das informações,

especialmente nas empresas. Porém, nos casos em que o dispositivo móvel é

obtido ligado, alguns procedimentos devem ser tomados antes que a tela seja

bloqueada e um eventual pass code precise ser reinserido.

1. Aumentar o tempo de espera da tela, para o máximo possível, para

evitar o bloqueio da mesma. O modo de acessar a opção pode variar

conforme a versão do Android. Na versão 4 do Android ela é acessada

através das opções Lock Screen Setting -> Lock Timer.

2. Habilitar a depuração por USB e a opção “Stay Awake”. Estas podem

ser encontradas em Settings -> Developer Options. Depuração USB é

para possibilitar a extração de dados e a opção Stay Awake para evitar

que a tela seja bloqueada enquanto o dispositivo é recarregado.

Lembrando que estas são alterações da configuração original do aparelho e

que, por isso, devem ser devidamente documentadas e explicadas.

60

No caso dos dispositivos que são obtidos desligados ou com a tela bloqueada

é necessário passar pelo modo de proteção que esteja ativado, a seguir são

listadas as principais técnicas para desbloqueio da tela do Android.

Smudge Attack

No capítulo 4, Segurança no Sistema Operacional Android, foram apresentadas

algumas formas de bloqueio de tela para dispositivos móveis Android. Uma

delas era o desenho de um padrão (Draw pattern). Uma forma de passar por

este bloqueio é conhecido como Smudge Attack, um estudo realizado pelo

Departamento de Computação e Ciência da Informação da Universidade da

Pensilvânia, que consiste em fotografar a tela do dispositivo touch screen

(Smudge Attacks on Smartphone Touch Screens, 2011).

Figura 29 – Foto mostrando a marca do pattern desenhado. Fonte (Smudge Attacks on Smartphone Touch Screens, 2011)

O estudo diz que a superfície de tela touch screen limpa do dispositivo não é

totalmente reflexiva, e que uma manchada (pelo uso) não é totalmente difusa.

Essa mancha muitas vezes corresponde ao pattern desenhado pelo usuário

61

para desbloquear o aparelho. Assim, no experimento, algumas fotos foram

tiradas da tela do dispositivo quando uma fonte de luz era posicionada em um

ângulo não exatamente complementar e o resultado foi a visualização da

mancha que corresponde ao padrão desenhado para o desbloqueio da tela

(Android Forensics, 2011).

Modo de Recuperação

O modo de recuperação é comumente utilizado por usuário que instalam ROMs

customizadas (versões do sistema Android diferentes da originalmente

instalada no aparelho) que habilitam o root por meio da instalação de uma

partição modificada de recuperação. Esse modo faz com que o bloqueio de tela

seja desabilitado e permite montar suas partições em modo somente leitura.

Iniciar o Android em modo de recuperação varia conforme o fabricante do

hardware do dispositivo, no LG P970, por exemplo, isso é feito pressionando o

botão de volume para cima e pressionando o botão para liga-lo. Caso a

conexão via ADB e o smudge attack falhem, se o dispositivo executa uma ROM

modificada do Android, o modo de recuperação deve ser considerado, e este

só funciona se for um modo modificado por uma ROM customizada instalada

(Android Forensics, 2011).

Gravar Uma Nova Partição de Recuperação

Ferramentas como a Fastboot permitem gravar uma partição modificada de

modo de recuperação, e o não precisam que o modo de depuração USB esteja

habilitado para isso. Uma vez instalada esta partição modificada, é possível ter

acesso aos dados do usuário. A restrição fica por conta da proteção sobre o

modo bootloader (necessário para instalar a partição modificada) que alguns

fabricantes mantem habilitada. Como no modo de recuperação, o iniciar o

dispositivo em bootloader varia conforme o fabricante. Este é uma ferramenta

extremamente útil mas que modifica o estado do aparelho. Este tipo de

intervenção deve devidamente justificada e ser executada por uma pessoa que

saiba o que está fazendo, pois há risco de perda de informações (Android

Forensics, 2011).

62

Desabilitar o Bloqueio por Meio do Google Play

Se a senha e o login da conta Google do usuário do dispositivo móvel forem

conhecidas, é possível instalar um App no aparelho e através dele desabilitar o

bloqueio de tela. No artigo Android Lock Screen Bypass, de Thomas Canon,

essa técnica é descrita através da possibilidade de instalar App no Android pelo

Google Play. A técnica consiste em instalar dois APPs no dispositivo, o

segundo vai servir para dispara uma trigger que iniciará o primeiro, este,

através da chamada disableKeyguard() da API do Android fará o desbloqueio

da tela (Android Lock Screen ByPass, 2011).

Login da Conta Google

Se o analista estiver em posse do usuário e senha da conta Google vinculada

ao dispositivo Android é possível desbloquear a tela, pois após certo número

de tentativas mal sucedidas, o sistema oferece a opção de desbloqueio pelo

login da conta Google do usuário. Caso o analista não tenha esse login mas

tenha um mandato judicial para obtê-lo, é possível fazer uma requisição ao

Google e apagar a senha da conta. O risco desta operação fica por conta da

necessidade do dispositivo se conectar a rede para atualiza a senha e acabar

exposto a um ataque de rede, onde é possível executar ações no dispositivo

bastando o envio de uma mensagem.

4.4.2 Isolando o Dispositivo Móvel da Rede

Se o dispositivo não estiver com bloqueio de tela ou após este ser desabilitado,

a primeira ação a ser tomada é isolar o dispositivo da rede, caso contrário um

ataque aos dados do aparelho pode ser iniciado por uma simples mensagem

SMS do atacante. O modo mais simples de isolar o equipamento da rede é

coloca-lo no Modo Avião (Airplane mode). Isso pode ser feito pressionado o

botão de ligar e selecionado a opção modo avião (Android Forensics, 2011):

Caso não seja possível ativar o modo avião por caso do bloqueio do aparelho,

por exemplo, e caso esse seja um telefone GSM, é possível remover o chip do

aparelho se isso também não for possível, suspender a conta (número

63

telefone) diretamente na operadora também é uma opção. A ultima alternativa

é colocar o dispositivo móvel dentro de uma Gaiola de Faradey, mas nesse

caso existem várias implicações como o rápido consumo de bateria, já que o

dispositivo tentará insistentemente reestabelecer suas conexões. A tabela 9

mostra as vantagens e desvantagens de cada método (Android Forensics,

2011):

Tabela 9 – Técnicas para isolar um dispositivo móvel da rede

Método Vantagens Desvantagens

Colocar o dispositivo móvel em modo avião.

O dispositivo continua executando e mantem intactas as informações na memória volátil. Desabilita as conexões do dispositivo móvel como wi-fi, 3G, bluetooth.

Modifica as configurações do aparelho. Funciona apenas se o analista tiver acesso total ao dispositivo.

Remover o cartão SIM. Fácil de remover. Efetivo em desabilitar transmissões de voz, SMS e dados.

Não desabilita wi-fi, bluetooth e outras redes. Funciona apenas com telefones GSM.

Suspender a conta com a operadora.

Efetivo em desabilitar transmissões de voz, SMS e dados.

Requer tempo (mandato judicial). Não desabilita wi-fi, bluetooth e outras redes.

Colocar o dispositivo dentro de uma gaiola de faraday.

Interrompe todas as conexões de rede.

Rápido consumo da bateria em função das retentativas de restabelecer as conexões, por parte do aparelho. Não é possível inserir um cabo de energia na bolsa.

Desligar o dispositivo Interrompe todas as conexões de rede.

Modifica a memória volátil do dispositivo. Pode habilitar o bloqueio de tela na reinicialização.

Fonte (Android Forensics, 2011).

No caso da Gaiola de Faraday, o ideal seria uma sala com o mesmo tipo de

proteção contra redes externas onde haveria como fornecer cabo alimentação

ao dispositivo, mas os custos para construir e manter uma sala dessas são

muito altos (Android Forensics, 2011).

64

Por ultimo, se o dispositivo for encontrado desligado, convém inicia-lo no modo

de recuperação para ver as suas conexões, se o modo de depuração está

ativado e verificar se possui acesso de root (Android Forensics, 2011).

4.4.3 Conhecendo o Dispositivo

Como ultimo cuidado para preservar o estado do aparelho durante os

processos de dumping de memória e análise, é fundamental saber com o que

se está trabalhando. A iteração com o sistema Android varia conforme o

fabricante do hardware do aparelho, assim, um comando bastante útil neste

sentido é o lsusb, que listará as informações referentes ao software instalado e

fabricante do hardware. A figura 30 apresenta a saída do comando (Android

Forensics, 2011):

Figura 30 – Saída do comando lsub Fonte: O Autor (utilizando o Android ADB Tools para Linux Ubuntu).

4.5 EXTRAINDO INFORMAÇÕES DO DISPOSITIVO

Extração de dados é o primeiro procedimento a ser feito pelos analistas

forenses, depois dos cuidados para preservar o estado original do dispositivo.

4.5.1 Extração Via Software

Essa é geralmente a primeira técnica utilizada pelos analistas forenses, porque

além de simples, na maioria dos casos fornece informação suficiente para

encerrar uma acusação. O único requisito é que o modo de depuração USB

esteja habilitado. Não é necessário acesso de root, embora algumas partes da

memória interna necessitem desse tipo de permissão para serem acessíveis.

luffy@ubuntu:~$ sudo lsusb -v Bus 002 Device 004: ID 1004:61a6 LG Electronics, Inc. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 239 Miscellaneous Device bDeviceSubClass 2 ? bDeviceProtocol 1 Interface Association bMaxPacketSize0 64 idVendor 0x1004 LG Electronics, Inc. idProduct 0x61a6 bcdDevice 2.16 iManufacturer 2 LGE iProduct 3 LG Android iSerial 4 7DF600229FFC0000016395910A01600F bNumConfigurations 1

65

ADB Pull

O comando adb pull copia recursivamente uma parte desejada do sistemas de

arquivos. Porém, como já dito, as partes mais importantes do sistema de

arquivo são visíveis apenas ao root. Mas, mesmo sem acesso de super usuário

é possível extrair informações relevantes da memória interna e do SDCard. A

figura 31 mostra um exemplo de tentativa de obter o conteúdo do diretório

/data, que está visível apenas acesso root, com um shell de usuário comum

(Android Forensics, 2011):

Figura 31 – Extração de dados via adb pull sem acesso de root Fonte: O Autor (utilizando o Android ADB Tools para Linux Ubuntu).

Como não há permissão suficiente o comando simplesmente não copia os

arquivos.

Para executar o comando com acesso de root é necessário reiniciar o ADB em

modo root com o comando adb root. Agora uma tentativa de extrair em um

dispositivo com root resulta na saída:

Figura 32 – Extração de dados via adb pull como root Fonte: O Autor (utilizando o Android ADB Tools para Linux Ubuntu).

No caso de um dispositivo Android com root mas que mantem a ROM do

fabricante, o analista receberá a mensagem “adbd cannot run as root in

production builds”. Neste caso é preciso seguir os seguintes passos para

obter os dados de diretórios protegidos:

1) Obter uma shell pelo comando abd shell.

2) Obter acesso de root com o comando su.

luffy@ubuntu:~$ adb pull /data data/ pull: building file list... 0 files pulled. 0 files skipped

luffy@ubuntu:~$ adb pull data/ data/ // varios outros arquivos pull: data/backup/processed -> data/backup/processed pull: data/backup/ancestral -> data/backup/ancestral pull: data/LostFound/Vesta -> data/LostFound/Vesta pull: data/LostFound/Interamnia -> data/LostFound/Interamnia pull: data/LostFound/Hygiea -> data/LostFound/Hygiea pull: data/LostFound/Europa -> data/LostFound/Europa pull: data/LostFound/Davida -> data/LostFound/Davida pull: data/LostFound/Ceres -> data/LostFound/Ceres 1463 files pulled. 0 files skipped. 2050 KB/s (521045345 bytes in 248.121s)

66

3) Mudar a permissão de acesso do diretório e subdiretórios visados

recursivamente com o comando chmod –R 777 <diretório raiz>.

4) Sair do modo adb shell e executar o comando adb pull [origem]

[destino].

4.5.2 Extração Via Hardware

Técnicas de extração de dados via hardware sempre obtém mais informações

do dispositivo, conseguem passar por eventuais bloqueios de software e

recuperar informações já removidas. No sistema YAFFS2 do Android, por

exemplo, quando dados são atualizados as versões anteriores não são

imediatamente apagadas, apenas não são listadas. Removê-las

definitivamente é tarefa do coletor de lixo, então, enquanto este não executar,

há dados “apagados” que podem ser recuperados. Considerando o alto custo

dos equipamentos para realizar uma extração física dos dados e que este

método geralmente não é a primeira escolha do analistas forenses, este

assunto não parte desta pesquisa (Android Forensics, 2011).

4.6 ANÁLISE DAS INFORMAÇÕES OBTIDAS

Após extrair os dados do dispositivo vem a parte de análise já que informação

sem contexto não prova nada. No capítulo 2, sobre o Android, foram exibidos

alguns mecanismos para visualização dos logs do sistema e sua análise. Neste

capítulo são mostradas mais algumas técnicas de análise (não todas). Ao

contrário do processo de extração de dados, várias técnicas tradicionais de

análise podem ser aplicadas aos dispositivos com Android (Android Forensics,

2011).

4.6.1 Ferramentas e Técnicas de Análise de Dados

Time Line

Saber quando determinado evento ocorreu é muito importante numa

investigação, porém criar uma linha do tempo a partir das informações

extraídas manualmente é um trabalho cansativo. Existem vários softwares que

podem realizar esta tarefa, esta sessão se concentra nos aplicativos

67

opensource para criação de time line como os do Sleuth Kit e log2timeline

(Android Forensics, 2011).

Sistemas de Arquivos

Alguns diretórios e arquivos que merecem maior atenção do examinador já

foram apresentados durante o capítulo 2, o comando adb mount apresenta

mais alguns desses diretórios:

Figura 33 – Saída do comando mount Fonte: O Autor (utilizando o Android ADB Tools para Linux Ubuntu).

Algumas das principais partições foram listadas em negrito. A tabela 10 mostra

uma descrição dos dados de cada partição.

Tabela 10 – Partições e sistemas de arquivos

Local de Montagem Sistema de Arquivos Relevância

/proc proc metadados e estatísticas do sistema de arquivos

/data/data YAFFS2 Contem os dados de todas as aplicações

/cache YAFFS2 Arquivos de cache do sistema

/app-cache tmpfs Sistema de arquivos de cache.

/mnt/sdcard vfat Sistema de arquivos do cartão removível

/mnt/emmc vfat Memória interna dedicada ao usuário

/data/local YAFFS2 Permite leitura e escrita para usuários não root num shell adb

/data/misc YAFFS2 Dados de bluetooth, dhcp, wi-fi, vpn e outros.

Fonte: (Android Forensics, 2011).

luffy@ubuntu:~$ adb shell mount rootfs / rootfs ro,relatime 0 0 tmpfs /dev tmpfs rw,nosuid,relatime,mode=755 0 0 devpts /dev/pts devpts rw,relatime,mode=600 0 0 proc /proc proc rw,relatime 0 0 sysfs /sys sysfs rw,relatime 0 0 tmpfs /mnt/extobb tmpfs rw,relatime,mode=755,gid=1000 0 0 none /acct cgroup rw,relatime,cpuacct 0 0 tmpfs /mnt/asec tmpfs rw,relatime,mode=755,gid=1000 0 0 tmpfs /mnt/obb tmpfs rw,relatime,mode=755,gid=1000 0 0 /dev/block/mmcblk0p5 /drm/widevine ext4 rw,nosuid,nodev,relatime,user_xattr,barrier=1,data=ordered 0 0 /dev/block/mmcblk0p9 /data ext4 /dev/block/mmcblk0p10 /cache ext4 rw,nosuid,nodev,noatime,user_xattr,barrier=1,nomblk_io_submit,data=ordered 0 0 /sys/kernel/debug /sys/kernel/debug debugfs rw,relatime 0 0 /dev/block/vold/179:49 /mnt/sdcard vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0002,dmask=0002,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0 /dev/block/vold/179:49 /mnt/secure/asec vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0002,dmask=0002,allow_ut

68

Mesmo que não existam ferramentas que lidem diretamente com o sistema de

arquivos YAFFS2, através do adb tools, as informações da memória interna do

dispositivo podem ser copiadas para uma estação de trabalho com sistema de

arquivo suportado e, depois, analisadas diretamente (Android Forensics, 2011).

Strings

Um comando bastante útil, do mundo Linux, é o strings. Ele faz com que o

conteúdo de um arquivo seja apresentado, por padrão ASCII, como strings. A

figura 34 mostra o comando strings utilizado sobre a base SQLite do dropbox:

Figura 34 – Saída do comando strings sobre uma base SQLite Fonte: O Autor (utilizando o Android ADB Tools para Linux Ubuntu).

Como visto, esse comando ajuda a extrair informações mesmo de arquivos

aparentemente ininteligíveis em um editor de texto comum.

Editor Hexa

Em geral, uma cópia dos arquivos da memória interna do Android fornecerá as

informações necessárias para a investigação, porém, nos casos em que é

necessário uma análise mais profunda de arquivos apagados ou

desconhecidos em partições YAFFS2, que as ferramentas de análise não

suportam. Por essa razão saber utilizar um editor hexadecimal é de

fundamental importância.

luffy@ubuntu:~/data/data/com.dropbox.android$ strings databases/prefs.db SQLite format 3 tableDropboxPersistentPrefsDropboxPersistentPrefs CREATE TABLE DropboxPersistentPrefs (_id INTEGER PRIMARY KEY AUTOINCREMENT, pref_name TEXT NOT NULL UNIQUE, pref_value TEXT)K indexsqlite_autoindex_DropboxPersistentPrefs_1DropboxPersistentPrefs Ytablesqlite_sequencesqlite_sequence CREATE TABLE sqlite_sequence(name,seq) tableDropboxAccountPrefsDropboxAccountPrefs CREATE TABLE DropboxAccountPrefs (_id INTEGER PRIMARY KEY AUTOINCREMENT, pref_name TEXT NOT NULL UNIQUE, pref_value TEXT)E indexsqlite_autoindex_DropboxAccountPrefs_1DropboxAccountPrefs ctableandroid_metadataandroid_metadata CREATE TABLE android_metadata (locale TEXT) fr_CA 37=NOTIFICATIONS_TO_M NOTIFICATIONS_TO_MUTEB

69

Figura 35 – Visualização de uma base SQLite no hexeditor Fonte: (Android Forensics, 2011).

Na figura 35, a saída do editor hexadecimal executado sobre uma base SQLite

de um App Android.

SQLite3

Uma vez que os APPs Android armazenam suas informações em bases

SQLite, é conveniente ter instalado a ferramenta sqlite3 no ubuntu.

Figura 36 – Visualização das tabelas de uma base SQLite Fonte: (Android Forensics, 2011).

Na figura 36, a listagem das tabelas de uma base com a ferramenta sqlite3.

4.6.2 Análise Forense das Partições SDCard e eMMC

Arquivos multimídia, fotos, dados de aplicativos, músicas, backup de arquivos

são todos exemplos de informações recuperáveis a partir do cartão de

memória. E não apenas arquivos encontráveis mas também informações

apagadas, cache de aplicações apk baixados. Além disso, o SDCard pode ser

montado como dispositivo de armazenamento externo a um PC e qualquer tipo

de arquivo pode ser transferido à ele (Android Forensics, 2011).

ahoog@ubuntu:~$ hexeditor mmssms.db File: mmssms.db ASCII Offset: 0x00000000 / 0x00077FFF (%00) 00000000 53 51 4C 69 74 65 20 66 6F 72 6D 61 74 20 33 00 SQLite format 3. 00000010 04 00 01 01 00 40 20 20 00 00 24 4A 00 00 00 00 .....@ ..$J.... 00000020 00 00 00 00 00 00 00 00 00 00 00 3C 00 00 00 01 ...........<.... 00000030 00 00 00 00 00 00 00 18 00 00 00 01 00 00 00 3C ...............< 00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000060 00 00 00 00 05 00 00 00 17 03 8D 00 00 00 00 45 ...............E 00000070 03 FB 03 F6 03 F1 03 EC 03 E7 03 E2 03 DD 03 D8 ................ 00000080 03 D3 03 CE 03 C9 03 C4 03 BF 03 BA 03 B5 03 B0 ................ 00000090 03 AB 03 A6 03 A1 03 9C 03 97 03 92 03 8D 00 00 ................ 000000A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000B0 00 00 00 00 00 00 00 00 00 00 00 00 00 04 81 0C ................ 000000C0 03 07 17 15 15 01 81 7B 74 61 62 6C 65 61 64 64 .......{tableadd 000000D0 72 61 64 64 72 05 43 52 45 41 54 45 20 54 41 42 raddr.CREATE TAB

ahoog@ubuntu:~$ sqlite3 mmssms.db SQLite version 3.6.22 Enter ".help" for instructions Enter SQL statements terminated with a ";" sqlite> .tables addr incoming_msg sms android_metadata incoming_msg_v2 sr_pending attachments part threads canonical_addresses pdu threads_list cbch pending_msgs words drm qtext words_content htcmsgs rate words_segdir htcthreads raw words_ segments

70

Apps no SDCard

Com o objetivo de liberar espaço na memória interna do dispositivo, é possível

mover um aplicativo para o SDCard (o app deve ter suporte para esta ação).

Como já dito, o diretório dos aplicativos é o /data/data, onde os dados do

usuário estão salvos. Como na imagem abaixo, desde que a aplicação suporte

esta operação, basta clicar sobre o botão “Move to SD card” para mover um

aplicativo para a partição do usuário.

Figura 37 – Opção Mover para o cartão de memória Fonte: (Android Forensics, 2011).

Para o usuário de um dispositivo Android com pouca memória interna esta

opção é bastante conveniente, mas do ponto de vista da análise forense

existem algumas considerações:

1. O arquivo .apk é movido de “/data/<app-name>” para partição

criptografada “/mnt/secure/asec/” acessível apenas pelo root.

2. Uma nova partição é montada (no modo somente leitura) e o aplicativo

da “/mnt/secure/asec” é decriptografado e acessível ao sistema em

“/mnt/asec/<app-name>”, pois o sistema precisa ter acesso ao apk

decriptografado para executá-lo.

71

3. O diretório de dados do usuário referente ao aplicativo permanece sendo

o “/data/data/<app-name>”

4. Se o SDCard ficar inacessível, o aplicativo não é mais acessível ao

sistema, razão pela qual os apps básicos não podem ser movido para o

SDCard.

Como já mencionado, o .apk é criptografado de modo a impedir que outros

apps não o corrompam ou façam alguma modificação maliciosa. O

desenvolvedor também não deve confiar somente nesta criptografia uma vez

que basta copia-lo da partição decriptografada “/mnt/asec/<app-name>”. Logo,

se o analista precisa do .apk para a investigação (de um malware, por

exemplo) então ele deve copiar a partição “/mnt/asec” e seus subdiretórios

durante a fase de extração de informações. Esta cópia, deve ser feita com o

dispositivo ligado e ativo e não montada na estação de trabalho do analista.

Abaixo, a listagem da partição “/mnt” e as permissões relacionadas a cada

subdiretório, incluindo, como exemplo, o aplicativo movido:

Figura 38 – Listagem do diretório /mnt Fonte (Android Forensics, 2011).

nonmedia

Nonmedia é um arquivo que instrui o scanner de media do Android a pular o

diretório atual. Assim, se um diretório não tem este arquivo, é possível que

contenha arquivos do tipo thumbnails de imagens já apagadas. O arquivo

nonmedia é encontrado nas partições do sdcard e eMMC (Android Forensics,

2011).

Timeline

Para análise do tipo linha do tempo a ferramenta utilizada será a log2timeline.

Porém, após copiar os dados do dispositivo e antes de iniciar a análise,

ahoog@ubuntu:~/sd-emmc$ adb shell ls -l /mnt d---rwxr-x system sdcard_rw 1969-12-31 18:00 emmc drwxr-xr-x root system 2011-02-15 05:17 asec drwx------ root root 2011-02-14 07:59 secure d---rwxr-x system sdcard_rw 1969-12-31 18:00 sdcard ahoog@ubuntu:~/sd-emmc$ adb shell ls -l /mnt/asec dr-xr-xr-x system root 1969-12-31 18:00 com.rovio.angrybirds-1 ahoog@ubuntu:~/sd-emmc$ adb shell ls -l /mnt/asec/com.rovio.angrybirds-1 -r-xr-xr-x system root 17235931 2011-02-15 05:17 pkg.apk # ls -l /mnt/secure/asec ----rwxr-x system sdcard_rw 19192832 2011-02-15 05:17 com.rovio.angrybirds-1. asec # ls -l /data/data/com.rovio.angrybirds drwxrwx--x app_106 app_106 2011-02-15 05:14 cache drwxrwx--x app_106 app_106 2011-02-15 05:15 files drwxr-xr-x system system 2011-02-15 05:14 lib

72

convém usar uma criptografia de hash (md5sum ou sha256sum) tanto no

SDCard quanto na imagem, a fim de validar a última.

4.6.3 Análise Forense no Sistema de Arquivos YAFFS2

Como já mencionado, o sistemas de arquivos YAFFS2 é opensource,

desenvolvido especialmente para memórias do tipo flash NAND e inclui

algoritmos para correção de erros. Seu modelo arquitetural permite que dados

apagados e/ou atualizados sejam recuperados mas por ser um sistema de

arquivos recente, ainda não existem ferramentais (nem opensource nem,

comerciais) que o suportem. Sendo assim, a extração e analise dos arquivos

desta partição é feita via Android ADB Tools (Android Forensics, 2011).

73

CAPÍTULO 5. ESTUDO DE CASO

5.1 INTRODUÇÃO

A fim de demonstrar o uso das técnicas e ferramentas de extração e análise de

dados apresentadas ao longo deste trabalho, foi proposta a utilização destas

em uma situação encontrada pelos analistas forenses.

Um smartphone LG Optimus Black (P970) foi propositalmente infectado com o

malware Zitmo Trojan para identificação e análise do mesmo utilizando as

técnicas e ferramentas apresentadas no capítulo anterior. A análise do

malware, após sua extração, foi realizada em desktop com a versão 13.04 do

Linux Ubuntu.

5.2 METODOLOGIA DE ANÁLISE PROPOSTA

A metodologia de apreensão e extração de dados do dispositivo Android é uma

versão adaptada e simplificada da tese de mestrado de André Morum (Método

para Análise Pericial em Smartphone com Sistema Operacional Android, 2011).

A esta versão, acrescenta-se a fase de análise dos dados obtidos através das

técnicas e ferramentas apresentadas durante este trabalho. O diagrama a

seguir exemplifica o método proposto para este estudo de caso.

Na figura são apresentados dois cenários: telefone com o sistema Android com

e sem root e os respectivos procedimentos a serem adotados pelo analista em

cada caso. A partir deste método, é possível obter o máximo de informações do

dispositivo móvel, de maneira a documentar, resguardar e processar a

evidência da forma mais segura e menos intrusiva possível (Aquisição de

Evidências Digitais em Smartphones Android, 2011).

Para análise dos fatos que identificam a existência do malware foi utilizada

como base o artigo da Kindsight Security Labs cujo tema á análise do trojam

Zitmo para o AndroidOS.

74

Obter relatos do usuário sobre

comportamento suspeito

Telefone ligado?É possível extrair

dados do cartão?

não

Isolar rede

sim

Extrair dados do cartão de memória e substituir o cartão

sim

não

Ligar telefone não Ligar telefonesim

É possível isolar fisicamente a

rede?

Telefone bloqueado?

Obter senha com o usuário

sim

Extrair dados do cartão de memória

e avaliar sua substituição

Shell via ADB com super usuário?

nãoAtivar o modo de

depuraçãoEspelhar partições

do sistemasim

Extrair informações do sistema

acessíveis (dmesg, dumpsys, logcat)

Listar aplicativos instalados

Verificar apps com acesso a rede (3g,

wi-fi)

Simular o envio de informações por

SMS e outras conexões

Informações pessoais

interceptadas?

Listar o app e analisar o IP de

destino

Aplicativo suspeito

identificado?

sim

Coverter o classes.dex em jar com a ferramenta

dex2jar

Descompilar o jar e suas classes com JD-

GUI

sim

Analisar o código fonte e arquivos

XML do APP

Malware encontrado?

Concluirsim

não

Desempacotar com o APKTools

não

Extrair o arquivo APK e instalar numa

AVD (sandbox)

não

não

Figura 39 – Diagrama de identificação e análise de malware Fonte: O Autor (Adaptado de Aquisição de Evidências Digitais em Smatphones Android, 2011).

75

5.2.1 O Malware Zitmo

O trojan Zitmo é a versão Android do malware Zeus que trabalha em conjunto

com o Zeus Banking Trojam para roubar informações da conta bancária do

usuário. Com o advento dos malwares para desktops, as instituições

financeiras passaram a enviar um número de autorização para transações

bancária (TAN) para o celular do usuário, numa tentativa de adicionar mais um

etapa de segurança, o Zitmo foi criado para anular essa etapa (Malware

Analysis Report, 2011).

Por ser um trojan, Zitmo pode ser parte de qualquer outro aplicativo. A infecção

começa com um ataque de phishing que pede ao usuário para fazer o

download de um aplicativo para PC que por sua vez direciona o usuário para o

download do app Android Trustter Rapport, infectado com o trojan. A vitima

acreditando se tratar de uma aplicação de segurança acaba com o dispositivo

infectado (Malware Analisis Report, 2011).

5.2.2 Identificação do Malware

Seguindo o diagrama para análise da existência de malware, o primeiro passo

é obter o relato do usuário do dispositivo Android suspeito de infecção pelo

malware. No caso, existe a suspeita de que as mensagens SMS recebidas pelo

dispositivo Android estão sendo enviadas para um servidor remoto. Uma

análise dos últimos aplicativos instalados leva a um provável candidato: o app

de segurança Trustter Rapport. A fim de reproduzir o mesmo cenário do

usuário, o APP foi baixado usando a mesma mensagem de phishing enviada

ao usuário e instalado em uma AVD (Malware Analisis Report, 2011).

76

Figura 40 – Instalação do APP Trusteer Rapport Fonte (O Autor, utilizando o AVD).

Como pode ser visto na figura 40, uma das permissões requisitadas pelo

aplicativo é o acesso as mensagens SMS. Comparando os processos em

execução depois da instalação é notado o novo processo em execução:

Figura 41 – Visualização dos processos em execução Fonte: O Autor (utilizando o Android ADB Tools para Linux Ubuntu).

Com a análise dos logs e com os relatos de comportamento suspeito informado

pelo usuário, é possível traçar a estratégia de análise para este app. Como a

extração do arquivo apk do aplicativo suspeito e sua instalação numa Android

Virtual Device (AVD), é criada uma sandbox para a analise isolado do app.

USER PID PPID VSIZE RSS WCHAN PC NAME root 1 0 816 464 ffffffff 00000000 S /init app_9 2473 10636 288576 29148 ffffffff 00000000 S com.android.mms app_120 3634 10636 326220 71196 ffffffff 00000000 S com.lge.launcher2 app_25 8426 10636 311072 51588 ffffffff 00000000 S com.nullsoft.winamp app_0 9134 10636 312908 38748 ffffffff 00000000 S com.whatsapp app_1 9186 10636 318672 37576 ffffffff 00000000 S com.google.process.location app_1 9198 10636 309268 33436 ffffffff 00000000 S com.google.android.gms app_37 9315 10636 293616 31792 ffffffff 00000000 S com.systemsecurity6.gms

77

Como já mencionado neste trabalho, o arquivo “.apk” dos aplicativos instalados

no Android fica no diretório “/data/app” (é necessário privilégio de root para

acessar), assim, se já foi feito root no dispositivo basta copiar o “apk” do

aplicativo suspeito para análise posterior em um desktop Ubuntu.

Figura 42 – Extração do arquivo apk do app suspeito Fonte: O Autor (utilizando o Android ADB Tools para Linux Ubuntu).

Antes da instalação do app na AVD, foi configurado o software Wireshark para

monitorar o tráfego de rede do emulador. Como apenas uma aplicação com

acesso ao serviço de mensagens continua em execução, caso haja o envio de

uma requisição pelo dispositivo Android a um host desconhecido, ela será uma

forte candidata a ser analisada.

Figura 43 – Analise do tráfego de rede do AVD pelo software Wireshark Fonte (Malware Analisis Report, 2011).

Pela figura 43, após o envio de uma mensagem SMS ao AVD, através de uma

conexão telnet, houve o envio de uma requisição a um servidor desconhecido,

portanto, o aplicativo é suspeito e deve ser analisado.

5.2.3 Engenharia Reversa e Análise do Arquivo APK

Figura 44 – Visualização do conteúdo do apk do app Zitmo Fonte: O Autor.

luffy@ubuntu:~$ adb pull /data/app/ Zitmo_tr_ECBBCE17053D6EAF9BF9CB7C71D0AF8D.apk

luffy@ubuntu:~/Downloads/Zitmo_tr_ECBBCE17053D6EAF9BF9CB7C71D0AF8D$ ll total 56 drwxrwxr-x 4 luffy luffy 4096 Nov 3 20:07 ./ drwxr-xr-x 6 luffy luffy 4096 Nov 3 20:08 ../ -rw-rw-r-- 1 luffy luffy 2736 Mai 29 2011 AndroidManifest.xml -rw-rw-r-- 1 luffy luffy 7660 Mai 29 2011 classes.dex drwx------ 2 luffy luffy 4096 Nov 3 20:07 META-INF/ drwx------ 6 luffy luffy 4096 Nov 3 20:07 res/ -rw-rw-r-- 1 luffy luffy 1800 Mai 29 2011 resources.arsc

78

O arquivo APK é um zip, de modo que após ser descompactado é possível ver

o seu conteúdo na figura 44:

Pasta META-INF – contém informações para verificar a segurança e

validade da aplicação apk.

Pasta res – recursos da aplicação como imagens, arquivos de layout,

sons, etc.

Arquivo AndroidManifest.xml – contém informações como as permissões

requeridas pela aplicação, nome do pacote, versão, etc.

Arquivo resources.arsc – arquivo binário obtido após a compilação.

Arquivo classes.dex – contém todas as classes Java da aplicação

compiladas para o conjunto de bytecodes interpretados pela Dalvik VM.

No caso dos arquivos XML, não é possível ver o seu conteúdo apenas

descompactando o APK, pois eles foram criptografados durante o

empacotamento. Nesse caso é utilizada a ferramenta APKTOOLS para o

desempacotamento do app. A execução e saída do uso da ferramenta seguem

na figura 45:

Figura 45 – Execução da ferramenta APKTools Fonte: O Autor (utilizando o APKTools em Linux Ubuntu).

O resultado é uma pasta com o mesmo nome do arquivo apk com a mesma

estrutura apresenta na descompactação. Agora é possível visualizar e analisar

os arquivos XML, mas para ver o código propriamente dito do aplicativo, é

preciso outra ferramenta, a dex2jar, para converter o arquivo “classes.dex” em

um jar, como na figura 46:

luffy@ubuntu:~/Downloads$ apktool d Zitmo_tr_ECBBCE17053D6EAF9BF9CB7C71D0AF8D.apk zitmo I: Baksmaling... I: Loading resource table... I: Loaded. I: Decoding AndroidManifest.xml with resources... I: Loading resource table from file: /home/luffy/apktool/framework/1.apk I: Loaded. I: Regular manifest package... I: Decoding file-resources... I: Decoding values */* XMLs... I: Done. I: Copying assets and libs...

79

Figura 46 – Execução da ferramenta dex2jar Fonte: O Autor (utilizando o dex2jar em Linux Ubuntu).

Após a execução da ferramenta é criado o arquivo “classes_dex2jar.jar” no

mesmo diretório do App descompactado e este, por sua vez, agora pode ter

seu código fonte analisado através de uma ferramenta de descompilação de

código Java, com o JD-GUI:

Figura 47 – Visualização do código do Zitmo no JD-GUI Fonte: O Autor (Utilizando o software JD-Gui).

Na figura 47 é mostrado o código fonte da classe MainService após a

descompilação. Nela, dois trechos chamam a atenção: a inicialização da thread

da classe interna SMSBlockerThread, que tem a função de interceptar

mensagens SMS recebidas e o trecho para extração da mensagem nessa

classe. Como já mencionado, o objetivo do trojan Zitmo é obter o código TAN

das mensagem SMS enviadas pelas instituições financeiras a seus clientes

como um passo adicional de segurança a transação bancária. Em outro trecho

luffy@ubuntu:~/Downloads$ dex2jar-0.0.9.15/dex2jar.sh Zitmo_tr_ECBBCE17053D6EAF9BF9CB7C71D0AF8D/classes.dex this cmd is deprecated, use the d2j-dex2jar if possible dex2jar version: translator-0.0.9.15 dex2jar Zitmo_tr_ECBBCE17053D6EAF9BF9CB7C71D0AF8D/classes.dex -> Zitmo_tr_ECBBCE17053D6EAF9BF9CB7C71D0AF8D/classes_dex2jar.jar Done.

80

do código fonte do APP a mensagem SMS é empacotada como um objeto

JSON e enviado via requisição POST a um servidor remoto, cuja URL está na

classe ServerSession (Malware Analisis Report, 2011).

5.3 CONCLUSÃO

O malware analisado se destaca pela combinação de spyware (envio de

informações do usuário para um servidor remoto) e falso aplicativo de

segurança. A identificação foi possível graças aos relatos do usuário e da

natureza spyware do malware, assim, a verificação dos aplicativos em

execução no Android, mais a listagem dos que possuem acesso ao serviço de

SMS e um monitoramento da rede, permitiram constatar a existência de um

malware suspeito, sua extração e posterior análise do código para conclusão

do caso.

Este estudo de caso mostrou como é possível não apenas extrair dados do

Android, mas também, com base no conhecimento do funcionamento do

sistema operacional, de quais são as informações relevantes e onde elas

estão, é possível identificar até mesmo a presença de um spyware no sistema.

Com a transição cada vez mais acentuada do desktop para os dispositivos

móveis, fica claro que os sistemas embarcados nestes dispositivos serão o

principal alvo de ataques de espionagem e, tão importante quanto a proteção é

a sua identificação.

81

CAPÍTULO 6. CONCLUSÃO

Neste trabalho foram apresentadas técnicas e ferramentas opensource para a

extração e análise dos dados de dispositivos com o sistema operacional

Android. Pelo fato dos dispositivos móveis ainda não serem a principal fonte

dos crimes virtuais, a análise forense neste meio ainda carece tanto de

técnicas quanto de ferramentas para sua execução. No entanto, mesmo com

estas dificuldades, foi possível apresentar as principais ferramentas para a

análise forense e suas aplicações práticas.

A análise forense quase sempre associada apenas a extração de informações

recebeu, durante o estudo de caso, um carácter investigativo durante a análise

de infecção de um dispositivo Android por um spyware. Este não foi apenas um

caso escolhido aleatoriamente, com a quantidade de malwares criados para o

Android aumentando a cada dia, as ferramentas de proteção podem não ser

capazes de detectar todas as pragas e, nesses casos, uma análise a fim de

detectar e isolar o equipamento infectado é de grande importância para a

segurança de todos.

Complementando o que foi publicado na tese de mestrado de André Motum de

Lima Simão, Proposta de Método para Análise Pericial em Smatphone com

Sistema Operacional Android, foi adicionada a fase de análise das informações

obtidas pelas técnicas de forense digital. Foi modo de apresentar uma

utilização diferente para o conhecimento adquirido sobre o sistema Android e

ao mesmo tempo não apenas repetir o que já foi feito em outro trabalho.

A maior dificuldade durante a pesquisa foi a total ausência de uma ferramenta

(comercial ou opensource) para análise de informações em partições YAFFS2.

O princípio básico da forense digital é mantar os dados inalterados e, num

processo judicial o analista forense pode encontrar dificuldades em explicar

porque o estado de um dispositivo foi alterado e de que forma.

6.1 TRABALHOS FUTUROS

Outro ponto que chamou a atenção neste trabalho, baseado nas técnicas de

análise e extração de dados apresentadas, é a falta de uma ferramenta de

análise com suporte ao sistema de arquivos YAFFS2 (Yet Another File

82

System), projetado especificamente para mídias de armazenamento do tipo

Flash NAND e largamente utilizado em dispositivos Android. O

desenvolvimento de uma ferramenta capaz de lidar com partições neste

formato facilitará muito o trabalho dos analistas forenses, além de tornar a

análise e extração de dados menos sujeita a erros e mais segura.

O estudo de caso deste trabalho sugere também uma nova e mais detalhada

pesquisa focada no método de análise de malware. Provavelmente com a

participação de entidades que são referência na área de segurança contra

malwares.

83

REFERENCIAS

A Castilho, Carlos. Android Malware Past, Present, and Future. Mobile Security

Working Group McAfee. Disponível em: <

http://www.mcafee.com/us/resources/white-papers/wp-android-malware-past-

present-future.pdf >. Acesso em: 26 de Outubro de 2013.

ACPO Good Pratice for Computer-Based Eletronic Evidence. 7Safe Information

Security. Acesso em 15 de Outubro de 2010. Disponível em: <

http://www.7safe.com/electronic_evidence/ACPO_guidelines_computer_eviden

ce.pdf>.

Adam J. Aviv, Katherine Gibson, Evan Mossop, Matt Blaze, and Jonathan M.

Smith. Smudge Attacks on Smartphone Touch Screens. 21 de Fevereiro de

2011. Disponível em: <

https://www.usenix.org/legacy/event/woot10/tech/full_papers/Aviv.pdf>.

Bornstein, D. Dalvik VM Internals. 2008 Google I/O Session 2008. Disponível

em: <https://sites.google.com/site/io/dalvik-vm-internals>. Acesso em: 31 de

março de 2013.

Business Week, Bloomberg. 2005. Disponível em <

http://www.businessweek.com/stories/2005-08-16/google-buys-android-for-its-

mobile-arsenal>. Acesso em 27 de Março de 2013.

Cannon, T. (n.d.). Android lock screen bypass.. Acessado em 15 de outubro de

2013. Disponível em: < http://www.mcafee.com/us/resources/white-papers/wp-

android-malware-past-present-future.pdf >.

Desai, Dhawal. Malware Analisis Report. Kindsight Security Labs. Setembro de

2011. Disponível em: <https://www.kindsight.net/sites/default/files/Android-

Trojan-Zitmo-final.pdf>. Acesso em 26 de Outubro de 2013.

Distefano, Alessandro; Mea, Gianluigi; Pace, Francesco. Android anti-forensics

through a local paradigma. Digital Investigation. 2010.

Ehringer, D. The Dalvik Virtual Machine Architeture. David Ehringer, março

2008. Disponível em:

84

<http://davidehringer.com/software/android/The_Dalvik_Virtual_Machine.pdf>.

Acesso em 31 de março de 2013.

Gadhavi, B. Analysis of the Emerging Android Market. The Faculty of the

Department of General Engineering, Sam Jose State University.

Gargenta, Marko. Learning Android. First Edition. Sebastopol, CA: O’Reilly

Media Inc, 2011.

Gartner, Inc. Gartner Says Smartphone Sales Grew 46.5 Percent in Second

Quarter of 2013 and Exceeded Feature Phone Sales for First Time. Disponível

em: <http://www.gartner.com/newsroom/id/2573415>. Acessado em: 13 de

Outubro de 2013.

Google Inc. Android Fundamentals. Android Developers, 2013. Disponível em:

<http://developer.android.com/guide/topics/connectivity/index.html>. Acesso

em: 26 março 2013.

Google Inc. Android Fundamentals. Android Developers, 2013. Disponível em:

< http://developer.android.com/about/dashboards/index.html>. Acesso em: 26

março 2013.

Hashimi, S.; Komatineni, S.; Maclean, D. Pro Android 2. 1ª edição. Ed; [S.1.]:

Apress, 2010. ISBN 978-1-4302-2659-8.

Hoog, Andrew. Android Forensics. First Edition. Waltham, MA. Elsevier Inc,

2011.

Lessard, Jeff; Kessler, Gary. Android Forensics: Simplifying Cell Phone

Examinations. Edith Cowan University. 2010.

Milbourne, Grayson; Orozco, Armando. Android Malware Exposed. Agosto de

2012. Webroot. Disponível em: <http://www.webroot.com/shared/pdf/Android-

Malware-Exposed.pdf>. Acesso em: 28 de Outubro de 2013.

Morum de Lima Simão, André. Proposta de Método para Análise Pericial em

Smatphone com Sistema Operacional Android. 2011. Tese de Mestrado.

Universidade de Brasília, Brasília.

85

Morum de L Simão, André; Sícoli, Fábio Caús; Peotta de Melo, Laerte; Deus,

Flávio Elias de; Sousa Júnior, Rafael Timóteo. Aquisição de Evidências Digitais

em Smatphones Android. Universidade de Brasília, Brasília, pp 92-99, Outubro

de 2011.

SQLite Documentation. SQLite, 2013. Disponível em:

<http://www.sqlite.org/docs.html>. Acesso em: 30 de abril de 2013.

W. Frank Ableson; Sen, Robi; King, Chris; Ortiz, C. Enrique . Android in Action.

Third Edition. Shelter Island, NY: Manning Publications Co, 2012