Android
Auditing Android apps usually requires to be able to
- capture and handles requests generated by the phone (e.g. through a proxy like Burp)
- communicate with the phone easily ("android debug bridge", a.k.a. ADB)
- handle all sorts of data (i.e. memory, logs, cache, backups)
This could be done using a real rooted phone, or a simulated one (e.g. MobSF, Genymotion).
Several tools allow to enumerate the attack surface of an APK (e.g. Drozer or AndroidManifest.xml showing exported services and features).
Android pentesting can be time-consuming. a reading of decompiled files allows to understand the role of functions used (APK transformation), hooks can be placed during the execution of the application in order to bypass its original behaviour (i.e. Frida, Objection).
Auditing Android covers multiples domains.
- Applications Storage
- Presence of sensitive data inside files (API_KEY, secrets)
- Presence of sensitive data inside backups
- Presence of sensitive data inside logs
- Presence of sensitive data inside cache
- Presence of sensitive data inside memory
- Communications
- Certificate pinning
- Audit communications between phone and backends
- Auditing platforms
- Applications permissions
- Fragments injection
- Webview's user input
- Webview's methods
- Object persistence
- Instants Apps
- Custom URLs
Auditing an Android APK requires a setup made of:
- An Android smartphone (e.g. Pixel3A, or any other smartphone easy enough to root) or a Genymotion virtual machine (e.g. using MobSF)
- A few utilities directly on the phone (whether it's real or virtual)
- Frida Server
- Drozer Server
- Magisk App with Modules
- A few utilities on the computer
- Frida client
- Drozer client
- MobSF
- A proxy (e.g. Burp Suite)
Last modified 1mo ago