Pentesting de Aplicações Android

Tip

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprenda e pratique Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporte o HackTricks

Conceitos Básicos de Aplicações Android

É altamente recomendável começar lendo esta página para conhecer as partes mais importantes relacionadas à segurança do Android e os componentes mais perigosos em uma aplicação Android:

Android Applications Basics

ADB (Android Debug Bridge)

Esta é a principal ferramenta necessária para conectar a um dispositivo Android (emulado ou físico).
ADB permite controlar dispositivos via USB ou Network a partir de um computador. Esta utilidade possibilita a cópia de arquivos em ambas as direções, instalação e desinstalação de apps, execução de comandos shell, backup de dados, leitura de logs, entre outras funções.

Consulte a seguinte lista de ADB Commands para aprender como usar o adb.

Smali

Às vezes é interessante modificar o código da aplicação para acessar informações ocultas (talvez senhas bem ofuscadas ou flags). Então, pode ser interessante descompilar o apk, modificar o código e recompilá-lo.
In this tutorial you can learn how to decompile and APK, modify Smali code and recompile the APK with the new functionality. Isto pode ser muito útil como uma alternativa para vários testes durante a análise dinâmica que serão apresentados. Então, mantenha sempre em mente essa possibilidade.

Outros truques interessantes

Aquisição automatizada de APKs de múltiplas fontes (justapk)

pip install justapk (Python 3.11+). A CLI gera JSON em stdout e progresso em stderr (compatível com pipes). Ele tenta uma cadeia de fallback determinística através de APK20 → F-Droid → APKPure (mobile API) → APKMirror (HTML scrape) → Uptodown (mobile API) → APKCombo (HTML scrape). Fontes protegidas por Cloudflare usam curl_cffi com impersonação de fingerprint TLS para imitar clientes reais e reduzir bloqueios por detecção de bots.

justapk download <package>              # auto fallback
justapk download <package> -s apkpure   # pin a source / version / output dir
justapk search telegram
justapk info org.telegram.messenger
justapk convert app.xapk -o output/      # merges splits, re-signs with debug key

convert mescla XAPK/split APKs e os assina com uma debug key, de modo que a assinatura/proveniência do APK resultante difere do original (usar para testes/análise, não para instalações em produção).

  • Extrair APK do dispositivo:
adb shell pm list packages
com.android.insecurebankv2

adb shell pm path com.android.insecurebankv2
package:/data/app/com.android.insecurebankv2-Jnf8pNgwy3QA_U5f-n_4jQ==/base.apk

adb pull /data/app/com.android.insecurebankv2-Jnf8pNgwy3QA_U5f-n_4jQ==/base.apk
  • Mescle todos os splits e base apks com APKEditor:
mkdir splits
adb shell pm path com.android.insecurebankv2 | cut -d ':' -f 2 | xargs -n1 -i adb pull {} splits
java -jar ../APKEditor.jar m -i splits/ -o merged.apk

# after merging, you will need to align and sign the apk, personally, I like to use the uberapksigner
java -jar uber-apk-signer.jar -a merged.apk --allowResign -o merged_signed

Android malware tradecraft (loaders, fileless DEX, persistence)

Estágio nativo + fileless DEX loaders

Alguns Android droppers embutem uma biblioteca nativa (lib*.so) que descriptografa e grava um segundo ELF (por exemplo, l.so) em um caminho temporário, carrega-o via JNI, e então carrega a lógica real como DEX apenas em memória usando dalvik.system.InMemoryDexClassLoader. Isso reduz a visibilidade estática do payload e evita gravar classes*.dex no disco.

Pontos práticos de triagem:

  • Procure por bibliotecas nativas que chamem dlopen ou System.loadLibrary muito cedo, e então resolvam métodos Java via strings ofuscadas na pilha (por exemplo, decodificadas por XOR na pilha).
  • Fique atento a InMemoryDexClassLoader em logs/strings ou hooks, o que indica execução fileless DEX.

Hook rápido do Frida para extrair o buffer DEX em memória:

Java.perform(() => {
const IM = Java.use('dalvik.system.InMemoryDexClassLoader');
IM.$init.overload('java.nio.ByteBuffer','java.lang.ClassLoader').implementation = function(buf, parent){
const arr = Java.array('byte', buf.array());
const fos = Java.use('java.io.FileOutputStream').$new("/sdcard/memdex.dex");
fos.write(arr); fos.close();
return this.$init(buf, parent);
};
});

Anti-analysis kill-switch

Loaders empacotados frequentemente se autoencerram quando verificações de emulator ou analysis falham (por exemplo, validação CPU_ABI) ao chamar:

android.os.Process.killProcess(android.os.Process.myPid());

Persistência via serviço em primeiro plano + MediaPlayer loop

Um padrão leve de persistência é manter um serviço em primeiro plano vivo com uma notificação fixada e tocar continuamente um loop de áudio quase inaudível via MediaPlayer. Isso mantém o processo “ativo” e reduz kills por inatividade do SO. Procure por uso de ForegroundService + MediaPlayer que faça loop de um asset pequeno (frequentemente de alguns segundos).

Overlay de Accessibility + sequestro de ACTION_SET_TEXT

Depois que o usuário concede Accessibility, banking trojans podem monitorar o foreground app, renderizar um overlay realista (frequentemente HTML de WebView armazenado como Base64) e substituir campos de transação usando AccessibilityNodeInfo.ACTION_SET_TEXT. Isso possibilita a substituição silenciosa do endereço do destinatário enquanto a vítima vê uma UI plausível.

Exemplo mínimo de substituição de texto:

Bundle args = new Bundle();
args.putCharSequence(AccessibilityNodeInfo.ACTION_ARGUMENT_SET_TEXT_CHARSEQUENCE,
"ATTACKER_USDT_ADDRESS");
node.performAction(AccessibilityNodeInfo.ACTION_SET_TEXT, args);

Legitimate push infrastructure as C2 gating

Ao invés de sockets customizados, algum malware usa Firebase Cloud Messaging (FCM) como canal de C2. Mensagens FCM podem acionar checagens de telemetria (estado de carregamento, % da bateria, temperatura, inatividade do usuário) e condicionar ações como mining ou fraude para furtividade.

Encrypted native payload staging with filename‑derived keys

Native payloads podem ser entregues como blobs ELF criptografados e decriptados com CipherInputStream(), usando uma chave derivada do SHA‑1 do filename baixado. Cada filename/version gera uma chave distinta, dificultando o reuso estático de IOC.

Jezail rooted Android pentesting toolkit (REST API + web UI)

  • Executa em um rooted device (Magisk/rootAVD) e inicia um HTTP server on tcp/8080 com uma Flutter web UI e REST API.
  • Instale o APK de release com permissões: adb install -g -r jezail.apk, então inicie o app (o server inicia automaticamente).
  • Endpoints: http://<device-ip>:8080/ (UI), http://<device-ip>:8080/api/json (API listing), http://<device-ip>:8080/api/swagger (Swagger).
  • Faça port-forward do emulator para alcançar a UI/API a partir do host: adb forward tcp:8080 tcp:8080 então acesse http://localhost:8080.

Android Enterprise & Work Profile Attacks

Android Enterprise Work Profile Bypass

Case Studies & Vulnerabilities

Air Keyboard Remote Input Injection

Android Rooting Frameworks Manager Auth Bypass Syscall Hook

Abusing Android Media Pipelines Image Parsers

Firmware Level Zygote Backdoor Libandroid Runtime

Static Analysis

Antes de mais nada, ao analisar um APK você deve dar uma olhada no código Java usando um decompiler.
Por favor, leia aqui para encontrar informações sobre diferentes decompilers disponíveis.

Looking for interesting Info

Apenas ao olhar as strings do APK você pode buscar por passwords, URLs (https://github.com/ndelphit/apkurlgrep), api keys, encryption, bluetooth uuids, tokens e qualquer coisa interessante… procure até por backdoors de execução de código ou backdoors de autenticação (credenciais admin hardcoded no app).

Firebase

Preste atenção especial às firebase URLs e verifique se está mal configurado. More information about whats is FIrebase and how to exploit it here.

Basic understanding of the application - Manifest.xml, strings.xml

A examinação dos arquivos Manifest.xml e strings.xml de uma aplicação pode revelar potenciais vulnerabilidades de segurança. Esses arquivos podem ser acessados usando decompilers ou renomeando o arquivo APK para .zip e descompactando-o.

Vulnerabilities identificadas a partir do Manifest.xml incluem:

  • Debuggable Applications: Aplicações marcadas como debuggable (debuggable="true") no arquivo Manifest.xml representam um risco, pois permitem conexões que podem levar à exploração. Para entender melhor como explorar aplicações debuggable, consulte um tutorial sobre encontrar e explorar aplicações debuggable em um dispositivo.
  • Backup Settings: O atributo android:allowBackup="false" deve ser explicitamente definido para aplicações que lidam com informação sensível para prevenir backups não autorizados via adb, especialmente quando usb debugging está habilitado.
  • Network Security: Configurações de network security customizadas (android:networkSecurityConfig="@xml/network_security_config") em res/xml/ podem especificar detalhes de segurança como certificate pins e configurações de tráfego HTTP. Um exemplo é permitir tráfego HTTP para domínios específicos.
  • Exported Activities and Services: Identificar activities e services exportados no manifest pode destacar componentes que podem ser mal utilizados. Análises adicionais durante testes dinâmicos podem revelar como explorar esses componentes.
  • Content Providers and FileProviders: Content providers expostos podem permitir acesso ou modificação não autorizada de dados. A configuração de FileProviders também deve ser examinada.
  • Broadcast Receivers and URL Schemes: Esses componentes podem ser aproveitados para exploração, com atenção particular a como os URL schemes são gerenciados para vulnerabilidades de input.
  • SDK Versions: Os atributos minSdkVersion, targetSDKVersion, e maxSdkVersion indicam as versões Android suportadas, destacando a importância de não suportar versões desatualizadas e vulneráveis do Android por razões de segurança.

Do arquivo strings.xml, informações sensíveis como API keys, schemas customizados e outras notas do desenvolvedor podem ser descobertas, reforçando a necessidade de revisão cuidadosa desses recursos.

Tapjacking

Tapjacking é um ataque onde uma aplicação maliciosa é iniciada e se posiciona por cima de uma aplicação vítima. Uma vez que obscurece visivelmente o app vítima, sua interface é desenhada de forma a enganar o usuário para interagir com ela, enquanto ela passa a interação para o app vítima.
Em efeito, é cegoar o usuário para que ele não saiba que está realmente executando ações no app vítima.

Find more information in:

Tapjacking

Task Hijacking

Uma activity com o launchMode configurado para singleTask sem qualquer taskAffinity definida é vulnerável a Task Hijacking. Isso significa que uma aplicação pode ser instalada e, se iniciada antes da aplicação real, ela pode hijackar a task da aplicação real (fazendo o usuário interagir com a aplicação maliciosa acreditando que está usando a real).

More info in:

Android Task Hijacking

Insecure data storage

Internal Storage

No Android, arquivos armazenados em internal storage são projetados para serem acessíveis exclusivamente pelo app que os criou. Essa medida de segurança é aplicada pelo sistema operacional Android e geralmente é adequada para as necessidades de segurança da maioria das aplicações. No entanto, desenvolvedores às vezes utilizam modos como MODE_WORLD_READABLE e MODE_WORLD_WRITABLE para permitir que arquivos sejam compartilhados entre diferentes aplicações. Ainda assim, esses modos não restringem o acesso a esses arquivos por outras aplicações, incluindo possíveis aplicações maliciosas.

  1. Static Analysis:
  • Assegure-se de que o uso de MODE_WORLD_READABLE e MODE_WORLD_WRITABLE seja cuidadosamente analisado. Esses modos podem expor arquivos a acessos não intencionados ou não autorizados.
  1. Dynamic Analysis:
  • Verifique as permissões definidas nos arquivos criados pelo app. Especificamente, cheque se algum arquivo está configurado como legível ou gravável mundialmente. Isso pode representar um risco significativo de segurança, pois permitiria que qualquer aplicação instalada no dispositivo, independentemente de sua origem ou intenção, leia ou modifique esses arquivos.

External Storage

Ao lidar com arquivos em external storage, como SD Cards, certas precauções devem ser tomadas:

  1. Accessibility:
  • Arquivos em external storage são legíveis e graváveis globalmente. Isso significa que qualquer aplicação ou usuário pode acessar esses arquivos.
  1. Security Concerns:
  • Dada a facilidade de acesso, é aconselhável não armazenar informações sensíveis em external storage.
  • External storage pode ser removido ou acessado por qualquer aplicação, tornando-o menos seguro.
  1. Handling Data from External Storage:
  • Sempre realize validação de input nos dados recuperados de external storage. Isso é crucial porque os dados vêm de uma fonte não confiável.
  • Armazenar executáveis ou arquivos de classe em external storage para carregamento dinâmico é fortemente desaconselhado.
  • Se sua aplicação precisa recuperar arquivos executáveis de external storage, assegure que esses arquivos estejam assinados e verificados criptograficamente antes de serem carregados dinamicamente. Esse passo é vital para manter a integridade de segurança da sua aplicação.

External storage pode ser acessado em /storage/emulated/0 , /sdcard , /mnt/sdcard

Tip

A partir do Android 4.4 (API 17), o SD card possui uma estrutura de diretórios que limita o acesso de um app ao diretório que é especificamente para aquele app. Isso previne que uma aplicação maliciosa obtenha acesso de leitura ou escrita aos arquivos de outra app.

Sensitive data stored in clear-text

  • Shared preferences: Android permite que cada aplicação salve facilmente arquivos xml no caminho /data/data/<packagename>/shared_prefs/ e às vezes é possível encontrar informação sensível em texto claro nessa pasta.
  • Databases: Android permite que cada aplicação salve facilmente bancos sqlite no caminho /data/data/<packagename>/databases/ e às vezes é possível encontrar informação sensível em texto claro nessa pasta.

Broken TLS

Accept All Certificates

Por algum motivo, às vezes desenvolvedores aceitam todos os certificados mesmo se, por exemplo, o hostname não corresponder, com linhas de código como a seguinte:

SSLSocketFactory sf = new cc(trustStore);
sf.setHostnameVerifier(SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER);

A good way to test this is to try to capture the traffic using some proxy like Burp without authorising Burp CA inside the device. Also, you can generate with Burp a certificate for a different hostname and use it.

Criptografia Quebrada

Processos de Gerenciamento de Chaves Inadequados

Alguns desenvolvedores salvam dados sensíveis no armazenamento local e os criptografam com uma chave hardcoded/predictable no código. Isso não deveria ser feito, pois algum reversing poderia permitir que atacantes extraiam a informação confidencial.

Uso de Algoritmos Inseguros e/ou Depreciados

Desenvolvedores não deveriam usar algoritmos depreciados para realizar checks de autorização, armazenar ou enviar dados. Alguns desses algoritmos são: RC4, MD4, MD5, SHA1… Se hashes são usados para armazenar senhas por exemplo, hashes resistentes a brute-force devem ser usados com salt.

Outras verificações

  • É recomendado ofuscar o APK para dificultar o trabalho de reverse engineering dos atacantes.
  • Se o app for sensível (como apps bancários), ele deveria realizar suas próprias verificações para ver se o mobile está rootado e agir em consequência.
  • Se o app for sensível (como apps bancários), ele deveria checar se um emulator está sendo usado.
  • Se o app for sensível (como apps bancários), ele deveria verificar sua própria integridade antes de executar para checar se foi modificado.
  • Use APKiD para checar qual compiler/packer/obfuscator foi usado para construir o APK

React Native Application

Read the following page to learn how to easily access javascript code of React applications:

React Native Application

Xamarin Applications

Read the following page to learn how to easily access C# code of a xamarin applications:

Xamarin Apps

Superpacked Applications

According to this blog post superpacked is a Meta algorithm that compress the content of an application into a single file. The blog talks about the possibility of creating an app that decompress these kind of apps… and a faster way which involves to execute the application and gather the decompressed files from the filesystem.

Automated Static Code Analysis

The tool mariana-trench is capable of finding vulnerabilities by scanning the code of the application. This tool contains a series of known sources (that indicates to the tool the places where the input is controlled by the user), sinks (which indicates to the tool dangerous places where malicious user input could cause damages) and rules. These rules indicates the combination of sources-sinks that indicates a vulnerability.

With this knowledge, mariana-trench will review the code and find possible vulnerabilities on it.

Secrets leaked

An application may contain secrets (API keys, passwords, hidden urls, subdomains…) inside of it that you might be able to discover. You could us a tool such as https://github.com/dwisiswant0/apkleaks

Bypass Biometric Authentication

Bypass Biometric Authentication (Android)

Other interesting functions

  • Code execution: Runtime.exec(), ProcessBuilder(), native code:system()
  • Send SMSs: sendTextMessage, sendMultipartTestMessage
  • Native functions declared as native: public native, System.loadLibrary, System.load
  • Read this to learn how to reverse native functions
  • In-memory native code execution via JNI (downloaded shellcode → mmap/mprotect → call):

In Memory Jni Shellcode Execution

Other tricks

content:// protocol

Dynamic Analysis

First of all, you need an environment where you can install the application and all the environment (Burp CA cert, Drozer and Frida mainly). Therefore, a rooted device (emulated or not) is extremely recommended.

Online Dynamic analysis

You can create a free account in: https://appetize.io/. This platform allows you to upload and execute APKs, so it is useful to see how an apk is behaving.

You can even see the logs of your application in the web and connect through adb.

Thanks to the ADB connection you can use Drozer and Frida inside the emulators.

Local Dynamic Analysis

Using an emulator

  • Android Studio (You can create x86 and arm devices, and according to this latest x86 versions support ARM libraries without needing an slow arm emulator).
  • Learn to set it up in this page:

AVD - Android Virtual Device

  • Genymotion (Free version: Personal Edition, you need to create an account. It’s recommend to download the version WITH VirtualBox to avoid potential errors.)
  • Nox (Free, but it doesn’t support Frida or Drozer).

Tip

When creating a new emulator on any platform remember that the bigger the screen is, the slower the emulator will run. So select small screens if possible.

To install google services (like AppStore) in Genymotion you need to click on the red marked button of the following image:

Also, notice that in the configuration of the Android VM in Genymotion you can select Bridge Network mode (this will be useful if you will be connecting to the Android VM from a different VM with the tools).

Use a physical device

You need to activate the debugging options and it will be cool if you can root it:

  1. Settings.
  2. (FromAndroid 8.0) Select System.
  3. Select About phone.
  4. Press Build number 7 times.
  5. Go back and you will find the Developer options.

Once you have installed the application, the first thing you should do is to try it and investigate what does it do, how does it work and get comfortable with it.
I will suggest to perform this initial dynamic analysis using MobSF dynamic analysis + pidcat, so we will be able to learn how the application works while MobSF captures a lot of interesting data you can review later on.

Magisk/Zygisk quick notes (recommended on Pixel devices)

  • Patch boot.img with the Magisk app and flash via fastboot to get systemless root
  • Enable Zygisk + DenyList for root hiding; consider LSPosed/Shamiko when stronger hiding is required
  • Keep original boot.img to recover from OTA updates; re-patch after each OTA
  • For screen mirroring, use scrcpy on the host

Unintended Data Leakage

Logging

Developers should be cautious of exposing debugging information publicly, as it can lead to sensitive data leaks. The tools pidcat and adb logcat are recommended for monitoring application logs to identify and protect sensitive information. Pidcat is favored for its ease of use and readability.

Warning

Note that from later newer than Android 4.0, applications are only able to access their own logs. So applications cannot access other apps logs.
Anyway, it’s still recommended to not log sensitive information.

Copy/Paste Buffer Caching

Android’s clipboard-based framework enables copy-paste functionality in apps, yet poses a risk as other applications can access the clipboard, potentially exposing sensitive data. It’s crucial to disable copy/paste functions for sensitive sections of an application, like credit card details, to prevent data leaks.

Crash Logs

If an application crashes and saves logs, these logs can assist attackers, particularly when the application cannot be reverse-engineered. To mitigate this risk, avoid logging on crashes, and if logs must be transmitted over the network, ensure they are sent via an SSL channel for security.

As pentester, try to take a look to these logs.

Analytics Data Sent To 3rd Parties

Applications often integrate services like Google Adsense, which can inadvertently leak sensitive data due to improper implementation by developers. To identify potential data leaks, it’s advisable to intercept the application’s traffic and check for any sensitive information being sent to third-party services.

SQLite DBs

Most of the applications will use internal SQLite databases to save information. During the pentest take a look to the databases created, the names of tables and columns and all the data saved because you could find sensitive information (which would be a vulnerability).
Databases should be located in /data/data/the.package.name/databases like /data/data/com.mwr.example.sieve/databases

If the database is saving confidential information and is encrypted but you can find the password inside the application it’s still a vulnerability.

Enumerate the tables using .tables and enumerate the columns of the tables doing .schema <table_name>

Drozer (Exploit Activities, Content Providers and Services)

From Drozer Docs: Drozer allows you to assume the role of an Android app and interact with other apps. It can do anything that an installed application can do, such as make use of Android’s Inter-Process Communication (IPC) mechanism and interact with the underlying operating system. .
Drozer is s useful tool to exploit exported activities, exported services and Content Providers as you will learn in the following sections.

Exploiting exported Activities

Read this if you want to refresh what is an Android Activity.
Also remember that the code of an activity starts in the onCreate method.

Authorisation bypass

When an Activity is exported you can invoke its screen from an external app. Therefore, if an activity with sensitive information is exported you could bypass the authentication mechanisms to access it.

Learn how to exploit exported activities with Drozer.

You can also start an exported activity from adb:

  • PackageName is com.example.demo
  • Exported ActivityName is com.example.test.MainActivity
adb shell am start -n com.example.demo/com.example.test.MainActivity

NOTA: MobSF vai detectar como malicioso o uso de singleTask/singleInstance como android:launchMode em uma activity, mas devido a this, aparentemente isso é perigoso apenas em versões antigas (API versions < 21).

Tip

Note that an authorisation bypass is not always a vulnerability, it would depend on how the bypass works and which information is exposed.

Vazamento de informações sensíveis

Activities can also return results. Se você conseguir encontrar uma activity exportada e sem proteção que chama o método setResult e retorna informações sensíveis, há um vazamento de informações sensíveis.

Tapjacking

If tapjacking isn’t prevented, you could abuse the exported activity to make the user perform unexpected actions. For more info about what is Tapjacking follow the link.

Exploiting Content Providers - Accessing and manipulating sensitive information

Read this if you want to refresh what is a Content Provider.
Content providers are basically used to share data. If an app has available content providers you may be able to extract sensitive data from them. It also interesting to test possible SQL injections and Path Traversals as they could be vulnerable.

Learn how to exploit Content Providers with Drozer.

Exploiting Services

Read this if you want to refresh what is a Service.
Remember that a the actions of a Service start in the method onStartCommand.

As Service is basically something that can receive data, process it and returns (or not) a response. Then, if an application is exporting some services you should check the code to understand what is it doing and test it dynamically for extracting confidential info, bypassing authentication measures…
Learn how to exploit Services with Drozer.

Exploiting Broadcast Receivers

Read this if you want to refresh what is a Broadcast Receiver.
Remember that a the actions of a Broadcast Receiver start in the method onReceive.

A broadcast receiver will be waiting for a type of message. Depending on ho the receiver handles the message it could be vulnerable.
Learn how to exploit Broadcast Receivers with Drozer.

Exploiting Schemes / Deep links

You can look for deep links manually, using tools like MobSF or scripts like this one.\ You can open a declared scheme using adb or a browser:

adb shell am start -a android.intent.action.VIEW -d "scheme://hostname/path?param=value" [your.package.name]

Observe que você pode omitir o nome do pacote e o dispositivo móvel chamará automaticamente o app que deve abrir esse link.

<!-- Browser regular link -->
<a href="scheme://hostname/path?param=value">Click me</a>
<!-- fallback in your url you could try the intent url -->
<a href="intent://hostname#Intent;scheme=scheme;package=your.package.name;S.browser_fallback_url=http%3A%2F%2Fwww.example.com;end">with alternative</a>

Código executado

Para encontrar o código que será executado no App, vá para a activity chamada pelo deeplink e procure a função onNewIntent.

Informações sensíveis

Sempre que encontrar um deep link verifique que ele não está recebendo dados sensíveis (como senhas) via parâmetros de URL, pois qualquer outra aplicação poderia se passar pelo deep link e roubar esses dados!

Parâmetros no path

Você também deve checar se algum deep link está usando um parâmetro dentro do path da URL como: https://api.example.com/v1/users/{username} , nesse caso você pode forçar um path traversal acessando algo como: example://app/users?username=../../unwanted-endpoint%3fparam=value .
Note que se você encontrar os endpoints corretos dentro da aplicação você pode ser capaz de causar um Open Redirect (se parte do path for usada como domain name), account takeover (se você puder modificar detalhes de usuários sem token CSRF e o endpoint vuln usar o método correto) e qualquer outra vuln. More info about this here.

Mais exemplos

Um interesting bug bounty report sobre links (/.well-known/assetlinks.json).

Inspeção da Camada de Transporte e Falhas de Verificação

  • Os certificados nem sempre são inspecionados corretamente por aplicações Android. É comum que essas aplicações ignorem avisos e aceitem certificados autoassinados ou, em algumas instâncias, revertam para usar conexões HTTP.
  • As negociações durante o handshake SSL/TLS às vezes são fracas, empregando cipher suites inseguros. Essa vulnerabilidade torna a conexão suscetível a ataques man-in-the-middle (MITM), permitindo que atacantes decifrem os dados.
  • Leakage of private information é um risco quando aplicações autenticam usando canais seguros mas depois se comunicam por canais não seguros para outras transações. Essa abordagem falha em proteger dados sensíveis, como session cookies ou detalhes do usuário, contra interceptação por entidades maliciosas.

Verificação de Certificado

Focaremos na verificação de certificados. A integridade do certificado do servidor deve ser verificada para aumentar a segurança. Isso é crucial porque configurações TLS inseguras e a transmissão de dados sensíveis por canais não criptografados podem representar riscos significativos. Para passos detalhados sobre verificar certificados de servidor e corrigir vulnerabilidades, this resource fornece orientação abrangente.

SSL Pinning

SSL Pinning é uma medida de segurança onde a aplicação verifica o certificado do servidor contra uma cópia conhecida armazenada dentro da própria aplicação. Esse método é essencial para prevenir ataques MITM. Implementar SSL Pinning é fortemente recomendado para aplicações que lidam com informações sensíveis.

Inspeção de Tráfego

Para inspecionar tráfego HTTP, é necessário instalar o certificado da ferramenta proxy (por exemplo, Burp). Sem instalar esse certificado, o tráfego criptografado pode não ser visível através do proxy. Para um guia sobre instalar um certificado CA customizado, click here.

Aplicações targeting API Level 24 and above requerem modificações no Network Security Config para aceitar o certificado CA do proxy. Este passo é crítico para inspecionar tráfego criptografado. Para instruções sobre modificar o Network Security Config, refer to this tutorial.

Se Flutter estiver sendo usado você precisa seguir as instruções em this page. Isso é porque, apenas adicionar o certificado ao store não funcionará já que o Flutter tem sua própria lista de CAs válidas.

Detecção estática de SSL/TLS pinning

Antes de tentar bypasses em runtime, mapeie rapidamente onde o pinning é aplicado no APK. A descoberta estática ajuda a planejar hooks/patches e a focar nos caminhos de código corretos.

Tool: SSLPinDetect

  • Utilitário de análise estática open-source que decompila o APK para Smali (via apktool) e escaneia padrões regex curados de implementações de SSL/TLS pinning.
  • Reporta o caminho exato do arquivo, número da linha e um trecho de código para cada correspondência.
  • Cobre frameworks comuns e caminhos de código customizados: OkHttp CertificatePinner, custom javax.net.ssl.X509TrustManager.checkServerTrusted, SSLContext.init com custom TrustManagers/KeyManagers, e Network Security Config XML pins.

Install

  • Prereqs: Python >= 3.8, Java on PATH, apktool
git clone https://github.com/aancw/SSLPinDetect
cd SSLPinDetect
pip install -r requirements.txt

Uso

# Basic
python sslpindetect.py -f app.apk -a apktool.jar

# Verbose (timings + per-match path:line + snippet)
python sslpindetect.py -a apktool_2.11.0.jar -f sample/app-release.apk -v

Exemplos de regras de padrão (JSON) Use ou estenda signatures para detectar estilos proprietários/personalizados de pinning. Você pode carregar seu próprio JSON e scan em escala.

{
"OkHttp Certificate Pinning": [
"Lcom/squareup/okhttp/CertificatePinner;",
"Lokhttp3/CertificatePinner;",
"setCertificatePinner"
],
"TrustManager Override": [
"Ljavax/net/ssl/X509TrustManager;",
"checkServerTrusted"
]
}

Notas e dicas

  • Fast scanning on large apps via multi-threading and memory-mapped I/O; pre-compiled regex reduces overhead/false positives.
  • Pattern collection: https://github.com/aancw/smali-sslpin-patterns
  • Typical detection targets to triage next:
  • OkHttp: uso de CertificatePinner, setCertificatePinner, referências aos pacotes okhttp3/okhttp
  • Custom TrustManagers: javax.net.ssl.X509TrustManager, sobrescritas de checkServerTrusted
  • Custom SSL contexts: SSLContext.getInstance + SSLContext.init com custom managers
  • Declarative pins em res/xml network security config e referências no manifest
  • Use the matched locations to plan Frida hooks, static patches, or config reviews before dynamic testing.

Contornando SSL Pinning

When SSL Pinning is implemented, bypassing it becomes necessary to inspect HTTPS traffic. Various methods are available for this purpose:

Procurando Vulnerabilidades Web Comuns

It’s important to also search for common web vulnerabilities within the application. Detailed information on identifying and mitigating these vulnerabilities is beyond the scope of this summary but is extensively covered elsewhere.

Frida

Frida é um toolkit de instrumentação dinâmica para desenvolvedores, engenheiros de reverso e pesquisadores de segurança.
Você pode acessar a aplicação em execução e hook métodos em runtime para alterar o comportamento, mudar valores, extrair valores, executar código diferente…
Se você quer pentest aplicações Android você precisa saber como usar Frida.

Anti-instrumentation & SSL pinning bypass workflow

Android Anti Instrumentation And Ssl Pinning Bypass

Dump de Memória - Fridump

Verifique se a aplicação está armazenando informações sensíveis na memória que não deveria, como senhas ou frases mnemônicas.

Usando Fridump3 você pode dumpar a memória do app com:

# With PID
python3 fridump3.py -u <PID>

# With name
frida-ps -Uai
python3 fridump3.py -u "<Name>"

Isso irá dump a memória na pasta ./dump, e ali você pode usar grep com algo como:

strings * | grep -E "^[a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+$"

Dados sensíveis no Keystore

No Android o Keystore é o melhor lugar para armazenar dados sensíveis, no entanto, com privilégios suficientes ainda é possível acessá-lo.

Como as aplicações tendem a armazenar aqui dados sensíveis em texto claro, os pentests devem verificar isso, já que um usuário root ou alguém com acesso físico ao dispositivo poderia roubar esses dados.

Mesmo que um app armazene dados no keystore, os dados devem ser criptografados.

Para acessar os dados dentro do keystore você pode usar este script Frida: https://github.com/WithSecureLabs/android-keystore-audit/blob/master/frida-scripts/tracer-cipher.js

frida -U -f com.example.app -l frida-scripts/tracer-cipher.js

Fingerprint/Biometrics Bypass

Usando o seguinte Frida script, pode ser possível bypass fingerprint authentication que aplicações Android possivelmente estejam a executar para proteger certas áreas sensíveis:

frida --codeshare krapgras/android-biometric-bypass-update-android-11 -U -f <app.package>

Imagens de fundo

Quando você coloca um aplicativo em segundo plano, o Android armazena um snapshot da aplicação, de modo que, quando ele é trazido de volta ao primeiro plano, começa a carregar essa imagem antes do app, fazendo parecer que o aplicativo foi carregado mais rápido.

No entanto, se esse snapshot contiver informação sensível, alguém com acesso ao snapshot pode roubar essa informação (observe que é necessário root para acessá-lo).

Os snapshots normalmente são armazenados em: /data/system_ce/0/snapshots

O Android fornece uma forma de evitar a captura de tela definindo o parâmetro de layout FLAG_SECURE. Ao usar essa flag, o conteúdo da janela é tratado como seguro, impedindo que apareça em capturas de tela ou que seja exibido em displays não seguros.

getWindow().setFlags(LayoutParams.FLAG_SECURE, LayoutParams.FLAG_SECURE);

Android Application Analyzer

Esta ferramenta pode ajudar você a gerenciar diferentes ferramentas durante a análise dinâmica: https://github.com/NotSoSecure/android_application_analyzer

Intent Injection

Developers often create proxy components like activities, services, and broadcast receivers that handle these Intents and pass them to methods such as startActivity(...) or sendBroadcast(...), which can be risky.

O perigo está em permitir que atacantes acionem componentes de app não-exportados ou acessem content providers sensíveis ao redirecionar esses Intents. Um exemplo notável é o componente WebView convertendo URLs em objetos Intent via Intent.parseUri(...) e então executando-os, potencialmente levando a injeções maliciosas de Intent.

Principais conclusões

  • Intent Injection é similar ao problema Open Redirect da web.
  • Exploits envolvem passar objetos Intent como extras, que podem ser redirecionados para executar operações inseguras.
  • Pode expor componentes não-exportados e content providers a atacantes.
  • A conversão de URL para Intent do WebView pode facilitar ações não intencionais.

Android Client Side Injections and others

Provavelmente você conhece esse tipo de vulnerabilidade pela Web. Você precisa ter cuidado especial com essas vulnerabilidades em uma aplicação Android:

  • SQL Injection: When dealing with dynamic queries or Content-Providers ensure you are using parameterized queries.
  • JavaScript Injection (XSS): Verify that JavaScript and Plugin support is disabled for any WebViews (disabled by default). More info here.
  • Local File Inclusion: WebViews should have access to the file system disabled (enabled by default) - (webview.getSettings().setAllowFileAccess(false);). More info here.
  • Eternal cookies: In several cases when the android application finish the session the cookie isn’t revoked or it could be even saved to disk
  • Secure Flag in cookies

Análise Automática

MobSF

Análise estática

Avaliação de vulnerabilidades da aplicação usando um frontend web agradável. Você também pode realizar análise dinâmica (mas precisa preparar o ambiente).

docker pull opensecurity/mobile-security-framework-mobsf
docker run -it -p 8000:8000 opensecurity/mobile-security-framework-mobsf:latest

Notice que o MobSF pode analisar Android(apk), IOS(ipa) and Windows(apx) applications (Aplicações Windows devem ser analisadas a partir de um MobSF instalado em um host Windows).
Além disso, se você criar um arquivo ZIP com o código-fonte de um app Android ou IOS (vá para a pasta raiz da aplicação, selecione tudo e crie um ZIPfile), ele também será capaz de analisá-lo.

MobSF também permite que você diff/Compare análises e integrar VirusTotal (você precisará definir sua API key em MobSF/settings.py e habilitá-la: VT_ENABLED = TRUE VT_API_KEY = <Your API key> VT_UPLOAD = TRUE). Você também pode definir VT_UPLOAD para False, então o hash será upload em vez do arquivo.

Assisted Dynamic analysis with MobSF

MobSF também pode ser muito útil para dynamic analysis no Android, mas nesse caso você precisará instalar MobSF e genymotion no seu host (uma VM ou Docker não funcionam). Note: You need to start first a VM in genymotion and then MobSF.
O MobSF dynamic analyser pode:

  • Dump application data (URLs, logs, clipboard, screenshots feitas por você, screenshots feitas pelo “Exported Activity Tester”, emails, SQLite databases, XML files, e outros arquivos criados). Tudo isso é feito automaticamente, exceto pelos screenshots — você precisa pressionar quando quiser um screenshot ou pressionar “Exported Activity Tester” para obter screenshots de todas as activities exportadas.
  • Capturar HTTPS traffic
  • Usar Frida para obter runtime information

A partir de versões do android > 5, ele irá automatically start Frida e irá configurar as definições globais de proxy para capture o tráfego. Ele irá capturar apenas o tráfego da aplicação testada.

Frida

Por padrão, ele também usará alguns Frida Scripts para bypass SSL pinning, root detection e debugger detection e para monitor interesting APIs.
MobSF também pode invoke exported activities, capturar screenshots delas e save para o relatório.

Para start o teste dinâmico pressione o botão verde: “Start Instrumentation”. Pressione “Frida Live Logs” para ver os logs gerados pelos Frida scripts e “Live API Monitor” para ver todas as invocações aos métodos hookados, argumentos passados e valores retornados (isso aparecerá após pressionar “Start Instrumentation”).
MobSF também permite carregar seus próprios Frida scripts (para enviar os resultados dos seus Frida scripts para o MobSF use a função send()). Ele também possui vários scripts pré-escritos que você pode carregar (você pode adicionar mais em MobSF/DynamicAnalyzer/tools/frida_scripts/others/), basta selecioná-los, pressionar “Load” e pressionar “Start Instrumentation” (você poderá ver os logs desses scripts dentro de “Frida Live Logs”).

Além disso, você tem algumas funcionalidades auxiliares do Frida:

  • Enumerate Loaded Classes: Irá imprimir todas as classes carregadas
  • Capture Strings: Irá imprimir todas as strings capturadas enquanto usa a aplicação (muito ruidoso)
  • Capture String Comparisons: Pode ser muito útil. Irá mostrar as 2 strings sendo comparadas e se o resultado foi True ou False.
  • Enumerate Class Methods: Coloque o nome da classe (como “java.io.File”) e ele imprimirá todos os métodos da classe.
  • Search Class Pattern: Buscar classes por padrão
  • Trace Class Methods: Trace uma classe inteira (ver entradas e saídas de todos os métodos da classe). Lembre-se que por padrão o MobSF traça vários métodos interessantes da Android Api.

Uma vez que você tenha selecionado o módulo auxiliar que deseja usar, você precisa pressionar “Start Intrumentation” e verá todas as saídas em “Frida Live Logs”.

Shell

Mobsf também traz um shell com alguns comandos adb, MobSF commands, e comandos comuns de shell no rodapé da página de dynamic analysis. Alguns comandos interessantes:

help
shell ls
activities
exported_activities
services
receivers

Ferramentas HTTP

Quando o tráfego http é capturado você pode ver uma visualização feia do tráfego capturado no botão “HTTP(S) Traffic” inferior ou uma visualização mais agradável no botão verde “Start HTTPTools”. A partir da segunda opção, você pode enviar as captured requests para proxies como Burp ou Owasp ZAP.
Para isso, power on Burp –> turn off Intercept –> in MobSB HTTPTools select the request –> pressione “Send to Fuzzer” –> select the proxy address (http://127.0.0.1:8080\).

Quando você terminar a análise dinâmica com MobSF pode pressionar “Start Web API Fuzzer” para fuzz http requests e procurar vulnerabilidades.

Tip

Após realizar uma análise dinâmica com MobSF as configurações de proxy podem ficar mal configuradas e você não conseguirá corrigi-las pela GUI. Você pode corrigir as configurações de proxy executando:

adb shell settings put global http_proxy :0

Análise Dinâmica Assistida com Inspeckage

Você pode obter a ferramenta em Inspeckage.
Esta ferramenta irá usar alguns Hooks para informar o que está acontecendo na aplicação enquanto você realiza uma análise dinâmica.

Yaazhini

Esta é uma ótima ferramenta para realizar análise estática com uma GUI

Qark

Esta ferramenta foi projetada para procurar várias vulnerabilidades relacionadas à segurança em aplicações Android, seja no source code ou em packaged APKs. A ferramenta também é capaz de criar um “Proof-of-Concept” deployable APK e ADB commands, para explorar algumas das vulnerabilidades encontradas (Exposed activities, intents, tapjacking…). Como com o Drozer, não há necessidade de rootear o dispositivo de teste.

pip3 install --user qark  # --user is only needed if not using a virtualenv
qark --apk path/to/my.apk
qark --java path/to/parent/java/folder
qark --java path/to/specific/java/file.java

ReverseAPK

  • Exibe todos os arquivos extraídos para referência fácil
  • Descompila automaticamente arquivos APK para os formatos Java e Smali
  • Analisa o AndroidManifest.xml em busca de vulnerabilidades comuns e comportamentos
  • Análise estática de código-fonte em busca de vulnerabilidades comuns e comportamentos
  • Informações do dispositivo
  • e mais
reverse-apk relative/path/to/APP.apk

SUPER Android Analyzer

SUPER é uma aplicação de linha de comando que pode ser usada no Windows, MacOS X e Linux, que analisa arquivos .apk em busca de vulnerabilidades. Faz isso descompactando APKs e aplicando uma série de regras para detectar essas vulnerabilidades.

Todas as regras estão centralizadas em um arquivo rules.json, e cada empresa ou testador pode criar suas próprias regras para analisar o que for necessário.

Baixe os binários mais recentes na download page

super-analyzer {apk_file}

StaCoAn

StaCoAn é uma ferramenta multiplataforma que auxilia desenvolvedores, bugbounty hunters e ethical hackers na realização de static code analysis em aplicações móveis.

O conceito é que você arraste e solte o arquivo do seu aplicativo móvel (um .apk ou .ipa file) na aplicação StaCoAn e ela gerará um relatório visual e portátil para você. Você pode ajustar as configurações e wordlists para obter uma experiência personalizada.

Baixar latest release:

./stacoan

AndroBugs

AndroBugs Framework é um sistema de análise de vulnerabilidades para Android que ajuda desenvolvedores ou hackers a encontrar potenciais vulnerabilidades de segurança em aplicativos Android.
Windows releases

python androbugs.py -f [APK file]
androbugs.exe -f [APK file]

Androwarn

Androwarn é uma ferramenta cujo objetivo principal é detectar e alertar o usuário sobre potenciais comportamentos maliciosos desenvolvidos por um aplicativo Android.

A detecção é realizada com a static analysis do bytecode Dalvik da aplicação, representado como Smali, com a biblioteca androguard.

Esta ferramenta procura por comportamento comum de “bad” applications como: Telephony identifiers exfiltration, Audio/video flow interception, PIM data modification, Arbitrary code execution…

python androwarn.py -i my_application_to_be_analyzed.apk -r html -v 3

MARA Framework

MARA é um framework de engenharia reversa e análise de Mobile Application. É uma ferramenta que reúne ferramentas comumente usadas para engenharia reversa e análise de aplicações móveis, para auxiliar nos testes de aplicações móveis contra as ameaças de segurança mobile do OWASP. Seu objetivo é tornar essa tarefa mais fácil e mais amigável para desenvolvedores de aplicações móveis e profissionais de segurança.

Ele é capaz de:

Koodous

Útil para detectar malware: https://koodous.com/

Ofuscação/Desofuscação de código

Note que, dependendo do serviço e da configuração que você usa para ofuscar o código, segredos podem ou não acabar ofuscados.

ProGuard

Do Wikipedia: ProGuard é uma ferramenta de linha de comando open source que reduz, otimiza e ofusca código Java. É capaz de otimizar bytecode assim como detectar e remover instruções não utilizadas. ProGuard é software livre e é distribuído sob a GNU General Public License, versão 2.

ProGuard é distribuído como parte do Android SDK e é executado ao construir a aplicação no modo release.

DexGuard

Encontre um guia passo a passo para desofuscar o apk em https://blog.lexfo.fr/dexguard.html

(Do guia) Da última vez que verificamos, o modo de operação do Dexguard era:

  • carregar um recurso como um InputStream;
  • passar o resultado para uma classe que herda de FilterInputStream para descriptografá-lo;
  • fazer alguma ofuscação inútil para desperdiçar alguns minutos do tempo de um reverser;
  • passar o resultado descriptografado para um ZipInputStream para obter um arquivo DEX;
  • por fim, carregar o DEX resultante como um Resource usando o método loadDex.

DeGuard

DeGuard reverte o processo de ofuscação realizado por ferramentas de ofuscação Android. Isso possibilita várias análises de segurança, incluindo inspeção de código e identificação de bibliotecas.

Você pode enviar um APK ofuscado para a plataforma deles.

[Deobfuscate android App]https://github.com/In3tinct/deobfuscate-android-app

Esta é uma ferramenta LLM para encontrar potenciais vulnerabilidades de segurança em apps Android e desofuscar o código de apps Android. Usa a API pública Gemini do Google.

Simplify

É um desofuscador Android genérico. Simplify executa virtualmente um app para entender seu comportamento e então tenta otimizar o código para que ele se comporte de forma idêntica, mas seja mais fácil para um humano entender. Cada tipo de otimização é simples e genérico, então não importa qual tipo específico de ofuscação foi usado.

APKiD

APKiD fornece informações sobre como um APK foi criado. Identifica muitos compilers, packers, obfuscators, e outras coisas estranhas. É o PEiD para Android.

Manual

Leia este tutorial para aprender alguns truques sobre como reverter ofuscação customizada

Laboratórios

Androl4b

AndroL4b é uma máquina virtual de segurança Android baseada em ubuntu-mate que inclui a coleção dos frameworks, tutoriais e labs mais recentes de diferentes geeks e pesquisadores de segurança para engenharia reversa e análise de malware.

Referências

Tip

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprenda e pratique Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporte o HackTricks