Estrutura de aplicações Android

Um aplicativo Android é distribuído como um APK (pacote Android). Na verdade, ele é um arquivo ZIP que contém o código compilado, os recursos e os metadados.

Por ser um ZIP, você pode simplesmente descompactá-lo para inspecionar seu conteúdo, que é o primeiro passo em um teste de invasão móvel.

Um APK extraído contém:

• AndroidManifest.xml: configuração do aplicativo.
• classes.dex: código de bytes compilado.
• res/ e resources.arsc: recursos.
• lib/: bibliotecas nativas.
• META-INF/: informações de assinatura.

O AndroidManifest.xml declara os componentes, as permissões e a configuração do aplicativo. No APK, ele está em formato XML binário, que as ferramentas podem decodificar.

Ele é o arquivo mais importante para compreender a superfície de ataque de um aplicativo.

O código-fonte Java/Kotlin é compilado em código de bytes DEX (Dalvik Executable) no arquivo classes.dex. As versões modernas do Android o executam por meio do ART (Android Runtime).

O DEX pode ser convertido novamente em direção a um código legível, e é nisso que se baseia a análise estática de APKs.

Os aplicativos Android são construídos com quatro tipos de componentes:

• Atividades: telas / interface do usuário.
• Serviços: trabalho em segundo plano.
• Receptores de transmissão: respondem a eventos do sistema.
• Provedores de conteúdo: compartilham dados entre aplicativos.

Um componente marcado como android:exported="true" pode ser invocado por outros aplicativos. Se esse componente executar ações sensíveis sem verificações, ele será uma superfície de ataque.

Os profissionais de testes de invasão procuram atividades, serviços e provedores exportados que vazem dados ou executem ações privilegiadas.

Os aplicativos solicitam permissões no manifesto (por exemplo, INTERNET, READ_SMS, ACCESS_FINE_LOCATION).

Permissões amplas demais sugerem comportamento arriscado ou acesso excessivo a dados. As permissões personalizadas também podem estar configuradas incorretamente, permitindo acesso não autorizado.

O Android isola cada aplicativo em sua própria sandbox, com um UID exclusivo do Linux. Por padrão, os aplicativos não podem ler os dados uns dos outros.

As vulnerabilidades surgem quando os aplicativos enfraquecem essa barreira, por exemplo, com arquivos legíveis por qualquer usuário ou provedores expostos.

Um aplicativo instalado armazena dados privados em /data/data/<package>/: bancos de dados, preferências compartilhadas e arquivos.

Em um dispositivo com acesso root ou por meio de backups, um profissional de testes de invasão inspeciona esse diretório em busca de segredos armazenados de forma insegura, assunto explorado em uma lição posterior.

Todo APK é assinado digitalmente; a assinatura fica em META-INF/. O Android a verifica durante a instalação e nas atualizações.

Se você modificar e reempacotar um aplicativo, deverá assiná-lo novamente, motivo pelo qual os desenvolvedores dependem da assinatura para detectar adulterações.

A lógica crítica para o desempenho ou ofuscada pode estar em bibliotecas nativas (arquivos .so) dentro de lib/, compiladas a partir de C/C++.

Elas não estão no DEX, portanto exigem uma análise separada com desmontadores nativos. Às vezes, os desenvolvedores escondem segredos nesse local, acreditando equivocadamente que o código nativo é mais difícil de inspecionar.

Relembre qual atributo do manifesto expõe um componente a outros aplicativos.

Agora você entende a estrutura dos aplicativos Android:

• Um APK é um ZIP que contém AndroidManifest.xml, classes.dex, recursos e dados de assinatura.
• Os aplicativos usam quatro componentes; os componentes exportados são superfícies de ataque.
• As permissões e a sandbox individual de cada aplicativo controlam o acesso; os dados privados ficam em /data/data/.
• Os APKs são assinados para detectar adulterações.

Em seguida, você fará a descompilação de um APK em uma análise estática.