> For the complete documentation index, see [llms.txt](https://jorgelucas011.gitbook.io/manual-pentest-mobile/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://jorgelucas011.gitbook.io/manual-pentest-mobile/passo-a-passo.md).
# Passo a Passo
Está sessão apresenta um passo a passo de pentest (teste de penetração ou intrusão) baseado em informações coletadas do Guia de teste de segurança móvel da OWASP (OWASP Mobile Security Testing Guide).
* Instalar **Virtual Box Oracle** ().
* Baixar a ISO do Sistema Operacional **Santoku** (().
* Instalação de alguns drivers que ajudarão o SO a se comportar bem (drivers presentes na sessão de Ferramentas).
* Reiniciar, agora é possível utilizar o Full screen mode.
* Criar uma conta no site do **Genymotion**
* Instalar **Genymotion**(emulador Android)
* Criando uma imagem android
* Configurar o modo de rede na configuração(dentro do Genymotion) para Bridge
* Conectar o **ADB**(Android Debug Bridge) entre o SO e o Emulador
* **$ adb shell (entrando nos files do android)**
* **$ cd /data/app (apps do android)**
* Explorando mais o Emulador
* Ter qualquer apk e instalar dentro do genymotion: **$ adb install “apk.file.apk”**
* **$ adb logcat** (ter acesso aos log das aplicações)
* Do emulador para a ISO(imagem):
## 1. Android App
* **Classes.dex(file)**, analisar como o app funciona
* **AndroidManifest.xml (file)**, características do app, e também com **META-INF(folder)** podendo descobrir qual tipo de permissão do usuário, um código fonte completo, enquanto gerenciador de intenção de atividades.
* **res(folder), assests(folder) e lib(folder),** como componentes adicionais.
* **$ vim classes.dex**
* Não verá nada porque há a necessidade de descompilar.
* **Android-apktool,** ferramenta APK para reverter ou descompilar qualquer arquivo APK do android. (já instalado no Santoku (SO)
* **JaDX Decompiler,** reverter o aplicativo Android.
* **$ apktool d app.apk, “d” de decompiler.**
* Descompilando:
* Primeiro App sem permissões de usuario em “androidmanifest.xml”
* **$ vim AndroidManifest.xml**, para ver as permissões de usuário
* **“smali”** é o diretório que contém nosso código-fonte, diretório que varia de acordo com o desenvolvimento da aplicação.
* **$ cd smali**, conseguindo ter acesso ao código.
* Outra maneira é pelo **Jadx**
* Link :
## **2.** **Android Application Signing**
* Assinar um app antes de torná-lo publico, através de um certificado de autoridade ou uma auto-assinatura, através de diferentes algoritmos de criptografia, tendo as duas chaves a pública e privada, mantendo a segunda em segurança.
* **Assinatura JAR (esquema v1)**
É baseado em JAR assinado . As assinaturas v1 não protegem algumas partes do APK, como metadados ZIP. O verificador de APK precisa processar muitas estruturas de dados não confiáveis (ainda não verificadas) e, em seguida, descartar os dados não cobertos pelas assinaturas. Isso oferece uma superfície de ataque considerável. Além disso, o verificador de APK deve descompactar todas as entradas compactadas, consumindo mais tempo e memória.
* **Esquema de assinatura APK v2 e v3 (esquema v2 +)**
O esquema v2 foi atualizado para v3 no Android 9 para incluir informações adicionais no bloco de assinatura, mas de outra forma funciona da mesma forma. O conteúdo do APK é hash e assinado, então o APK Signing Block resultante é inserido no APK.
Durante a validação, o esquema v2 + trata o arquivo APK como um blob e executa a verificação de assinatura em todo o arquivo. Qualquer modificação no APK, incluindo modificações nos metadados ZIP, invalida a assinatura do APK. Essa forma de verificação de APK é substancialmente mais rápida e permite a detecção de mais classes de modificações não autorizadas.
## **3. Tráfego Android**
* **Passivo:** analisando o tráfego secretamente, capturando os dados para a análise posterior, farejando o pacote TCP.
* **Ativo:** interceptação de solicitação de usuário, por exemplo, utilizando algumas ferramentos proxy, como **BURPSUITE.**
* Ferramenta já presente no Santoku SO.
* Primeiro: **Proxy < Options < Edit(Selecionando o primeiro) < All interfaces**
* Obs: Configure a Placa em modo Bridge no virtual Box : **Botão direito < Configuraçoes < Rede < Placa em modo Bridge**
* **$ Ifconfig** , para pegar o ip do SO
## 4 . Configurações de Proxy com o IP do Santoku (SO)
* Digitando qualquer coisa no navegador
* Interceptação
* Instalar o certificado do **burp** no android:
* **Configurações < Segurança < Instalar do cartao SD < certificado.crt**
## **5.** Aplicativo de Teste (**DIVA - Damn Insecure and Vulnerable Application)**
* Link : payatu.com/damn-insecure-and-vulnerable-app/
* Procure por “diva-beta.apk”
* Instalar o **010 Editor** para analisar arquivos.dex transformandos em arquivos java futuramente.
* Link : [www.sweetscape.com/download/010editor/](http://www.sweetscape.com/download/010editor/)
* Analisando os Logs de app
* Descobrindo que o processo é “21425” podemos através do comando $adb logcat | grep 21425
* Conseguimos armazenar o número do cartao de crédito através dos **Logs.**
## 6. Problemas de Codificação (HardcodeActivity)
* Descobringo o codigo **“HardcodeActivity”** descobrimos uma key
* Com essa key, seria possível garantir algum acesso no app.
## **7.** **Armazenamento de Dados de Forma Insegura**
* Em um app que armazena login e senha temos:
* Salvando um password : **admin, secretpassword**
* Assim como em hardcore inssues, analisamos através do **“jd-gui”** as classes.dex que foram transformadas em codigos .jar através do comando **$ d2j-dex2jar classes.dex**
* Através do comando **$ jd-gui “classes .dex** transformadas em **“.jar”** para alise do código fonte, sendo possivelmente as atividades inseguras do logon
* Ao abrir código podem ver um metodo que salva as credencias de user e password, em seguida voltamos ao Santoku e ao emulador atraves do **$ adb shell**
* Entramos em seguida **$ data/data**,
* **$ cd jakhar.assem.diva**
* **$ cd $shared\_prefs**
* e vemos que existem um arquivo chamado **“jakhar.assem.diva\_preferences.xml”**
* usando **$ cat jakhar.assem.diva\_preferences.xml**, podemos ter acesso ao nosso login e senha salvos.
## **8. Banco de Dados Inseguro**
* Salvando um login como demo, e password como secretpassword em outra partição, vamos tentar descobrir aonde estão esses dados.
* Usando a mesma técnica anterior, analisamos novamente a codificação e vemos sua estrutura e como está armazenado e vamos ver se está ou não criptografado
* No android usamos o comando **$ sqlite3 ids**, pelo fato desse banco é o mais comum nos androids. Depois um **.tables**, e faremos um **select** para visualizar
## **9. Arquivos Temporários Inseguros**
* Usando demo como login e demodemodemo como senha
* Abrimos novamente o **jd-gui,** e as classes.2jat para analisar o código temporários
* Seguindo o mesmo processo dos tópicos anteriores conseguimos visualizar os arquivos temporários
* Utilizando novamente o **$ cat uinfo-1634723552tmp**
* obtendo assim, os dados do arquivo temporário.
## **10. Dados do Cartão SD**
* Utilizando dessa vez “lucas” como login e “senhamuitosecreta” como password
* Analisaremos novamente o código fonte atraves do **“jd-gui”**, conseguimos observar como o método funciona e como e salvo o arquivos
* Procurando agora no **SDCARD** pelo arquivo, utilizaremos o comando $ ls -a, para encontrar os arquivos ocultos
* **Encontramos** o **“uinfo.txt”** abrindo novamente com o comando **“cat”** e tendo assim acesso as credenciais ocultas
## **11. SQL INJECTION**
* Colocando algo malicioso na entrada de dados onde o app não valida ou higieniza os dados de inserção, podendo resultar no despejo de todo o banco de dados.
* Em uma caixa de busca, supostamente colocamos algo malicioso e assim que é pressionado o botao de “search” tentaremos recuperar todos os dados.
* Verificando o código fonte novamente para analisar a estrutura e olhando o select
* Obtemos: **“SELECT \* FROM sqliuser WHERE user = “+ localEditText.getText().toString+””**
* Inserindo algo malicioso no código como uma condição para mostrar os dados com o código **“SELECT \* FROM sqliuser WHERE user = ‘ 1’ or ‘ 1’=’1 ”**, podemos simplesmente depois na própria barra de pesquisa digitá-lo para ter acesso a database:
## **12. Vasculhando o WEBVIEW**
**O que é?**
* Pequeno navegador no nosso app para mostrar o conteúdo da WEB
* Verificar algum acesso interino relacionado, no caso acima existe o **demo.txt** e assim conseguimos dados
## **13. Lendo o AndroidManifest.xml e Obtendo Credenciais**
## **14.** Provedor de Conteúdos (**Content Provider)**
* Criando um PIN com 1234
* Depois acessando o mesmo com o próprio PIN
* Encontrar os dados sem usar o PIN:
* 1 – Encontrar o Provedor URI e encontrar os dados particular os dados do mesmo
* Analisando novamente o AndroidManifest.xml
* Analisaremos esse arquivo através do **$ vim AcessControl3Activity.java**
* Vimos que há um NotesProvider e também, o analisaremos
* Vimos que temos um uri content : //jakhar.aseem.diva.provider.notesprovider/notes
* Usaremos o comando
* Obetendo o acesso de TODOS OS DADOS
## **15. Drozer “Engenharia Reversa”**
**Link :** labs.mrinfosecurity.com/tools/drozer
Instalar o Drozer e o drozer apk
**$ adb forward tcp:31415 tcp: 31415**
**$ drozer console connect**
**$ ls**
**$ run “modulo”**
**$ run app.package.list (listar todos os app)**
tendo acessos a vários modulos que podem usados para testar apps androids
