Android-appens struktur

En Android-app leveres som en APK (Android-pakke). Den er i virkeligheden et ZIP-arkiv, der indeholder den kompilerede kode, ressourcer og metadata.

Fordi den er en ZIP-fil, kan du blot pakke den ud for at undersøge indholdet, hvilket er det første skridt i mobil-pentesting.

En udpakket APK indeholder:

• AndroidManifest.xml: appens konfiguration.
• classes.dex: kompileret bytekode.
• res/ og resources.arsc: ressourcer.
• lib/: native biblioteker.
• META-INF/: signeringsoplysninger.

AndroidManifest.xml erklærer appens komponenter, tilladelser og konfiguration. I APK'en findes det i et binært XML-format, som værktøjer kan afkode.

Det er den vigtigste fil til at forstå en apps angrebsflade.

Java/Kotlin-kildekode kompileres til DEX-bytekode (Dalvik Executable) i classes.dex. Moderne Android kører den via ART (Android Runtime).

DEX kan konverteres tilbage til kode, der er lettere at læse, og det er det, statisk analyse af APK'er udnytter.

Android-apps er bygget af fire komponenttyper:

• Aktiviteter: skærme/brugergrænseflade.
• Tjenester: arbejde i baggrunden.
• Broadcast-modtagere: reagerer på systemhændelser.
• Indholdsudbydere: deler data mellem apps.

En komponent, der er markeret med android:exported="true", kan kaldes af andre apps. Hvis en sådan komponent udfører følsomme handlinger uden kontroller, udgør den en angrebsflade.

Penetrationstestere leder efter eksporterede aktiviteter, tjenester og udbydere, der lækker data eller udfører privilegerede handlinger.

Apps anmoder om tilladelser i manifestet (f.eks. INTERNET, READ_SMS, ACCESS_FINE_LOCATION).

For bredt definerede tilladelser kan tyde på risikabel adfærd eller overdreven dataadgang. Brugerdefinerede tilladelser kan også være fejlkonfigureret, så de tillader uautoriseret adgang.

Android isolerer hver app i sin egen sandkasse med et unikt Linux-UID. Som standard kan apps ikke læse hinandens data.

Sårbarheder opstår, når apps svækker denne grænse, f.eks. med filer, der kan læses af alle, eller eksponerede udbydere.

En installeret app gemmer private data under /data/data/<package>/: databaser, delte præferencer og filer.

På en rootet enhed eller via sikkerhedskopier undersøger en penetrationstester denne mappe for hemmeligheder, der er gemt usikkert. Det udforsker en senere lektion.

Alle APK'er er digitalt signeret; signaturen ligger i META-INF/. Android verificerer den ved installation og ved opdateringer.

Hvis du ændrer og pakker en app om, skal du signere den igen. Derfor bruger udviklere signering til at opdage manipulation.

Ydeevnekritisk eller sløret logik kan ligge i native biblioteker (.so-filer) under lib/, kompileret fra C/C++.

De findes ikke i DEX og kræver derfor separat analyse med native disassembleringsværktøjer. Udviklere skjuler somme tider hemmeligheder her, fordi de fejlagtigt tror, at native kode er sværere at undersøge.

Du forstår nu Android-appens struktur:

• En APK er en ZIP-fil, der indeholder AndroidManifest.xml, classes.dex, ressourcer og signeringsdata.
• Apps bruger fire komponenter; eksporterede komponenter udgør en angrebsflade.
• Tilladelser og den appspecifikke sandkasse styrer adgangen; private data ligger i /data/data/.
• APK'er er signerede for at opdage manipulation.

Derefter skal du dekompilere en APK i en statisk analyse.