MASTG-TEST-0043: Corrupção de Memória Bugs

Visão Geral

Análise Estática

Existem diversos itens a serem verificados:

• Existem partes de código nativo? Se sim: verifique os problemas indicados na seção geral de corrupção de memória. O código nativo pode ser facilmente identificado por meio de wrappers JNI, arquivos .CPP/.H/.C, NDK ou outros frameworks nativos.
• Existe código Java ou Kotlin? Procure por problemas de serialização/desserialização, conforme descrito em Uma breve história das vulnerabilidades de desserialização no Android.

Observe que também podem existir vazamentos de memória em código Java/Kotlin. Procure por diversos itens, como: BroadcastReceivers que não são cancelados, referências estáticas a classes Activity ou View, classes Singleton que possuem referências a Context, referências a Classes Internas, referências a Classes Anônimas, referências a AsyncTask, referências a Handler, implementação incorreta de Threading, referências a TimerTask. Para mais detalhes, consulte:

• 9 maneiras de evitar vazamentos de memória no Android
• Padrões de vazamento de memória no Android.

Análise Dinâmica

Existem diversas etapas a serem realizadas:

• No caso de código nativo: use Valgrind ou Mempatrol para analisar o uso de memória e as chamadas de memória feitas pelo código.
• No caso de código Java/Kotlin, tente recompilar o aplicativo e utilizá-lo com o Squares Leak Canary.
• Verifique vazamentos com o Memory Profiler do Android Studio.
• Teste vulnerabilidades de serialização com o Android Java Deserialization Vulnerability Tester.