Sala de Aula _ Estacio 10

Prévia do material em texto

Análise de Malwares
Aula 10: Análise de Malware em ambiente Mobile
Apresentação
Nesta décima e última aula utilizaremos todos os conhecimentos acumulados até agorapara analisar aplicações
maliciosas em dispositivos móveis, em Android e Apple.
Abordaremos algumas características da arquitetura ARM e depois veremos as peculiaridades de cada um dos ambientes
mobiles.
Por �m, elencaremos algumas técnicas de análises de aplicações maliciosas em cada um dos ambientes.
Objetivo
Identi�car as características da arquitetura ARM;
Identi�car as peculiaridades do sistema Android;
Identi�car as peculiaridades do sistema iOS.
Introdução
É inegável o aumento de dispositivos móveis e seu uso em comparação com os computadores tradicionais. Esses dispositivos
se tornaram um grande vetor de entrada nas organizações. Por isso, já se justi�ca a importância em estudar e entender estes
dispositivos para que seja analisado seu uso malicioso.
Arquitetura ARM
Antes de aprofundarmos na linguagem assembly para a arquitetura ARM, precisamos entender uma diferença básica daquilo
que vimos até agora.
Existem dois grandes grupos de arquiteturas que de�nem a linguagem assembly:
Conjunto Complexo de Instruções de Computador –
Complex Instruction Set Computer (CISC).
Conjunto Reduzido de Instruções de Computador –
Reduced Instruction Set Computer (RISC).

A maior diferença entre eles é a complexidade das
instruções. A arquitetura Intel, tanto 32 quanto 64
bits, utiliza o conjunto CISC; já a arquitetura ARM,
utiliza o conjunto RISC.
Linguagem assembly do tipo CISC
A linguagem assembly do tipo CISC possui, como já mencionado, instruções mais complexas. A ideia em criar instruções mais
complexas visa completar tarefas usando a menor quantidade de instruções possível.
Para isso, este modelo inclui instruções que podem executar várias operações, como por exemplo a instrução mul, que pode
executar operações de acesso de dados, multiplicação e até armazenamento.
Linguagem assembly do tipo RISC
Já a linguagem assembly do tipo RISC possui instruções simples que, geralmente, executam apenas uma operação cada.
Como consequência, são necessárias mais linhas de código para concluir a mesma tarefa, comparando à linguagem CISC.
No entanto, há um ganho em e�ciência do uso do processador, pois são utilizadas apenas as instruções necessárias,
descartando todas as execuções de quaisquer operações desnecessárias.
Comentário
Outra grande vantagem das arquiteturas RISC é a menor necessidade de transistores para os processadores que as
implementam. Isso traz um maior benefício em relação à e�ciência energética e menor dissipação de calor, além de reduzir os
custos de fabricação associados, tornando-os uma escolha melhor para dispositivos portáteis.
Com tudo isso em mente, podemos entender o motivo das arquiteturas RISC com ARM serem a arquitetura mais utilizada no
mundo.
 Esses processadores podem ser encontrados em vários dispositivos móveis e aparelhos, como telefones, consoles de videogame ou câmeras digitais. Fonte: niekverlaan / Pixabay.
Por esse motivo, várias famílias de malware são direcionados às plataformas Android e iOS e com instruções para a arquitetura
ARM. Portanto, para poder analisá-los, é necessário primeiro entender como o ARM funciona.
Existem vários sistemas operacionais com suporte a essa arquitetura: Windows, Android, iOS, distribuições Unix e Linux, além
de outros sistemas operacionais menos conhecidos. O suporte para um espaço de endereço de 64 bits foi adicionado em 2011
com o lançamento do padrão ARMv8.
A arquitetura ARM é do tipo armazenamento de carga, a qual divide todas as instruções em dois tipos de categorias:
1
Acesso de memória
Movimenta os dados entre memórias e registradores.
2
Operações de unidade lógica e aritmética
(ALU)
Realiza os cálculos envolvendo registradores,suporta as
operações aritméticas de adição, subtração,multiplicação e
divisão (a partir do padrão ARMv7).
Existem 30 registradores de 32-bits de propósito geral na arquitetura ARM, divididos em baixo e alto registradores, ponteiro para
pilha, ponteiro de ligação – que contêm o endereço de retorno da função corrente, registrador de contagem, além de outros
para controle de execução do programa e �ags de controle de execução.
O processador ARM tem dois subconjuntos de instruções:
Conjunto ARM tradicional
As instruções são todas de
32 bits.
Conjunto Thumb mais
condensado
As instruções mais comuns
têm 16 bits e algumas têm 32
bits.
O conjunto de instruções a ser
executado pode ser escolhido
pelo desenvolvedor, e apenas um
conjunto pode estar ativo, ou seja,
uma vez que o processador é
alterado para o modo Thumb,
todas as instruções serão
decodi�cadas usando o Thumb
em vez de ARM.
Android
Sistema operacional originalmente desenvolvido pela Android Inc. e posteriormente adquirido pelo Google em 2005, trata-se de
um sistema operacional de código aberto baseado em uma versão modi�cada do kernel Linux. Há muitas variantes dele, como
Wear OS para dispositivos vestíveis, como relógios, e Android TV, que pode ser encontrada em várias televisões inteligentes.
 Fonte: andrekheren / Pixabay.
Como os dispositivos móveis armazenam ou podem fornecer acesso a cada vez mais informações con�denciais, não é
surpresa que as plataformas móveis estejam cada vez mais se tornando alvos deinvasores para �ns maliciosos.
Hierarquia de arquivos
Como o Android é baseado no Linux, sua estrutura de arquivos se assemelha ao que vimos em aulas passadas. O sistema de
arquivos é semelhante a uma árvore com a raiz representada pelo símbolo ‘/’ e possui diversos diretórios semelhantes ao Linux,
como /proc e /sbin, por exemplo.
O kernel do Android possui suporte a diversos sistemas de arquivos dependendo da versão do sistema operacional e do
fabricante do dispositivo. Normalmente, tem sido o EXT4 o sistema de arquivos principal padrão desde o Android 2.3. O
armazenamento externo e os cartões SD são geralmente formatados usando FAT32 para manter a compatibilidade com o
Windows.
Em termos especí�cos, a documentação o�cial do Android divide a estrutura de armazenamento em duas opções:
Clique nos botões para ver as informações.
Representado pelo diretório /data/data/. Seu principal objetivo é armazenar, com segurança, arquivos privados para
aplicativos. Nenhum outro aplicativo, ou mesmo o usuário, tem acesso direto a eles.
Cada aplicativo obtém sua própria pasta e, se o usuário desinstalar o aplicativo, todo o seu conteúdo será excluído. Assim,
os aplicativos usuais não armazenam nada que deva persistir independentemente deles como, por exemplo, fotos tiradas
por um usuário com a ajuda de um aplicativo.
Interno 
Geralmente está associado a /storage/emulated/0, /sdcard e /mnt/sdcard. Este espaço é compartilhado por todos os
aplicativos e pode ser lido por qualquer usuário. Nesse espaço �cam pastas conhecidas como Downloads e DCIM.Esse
local é acessível a todos.
Externo 
Segurança
Existem diversos mecanismos de segurança implementados no Android; como em qualquer outro sistema, esses mecanismos
têm evoluídos cada vez mais. Em relação a gerenciamento de processos, o Android implementa o Controle de Acesso
Obrigatório – Mandatory Access Control (MAC) em todos os processos, e usa o modelo Security-Enhanced Linux (SELinux)
para aplicá-lo.
O SELinux é baseado no princípio de negação padrão, em que tudo o
que não é explicitamente permitido é proibido. Sua implementação
evoluiu em diferentes versões do Android; o modo de aplicação foi
habilitado no Android 5.0.
No Android, cada aplicativo é executado como um processo individual e seu próprio usuário é criado. É assim que a proteção
do processo é implementada, para garantir que nenhum processo possa acessar os dados de outro.Os mapeamentos entre
aplicativos e os IDs de usuário correspondentes podem ser encontrados no arquivo /data/system/packages.xml, bem como no
arquivo packages.list.
Além dos usuários reais, o Android tem muitas contasde sistema com IDs prede�nidos.
Além de AID_ROOT (0), que é usado para executar alguns programas nativos necessários, podemos citar:
1
AID_SYSTEM (1000)
Conta de usuário regular com permissões especiais para
interagir com os serviços do sistema.
2
AID_VPN (1016)
Associado ao sistema de Rede Privada Virtual (VPN);
AID_SHELL (2000) – conta que o usuário obtém ao utilizar
ferramenta depuradora para acessar o terminal de
comando.
3
AID_INET (3003)
Conta capaz de criar soquetes.
Permissões de aplicativos
O principal objetivo das permissões de aplicativos é proteger a privacidade do usuário, dando-lhe controle sobre quais dados e
funcionalidades do sistema podem ser acessados por aplicativo. Por padrão, nenhum aplicativo pode afetar a execução de
outro, a menos que tenha permissão explícita para isso; o mesmo se aplica ao acesso a dados con�denciais do usuário.
01
Dependendo da versão do Android e das con�gurações, algumas permissões podem ser concedidas
automaticamente, enquanto outras requerem aprovação manual do usuário.
02
O comportamento padrão de solicitar o consentimento do usuário depende da versão do Android. A partir do Android
6.0, o usuário não é noti�cado no momento da instalação; em vez disso, o aplicativo precisa pedir permissão em
tempo de execução usando uma janela de diálogo padrão do sistema. Para versões mais antigas do Android, todas as
permissões são solicitadas no momento da instalação.
03
Cada aplicativo deve anunciar quais permissões ele requer em seu arquivo de manifesto incorporado – manifest.xml,
responsável por enumerar diversas opções e funcionalidades da aplicação. Tal arquivo é uma grande fonte de
informações ao analista.
Atenção! Aqui existe uma videoaula, acesso pelo conteúdo online
Root
Muitos usuários comuns encontram aplicativos que exigem o root em seus dispositivos.
O que exatamente signi�ca e como esse processo realmente funciona?
Exemplo
Se o usuário precisar de alguma funcionalidade não suportada por APIs de sistema padrão, por exemplo, remover certos
aplicativos pré-instalados ou aplicativos de operadora, ou fazer aumentar o clock da CPU, ou substituir completamente o sistema
operacional, a única opção que o permite realizar todas essas atividades é obtendo acesso root por meio de alguma
vulnerabilidade conhecida.
Como resultado, o usuário obtém privilégios elevados e controle total sobre o sistema.
A legalidade desse processo varia dependendo do país; é aceitável para atividades não relacionadas a direitos autorais ou é
regulamentada por algumas isenções especí�cas. Às vezes, o processo de root é usado alternadamente com o jailbreak ,
geralmente aplicado a dispositivos iOS. No entanto, esses são procedimentos diferentes em termos de escopo.
Ao contrário do iOS, no Android é possível habilitar o�cialmente a instalação de aplicativos não o�ciais, e muitos dispositivos
são enviados com bootloaders desbloqueados, ou seja, com capacidade de modi�car o sistema operacional, então apenas o
root continua sendo um problema.
O processo de obtenção do superusuário – root é acompanhado por riscos de segurança, já que, nesse caso, o processo
remove a proteção por mecanismos e restrições de segurança incorporados ao sistema.
Uma maneira comum de obter privilégios de root é colocar um utilitário Linux su padrão, que é capaz de conceder os privilégios
necessários para arquivos personalizados e para um local acessível e usá-lo sob demanda. O malware pode veri�car se essa
ferramenta já está disponível no dispositivo comprometido e usá-la indevidamente a seu critério, sem que nenhum trabalho
extra seja necessário.
Muitas famílias de malware Android também vêm com ferramentas para elevar os privilégios por conta própria. Existem vários
motivos pelos quais esse tipo de acesso é visado para os atacantes. Particularmente, permite-lhes obter o seguinte:
1
Acesso a dados críticos. Capacidades de persistência
aprimoradas.
Capacidade de se esconder.
Análise estática e dinâmica
Já temos quase todos os conhecimentos su�cientes para começar a analisar aplicações maliciosas. Para análise estática, o
processo e as ferramentas usadas são basicamente os mesmos para diferentes versões do sistema operacional Android, as
diferenças estão nas técnicas de análise dinâmica utilizada.
Dalvik era uma máquina virtual de processo de código aberto, utilizado até o Android 4.4, que executava aplicativos escritos
para Android. Os programas para Android são comumente escritos em Java ou em Kotlin e compilados em bytecode para a
máquina virtual Java, depois traduzidos para bytecodeDalvik e armazenado em arquivos dex.
O sucessor do Dalvik é o AndroidRuntime (ART), que utiliza os mesmos arquivos bytecode. Sua maior diferença é que, em vez
de interpretar diretamente o bytecodedex, o ART o traduz em instruções de código de máquina para obter melhores resultados
de desempenho.
Análise estática
Geralmente, a análise estática de um malware em bytearray envolve desmontá-lo, examinar suas instruções ou descompilar
para linguagem originalmente escrita e explorar o código-fonte. Em muitos casos, a última abordagem é preferível sempre que
possível, pois a leitura do código amigável reduz o tempo associado à análise.
https://stecine.azureedge.net/webaula/estacio/go0682/aula10.html
A primeira abordagem é frequentemente usada quando a descompilação não funciona por qualquer motivo, como a falta de
ferramentas atualizadas ou por causa de técnicas de engenharia anti-reversa implementadas na amostra.
Existem algumas ferramentas que visam restaurar as informações, a partir do bytecode compilado:
1
Baksmali
Ferramenta que pode ser usada para restaurar o código de
montagem Dalvik a partir de instruções de bytecode, bem
como recuperar a estrutura de cabeçalho dex.
2
Apktool
Fornece a funcionalidade para processar facilmente os
arquivos APK e recuperar as instruções para uma linguagem
de alto nível. Ferramenta bastante utilizada.
3
oat2dex
Ferramenta muito útil para extrair bytecode DEX de arquivos
ELF mais antigos, armazenando-os como parte de dados do
tipo OAT para que possam ser analisados normalmente.
4
vdexExtractor
Pode ser utilizada para extrair bytecode DEX de arquivos
VDEX, pois os arquivos OAT modernos não os armazenam
mais.
Atenção! Aqui existe uma videoaula, acesso pelo conteúdo online
Embora a montagem de bytecode já possa ser utilizada para propósitos de análise estática, é melhor trabalhar com código
descompilado para economizar tempo. Nesse caso, as ferramentas de descompilação são extremamente úteis. Em vez de
restaurar as instruções de montagem, esse conjunto de ferramentas restaura o código-fonte:
1
JADX
Essa ferramenta fornece linhas de comando e uma
ferramenta GUI para obter um código próximo ao código-
fonte original na linguagem Java – DEX para descompilador
Java. Além disso, fornece funcionalidade básica de
desofuscamento.
2
AndroChef
Esse descompilador comercial oferece suporte a arquivos
Java e Android e fornece uma GUI bastante simples.
3
JEB decompiler
Outra solução comercial poderosa de desmontagem e
descompilação, suporta tanto Dalvik quanto código de
máquina.
4
dex2jar
Embora não seja exatamente um descompilador, essa
ferramenta permite que os analistas convertam arquivos
DEX em JARs. Torna-se possível usar vários
descompiladores Java para obter o código-fonte Java.
Uma vez obtido o código-fonte, pode ser analisado em qualquer IDE ou editor de texto com destaque de sintaxe que o suporte.
Análise dinâmica
A análise dinâmica e�caz requer algum tipo de emulação ou depuração remota, pois muitos dispositivos móveis tendem a ter
telas nativas relativamente pequenas e recursos básicos de entrada.
A ferramenta de linha de comando Android Debug Bridge (ADB) é bastante versátil e permite aos usuários interagir com
dispositivos móveis a partir de um computador, possibilitando uma variedade de ações. Ela faz parte das ferramentas da
plataforma Android SDK e consiste em três partes:
Atenção! Aquiexiste uma videoaula, acesso pelo conteúdo online
 Fonte: Autor.
No dispositivo, a depuração via ADB pode ser ativada explicitamente usando a opção Depuração USB em Opções do
desenvolvedor. Além do acesso via USB, é possível interagir via Wi-Fi com o dispositivo. Para isso, basta emitir o comando:
adbtcpip<porta> via USB e, em seguida, desconectar o dispositivo e usar o comando: adbconnect<ip_address>.
Como em qualquer outra plataforma, os emuladores visam facilitar a análise dinâmica emulando as instruções executadas
sem necessidade do uso de dispositivos reais. Existem várias soluções de terceiros com o objetivo de fornecer acesso mais
fácil a aplicativos Android.
No entanto, para �ns de engenharia reversa, as soluções mais focadas em fornecer aos desenvolvedores a capacidade de criar
e depurar aplicativos geralmente oferecem opções melhores. Das diversas existentes, podemos destacar as seguintes:
AndroidEmulator: O emulador Android o�cial pode ser instalado como parte das ferramentas o�ciais do Android
SDK usando o SDK Manager. Ele fornece quase todos os recursos de dispositivos físicos reais e vem com conjuntos
prede�nidos de con�gurações com o objetivo de simular vários dispositivos móveis, como telefones, tablets e
wearables.
Outra grande vantagem é a capacidade de criar e restaurar snapshots contendo todo o estado de uma máquina
emulada.
VMWare/VirtualBox: Essas soluções versáteis podem ser usadas para executar uma imagem Android e realizar
análises dinâmicas de maneira semelhante ao que seria feito em uma máquina virtual Linux.
QEMU: Os emuladores baseados em QEMU, como Limbo, podem ser usados para emular código malicioso.
Genymotion: Solução bastante utilizada, fornece dispositivos virtuais Android tanto para desktop quanto para
nuvem.
Fluxo de análise Android
As metodologias a seguir podem ser utilizadas como �uxo de análise de uma aplicação Android:
Clique nos botões para ver as informações.
A amostra pode ser fornecida ou baixada de um site de terceiros. No entanto, às vezes é necessário obter amostras do
Google Play.
Isso pode ser feito de várias maneiras: Usando ferramentas dedicadas, como o APK Downloader, ou instalando um
aplicativo no emulador e, em seguida, obtendo seu arquivo APK do disco que �cam no diretório /data/app para as
aplicações instaladas pelo usuário e em /system/app para as aplicações pré-instaladas.
Aquisição de amostra 
É mais fácil entender a aplicação através de seu código-fonte do que analisar suas instruções em assembly. Caso não
seja possível realizar a descompilação, por causa de alguma técnica anti-engenharia reversa, por exemplo, o código pode
ser desmontado para que seja realizada sua análise em assembly.
Descompilação/desmontagem 
Vale a pena passar algum tempo revisando o manifesto do aplicativo primeiro – arquivo manifest.xml, quase sempre
presente nas aplicações, pois ele pode fornecer informações sobre a funcionalidade do mesmo. Como as seguintes:
Permissões necessárias ao funcionamento;
Componentes da aplicação; e
Atividade principal e subclasse de aplicativo.
Revisar o manifesto do aplicativo 
Abrir o projeto em alguma IDE ou outra ferramenta que forneça uma interface grá�ca e revisar a lógica implementada. Um
bom ponto de partida é começar com os métodos onCreatedo componente de atividade principal e as sub-classes da
aplicação especi�cadas no manifesto, pois é onde inicia o �uxo de execução do aplicativo.
Análise de código 
Caso seja identi�cado que a amostra está ofuscada, primeiro é importante veri�car se existem desofuscadores prontos.
Caso contrário, existem ferramentas que podem fazer isso, já mencionadas em aulas anteriores.
Desofuscação e descriptogra�a 
Faz parte do processo de análise a fase de execução da amostra em um emulador aliado a uma ferramenta de análise
comportamental para assim entender as funcionalidades da aplicação. Caso alguma técnica de detecção de emulador
sejaimplementada, é necessário identi�cá-la e removê-la do código-fonte.
Análise comportamental 
Às vezes, é difícil entender certas funcionalidades da aplicação, especialmente aquelas em que há uma forte interação
com o sistema operacional. Nesses casos, a execução das instruções passo a passo pode ser necessária para auxiliar a
análise.
Sempre utilize emuladores que suportem a criação de snapshots, para que seja possível retornar ao estado original e
reproduzir a mesma situação quantas vezes forem necessárias.
Depuração 
Apple
A Apple foi fundada em 1976 para vender um dos primeiros computadores pessoais do mundo. No entanto, seus sistemas
operacionais modernos, como macOS, iOS, watchOS e tvOS, são baseados principalmente na solução NeXTSTEP desenvolvida
pela NeXT, Inc., uma empresa fundada por Steve Jobs após sua renúncia da Apple em 1985, e adquirida pela Apple em 1997.
Todos os sistemas operacionais modernos da Apple são baseados em um
conjunto de componentes uni�cados, como o sistema operacional Darwin,
que é baseado no kernel híbrido XNU.
O macOS foi lançado em 2001; antes disso, uma série de sistemas operacionais desenvolvidos entre 1984 e 2001 para a
família Macintosh de PC estava em uso. Derivado do NeXTSTEP, foi originalmente baseado em Unix, particularmente, BSD com
o microkernel Mach.
Além das linguagens C/C++ tradicionais, as principais linguagens de programação que a Apple suporta em seus produtos são
Object-C e Swift, essa última desde 2014. As interações entre os aplicativos e o SO são possíveis por meio da API nativa,
chamada Cocoa.
Já o iOS é relativamente novo e foi criado exclusivamente para dispositivos móveis,afetando o modelo de segurança
introduzido com ele. Outros sistemas operacionais mais recentes, como watchOS e tvOS, são amplamente baseados nele.
Semelhante ao macOS, o desenvolvimento pode ser feito nas linguagens de programação Object-C e Swift, e a API, nesse caso,
é chamada CocoaTouch, que também inclui recursos voltados para dispositivos móveis, como reconhecimento de gestos.
Todos os dispositivos com iOS usam processadores baseados em ARM.
Segurança
A primeira proteção do iOS é a cadeia de inicialização segura. Isso signi�ca que todos os componentes envolvidos no processo
de criação são assinados pela Apple e, portanto, constituem uma cadeia de con�ança, incluindo o seguinte:
ROM de inicialização: O primeiro código
executado assim que o dispositivo é ligado.
Localizado na memória como somente
leitura, ele veri�ca o próximo estágio, o
bootloaderiBoot ou o Bootloader de baixo
nível . Uma falha nesse estágio resulta no
dispositivo entrando no modo de proteção –
Device Firmware Upgrade (DFU).
2
iBoot: Uma vez concluído, ele veri�ca o kernel
do sistema operacional antes de permitir que
seja carregado. Uma falha no estágio iBoot
ou LLB faz com que o dispositivo entre no
modo de recuperação.
Kernel do iOS: Após a inicialização, um
mecanismo denominado
KernelIntegrityProtection (KIP), proteção da
integridade do Kernel, é habilitado. Seu
objetivo é manter o kernel e o código do driver
em uma região de memória protegida para
que não seja acessível em operações de
gravação depois que a inicialização for
concluída.
Nos modos de recuperação e DFU, o dispositivo pode ser atualizado ou restaurado para um estado válido do sistema
operacional. A diferença entre eles é que o modo de recuperação funciona principalmente por meio do iBoot, que é
essencialmente uma parte do sistema operacional, podendo ser atualizado ou modi�cado, se necessário.
Atenção
Em contraste, o DFU faz parte da memória somente leitura (ROM) e não pode ser violado.
O processo de inicialização garante que apenas o código assinado pela Apple possa ser instalado e executado, o que serve
como proteção contra bootkits e ameaças semelhantes.
Além disso, a Apple se opõe fortemente ao downgrade de software para versões mais antigas e menos seguras; por isso,
introduz um mecanismo chamado autorização de software de sistema que impede a instalação desse tipo de aplicações.Proteção de dados



https://stecine.azureedge.net/webaula/estacio/go0682/aula10.html
Em termos de criptogra�a, a Apple introduziu vários recursos importantes para torná-la extremamente robusta e altamente
produtiva.
Cada dispositivo iOS tem seus IDs exclusivos (UID) e IDs de grupo (GID) para serem usados em operações criptográ�cas, em
que o UID é exclusivo para o dispositivo e o GID é compartilhado por todos os processadores do mesmo tipo.
01
O Secure Enclave é um coprocessador seguro que inclui um gerenciador de chaves baseado em hardware, o qual é
isolado do processador principal para fornecer uma camada extra de segurança.
02
As chaves criptográ�cas são geradas dentro desse coprocessador utilizando um gerador de números aleatórios de
hardware verdadeiro; normalmente, os geradores de números de software são pseudo-aleatórios.
03
A criptogra�a de arquivos é implementada com base na tecnologia chamada Proteção de Dados. Ela gera uma nova
chave AES de 256 bits para cada arquivo criado no dispositivo. Em dispositivos mais novos, o modo de criptogra�a
AES-XTS é usado, enquanto os dispositivos mais antigos apresentam o modo AES-CBC.
04
Essa chave por arquivo é então criptografada com a chave de classe correspondente, que varia para diferentes tipos
de dados e é tratada de forma diferente de acordo com ela.
05
Quando o usuário de�ne uma senha, a proteção de dados é ativada automaticamente. Como ele está conectado ao
UID do dispositivo, que não está acessível, é impossível aplicar senhas de força bruta sem que o dispositivo esteja
�sicamente presente.
Existem outros mecanismos implementados para complicar a força bruta como, por exemplo, contagem de iterações para
desacelerá-la, atrasos de tempo de resposta para cada tentativa ou, como última ação, a limpeza automática de dados após
inserção de vários valores inválidos consecutivos.
Comentário
Outros mecanismos de autenticação, como TouchID e FaceID, trabalham em estreita colaboração com essa tecnologia.
Todos os dados con�denciais que pertencem a aplicativos podem ser armazenados no chaveiro do iOS, que consiste em um
banco de dados SQLite em que os valores são criptografados usando o algoritmo AES-256-GCM.
Esse chaveiro possui sua própria classe para lidar com diferentes tipos de dados. Dessa forma, os desenvolvedores podem
impedir o acesso a certos dados em circunstâncias especí�cas, por exemplo, quando o dispositivo está bloqueado. Os itens de
chaveiro podem ser compartilhados por vários aplicativos, mas apenas quando vêm do mesmo desenvolvedor.
 Certi�cados
 Clique no botão acima.
O iOS requer que todos os códigos em execução no dispositivo sejam assinados usando um certi�cado válido emitido
pela própria Apple; isso é feito para garantir a integridade do código e da fonte.
Uma exceção notável a essa regra é o código assinado com certi�cados de programa corporativo, cujo objetivo é
principalmente permitir a distribuição de software proprietário para uso interno ou versões beta para teste apenas
dentro de uma organização.
Pode ser muito difícil para um invasor obter um certi�cado válido, mas, mesmo em caso de sucesso, a Apple tem a
opção de revogar imediatamente o mesmo caso seja identi�cada alguma atividade maliciosa.
Todos os aplicativos são executados de forma conteinerizada, para que possam acessar apenas os recursos
necessários para executar sua função. Eles são executados sob o usuário móvel sem privilégios e não há APIs que
permitem o escalonamento de privilégios próprios.
Cada aplicativo tem seu próprio diretório para armazenar arquivos e não pode coletar ou alterar informações
associadas a outros aplicativos; apenas aplicativos que pertencem ao mesmo grupo e vêm do mesmo desenvolvedor
podem acessar um conjunto limitado de itens compartilhados.
Análise estática e dinâmica
Como sabemos, as linguagens de programação mais comuns usadas para escrever código para plataformas Apple são
Objetive-C e Swift. A desmontagem terá uma aparência diferente dependendo da linguagem que o autor do malware escolher,
mas, em ambos os casos, praticamente as mesmas ferramentas podem ser utilizadas para análise.
Análise estática
É ideal que as ferramentas de análise estática sejam multiplataforma, pois o acesso a um computador Mac ou VM disponível
para executar a aplicação nele não é simples. Com isso, a análise pode ser realizada em outros sistemas operacionais sem
afetar a e�cácia.
Antes que o código malicioso possa ser analisado, primeiro ele precisa ser obtido. Existem algumas ferramentas que permitem
essa aquisição e que são multiplataformas, como as seguintes:
7-zip iTunes iMazing
Pode ser usada para extrair
executáveis reais de pacotes
DMG e IPA, formatos de
arquivos para instalação, tanto
do MacOS quanto do iOS.
Se a aplicação em análise estiver hospedada na
AppStore, a maneira mais fácil de obtê-la é utilizando
o iTunes antes da versão 12.7. Depois de baixada, a
aplicação pode ser encontrada no subdiretório
Aplicativos Móveis.
Alternativa comercial ao iTunes que pode ser
utilizada para gerenciar aplicativos oficiais
da AppStore e obter dados de aplicativos do
dispositivo sem qualquer manipulação no
aparelho.
Após a aquisição, faz-se necessário a ferramenta para realizar a desmontagem. A seguir, listaremos as ferramentas
comumente utilizadas para trabalhar com a desmontagem e que são multiplataformas:
1
IDA
A mesma que utilizamos na análise em ambiente Windows
e Linux, é uma ferramenta poderosa que também pode ser
usada para analisar arquivos Mach-O, padrões para esse
tipo de ambiente.
2
Hopper
Inicialmente implementada para a plataforma Mac, então os
autores estão familiarizados com seus componentes
internos. Apresenta um desmontador e descompilador e
suporta as linguagens Objective-C e Swift
2
radare2
Alternativa de código aberto, permite que os analistas
desmontem e analisem arquivos Mach-O.
4
RetDec
Esse descompilador de multiplataforma suporta vários
formatos de arquivo, incluindo Mach-O, para várias
arquiteturas.
5
Ghidra
Recém-lançada pela NSA – Agência de Segurança Nacional
dos EUA, é uma ferramenta de código aberto que também
oferece suporte a executáveis da Apple.
Além disso, ferramentas que já abordamos, como �le, strings, dentre outras,podem ser usadas para extrair informações de
executáveis.
Análise dinâmica
Controles de segurança mais rígidos e o AppSandbox no iOS geralmente evitam que os pesquisadores realizem análises de
forma simples; portanto, frequentemente, o uso de dispositivos desbloqueados com o gerenciador de pacotes Cydia instalado é
preferível.
O Cydia oferece um mercado de aplicativos alternativo com muitas ferramentas úteis para �ns de engenharia reversa. Além do
Cydia, é importante instalar a aplicação OpenSSH, que permite que o analista execute comandos no dispositivo de teste a partir
do PC conectado.
Também é possível con�gurar ferramentas de monitoramento para iOS, embora isso possa exigir uma certa perícia por parte
do analista. Felizmente, existem várias ferramentas que tornam isso possível:
Theos: Conjunto de ferramentas de desenvolvimento para iOS. Um desses utilitários é o logify, que pode ser usado
para gerar arquivos de registro que facilitam o entendimento da aplicação.
Cycrypt: Conjunto de ferramentas que permite aos analistas modi�car a funcionalidade da aplicação em execução
por meio de injeções da lógica necessária.
Frida: Oferece vários recursos úteis para modi�car o �uxo de execução por meio de injeções de JavaScript ou
apenas para monitorá-lo, por meio de rastreamento de método através do frida-trace.
fsmon/�lemon: Essas ferramentas de código aberto podem ser usadas para monitorar eventos do sistema de
arquivos.
Em relação ao monitoramento de rede, a própria Apple fornece um mecanismo de Interface Virtual Remota (RVI) para ser
usado no Mac conectado ao dispositivo via USB. Depois de criada com a ferramenta rvictl, a interface pode ser usada em
conjunto com o tcpdump no Mac para registrar todoo tráfego do dispositivo móvel.
Além disso, assim como com o macOS, é possível redirecionar o tráfego de rede necessário para um mecanismo de controle
de rede, como um proxy, por exemplo, e revisar ou modi�car o pacote, se necessário.
Comentário
Como último tópico, vale reforçar sobre o Jailbreak. O jailbreak geralmente se aplica a dispositivos móveis iOS e tem como
objetivo a obtenção de privilégios elevados para remover certas restrições de software.
Existem vários motivos pelos quais os usuários podem querer fazer isso com seus dispositivos, tais como:
Obter acesso à funcionalidade extra;
Desbloquear telefones bloqueados por operadoras;
Instalar aplicações não aprovadas.
Embora os termos jailbreaking e root sejam frequentemente usados de forma intercambiável, o jailbreak é um termo mais
amplo, pois também envolve desbloquear o bootloader para modi�car o sistema operacional, bem como permitir a instalação
de aplicativos não assinados ou aplicativos distribuídos fora da AppStore, conforme já mencionado.
Atividade
1. Das diferenças de arquitetura entre RISC e CISC, pode-se a�rmar:
I. RISC executa a mesma tarefa com menos instruções do que o CISC.
II. CISC consome menos energia em relação ao RISC.
III. RISC é o conjunto de instruções da arquitetura ARM
a) Apenas I está correta.
b) Apenas II está correta.
c) Apenas III está correta.
d) I e II estão corretas.
e) I e III estão corretas.
2. Qual dos diretórios abaixo é acessível a todos os usuários, no ambiente Android?
a) /data/data/
b) /sdcard/
c) /root/
d) /boot/
e) /sbin/
3. Qual o nome do mecanismo presente no iOS responsável porproteger o kernel e o código do driver?
a) iBoot
b) Low-LevelBootloader
c) KernelIntegrityProtection
d) Device Firmware Upgrade
e) Boot ROM
Notas
Jailbreaking1
Jailbreaking é o processo de contornar vários tipos diferentes de restrições do usuário �nal. Os principais são: 
• A capacidade de modi�car e substituir o sistema operacional, controlado pela tecnologia de bootloader, bloqueado no iOS; 
• Instalação de aplicativos não o�ciais; e 
• Obtenção de privilégios elevados.
Bootloader de baixo nível2
Low-Level Boot loader (LLB)Referências
ANLEY, C. The shellcoder’sHandbook: discoveringandexploringsecurityholes. 2.ed. [S.1.]: WileyPublishing, Inc., 2007.
DUNHAM, K.et al. Androidmalwareandanalysis. CRC Press, 2014.
KLEYMENOV, A.;THABET, A. MasteringMalwareAnalysis: The complete malwareanalyst'sguidetocombatingmalicious software,
APT, cybercrime, andIoTattacks. PacktPublishingLtd, 2019.
LIGH, M.H. et al. The ArtofMemoryForensics: DetectingMalwareandThreats in Windows Linux and Mac Mamory, Indianapolis,
Indiana:J. Wiley& Sons, 2014.
SIKORSKI,M.;HONIG, A. PracticalMalwareAnalysis: The Hands-On GuidetoDissectingMalicious Software(1. ed.). No Starch
Press,2012.
TANENBAUM, A.S. Organização Estruturada de Computadores. 5.ed. São Paulo: Pearson Prentice Hall, 2010.
Próxima aula
Explore mais
Finalizamos nossa jornada, agora você deve prosseguir e aprofundar neste vasto mundo da análise de aplicações maliciosas. A
importância deste assunto tem incrementado a cada dia, pois malwares cada vez mais complexos estão sendo
implementados. Foi possível ver que cada sistema operacional possui suas peculiaridades e o autor da aplicação deve
implementá-la com determinadas características para atuar no sistema escolhido. Portanto, cada dia como analista haverá
uma novidade. Abordamos um aspecto geral pois não haveria tempo para aprofundarmos em cada um dos assuntos.
Convidamos você a buscar mais bibliogra�as para se aprofundar.