4 en PT

Traduzido do Inglês para o Português - www.onlinedoctranslator.
com
Capítulo 2-Design e arquitetura de segurança do Android 43
iniciarprograma inicializa o ambiente de espaço do usuário executando uma série de

comandos. No entanto, o Android usa uma implementação personalizada deiniciar.Em vez
de executar scripts de shell baseados em nível de execução de /etc/init.d,O Android executa
comandos com base em diretivas encontradas em /init.rc.Para diretivas específicas do
dispositivo, pode haver um arquivo chamado /init.[hw].rc,Onde [como]é o codinome do
hardware para aquele dispositivo específico. O seguinte é um trecho do conteúdo de /
init.rcem um HTC One V:
serviço dbus /system/bin/dbus-daemon --system --nofork

classe principal
soquete dbus stream 660 bluetooth bluetooth usuário
bluetooth
grupo bluetooth net_bt_admin
serviço bluetoothd /system/bin/bluetoothd -n

classe principal
soquete bluetooth stream 660 bluetooth soquete dbus_bluetooth
stream 660 bluetooth bluetooth
# init.rc ainda não suporta a aplicação de recursos, então execute como root e
# deixe o bluetoothd soltar o uid para o bluetooth com os recursos corretos do linux grupo
bluetooth net_bt_admin misc
Desativado
serviço bluetoothd_one /system/bin/bluetoothd -n

classe principal
soquete bluetooth stream 660 bluetooth soquete dbus_bluetooth
stream 660 bluetooth bluetooth
# init.rc ainda não suporta a aplicação de recursos, então execute como root e
# deixe o bluetoothd soltar o uid para o bluetooth com os recursos corretos do linux grupo
bluetooth net_bt_admin misc
Desativado
um disparo
# DRM Discretix
service dx_drm_server /system/bin/DxDrmServerIpc -f -o allow_other \
/data/DxDrm/fuse
na propriedade:ro.build.tags=test-keys
iniciar htc_ebdlogd
na propriedade:ro.build.tags=release-keys
iniciar htc_ebdlogd_rel
serviço zchgd_offmode /system/bin/zchgd -pseudooffmode

usuário root
gráficos de raiz do grupo
Desativado
44 Capítulo 2-Design e arquitetura de segurança do Android
Essesiniciarscripts especificam várias tarefas, incluindo
- Iniciando serviços ou daemons que devem ser iniciados na inicialização, por meio do
serviçodiretiva
- Especificando o usuário e o grupo em que o serviço deve ser executado, de acordo com os
argumentos recuados abaixo de cada entrada de serviço
- Definir propriedades de todo o sistema e opções de configuração que são expostas por meio
do Serviço de propriedade
- Registro de ações ou comandos a serem executados na ocorrência de determinados

eventos, como modificação de uma propriedade do sistema ou montagem de um
sistema de arquivos, por meio da diretiva “on”
O Serviço de Propriedade
Escondido dentro do Androidiniciarprocesso é oServiço de propriedade, que fornece um recurso

de configuração de valor-chave persistente (por inicialização), mapeado em memória. Muitos
componentes do SO e da estrutura dependem dessas propriedades, que incluem itens como
configuração de interface de rede, opções de rádio e até mesmo configurações relacionadas à
segurança, cujos detalhes são discutidos no Capítulo 3.
As propriedades podem ser recuperadas e definidas de várias maneiras. Por exemplo,
usando os utilitários de linha de comandoobterpropesetprop,respectivamente; programaticamente
em código nativo atravéspropriedade_geteconjunto_propriedadedentrolibcutils;ou programa-
matematicamente usando oandroid.os.SystemPropertiesclass (que por sua vez chama as
funções nativas mencionadas). Uma visão geral do serviço de propriedade é
mostrada na Figura 2-2.
definidor de propriedades
soquete de domínio unix
consumidor imobiliário serviço de propriedade
ler Escreva carregar
propriedade_espaço de trabalho
(memoria compartilhada) arquivo persistente
Figura 2-2:O serviço de propriedade do Android

Executando oobterpropcomando em um dispositivo Android (neste caso, um HTC One V),

você vê uma saída que inclui opções DalvikVM, papel de parede atual, configuração de
interface de rede e até mesmo URLs de atualização específicos do fornecedor:
root@android :/ # getprop [dalvik.vm.dexopt-

flags]: [m=y] [dalvik.vm.heapgrowthlimit]:
[48m] [dalvik.vm.heapsize]: [128m]
...
[dhcp.wlan0.dns1]: [192.168.1.1]
[dhcp.wlan0.dns2]: []
[dhcp.wlan0.gateway]: [192.168.1.1]
[dhcp.wlan0.ipaddress]: [192.168.1.125]
[dhcp.wlan0.leasetime]: [7200]
...
[ro.htc.appupdate.exmsg.url]:
[http://apu-msg.htc.com/extra-msg/rws/and-app/msg]
[ro.htc.appupdate.exmsg.url_CN]:
[http://apu-msg.htccomm.com.cn/extra-msg/rws/and-app/msg]
[ro.htc.appupdate.url]:
[http://apu-chin.htc.com/check-in/rws/and-app/update]
...
[service.brcm.bt.activation]: [0]
[service.brcm.bt.avrcp_pass_thru]: [0]
Algumas propriedades, que são definidas como “somente leitura”, não podem ser alteradas,
mesmo pelo root (embora haja algumas exceções específicas do dispositivo). Estes são designados
peloroprefixo:
[ro.seguro]: [0]
[ro.serialno]: [HT26MTV01493]
[ro.setupwizard.enterprise_mode]: [1]
[ro.setupwizard.mode]: [DISABLED]
[ro.sf.lcd_density]: [240]
[ro.telephony.default_network]: [0] [ro.use_data_netmgrd]: [true]
[ro.vendor.extension_library]: [/system/lib/libqc-opt.so]
Você pode encontrar alguns detalhes adicionais do Serviço de Propriedade e suas

implicações de segurança no Capítulo 3.
Camada de Interface de Rádio
A camada de interface de rádio (RIL), abordada em detalhes no Capítulo 11, fornece a

funcionalidade que coloca o “telefone” em “smartphone”. Sem este componente, um
dispositivo Android não poderá fazer chamadas, enviar ou receber
mensagens de texto ou acessar a Internet sem Wi-Fi. Como tal, será encontrado em execução
em qualquer dispositivo Android com dados de celular ou capacidade de telefonia.
depurado
O principal recurso de relatório de falhas do Android gira em torno de um daemon chamado
depurado. Quando o daemon do depurador é inicializado, ele abre uma conexão com o recurso
de log do Android e começa a ouvir clientes em um soquete de namespace abstrato. Quando
cada programa é iniciado, o vinculador instala manipuladores de sinal para lidar com
determinados sinais.
Quando um dos sinais capturados ocorre, o kernel executa a função de manipulador de
sinal,debugger_signal_handler.Esta função de manipulador se conecta ao soquete
mencionado acima, conforme definido porDEBUGGER_SOCKET_NAME.Depois de conectado, o
vinculador notifica a outra extremidade do soquete (depurado)que o processo de destino
falhou. Isso serve para avisardepuradoque ele deve invocar seu processamento e, assim,
criar um relatório de falha.
ADB
A ponte de depuração do Android, ouADB, é composto por algumas peças, incluindo o
adbddaemon no dispositivo Android, oadbservidor na estação de trabalho host e o
correspondenteadbcliente de linha de comando. O servidor gerencia a conectividade entre
o cliente e o daemon executado no dispositivo alvo, facilitando tarefas como executar um
shell; aplicativos de depuração (através do Java Debug Wire Protocol); encaminhamento de
soquetes e portas; transferência de arquivo; e instalar/desinstalar pacotes de aplicativos.
Como um breve exemplo, você pode executar odispositivos adbcomando para listar seus
dispositivos conectados. Como o ADB ainda não está rodando em nosso host, ele é inicializado,
escutando em 5037/tcp para conexões de clientes. Em seguida, você pode especificar um
dispositivo de destino por seu número de série e executarshell adb,dando-lhe um shell de
comando no dispositivo:
% dispositivos adb
* não corra, Daemon. iniciando agora na porta 5037 *
* daemon iniciado com sucesso * Lista de
dispositivos conectados
D025A0A024441MGK dispositivo
HT26MTV01493 dispositivo
% adb -s HT26MTV01493 shell

root@android :/ #
Podemos ver também que o daemon ADB,adbd,está sendo executado no dispositivo de

destino, grepping para o processo (ou neste caso, usandopgrep):
root@android :/ # busybox pgrep -l adbd 2103 /

sbin/adbd
O ADB é fundamental para o desenvolvimento com dispositivos e emuladores Android. Como tal,
vamos usá-lo fortemente ao longo do livro. Você pode encontrar informações detalhadas
ção sobre o uso doadbcomando emhttp://developer.android.com/tools/help/
adb.html.
Volume Daemon
O Volume Daemon, ouvold, é responsável por montar e desmontar vários
sistemas de arquivos no Android. Por exemplo, quando um cartão SD é inserido,
voldprocessa esse evento verificando se há erros no sistema de arquivos do cartão SD
(como ao iniciarfsck)e montando o cartão no caminho apropriado (ou seja, /mnt/
sdcard).Quando o cartão é puxado ou ejetado (manualmente pelo usuário)
volddesmonta o volume de destino.
O Volume Daemon também lida com a montagem e desmontagem de arquivos do Android Secure
Container (ASEC). Eles são usados para criptografar pacotes de aplicativos quando armazenados em
sistemas de arquivos inseguros, como FAT. Eles são montados por meio de dispositivos de loopback no
tempo de carregamento do aplicativo, normalmente em /mnt/asseg.
Opaque Binary Blobs (OBBs) também são montados e desmontados pelo Volume Daemon.
Esses arquivos são empacotados com um aplicativo para armazenar dados criptografados com
um segredo compartilhado. Ao contrário dos contêineres ASEC, no entanto, as chamadas para
montar e desmontar OBBs são realizadas pelos próprios aplicativos, e não pelo sistema. O
trecho de código a seguir demonstra a criação de um OBB com
SuperSecretKeycomo a chave compartilhada:
obbFile = "caminho/para/algum/obbfile";
storageRef = (StorageManager) getSystemService(STORAGE_SERVICE);
storageRef.mountObb(obbFile, "SuperSecretKey", obbListener); obbContent =
storageRef.getMountedObbPath(obbFile);
Dado que o Volume Daemon é executado como root, ele é um alvo atraente tanto em sua
funcionalidade quanto em sua potencial vulnerabilidade. Você pode encontrar detalhes sobre ataques
de escalonamento de privilégios contravolde outros serviços semelhantes no Capítulo 3.
Outros serviços
Existem vários outros serviços que são executados em muitos dispositivos Android,
fornecendo funcionalidades adicionais, embora não necessariamente críticas
(dependendo do dispositivo e do serviço). A Tabela 2-2 destaca alguns desses serviços,
suas finalidades e seus níveis de privilégio no sistema (UID, GID e quaisquer grupos
suplementares para esse usuário, que podem ser especificados noinit.rcarquivos).
Tabela 2-2:Serviços nativos do espaço do usuário
ID, GID,
SUPLEMENTAR
SERVIÇO DESCRIÇÃO GRUPOS
líquido Presente no Android 2.2+, usado pelo Network UID: 0 / raiz
Management Service para configurar interfaces de
GID: 0 / raiz
rede, executar o daemon PPP (pppd), tethering e
outras tarefas semelhantes.
servidor de mídia Responsável por iniciar serviços relacionados à UID: 1013 / mídia
mídia, incluindo Audio Flinger, Media Player
GID: 1005 / áudio
Service, Camera Service e Audio Policy Service.
Grupos: 1006 /
Câmera
1026 / drmpc
3001 / net_bt_admin
3002 / net_bt
3003 / inet
3007 / net_bw_acct
dbus- Gerencia o IPC/passagem de mensagens específico do D-Bus UID: 1002/bluetooth
demônio (principalmente para componentes não específicos do Android).
GID: 1002 / bluetooth
Grupos: 3001 /
net_bt_admin
instalado Gerencia a instalação de pacotes de aplicativos nos UID: 1012 / instalar
dispositivos (em nome do Package Manager),
GID: 1012 / instalar
incluindo a otimização inicial do bytecode Dalvik
Executable (DEX) em pacotes de aplicativos (APKs). Em dispositivos pré-4.2:
UID: 0 /raiz
GID: 0 /raiz
armazenamento de chaves Responsável pelo armazenamento seguro de pares chave- UID: 1017 / armazenamento de chaves
valor no sistema (protegido por uma senha definida pelo

GID: 1017 / armazenamento de chaves
usuário).
Grupos: 1026 / drmpc
drmserver Fornece as operações de baixo nível para gerenciamento de UID: 1019/drm

direitos digitais (DRM). Os aplicativos interagem com esse
GID: 1019/drm
serviço por meio de classes de nível superior no pacote DRM
(no Android 4.0+). Grupos: 1026 /
drmrpc
3003 / inet
ID, GID,
SUPLEMENTAR
SERVIÇO DESCRIÇÃO GRUPOS
militar- Atua como árbitro para registro/cancelamento de registro de UID: 1000 / sistema
velho serviços de aplicativos com terminais IPC do Binder.
GID: 1000 / sistema
superfície- Presente no Android 4.0+, o compositor de exibição UID: 1000 / sistema

dedo responsável por construir o quadro/tela gráfico a ser
GID: 1000 / sistema
exibido e enviar para o driver da placa gráfica.
Ueventd Presente no Android 2.2+, daemon de espaço do usuário para UID: 0 / raiz
manipular eventos de sistema e dispositivo e realizar ações
GID: 0 /raiz
correspondentes, como carregar módulos de kernel
apropriados.
Como dito anteriormente, esta não é de forma alguma uma lista exaustiva. Comparando a lista de
processos,init.rc,e sistema de arquivos de vários dispositivos ao de um dispositivo Nexus, muitas vezes
revela uma infinidade de serviços fora do padrão. Eles são particularmente interessantes porque seu
código pode não ter a mesma qualidade dos serviços principais presentes em todos os dispositivos
Android.
O Kernel
Embora a base do Android, o kernel Linux, seja bastante bem documentada e
compreendida, existem algumas diferenças notáveis entre o kernel Linux vanilla e o
que é usado pelo Android. Esta seção explica algumas dessas mudanças,
especialmente aquelas que são pertinentes à segurança do Android.
A bifurcação do Android
No início, o Google criou um fork centrado no Android do kernel Linux, pois muitas
modificações e adições não eram compatíveis com a árvore principal do kernel Linux. No
geral, isso inclui aproximadamente 250 patches, desde suporte ao sistema de arquivos e
ajustes de rede até recursos de gerenciamento de processo e memória. De acordo com
um engenheiro do kernel, a maioria desses patches “representa uma limitação que os
desenvolvedores do Android encontraram no kernel do Linux”. Em março de 2012, os
mantenedores do kernel do Linux mesclaram as modificações do kernel específicas do
Android na árvore principal. A Tabela 2-3 destaca algumas das adições/alterações no
kernel da linha principal. Discutiremos vários deles com mais detalhes posteriormente
nesta seção.
Tabela 2-3:Principais mudanças do Android no kernel do Linux
MUDANÇA DE KERNEL DESCRIÇÃO

Encadernador Mecanismo IPC com recursos adicionais, como validação de
segurança de chamadores/chamados; usado por vários serviços de
sistema e estrutura
ashmem Memória Compartilhada Anônima; alocador de memória compartilhada baseado em arquivo;

usa o Binder IPC para permitir que os processos identifiquem os descritores de arquivos da
região da memória
pmem Alocador de Memória de Processo; usado para gerenciar grandes regiões contíguas
de memória compartilhada
registrador Recurso de registro em todo o sistema
RAM_CONSOLE Armazena mensagens de log do kernel na RAM para visualização após um kernel panic
modificações "oom" O assassino “Sem memória” mata os processos quando a memória fica baixa; no
fork do Android, o OOM mata os processos mais cedo que o kernel vanilla, pois a
memória está sendo esgotada
wakelocks Recurso de gerenciamento de energia para evitar que um dispositivo entre no estado
de baixo consumo de energia e permaneça responsivo
Temporizadores de alarme Interface do kernel paraGerenciador de alarmes,para instruir o kernel

a agendar o “acordar”
Rede paranóica Restringe certas operações e recursos de rede a IDs de grupos

específicos
saída temporizada / gpio Permite que programas de espaço do usuário alterem e restaurem registros GPIO após
um período de tempo
yaffs2 Suporte para o sistema de arquivos flash yaffs2
Encadernador
Talvez uma das adições mais importantes ao kernel Linux do Android tenha sido um driver conhecido
comoEncadernador. O Binder é um mecanismo IPC baseado em uma versão modificada do
OpenBinder, originalmente desenvolvido pela Be, Inc., e posteriormente pela Palm, Inc. O Binder do
Android é relativamente pequeno (aproximadamente 4.000 linhas de código-fonte em dois arquivos),
mas é fundamental Funcionalidade do Android.
Em poucas palavras, o driver do kernel do Binder facilita a arquitetura geral do Binder.
O Binder – como uma arquitetura – opera em um modelo cliente-servidor. Ele permite que
um processo invoque métodos em processos “remotos” de forma síncrona. A arquitetura
do Binder abstrai os detalhes subjacentes, fazendo com que essas chamadas de método
pareçam ser chamadas de funções locais. A Figura 2-3 mostra o fluxo de comunicação do
Binder.
Processo A Procuração Processo B com Threads

Driver do fichário
Figura 2-3:Comunicação do fichário
O Binder também usa informações de ID de processo (PID) e UID como meio de identificar o
processo de chamada, permitindo que o chamador tome decisões sobre o controle de acesso.
Isso normalmente ocorre por meio de chamadas para métodos comoEncadernador
. getCallingUideBinder.getCallingPid,ou através de verificações de nível superior,
comocheckCallingPermission.
Um exemplo disso na prática seria aACCESS_SURFACE_FLINGERpermissão. Essa
permissão geralmente é concedida apenas aográficosusuário do sistema e permite o
acesso à interface IPC do Binder do serviço de gráficos Surface Flinger. Além disso, a
associação ao grupo do chamador - e o subsequente porte da permissão necessária -
é verificada por meio de uma série de chamadas para as funções mencionadas
acima, conforme ilustrado pelo seguinte trecho de código:
const int pid = ipc->getCallingPid(); const int uid =

ipc->getCallingUid();
if ((uid != AID_GRAPHICS) &&
!PermissionCache::checkPermission(sReadFramebuffer,
pid, uid)) {
ALOGE("Permissão Negação: "
"não é possível ler framebuffer pid=%d, uid=%d", pid, uid); retornar
PERMISSION_DENIED;
}
Em um nível mais alto, os métodos IPC expostos, como os fornecidos por serviços vinculados,
normalmente são destilados em uma interface abstrata por meio da linguagem de definição de
interface Android (AIDL). AIDL permite que dois aplicativos usem interfaces “acordadas” ou
padrão para enviar e receber dados, mantendo a interface separada da implementação. AIDL é
semelhante a outros arquivos de linguagem de definição de interface ou, de certa forma,
arquivos de cabeçalho C/C++. Considere o seguinte snippet AIDL de amostra:
// IRemoteService.aidl
pacote com.example.android;
// Declare quaisquer tipos não padrão aqui com instruções de importação
/** Exemplo de interface de serviço */

interface IRemoteService {
/** Solicita o ID do processo deste serviço, para fazer
coisas ruins com ele. */
int getPid();
/** Demonstra alguns tipos básicos que você pode usar como parâmetros
* e retorna valores em AIDL.
*/
void basicTypes(int anInt, long aLong, boolean aBoolean,
flutuar aFlotar,
double aDouble, String aString);
}
Este exemplo AIDL define uma interface simples,IRemoteService,juntamente

com dois métodos:getPideTipos básicos.Um aplicativo que se vincula ao serviço
expondo essa interface seria capaz de chamar os métodos mencionados acima -
facilitados pelo Binder.
ashmem
Memória compartilhada anônima, ouashmempara resumir, foi outra adição ao fork do kernel
Android Linux. O driver ashmem basicamente fornece uma interface de memória compartilhada
baseada em arquivo e contada por referência. Seu uso é predominante em muitos dos
principais componentes do Android, como Surface Flinger, Audio Flinger, System Server e
DalvikVM. Como o ashmem foi projetado para reduzir automaticamente os caches de memória
e recuperar regiões de memória quando a memória disponível em todo o sistema estiver baixa,
ele é adequado para ambientes com pouca memória.
Em um nível baixo, usar ashmem é tão simples quanto chamarashmem_create_region, e
usandommapno descritor de arquivo retornado:
int fd = ashmem_create_region("AlgumAshmem", tamanho); if(fd ==

0) {
dados = mmap(NULL, tamanho, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); . . .
Em um nível superior, o Android Framework fornece aArquivo de Memóriaclass, que serve

como um wrapper em torno do driver ashmem. Além disso, os processos podem usar o recurso
Binder para compartilhar posteriormente esses objetos de memória, aproveitando os recursos
de segurança do Binder para restringir o acesso. Aliás, o ashmem provou ser a fonte de uma
falha bastante séria no início de 2011, permitindo uma escalada de privilégios através das
propriedades do Android. Isso é abordado com mais detalhes no Capítulo 3.
pmem
Outro driver personalizado específico do Android épmem, que gerencia memória grande
e fisicamente contígua variando entre 1 megabyte (MB) e 16 MB (ou mais, dependendo da
implementação). Essas regiões são especiais, pois são compartilhadas entre processos de
espaço do usuário e outros drivers de kernel (como drivers de GPU). Ao contrário do
ashmem, o driver pmem requer que o processo de alocação mantenha um descritor de
arquivo para o heap de memória pmem até que todas as outras referências sejam
fechadas.
Registrador
Embora o kernel do Android ainda mantenha seu próprio mecanismo de registro de

kernel baseado em Linux, ele também usa outro subsistema de registro, coloquialmente
conhecido comoregistrador. Este driver atua como suporte para ologcatcomando, usado
para visualizar buffers de log. Ele fornece quatro buffers de log separados, dependendo
do tipo de informação:principal, rádio, evento,esistema.A Figura 2-4 mostra o fluxo de eventos
de log e componentes que auxiliam o registrador.
oa Principalbuffer é geralmente o mais volumoso e é a fonte de eventos relacionados a
aplicativos. Os aplicativos normalmente chamam um método doandroid.util.Log
classe, onde o método invocado corresponde ao nível de prioridade de entrada de log - por
exemplo, oLog.imétodo para “informativo”,Log.dpara "depurar" ouLog.epara logs de nível de
“erro” (muito parecido com syslog).
Visão geral do sistema de registro do Android
Alvo
programa Java
System.out
/System.err
com.android.internal.os
Programa nativo android.util.Log Hospedeiro
Android Printstream
ADT no Eclipse
padrão
logcat
padrão liblog
/stderr adbd adbserver
Do utilizador
Núcleo adb logcat
a Principal64 KB rádio
registrador 64 KB
/dev/log/main /dev/log/main
/dev/log/radio evento sistema /dev/log/radio
256 KB
/dev/log/evento 64 KB /dev/log/evento
/dev/log/sistema /dev/log/sistema
Figura 2-4:Arquitetura do sistema de registro do Android

osistemabuffer também é uma fonte de muitas informações, principalmente para eventos de

todo o sistema gerados por processos do sistema. Esses processos utilizam oprintln_native
método noandroid.util.Slogclasse. Esse método, por sua vez, chama o código nativo
específico para log nesse buffer específico.
As mensagens de log podem ser recuperadas usando ologcatcomando, com os
buffers principal e do sistema sendo as fontes padrão. No código a seguir,
executamosadb -d logcatpara ver o que está acontecendo no dispositivo conectado:
$ adb -d logcat
- - - - - - - - - início de /dev/log/system D/MobileDataStateTracker( 1600): null: Transmissão
recebida: ACTION_ANY_DATA_CONNECTION_STATE_CHANGEDmApnType=null != recebido
apnType=internet
D/MobileDataStateTracker( 1600): null: Transmissão recebida:

ACTION_ANY_DATA_CONNECTION_STATE_CHANGEDmApnType=null != recebido
apnType=internet
D/MobileDataStateTracker( 1600): httpproxy: Transmissão recebida:
ACTION_ANY_DATA_CONNECTION_STATE_CHANGEDmApnType=httpproxy != recebido
apnType=internet
D/MobileDataStateTracker( 1600): null: Transmissão recebida:
ACTION_ANY_DATA_CONNECTION_STATE_CHANGEDmApnType=null != recebido
apnType=internet
...
- - - - - - - - - início de /dev/log/main
...
D/memalloc( 1743): /dev/pmem: base de buffer de desmapeamento: 0x5396a000 tamanho:
12820480 deslocamento: 11284480
D/memalloc( 1743): /dev/pmem: base de buffer de desmapeamento:0x532f8000
tamanho:1536000 deslocamento:0
D/memalloc( 1743): /dev/pmem: base de buffer de desmapeamento: 0x546e7000 tamanho:
3072000 deslocamento: 1536000
D/libEGL ( 4887): carregado /system/lib/egl/libGLESv1_CM_adreno200.so ( 4887):
D/libEGL carregado /system/lib/egl/libGLESv2_adreno200.so
I/Adreno200-EGLSUB( 4887): <ConfigWindowMatch:2078>: Formato RGBA_8888. D/
OpenGLRenderer(4887): Habilitando o modo de depuração 0
V/chromium(4887): external/chromium/net/host_resolver_helper/host_ resolver_helper.cc:66:
[0204/172737:INFO:host_resolver_helper.cc(66)] DNSPreResolver::Init got
hostprovider:0x5281d220
V/cromo(4887): externo/cromo/net/base/host_resolver_impl.cc:1515:
[0204/172737:INFO:host_resolver_impl.cc(1515)]
HostResolverImpl::SetPreresolver preresolver:0x013974d8 V/WebRequest( 4887):
WebRequest::WebRequest, setPriority = 0 I/InputManagerService( 1600):
[unbindCurrentClientLocked] Desativa o cliente do método de entrada.
I/InputManagerService( 1600): [startInputLocked] Habilita o cliente do método de

entrada.
V/chromium(4887): external/chromium/net/disk_cache/hostres_plugin_bridge.cc:52:
[0204/172737:INFO:hostres_plugin_bridge.cc(52)] StatHubCreateHostResPlugin
inicializando... . . .
ologcatO comando é tão comumente executado que o ADB realmente fornece um

atalho para executá-lo em um dispositivo de destino. Ao longo do livro, fazemos uso
extensivo do comando logcat para monitorar processos e o estado geral do sistema.
Rede paranóica
O kernel do Android restringe as operações de rede com base na associação de grupo
suplementar do processo de chamada - uma modificação do kernel conhecida comoRede
paranóica. Em um nível alto, isso envolve o mapeamento de um AID e, posteriormente,
um GID, para uma declaração ou solicitação de permissão no nível do aplicativo. Por
exemplo, a permissão de manifestoandroid.permission.INTERNETefetivamente mapeia para o
AID_INETAID—ou GID 3003. Esses grupos, IDs e seus respectivos recursos são
definidos eminclude/linux/android_aid.hna árvore de origem do kernel e são
descritos na Tabela 2-4.
Tabela 2-4:Recursos de rede por grupo

DEFINIÇÃO DO AUXÍLIO ID / NOME DO GRUPO CAPACIDADE
Permite a criação de qualquer socket

AID_NET_BT_ADMIN 3001 / net_bt_admin Bluetooth, além de diagnosticar e
gerenciar conexões Bluetooth
AID_NET_BT 3002 / net_bt Permite a criação de soquetes SCO,

RFCOMM ou L2CAP (Bluetooth)
AID_INET 3003 / inet Permite a criação de soquetes

AF_INET e AF_INET6
AID_NET_RAW 3004 / net_raw Permite o uso de soquetes RAW e
PACKET
AID_NET_ADMIN 3005 / net_admin Concede a capacidade CAP_NET_ADMIN,

permitindo interface de rede, tabela de
roteamento e manipulação de soquete
Você pode encontrar IDs de grupo adicionais específicos do Android na fonte AOSP
repositório emsystem/core/include/private/android_filesystem_config.h.
Segurança complexa, explorações complexas
Depois de examinar mais de perto o design e a arquitetura do Android, fica claro que os
desenvolvedores do sistema operacional Android criaram um sistema muito complexo. Seu
design permite que eles sigam o princípio de privilégio mínimo, que afirma que qualquer
componente em particular deve ter acesso apenas às coisas que ele absolutamente requer. Ao
longo deste livro, você verá evidências substanciais do uso desse princípio. Embora sirva para
melhorar a segurança, também aumenta a complexidade.
O isolamento de processos e a redução de privilégios são técnicas que geralmente são

fundamentais no design de sistemas seguros. As complexidades dessas técnicas complicam o
sistema tanto para desenvolvedores quanto para invasores, o que aumenta o custo de
desenvolvimento para ambas as partes. Quando um invasor está elaborando seu ataque, ele
deve dedicar um tempo para entender completamente as complexidades envolvidas. Com um
sistema como o Android, explorar uma única vulnerabilidade pode não ser suficiente para obter
acesso total ao sistema. Em vez disso, o invasor pode ter que explorar várias vulnerabilidades
para atingir o objetivo. Para resumir, atacar com sucesso um sistema complexo requer uma
exploração complexa.
Um ótimo exemplo do mundo real desse conceito é o exploit “diaggetroot” usado para fazer
root no HTC J Butterfly. Para obter acesso root, essa exploração aproveitou vários problemas
complementares. Essa exploração específica é discutida em mais detalhes no Capítulo 3.
Resumo
Este capítulo forneceu uma visão geral do design e da arquitetura de segurança do

Android. Apresentamos a sandbox do Android e os modelos de permissões usados
pelo Android. Isso incluiu a implementação especial do Android de mapeamentos
Unix UID/GID (AIDs), bem como as restrições e recursos aplicados em todo o sistema.
Também abordamos as camadas lógicas do Android, incluindo aplicativos, o Android

Framework, o DalvikVM, o código nativo do espaço do usuário e o kernel do Linux. Para
cada uma dessas camadas, discutimos os principais componentes, especialmente aqueles
relacionados à segurança. Destacamos importantes adições e modificações que os
desenvolvedores do Android fizeram no kernel do Linux.
Essa cobertura de alto nível do design geral do Android ajuda a enquadrar os
capítulos restantes, que mergulham ainda mais nos componentes e camadas
apresentados neste capítulo.
O próximo capítulo explica como e por que assumir o controle total do seu dispositivo
Android. Ele discute vários métodos genéricos para fazer isso, bem como algumas
técnicas anteriores que dependem de vulnerabilidades específicas.
APÓS
CH 3
Enraizando você r Dispositivo
O processo de obtenção de privilégios de superusuário em um dispositivo Android é comumente

chamado deenraizando. A conta de superusuário do sistema é ubiquamente chamadaraiz, daí o termo
enraizando. Essa conta especial tem direitos e permissões sobre todos os arquivos e programas em
um sistema baseado em UNIX. Ele tem controle total sobre o sistema operacional.
Há muitas razões pelas quais alguém gostaria de obter privilégios administrativos em um
dispositivo Android. Para os propósitos deste livro, nosso principal motivo é auditar a segurança de
um dispositivo Android sem estar limitado pelas permissões do UNIX. No entanto, algumas pessoas
desejam acessar ou alterar arquivos do sistema para alterar uma configuração ou comportamento
embutido em código, ou para modificar a aparência com temas personalizados ou animações de
inicialização. O enraizamento também permite que os usuários desinstalem aplicativos pré-instalados,
façam backups e restaurações completos do sistema ou carreguem imagens e módulos
personalizados do kernel. Além disso, existe uma classe inteira de aplicativos que exigem permissões
de root para serem executados. Estes são normalmente chamadosaplicativos raize incluem programas
como firewalls baseados em iptables, bloqueadores de anúncios, overclocking ou aplicativos de
tethering.
Independentemente do motivo do root, você deve se preocupar com o fato de o processo de
root comprometer a segurança do seu dispositivo. Uma razão é que todos os dados do usuário
são expostos a aplicativos que receberam permissões de root. Além disso, pode deixar uma
porta aberta para alguém extrair todos os dados do usuário do dispositivo se você o perder ou
for roubado, especialmente se os mecanismos de segurança (como bloqueios do carregador de
inicialização ou atualizações de recuperação assinadas) foram removidos durante o root.
57
58 Capítulo 3-Enraizando seu dispositivo
Este capítulo aborda o processo de fazer root em um dispositivo Android de maneira

genérica, sem fornecer detalhes específicos sobre uma versão concreta do Android ou modelo
de dispositivo. Ele também explica as implicações de segurança de cada etapa executada para
obter root. Finalmente, o capítulo fornece uma visão geral de algumas falhas que foram usadas
para fazer o root de dispositivos Android no passado. Essas falhas foram corrigidas nas versões
atuais do Android.
AVISO Fazer root no seu dispositivo, se você não sabe o que está fazendo, pode
fazer com que seu telefone pare de funcionar corretamente. Isso é especialmente verdadeiro se você modificar
qualquer arquivo do sistema. Felizmente, a maioria dos dispositivos Android pode retornar ao estado original de
fábrica, se necessário.
Entendendo o layout da partição
As partições são unidades de armazenamento lógico ou divisões feitas dentro da memória de

armazenamento persistente do dispositivo. O layout refere-se à ordem, deslocamentos e tamanhos das várias
partições. O layout da partição é tratado pelo carregador de inicialização na maioria dos dispositivos, embora
em alguns casos raros também possa ser tratado pelo próprio kernel. Esse particionamento de
armazenamento de baixo nível é crucial para a funcionalidade adequada do dispositivo.
O layout da partição varia entre fornecedores e plataformas. Dois dispositivos
diferentes normalmente não têm as mesmas partições ou o mesmo layout. No entanto,
algumas partições estão presentes em todos os dispositivos Android. As mais comuns são
as partições de inicialização, sistema, dados, recuperação e cache. De um modo geral, a
memória flash NAND do dispositivo é particionada usando o seguinte layout de partição:
- carregador de inicialização:Armazena o programa carregador de inicialização do telefone,
que cuida da inicialização do hardware quando o telefone inicializa, inicializa o kernel do
Android e implementa modos de inicialização alternativos, como o modo de download.
- respingo:Armazena a primeira imagem da tela inicial vista logo após ligar o

dispositivo. Geralmente contém o logotipo do fabricante ou do operador. Em
alguns dispositivos, o bitmap da tela inicial é incorporado no próprio carregador de
inicialização, em vez de ser armazenado em uma partição separada.
- bota:Armazena a imagem de inicialização do Android, que consiste em um kernel Linux (
zImage) e o disco de RAM do sistema de arquivos raiz (initrd).
- recuperação:Armazena uma imagem mínima de inicialização do Android que fornece funções de
manutenção e funciona como uma proteção contra falhas.
- sistema:Armazena a imagem do sistema Android montada como /sistemaem um

dispositivo. Esta imagem contém a estrutura do Android, bibliotecas, binários do
sistema e aplicativos pré-instalados.
- dados do usuário:Também chamada de partição de dados, é o armazenamento interno do
dispositivo para dados de aplicativos e arquivos do usuário, como fotos, vídeos, áudio e
downloads. Isso é montado como /dadosem um sistema inicializado.
Capítulo 3-Enraizando seu dispositivo 59
- cache:Usado para armazenar vários arquivos de utilitários, como logs de

recuperação e pacotes de atualização baixados pelo ar. Em dispositivos com
aplicativos instalados em um cartão SD, ele também pode conter odalvik-cachepasta,
que armazena o cache da Dalvik Virtual Machine (VM).
- rádio:Uma partição que armazena a imagem de banda base. Essa partição geralmente está
presente apenas em dispositivos com recursos de telefonia.
Determinando o layout da partição

Você pode obter o layout da partição de um determinado dispositivo de várias maneiras.
Primeiro, você pode ver o conteúdo dopartiçõesentrada no /procsistema de arquivo. A
seguir está o conteúdo desta entrada em um Samsung Galaxy Nexus executando o
Android 4.2.1:
shell@android :/data $ cat /proc/partitions major minor
#blocks name
31 0 1024 mtdblock0
179 0 15388672 mmcblk0
179 1 128 mmcblk0p1
179 2 3584 mmcblk0p2
179 3 20480 mmcblk0p3
179 4 8192 mmcblk0p4
179 5 4096 mmcblk0p5
179 6 4096 mmcblk0p6
179 7 8192 mmcblk0p7
259 0 12224 mmcblk0p8
259 1 16384 mmcblk0p9
259 2 669696 mmcblk0p10
259 3 442368 mmcblk0p11
259 4 14198767 mmcblk0p12
259 5 64 mmcblk0p13
179 16 512 mmcblk0boot1
179 8 512 mmcblk0boot0
Em adição aoprocentrada, também é possível obter um mapeamento desses arquivos

de dispositivo para suas funções lógicas. Para fazer isso, verifique o conteúdo do diretório
específico do System-on-Chip (SoC) em /dev/bloco/plataforma.Lá, você deve encontrar um
diretório chamadopor nome,onde cada nome de partição está vinculado ao seu dispositivo
de bloco correspondente. O trecho a seguir mostra o conteúdo desse diretório no mesmo
Samsung Galaxy Nexus do exemplo anterior.
shell@android :/dev/block/platform/omap/omap_hsmmc.0/by-name $ ls -l lrwxrwxrwx root
raiz 2013-01-30 20:43 boot -> /dev/block/mmcblk0p7 2013-01-30 20:43
raiz lrwxrwxrwx raiz cache -> /dev/block/mmcblk0p11 2013-01-30 20:43 dgs -> /dev/
raiz lrwxrwxrwx raiz block/ mmcblk0p6 2013-01-30 20:43 efs -> /dev/block/mmcblk0p3
raiz lrwxrwxrwx raiz 2013-01-30 20:43 metadados -> /dev/block/mmcblk0p13 2013-01-30
raiz lrwxrwxrwx raiz 20:43 misc -> /dev/block /mmcblk0p5 2013-01-30 20:43 param -> /
raiz lrwxrwxrwx raiz dev/block/mmcblk0p4
raiz lrwxrwxrwx raiz
raiz lrwxrwxrwx raiz 2013-01-30 20:43 rádio -> /dev/block/mmcblk0p9 2013-01-30 20:43
raiz lrwxrwxrwx raiz recovery -> /dev/block/mmcblk0p8 2013-01-30 20:43 sbl -> /dev/
raiz lrwxrwxrwx raiz block/ mmcblk0p2 2013-01-30 20:43 system -> /dev/block/
raiz lrwxrwxrwx raiz mmcblk0p10 2013-01-30 20:43 userdata -> /dev/block/mmcblk0p12
raiz lrwxrwxrwx raiz 2013-01-30 20:43 xloader -> /dev/block /mmcblk0p1
raiz lrwxrwxrwx raiz
Além disso, existem outros lugares onde você pode obter informações sobre o
layout da partição. O /etc/vold.fstabarquivo, o log de recuperação (/cache/recuperação/
last_log),e os logs do kernel (viadmesgou /proc/kmsg)são conhecidos por conter
informações de layout de partição em alguns casos. Se tudo mais falhar, você pode
encontrar algumas informações sobre partições usando omontarcomando ou exame
ing /proc/montagens.
Entendendo o processo de inicialização
O carregador de inicialização geralmente é a primeira coisa que é executada quando o hardware é

ligado. Na maioria dos dispositivos, o carregador de inicialização é o código proprietário do fabricante
que cuida da inicialização de hardware de baixo nível (relógios de configuração, RAM interna, mídia de
inicialização e assim por diante) e fornece suporte para carregar imagens de recuperação ou colocar o
telefone no modo de download. O carregador de inicialização em si geralmente é composto de vários
estágios, mas nós o consideramos apenas como um todo aqui.
Quando o carregador de inicialização termina de inicializar o hardware, ele carrega o kernel
do Android e o initrd da partição de inicialização na RAM. Finalmente, ele salta para o kernel
para permitir que continue o processo de inicialização.
O kernel do Android faz todas as tarefas necessárias para que o sistema Android funcione
corretamente no dispositivo. Por exemplo, ele inicializará memória, áreas de entrada/saída (E/S),
proteções de memória, manipuladores de interrupção, agendador de CPU, drivers de dispositivo e
assim por diante. Finalmente, ele monta o sistema de arquivos raiz e inicia o primeiro processo de
espaço do usuário,iniciar.
oiniciarprocesso é o pai de todos os outros processos do espaço do usuário. Quando é
iniciado, o sistema de arquivos raiz do initrd ainda está montado para leitura/gravação. o
/init.rcscript serve como o arquivo de configuração parainiciar.Ele especifica as ações a serem
executadas ao inicializar os componentes do espaço do usuário do sistema operacional. Isso
inclui iniciar alguns serviços básicos do Android, comorildpara telefonia,mtpd
para acesso VPN e o daemon Android Debug Bridge (adbd).Um dos serviços,
Zygote, cria a Dalvik VM e inicia o primeiro componente Java, System Server.
Por fim, outros serviços do Android Framework, como o Telephony Manager,
são iniciados.
A seguir, mostra-se um trecho doinit.rcscript de um LG Optimus Elite (VM696).
Você pode encontrar mais informações sobre o formato deste arquivo em
asystem/core/init/readme.txtarquivo do repositório Android Open Source Project

(AOSP).
[...]
serviço adbd /sbin/adbd
Desativado
[...]
serviço ril-daemon /system/bin/rild
socket rild stream 660 root rádio socket rild-debug
stream 660 sistema de rádio root usuário
grupo rádio cache inet misc áudio sdcard_rw qcom_oncrpc diag [...]
serviço zygote /system/bin/app_process -Xzygote /system/bin --

zygote --start-system-server
sistema raiz socket zygote stream 660
ao reiniciar a gravação /sys/android_power/request_state acordar ao
reiniciar a gravação /sys/power/state on
ao reiniciar reinicie a mídia ao
reiniciar reinicie o netd
[...]
Quando a inicialização do sistema for concluída, umAÇÃO_BOTA_CONCLUÍDO O evento é

transmitido para todos os aplicativos registrados para receber essa intenção de transmissão em
seu manifesto. Quando isso for concluído, o sistema será considerado totalmente inicializado.
Acessando o modo de download
Na descrição do processo de inicialização, mencionamos que o carregador de inicialização

geralmente fornece suporte para colocar o telefone emmodo de download. Este modo permite
que o usuário atualize o armazenamento persistente em um nível baixo por meio de um
processo normalmente chamadopiscando. Dependendo do dispositivo, o flash pode estar
disponível viainicialização rápida protocolo, um protocolo proprietário, ou mesmo ambos. Por
exemplo, o Samsung Galaxy Nexus suporta o modo proprietário ODIN e fastboot.
NOTAFastboot é o protocolo padrão do Android para flashear imagens de disco completo para
partições específicas via USB. O utilitário cliente fastboot é uma ferramenta de linha de
comando que você pode obter no Android Software Development Kit (SDK) disponível emhttps://
developer.android.com/sdk/ou o repositório AOSP.
Entrar em modos alternativos, como o modo de download, depende do carregador de inicialização.

Quando certas combinações de pressionamento de tecla são mantidas durante a inicialização, o carregador
de inicialização inicia o modo de download em vez de fazer o processo normal de inicialização do kernel do
Android. A combinação exata de pressionamento de tecla varia de dispositivo para
dispositivo, mas y tributo,
o dispositivo s Ônibus
(USB). Figu
Figura 3-1:Modo Fastboot e ODIN
Quando uma conexão USB é estabelecida entre o carregador de inicialização e o computador

host, a comunicação ocorre usando o protocolo de download compatível com o dispositivo.
Esses protocolos facilitam a execução de várias tarefas, incluindo o flash de partições NAND, a
reinicialização do dispositivo, o download e a execução de uma imagem de kernel alternativa e
assim por diante.
Carregadores de inicialização bloqueados e desbloqueados
De um modo geral, os carregadores de inicialização bloqueados impedem que o usuário final execute
modificações no firmware do dispositivo implementando restrições no nível do carregador de
inicialização. Essas restrições podem variar, dependendo da decisão do fabricante, mas geralmente há
uma verificação de assinatura criptográfica que impede a inicialização e/ou a exibição de código não
assinado no dispositivo. Alguns dispositivos, como dispositivos Android chineses baratos, não incluem
nenhuma restrição de carregador de inicialização.
Nos dispositivos Google Nexus, o carregador de inicialização é bloqueado por padrão. No entanto,
existe um mecanismo oficial que permite que os proprietários o desbloqueiem. Se o usuário final
decidir executar um kernel personalizado, imagem de recuperação ou sistema operacional
imagem, o carregador de inicialização precisa ser desbloqueado primeiro. Para esses dispositivos,
desbloquear o carregador de inicialização é tão simples quanto colocar o dispositivo no modo fastboot
e executar o comandodesbloqueio oem fastboot. Isso requer o utilitário cliente fastboot de linha de
comando, que está disponível no Android SDK ou no repositório AOSP.
Alguns fabricantes também oferecem suporte ao desbloqueio dos carregadores de inicialização em
seus dispositivos, por dispositivo. Em alguns casos, o processo usa o procedimento de desbloqueio
padrão do fabricante de equipamento original (OEM) por meio do fastboot. No entanto, alguns casos
giram em torno de algum mecanismo proprietário, como um site ou desbloquear portal. Esses portais
geralmente exigem que o proprietário registre seu dispositivo e perca sua garantia para poder
desbloquear seu carregador de inicialização. Até o momento, HTC, Motorola e Sony suportam o
desbloqueio de pelo menos alguns de seus dispositivos.
Desbloquear o carregador de inicialização traz sérias implicações de segurança. Se o dispositivo for
perdido ou roubado, todos os dados nele contidos poderão ser recuperados por um invasor simplesmente
carregando uma imagem de inicialização personalizada do Android ou exibindo uma imagem de recuperação
personalizada. Após fazer isso, o invasor tem acesso total aos dados contidos nas partições do dispositivo.
Isso inclui contas do Google, documentos, contatos, senhas armazenadas, dados de aplicativos, fotos da
câmera e muito mais. Por causa disso, uma redefinição de dados de fábrica é realizada no telefone ao
desbloquear um carregador de inicialização bloqueado. Isso garante que todos os dados do usuário final
sejam apagados e que o invasor não possa acessá-los.
AVISO É altamente recomendável usar a criptografia do dispositivo Android. Mesmo depois
todos os dados foram apagados, é possível recuperar de forma forense os dados apagados em alguns
dispositivos.
Imagens de recuperação de estoque e personalizadas
O sistema de recuperação do Android é o mecanismo padrão do Android que permite que as

atualizações de software substituam todo o software do sistema pré-instalado no dispositivo
sem limpar os dados do usuário. É usado principalmente para aplicar atualizações baixadas
manualmente ouPelo ar(OTA). Essas atualizações são aplicadas offline após uma reinicialização.
Além de aplicar atualizações OTA, a recuperação pode executar outras tarefas, como limpar os
dados do usuário e as partições de cache.
A imagem de recuperação é armazenada na partição de recuperação e consiste em uma
imagem Linux mínima com uma interface de usuário simples controlada por botões de
hardware. A recuperação de estoque do Android é intencionalmente muito limitada em
funcionalidade. Ele faz o mínimo necessário para cumprir a compatibilidade do Android
Definições emhttp://source.android.com/compatibility/index.html.
Semelhante ao acesso ao modo de download, você acessa a recuperação pressionando uma
determinada combinação de teclas ao inicializar o dispositivo. Além de usar teclas pressionadas,
é possível instruir um sistema Android inicializado a reinicializar no modo de recuperação por
meio do comandorecuperação de reinicialização adb. A ferramenta de linha de comando Android
Debug Bridge (ADB) está disponível como parte do Android SDK
ou repositório AOSP emhttp://developer.android.com/sdk/index.html.
Um dos recursos mais usados da recuperação é aplicar um pacote de atualização. Esse

pacote consiste em um arquivo zip contendo um conjunto de arquivos a serem copiados
para o dispositivo, alguns metadados e um script de atualização. Esse script atualizador
informa à recuperação do Android quais operações devem ser executadas no dispositivo
para aplicar as modificações de atualização. Isso pode incluir a montagem da partição do
sistema, certificando-se de que as versões do dispositivo e do sistema operacional
correspondam àquela para a qual o pacote de atualização foi criado, verificando os hashes
SHA1 dos arquivos do sistema que serão substituídos e assim por diante. As atualizações
são assinadas criptograficamente usando uma chave privada RSA. A recuperação verifica a
assinatura usando a chave pública correspondente antes de aplicar a atualização. Isso
garante que apenas atualizações autenticadas possam ser aplicadas.
Extraindo um pacote de atualização OTA para Nexus 4
$descompacte 625f5f7c6524.signed-occam-JOP40D-from-JOP40C.625f5f7c.zip
Arquivo: 625f5f7c6524.signed-occam-JOP40D-from-JOP40C.625f5f7c.zip SignApk
assinado por
inflando: META-INF/com/android/metadata inflando: META-INF/com/google/
android/update-binary inflando: META-INF/com/google/android/updater-script
inflando: patch/system/app/ApplicationsProvider .apk.p inflando: patch/system/
app/ApplicationsProvider.odex.p inflando: patch/system/app/
BackupRestoreConfirmation.apk.p inflando: patch/system/app/
BackupRestoreConfirmation.odex.p [...]
inflando: patch/system/lib/libwebcore.so.p
inflando: patch/system/lib/libwebrtc_audio_preprocessing.so.p inflando: recovery/
etc/install-recovery.sh
inflando: recovery/recovery-from-boot.p inflando:
META-INF/com/android/otacert inflando: META-INF/
MANIFEST.MF
inflando: META-INF/CERT.SF inflando:
META-INF/CERT.RSA
Existem imagens personalizadas de recuperação do Android para a maioria dos dispositivos. Se um

não estiver disponível, você poderá criá-lo facilmente aplicando modificações personalizadas ao
código-fonte de recuperação do Android do repositório AOSP.
As modificações mais comuns incluídas nas imagens de recuperação personalizadas são
- Incluindo uma funcionalidade completa de backup e restauração (como script NANDroid)
- Permitir pacotes de atualização não assinados ou permitir pacotes assinados com chaves
personalizadas
- Montagem seletiva de partições de dispositivos ou cartão SD
- Fornece acesso de armazenamento em massa USB ao cartão SD ou partições de dados

- Forneça acesso completo ao ADB, com o daemon do ADB sendo executado como root
- Incluir um binário BusyBox completo

c popular são
ClockworkM 3-2
mostra estoque
Figura 3-2:Recuperação do Android e Recuperação do ClockworkMod
AVISO Mantendo uma imagem de recuperação personalizada com restrições de assinatura
removido, ou o acesso ADB completo exposto, em seu dispositivo Android também deixa uma porta aberta para
obter todos os dados do usuário contidos nas partições do dispositivo.
Enraizamento com um carregador de inicialização desbloqueado
O processo de enraizamento culmina em ter umsubinário com as permissões set-

uid adequadas na partição do sistema. Isso permite elevar privilégios sempre
que necessário. osuO binário geralmente é acompanhado por um aplicativo
Android, como SuperUser ou SuperSU, que fornece um prompt gráfico sempre
que um aplicativo solicita acesso root. Se o pedido for concedido, o aplicativo
invoca osubinário para executar o comando solicitado. Essessuwrapper Android
os aplicativos também gerenciam quais aplicativos ou usuários devem receber

acesso root automaticamente, sem avisar o usuário.
NOTAA versão mais recente do Chainfire SuperSU pode ser baixada como um
pacote de atualização de recuperação emhttp://download.chainfire.eu/supersuou
como um aplicativo independente do Google Play emhttps://play.google.com/store/
apps/details?id=eu.chainfire.supersu.
O pacote ClockworkMod SuperUser pode ser obtido no Google Play em
https://play.google.com/store/apps/details?id=com
. koushikdutta.superuser.O código fonte está disponível emhttps://github
. com/koush/Superusuário.
Em dispositivos com um carregador de inicialização desbloqueado ou desbloqueado, obter acesso root é

muito fácil, pois você não precisa confiar na exploração de uma falha de segurança não corrigida. O primeiro
passo é desbloquear o carregador de inicialização. Se você ainda não o fez, dependendo do dispositivo, você
deve usardesbloqueio oem fastbootconforme descrito na seção “Carregadores de inicialização bloqueados e
desbloqueados” ou use uma ferramenta de desbloqueio do carregador de inicialização específica do
fornecedor para desbloquear o dispositivo de forma legítima.
No momento da redação deste artigo, Motorola, HTC e Sony-Ericsson suportavam o desbloqueio do
carregador de inicialização em alguns dispositivos por meio de seus sites de portal de desbloqueio.
NOTAO portal de desbloqueio do carregador de inicialização para Motorola está

disponível emhttps://motorola-global-portal.custhelp.com/app/standalone/bootloader/
unlock-your-device-a.
O portal de desbloqueio do carregador de inicialização para HTC está disponível emhttp://www.htcdev.com/
bootloader.
O portal de desbloqueio do carregador de inicialização para SonyEricsson está
disponível emhttp://unlockbootloader.sonymobile.com/.
Quando o carregador de inicialização é desbloqueado, o usuário fica livre para fazer

modificações personalizadas no dispositivo. Neste ponto, existem várias maneiras de
incluir osubinário para a arquitetura do dispositivo na partição do sistema, com as
permissões corretas.
Você pode modificar uma imagem de fábrica para adicionar umsubinário. Neste exemplo,
descompactamos uma imagem de sistema formatada em ext4, montamos, adicionamos umsubinário
e reembale-o. Se piscarmos esta imagem, ela conterá osubinário e o dispositivo será enraizado.
mkdir systemdir
simg2img system.img system.raw
mount -t ext4 -o loop system.raw systemdir cp su
systemdir/xbin/su
chown 0:0 systemdir/xbin/su chmod
6755 systemdir/xbin/su
make_ext4fs -s -l 512M -a system custom-system.img systemdir umount
systemdir
Se o dispositivo for compatível com AOSP, você poderá compilar umuserdebugou

engCompilação do Android a partir da fonte. Visitahttp://source.android.com/source/
edifício.htmlpara obter mais informações sobre como criar o Android a partir da fonte. Essas
configurações de compilação fornecem acesso root por padrão:
curl http://commondatastorage.googleapis.com/git-repo-downloads/repo \
- o ~/bin/repo
chmod a+x ~/bin/repo
repo init -u https://android.googlesource.com/platform/manifest repo sync
fonte build/envsetup.sh almoço

full_maguro-userdebug
Se você construiu sua imagem de sistema personalizada modificando uma imagem de

fábrica ou compilando sua própria, você deve atualizar a partição do sistema para que ela tenha
efeito. Por exemplo, o comando a seguir mostra como fazer o flash desta imagem usando o
protocolo fastboot:
sistema flash fastboot custom-system.img
O método mais simples é inicializar uma imagem de recuperação personalizada. Isso

permite copiar osubinário na partição do sistema e definindo as permissões apropriadas
por meio de um pacote de atualização personalizado.
NOTAAo usar esse método, você está inicializando a imagem de recuperação personalizada sem
flashar, portanto, você a usa apenas para fazer flash de umsubinário na partição do sistema sem
modificar a partição de recuperação.
Para fazer isso, baixe uma imagem de recuperação personalizada esupacote de atualização. A
imagem de recuperação personalizada pode ser de sua escolha, desde que seja compatível com seu
dispositivo. Da mesma forma, osupacote de atualização pode ser SuperSU, SuperUser ou outro de sua
escolha.
1. Você deve colocar os dois downloads no armazenamento do dispositivo, normalmente no

cartão SD montado como /cartão SD.
2. Em seguida, coloque o dispositivo no modo fastboot.
3. Agora, abra um prompt de comando e digiteinicialização rápidarecuperação.imagem, Onde

recuperação.imagemé a imagem de recuperação bruta que você baixou.
4. No menu de recuperação, selecione a opção para aplicar um arquivo zip de

atualização e navegue até a pasta no armazenamento do dispositivo onde você
colocou o pacote de atualização com osubinário.
Além disso, os dispositivos que usam o Android 4.1 ou posterior contêm um novo recurso chamado
carregamento lateral. Esse recurso permite aplicar um zip de atualização sobre o ADB sem copiá-lo
para o dispositivo antes. Para fazer sideload de uma atualização, execute o comandosideload adbsu-
pacote.fecho eclair, Ondesu-pacote.fecho eclairé o nome do arquivo do pacote de atualização no disco
rígido do seu computador.

4 en PT

Enviado por

Direitos autorais:

Formatos disponíveis

4 en PT

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

4 en PT

Enviado por

Direitos autorais:

Formatos disponíveis

Traduzido do Inglês para o Português - www.onlinedoctranslator.

Capítulo 2-Design e arquitetura de segurança do Android 43

iniciarprograma inicializa o ambiente de espaço do usuário executando uma série de

serviço dbus /system/bin/dbus-daemon --system --nofork

serviço bluetoothd /system/bin/bluetoothd -n

serviço bluetoothd_one /system/bin/bluetoothd -n

serviço zchgd_offmode /system/bin/zchgd -pseudooffmode

Essesiniciarscripts especificam várias tarefas, incluindo

- Registro de ações ou comandos a serem executados na ocorrência de determinados

Escondido dentro do Androidiniciarprocesso é oServiço de propriedade, que fornece um recurso

soquete de domínio unix

consumidor imobiliário serviço de propriedade

ler Escreva carregar

(memoria compartilhada) arquivo persistente

Figura 2-2:O serviço de propriedade do Android

Executando oobterpropcomando em um dispositivo Android (neste caso, um HTC One V),

root@android :/ # getprop [dalvik.vm.dexopt-

Você pode encontrar alguns detalhes adicionais do Serviço de Propriedade e suas

Camada de Interface de Rádio

A camada de interface de rádio (RIL), abordada em detalhes no Capítulo 11, fornece a

% adb -s HT26MTV01493 shell

Podemos ver também que o daemon ADB,adbd,está sendo executado no dispositivo de

root@android :/ # busybox pgrep -l adbd 2103 /

Tabela 2-2:Serviços nativos do espaço do usuário

valor no sistema (protegido por uma senha definida pelo

Grupos: 1026 / drmpc

drmserver Fornece as operações de baixo nível para gerenciamento de UID: 1019/drm

superfície- Presente no Android 4.0+, o compositor de exibição UID: 1000 / sistema

Tabela 2-3:Principais mudanças do Android no kernel do Linux

MUDANÇA DE KERNEL DESCRIÇÃO

ashmem Memória Compartilhada Anônima; alocador de memória compartilhada baseado em arquivo;

registrador Recurso de registro em todo o sistema

Temporizadores de alarme Interface do kernel paraGerenciador de alarmes,para instruir o kernel

Rede paranóica Restringe certas operações e recursos de rede a IDs de grupos

yaffs2 Suporte para o sistema de arquivos flash yaffs2

Processo A Procuração Processo B com Threads

Figura 2-3:Comunicação do fichário

const int pid = ipc->getCallingPid(); const int uid =

// Declare quaisquer tipos não padrão aqui com instruções de importação

/** Exemplo de interface de serviço */

Este exemplo AIDL define uma interface simples,IRemoteService,juntamente

int fd = ashmem_create_region("AlgumAshmem", tamanho); if(fd ==

Em um nível superior, o Android Framework fornece aArquivo de Memóriaclass, que serve

Embora o kernel do Android ainda mantenha seu próprio mecanismo de registro de

Visão geral do sistema de registro do Android

Núcleo adb logcat

Figura 2-4:Arquitetura do sistema de registro do Android

osistemabuffer também é uma fonte de muitas informações, principalmente para eventos de

D/MobileDataStateTracker( 1600): null: Transmissão recebida:

I/InputManagerService( 1600): [startInputLocked] Habilita o cliente do método de

ologcatO comando é tão comumente executado que o ADB realmente fornece um

Tabela 2-4:Recursos de rede por grupo

Permite a criação de qualquer socket

AID_NET_BT 3002 / net_bt Permite a criação de soquetes SCO,

AID_INET 3003 / inet Permite a criação de soquetes

AID_NET_ADMIN 3005 / net_admin Concede a capacidade CAP_NET_ADMIN,

Segurança complexa, explorações complexas

O isolamento de processos e a redução de privilégios são técnicas que geralmente são

Este capítulo forneceu uma visão geral do design e da arquitetura de segurança do