Mobile Security: Vulnerabilidades em Android e iOS

Mobile como Superfície de Ataque

Em 2024, o tráfego mobile ultrapassou 60% do total global de internet. O smartphone é, para a maioria das pessoas, o dispositivo principal de acesso bancário, comunicação corporativa, autenticação 2FA e armazenamento de credenciais. Um dispositivo que carrega biometria, tokens de sessão, credenciais de email, mensagens criptografadas e acesso a VPNs corporativas é, por definição, um tesouro para qualquer atacante.

A segurança mobile, no entanto, ainda é tratada como cidadã de segunda classe em muitas organizações. Enquanto aplicações web recebem scans de vulnerabilidade regulares, WAFs e CI/CD pipelines com SAST/DAST integrados, os apps mobile frequentemente chegam à produção com hardcoded secrets, certificados pinados de forma inadequada, comunicação com APIs sem validação de integridade e dados sensíveis armazenados em SharedPreferences ou UserDefaults em texto puro.

No contexto do CEH v13, mobile security aparece como módulo dedicado porque o atacante ético precisa entender que o vetor mobile não é um subconjunto menor da web — é uma superfície de ataque com características próprias, ferramentas próprias e vetores de exploração que não existem no mundo desktop.

Estatísticas que justificam o foco

• 60%+ do tráfego web global vem de dispositivos móveis (StatCounter, 2024).
• O Play Store removeu mais de 1 milhão de apps por violação de política em 2023 — muitos continham malware ou spyware.
• 85% dos apps móveis testados em 2023 tinham pelo menos uma vulnerabilidade na OWASP Mobile Top 10 (NowSecure).
• O custo médio de uma violação de dados envolvendo dispositivos móveis é de $4.5M (IBM, 2024).

Arquitetura Android

Android é um sistema operacional de código aberto baseado no kernel Linux, desenvolvido pelo Google. Sua arquitetura é organizada em camadas que vão desde o kernel até as aplicações de usuário, cada uma com mecanismos de segurança específicos.

Camadas da arquitetura

• Linux Kernel — Fornece sandboxing via namespaces, SELinux (Security-Enhanced Linux), seccomp filters e controle de permissões de arquivo baseado em UID. Cada app roda com um UID único.
• Hardware Abstraction Layer (HAL) — Interface entre o kernel e drivers específicos de hardware (câmera, sensores, Bluetooth).
• Android Runtime (ART) — Executa bytecode Dalvik (formato DEX). Desde Android 5.0, ART substituiu a Dalvik VM, oferecendo Ahead-of-Time (AOT) compilation.
• Native Libraries — Bibliotecas C/C++ (libc, OpenSSL, SQLite, OpenGL ES) acessíveis via JNI (Java Native Interface).
• Java API Framework — APIs Java/Kotlin que os desenvolvedores usam: Activity Manager, Content Providers, Package Manager, etc.
• System Apps & User Apps — Camada de aplicação, incluindo apps pré-instalados (Launcher, Settings, Phone) e apps de terceiros.

O APK

Um APK (Android Package) é essencialmente um arquivo ZIP contendo:

• classes.dex — Bytecode compilado da aplicação (Dalvik).
• resources.arsc — Recursos compilados (strings, layouts, imagens).
• AndroidManifest.xml — Declarativo de permissões, activities, services, broadcast receivers, content providers.
• res/ — Recursos brutos (layouts, drawables, valores).
• META-INF/ — Assinatura do APK (certificate e digest).
• lib/ — Bibliotecas nativas (.so) por arquitetura (armeabi-v7a, arm64-v8a, x86).

O APK é o formato que o pentester manipula. Descompilar, modificar e reempacotar um APK é o fluxo básico de testes dinâmicos em Android.

Permissões

Android usa um sistema de permissões baseado em declaração no manifest e aprovação pelo usuário. As permissões se dividem em:

• Normal — Acesso a recursos de baixo risco (internet, vibration). Concedidas automaticamente na instalação.
• Dangerous — Acesso a recursos sensíveis (câmera, localização, contatos). Exigem consentimento explícito do usuário em runtime (desde Android 6.0).
• Signature — Apenas concedidas se o app solicitante foi assinado com a mesma chave do app que define a permissão.
• Special — Permissões do sistema (SYSTEM_ALERT_WINDOW, WRITE_SETTINGS) com fluxo de aprovação separado.

Play Store vs. Sideload

O Google Play Store oferece uma camada adicional de segurança: Google Play Protect analisa apps automaticamente (estático + comportamental), verifica assinaturas e pode desabilitar apps remotamente. No entanto, não é infalível — apps maliciosos passam pela análise regularmente.

Sideload (instalação de APKs fora da loja) é onde o atacante age. Android permite sideload por padrão (ativado em Settings → Security), e muitos usuários o habilitam para instalar apps não disponíveis na Play Store. APKs de fontes não confiáveis são um vetor clássico de infecção.

SafetyNet e Play Integrity

SafetyNet (e seu sucessor, Play Integrity API) é o mecanismo do Google para verificar a integridade do dispositivo: detecta root, bootloader desbloqueado, custom ROMs e ambientes emulados. Apps que implementam SafetyNet podem se recusar a rodar em dispositivos comprometidos.

Para o pentester, bypassar SafetyNet é frequentemente necessário para testar apps em dispositivos rooted ou emulators. Ferramentas como Magisk Hide, Shamiko e módulos Xposed são usadas para esse fim.

Arquitetura iOS

iOS é baseado em Darwin/ BSD (o mesmo núcleo do macOS), com uma arquitetura significativamente mais restritiva que Android. A Apple adota um modelo de segurança deny-by-default — tudo é proibido até ser explicitamente permitido.

Elementos-chave da segurança iOS

• App Sandbox — Cada app roda em um sandbox que restringe acesso ao filesystem, rede, hardware e outros apps. O sandbox é aplicado pelo kernel via sandbox profile (linguagem SBPL). Um app só acessa o que o sistema explicitamente permite.
• Keychain — Um storage criptografado para senhas, chaves, certificados e tokens. Dados do Keychain são criptografados com uma chave derivada do passcode do dispositivo + chave do hardware (Secure Enclave). Apps podem compartilhar itens do Keychain via Keychain Access Groups.
• Secure Enclave — Um coprocessador dedicado presente desde o A7 (iPhone 5s). Armazena biometria (Touch ID, Face ID data), chaves de criptografia e realiza operações criptográficas de forma isolada — nem o kernel tem acesso direto aos dados dentro da Secure Enclave.
• Code Signing — Todo app executável no iOS deve ser assinado com um certificado emitido pela Apple (ou um certificado de desenvolvedor registrado). O kernel verifica a assinatura antes de carregar o binário. Isso impede execução de código não autorizado — e é o principal obstáculo para jailbreak.
• App Review — A Apple mantém um processo de revisão humana + automatizada para apps publicados na App Store. Embora não seja perfeito, filtra muitos apps com comportamento malicioso antes da publicação.
• Address Space Layout Randomization (ASLR) — Presente desde iOS 4.3, randomiza posições de memória para dificultar exploits de memory corruption.
• Data Protection — Criptografia de dados em repouso integrada ao filesystem. Usa classes de proteção (NSFileProtectionComplete, NSFileProtectionCompleteUnlessOpen, etc.) que determinam quando os dados são descriptografados (device unlocked, first unlock, etc.).

Jailbreak

Jailbreak é o processo de remover as restrições de sandbox e code signing do iOS, permitindo acesso root e instalação de software não aprovado pela Apple. Para o pentester, um dispositivo com jailbreak é essencial para instalar ferramentas como Frida, Cycript e acessar filesystem de outros apps.

As principais ferramentas de jailbreak incluem checkra1n (exploit bootrom, irreparável pela Apple em dispositivos afetados), unc0ver e Dopamine (iOS 15+). O estado do jailbreak é um jogo de gato e rato: cada versão do iOS fecha exploits, e a comunidade encontra novos.

Vulnerabilidades Comuns em Aplicações Mobile

Insecure Data Storage

A vulnerabilidade mais prevalente em apps mobile. Dados sensíveis (tokens, senhas, dados pessoais, PINs) armazenados em formato não criptografado em:

• Android: SharedPreferences, SQLite databases, arquivos em /data/data/com.app/, External Storage acessível por qualquer app com READ_EXTERNAL_STORAGE.
• iOS: UserDefaults (plist em texto puro), SQLite databases, arquivos no sandbox Documents/Caches, Keychain com acesso grupo inadequado.

# Exemplo: dump de SharedPreferences de um app Android em device rooted
adb shell
su
cat /data/data/com.vulnerable.app/shared_prefs/credentials.xml
# Resultado:
# <map>
#   <string name="auth_token">eyJhbGciOiJIUzI1NiIs...</string>
#   <string name="user_password">senha123</string>
# </map>

Insecure Communication

Apps que se comunicam com APIs via HTTP em vez de HTTPS, ou que aceitam certificados autoassinados sem validação, expõem dados em trânsito a ataques de Man-in-the-Middle (MitM). Mesmo apps que usam HTTPS podem ter a implementação comprometida:

• setHostnameVerifier() que aceita qualquer hostname.
• TrustManager customizado que confia em todos os certificados (X509TrustManager vazio).
• Desabilitação de certificate pinning para facilitar debug em staging — que vai para produção.

Component Hijacking (Android)

Android apps são compostos por quatro tipos de componentes: Activities, Services, Broadcast Receivers e Content Providers. Quando esses componentes são exportados sem proteção adequada (sem permission check), outros apps podem interagir com eles:

• Activity Hijacking — Outro app lança uma activity da vítima para phishing (ex: falsa tela de login). O atributo android:exported="true" no manifest torna a activity acessível.
• Service Hijacking — Um app malicioso inicia um service da vítima para executar ações em contexto privilegiado.
• Broadcast Injection — Broadcast receivers não protegidos podem receber intents maliciosas que alteram o comportamento do app.
• Content Provider SQL Injection — Providers que aceitam query parameters diretamente sem sanitização.

# Verificar componentes exportados de um APK
aapt dump xmltree app.apk AndroidManifest.xml | grep -E "exported"
# ou via MobSF: analysis report mostra todos os exported components

# Explorar content provider exposto
adb shell content query --uri content://com.vulnerable.app.provider/users
# Se não há permission check, retorna dados de todos os usuários

Certificate Pinning Bypass

Certificate pinning é a técnica de associar um app a certificados TLS específicos (ou à CA que os emitiu), impedindo que um atacante MitM use certificados fraudulentos. No entanto, o pentester precisa bypassar pinning para interceptar tráfego com Burp Suite ou mitmproxy.

Técnicas de bypass incluem: Frida scripts que interceptam as APIs de validação SSL (SSLContext.init(), OkHttpClient.Builder()), patching do APK para remover a validação, uso de frameworks de instrumentation como Objection, e em iOS, SSL Kill Switch que desabilita a validação a nível de sistema.

Hardcoded Secrets

API keys, tokens de acesso, senhas de banco de dados e chaves de criptografia embutidos diretamente no código fonte ou em recursos do app. Um atacante que descompila o APK/IPA obtém esses secrets instantaneamente.

// Código vulnerável encontrado via JADX
public class ApiConfig {
    public static final String API_KEY = "AIzaSyB-EXAMPLE-KEY-FROM-PROD";
    public static final String DB_PASSWORD = "Sup3rS3cr3t!";
    public static final String SECRET = "my-hmac-secret-2024";
}

Reverse Engineering

Descompilar um app mobile é trivialmente simples em comparação com binários nativos. Android: JADX ou JEB convertem DEX para Java decompilado. iOS: class-dump, Hopper ou Ghidra para binaries Mach-O. Um atacante consegue ler toda a lógica de negócio, endpoints hardcoded, algoritmos de criptografia customizados e validações client-side.

Ferramentas para Testes em Android

MobSF (Mobile Security Framework)

Ferramenta open-source de análise estática e dinâmica para Android e iOS. Gera relatórios automatizados com informações sobre permissões, componentes exportados, hardcoded secrets, padrões inseguros de criptografia, URLs e muito mais. É o ponto de partida para qualquer assessment mobile.

# Instalação via Docker
docker run -it -p 8000:8000 opensecurity/mobile-security-framework-mobsf

# Upload de APK via web UI ou API
curl -F "file=@app.apk" http://localhost:8000/api/v1/upload
# MobSF retorna JSON com análise completa: malware scan, permissions,
# exported components, hardcoded strings, cryptography analysis

JADX

Decompilador DEX para Java. Converte bytecode Dalvik em código Java legível com highlight de syntax, navegação por classes e search. A versão GUI (jadx-gui) permite explorar o código interativamente.

# Decompilar APK
jadx -d output_dir/ target.apk

# Versão GUI
jadx-gui target.apk
# Pesquisar por "API_KEY", "password", "http://", "https://" para encontrar secrets

Apktool

Descompila APK para formato Smali (assembly do Dalvik) e recursos. Permite modificar o manifest, recursos XML, strings e código Smali, depois reempacotar o APK modificado com apktool b. Essencial para repackaging.

# Decompilar
apktool d target.apk -o decoded/

# Modificar Smali, resources, manifest...

# Reempacotar
apktool b decoded/ -o modified.apk

# Assinar com debug keystore
zipalign -v 4 modified.apk modified-aligned.apk
apksigner sign --ks ~/.android/debug.keystore modified-aligned.apk

Frida

Toolkit de instrumentation dinâmica que permite injetar snippets JavaScript em apps em runtime. Funciona em Android e iOS, com ou sem root/jailbreak. Usado para bypass de SSL pinning, root detection, manipulação de variáveis, hooking de funções criptográficas e mais.

# Bypass de SSL pinning genérico em Android
frida -U -f com.target.app --no-pause -l ssl_pinning_bypass.js

# Script genérico (Universal Android SSL Pinning Bypass)
// Hooka SSLContext.init() e TrustManager para aceitar qualquer cert
Java.perform(function() {
    var SSLContext = Java.use('javax.net.ssl.SSLContext');
    SSLContext.init.overload(
        '[Ljavax.net.ssl.KeyManager;', '[Ljavax.net.ssl.TrustManager;',
        'java.security.SecureRandom'
    ).implementation = function(km, tm, sr) {
        this.init(km, KmNullTrustManager.$new(), sr);
    };
});

ADB (Android Debug Bridge)

Ponte de debug entre computador e dispositivo Android. Fundamental para interagir com o filesystem, instalar/uninstall apps, capturar logs e transferir dados.

# Comandos essenciais do pentester
adb devices                           # Listar dispositivos conectados
adb install target.apk                # Instalar APK
adb shell pm list packages            # Listar apps instalados
adb shell dumpsys package com.app     # Detalhes do pacote (permissions, etc.)
adb logcat                            # Capturar logs do sistema
adb backup -f backup.ab com.app       # Backup de dados do app (Android <9)
adb pull /data/data/com.app/databases/  # Extrair databases (requer root)

Objection

Toolkit construído sobre Frida, focado em exploração mobile. Oferece comandos de alto nível para bypass de root detection, SSL pinning, dump de keystores, interação com atividades e mais — sem necessidade de escrever scripts Frida manualmente.

# Iniciar com objection
objection -g com.target.app explore

# Bypass de SSL pinning
android sslpinning disable

# Bypass de root detection
android root disable

# Dump de atividades
android hooking list activities

# Executar activity específica
android intent launch_activity com.target.app.LoginActivity

Ferramentas para Testes em iOS

Objection

Funciona de forma similar ao Android, mas com comandos específicos para iOS: ios sslpinning disable, ios jailbreak disable (bypass de jailbreak detection), ios keychain dump para extrair itens do Keychain, e ios plist dump para ler arquivos plist do sandbox do app.

Hopper / Ghidra

Decompiladores/disassembladores para binários Mach-O (formato executável do iOS). Hopper é comercial com interface excelente para análise interativa. Ghidra é gratuito da NSA e oferece decompilação para C pseudo- código. Essenciais para análise estática de apps iOS quando o código fonte não está disponível.

# Com ghidra: importar binary do IPA (extraído)
# Path tipicamente: Payload/App.app/App
# Ghidra identifica funções Objective-C/Swift, strings, imports e permite
# análise de fluxo de dados e referências cruzadas

Burp Suite Mobile

Para interceptar tráfego HTTPS mobile, configura-se o proxy Burp no dispositivo (manualmente ou via instalador do certificado CA). Em Android, isso requer bypass de SSL pinning (via Frida/Objection). Em iOS, é necessário instalar e confiar no certificado CA do Burp e, frequentemente, usar SSL Kill Switch para bypass de pinning.

# Configuração rápida:
# 1. Burp Suite → Proxy → Options → Edit → Bind to All Interfaces
# 2. Dispositivo → Wi-Fi → Proxy → IP do Burp : 8080
# 3. Acessar http://burp no browser do device → baixar certificado CA
# 4. iOS: Settings → General → About → Certificate Trust Settings → Enable
# 5. Rodar SSL Kill Switch (iOS) ou Frida bypass (Android)
# 6. Tráfego HTTPS agora visível no Burp Proxy → HTTP History

SSL Kill Switch

Tweak de Cydia que desabilita a validação de certificados SSL a nível de sistema no iOS jailbroken. Uma vez ativado, todo o tráfego HTTPS do dispositivo passa a ser interceptável por qualquer proxy MitM. Ferramenta indispensável para assessment mobile iOS.

keychain-dumper

Ferramenta open-source para dump do Keychain iOS em dispositivos jailbroken. Extrai todos os itens do Keychain (incluindo classes de proteção, access groups e dados criptografados/descriptografados dependendo do unlock state do dispositivo).

# No device jailbroken:
# keychain-dumper > keychain_dump.txt
# Mostra: entry class, access group, creation date, modification date,
# accessible attribute (kSecAttrAccessible), e o valor (plaintext se desbloqueado)

Repackaging de Aplicativos Android

O repackaging de APKs é a técnica de descompilar um app, modificar seu comportamento (remover pinning, injetar Frida gadget, alterar endpoints), reempacotar e reassinar o APK para instalar e testar em um dispositivo.

Fluxo completo

# 1. Obter o APK
# Via Play Store (usando APKPure, APKMirror) ou adb backup

# 2. Descompilar com Apktool
apktool d target.apk -o decoded/

# 3. Analisar e modificar
# - decoded/AndroidManifest.xml → remover segurança, exportar components
# - decoded/smali/ → modificar lógica de validação, root detection
# - decoded/res/values/strings.xml → alterar endpoints

# 4. Adicionar Frida Gadget (para instrumentation sem root)
# Copiar frida-gadget.so para decoded/lib/armeabi-v7a/
# Modificar smali da Activity principal para loadLibrary("frida-gadget")

# 5. Reempacotar
apktool b decoded/ -o repackaged.apk

# 6. Alinhar e assinar
zipalign -v 4 repackaged.apk repackaged-aligned.apk
# Gerar keystore de signing
keytool -genkey -v -keystore signing.keystore -alias mykey \
  -keyalg RSA -keysize 2048 -validity 10000
# Assinar
apksigner sign --ks signing.keystore --ks-key-alias mykey repackaged-aligned.apk

# 7. Instalar
adb install repackaged-aligned.apk

# 8. Conectar Frida ao gadget embutido
frida -U -n "Target App" -l script.js

O repackaging é especialmente útil quando o app detecta root e se recusa a rodar — ao injetar Frida Gadget via repackaging, o pentester obtém instrumentation sem que o app saiba que está sendo monitorado.

OWASP Mobile Top 10 (2024)

O OWASP Mobile Top 10 foi atualizado em 2024 para refletir as ameaças atuais do ecossistema mobile. É o framework de referência para qualquer assessment de segurança mobile, assim como o OWASP Top 10 Web é para aplicações web.

Hands-on: Análise com MobSF + JADX

Vamos simular o fluxo completo de análise de um app Android suspeito.

Passo 1 — Análise estática com MobSF

# Iniciar MobSF
docker run -d -p 8000:8000 opensecurity/mobile-security-framework-mobsf

# Upload do APK via API
curl -X POST http://localhost:8000/api/v1/upload \
  -F "file=@/path/to/target.apk" \
  -H "Authorization: Bearer API_KEY"

# MobSF retorna: {"hash": "abc123", "scan_type": "apk", "file_name": "target.apk"}
# Iniciar scan de análise estática
curl -X POST http://localhost:8000/api/v1/scan \
  -d "scan_type=apk&file_name=target.apk&hash=abc123"

O relatório MobSF inclui automaticamente:

• Permissions analysis — Lista completa de permissões declaradas, com flags de permissões perigosas.
• Exported components — Activities, services, receivers e providers exportados sem proteção.
• Browsable activities — Activities que aceitam deep links (possível phishing ou injection).
• Hardcoded secrets — Strings que parecem ser API keys, tokens, senhas (regex-based).
• Cryptography analysis — Identificação de uso de MD5, SHA1, DES, ECB mode e outros padrões fracos.
• Network security — URLs encontradas (http vs https), configurações de network security config.
• Malware analysis — Comparação com assinaturas de malware conhecidas.

Passo 2 — Análise de código com JADX

# Decompilar o APK
jadx -d jadx_output/ target.apk

# Pesquisar por padrões de vulnerabilidade
cd jadx_output/
grep -r "password" --include="*.java" .
grep -r "API_KEY\|api_key\|apikey" --include="*.java" .
grep -r "http://" --include="*.java" .                    # Endpoints HTTP
grep -r "TrustManager\|X509TrustManager" --include="*.java" .  # SSL bypass
grep -r "SharedPreferences" --include="*.java" .          # Storage inseguro
grep -r "MODE_WORLD_READABLE" --include="*.java" .        # Permissões de arquivo

# Investigar classe de configuração encontrada
cat sources/com/target/app/config/ApiConfig.java

Passo 3 — Interpretação dos resultados

Com os dados de MobSF e JADX, o pentester constrói o relatório de vulnerabilidades. Exemplo de findings típicos:

• CRITICAL: API key de produção hardcoded na classe ApiConfig.java.
• HIGH: Tokens de autenticação armazenados em SharedPreferences sem criptografia.
• HIGH: Custom TrustManager que aceita qualquer certificado TLS — interceptação de tráfego possível.
• MEDIUM: Content provider exportado sem permission check — IDOR potencial.
• MEDIUM: Senhas de banco de dados hardcoded como constantes estáticas.
• LOW: Debug logging habilitado em release build — informações sensíveis em logcat.

Contra-medidas e Proteções

Certificate Pinning

Implementar certificate pinning é a defesa primária contra MitM. Existem dois modelos:

• Public Key Pinning — Pinar o public key (SPKI hash) em vez do certificado. Permite rotação de certificado sem atualizar o app.
• Certificate Pinning — Pinar o certificado ou a CA. Mais simples mas menos flexível para rotação.

Em Android, usar Network Security Configuration (XML) é a abordagem recomendada:

<!-- res/xml/network_security_config.xml -->
<network-security-config>
  <domain-config cleartextTrafficPermitted="false">
    <domain includeSubdomains="true">api.targetapp.com</domain>
    <pin-set expiration="2025-12-31">
      <pin digest="SHA-256">BASE64_OF_PUBLIC_KEY_HASH</pin>
      <!-- Backup pin para rotação -->
      <pin digest="SHA-256">BASE64_OF_BACKUP_KEY_HASH</pin>
    </pin-set>
  </domain-config>
</network-security-config>

Root Detection

Detectar dispositivos rooted/jailbroken para impedir execução em ambientes comprometidos. Técnicas comuns:

• Android: Verificar existência do binary su, checar se Magisk está instalado (pacotes com.topjohnwu.magisk), verificar Build.TAGS para “test-keys”, checar se o app pode escrever em /system.
• iOS: Verificar existencia de arquivos de jailbreak (/bin/bash, /Applications/Cydia.app), checar se sandbox está ativo, tentar escrever em paths restritos.
• Em ambos: Usar múltiplos checks (não apenas um), anti-tampering para impedir bypass via patching, e ofuscar os checks para dificultar análise estática.

Obfuscation

Ferramentas de obfuscation tornam a análise estática significativamente mais difícil:

• ProGuard/R8 (Android, incluído no Android SDK) — Renomeia classes/métodos, remove código não utilizado, otimiza bytecode. Gratuito e padrão.
• DexGuard (Android, comercial) — Obfuscation avançada, encryption de strings, anti-debug, anti-tamper, anti-instrumentation.
• iXGuard (iOS, comercial) — Equivalente do DexGuard para iOS: obfuscation Swift/ObjC, anti-debug, anti-frida.
• SLL (Swift Language Lawyer, open-source) — Ofuscação de código Swift.

Obfuscation não substitui segurança — um atacante determinado ainda consegue analisar o código. Mas aumenta significativamente o custo de tempo e esforço do ataque.

Secure Storage

• Android: Usar EncryptedSharedPreferences (AndroidX Security Library) para dados leves. Para dados maiores, SQLCipher para databases criptografados. Nunca armazenar dados sensíveis em External Storage.
• iOS: Usar Keychain Services com classe de proteção kSecAttrAccessibleWhenUnlockedThisDeviceOnly para tokens e credenciais. Para dados estruturados maiores, Core Data com NSFileProtectionComplete. Nunca usar UserDefaults para dados sensíveis.
• Em ambos: Minimizar armazenamento de dados sensíveis no device. Prefira sempre tokens curtos com expiração (OAuth 2.0) em vez de credenciais estáticas.

Defesa em Profundidade para Mobile

• Network Security: TLS 1.2+ obrigatório, certificate pinning, HSTS, certificate transparency.
• Code Protection: Obfuscation (ProGuard/R8 mínimo), anti-debug, anti-tamper, integrity checks do APK.
• Runtime Protection: Root/jailbreak detection, emulator detection, repackaging detection (verificar assinatura do APK).
• Data Protection: Encryption at rest (EncryptedSharedPreferences, SQLCipher, Keychain), minimização de dados, token expiration.
• Authentication: Server-side validation de tudo — nunca confiar em validações client-side, biometria como fator adicional, MFA.
• Supply Chain: Auditar SDKs de terceiros, manter SBOM atualizado, monitor CVEs de dependências.
• Testing: SAST mobile integrado no CI/CD, MobSF como gate de qualidade, pentest anual de apps críticos.

Conclusão

Mobile security é uma disciplina com identidade própria — não é web security em tela pequena. O pentester que entende as arquiteturas Android e iOS, domina as ferramentas de análise estática e dinâmica, e conhece as vulnerabilidades específicas do mundo mobile está preparado para avaliar o vetor de ataque que mais cresce no cenário atual. A OWASP Mobile Top 10 fornece o framework mental; as ferramentas fornecem os meios; e a prática constante em apps de CTF e bug bounty constrói a intuição necessária para encontrar o que os scanners automatizados não encontram.