Android App Reverse Engineering 101

  1. Introduktion
  2. Grunderna för Android-applikationer
  3. Kom igång med att vända Android-applikationer
    • Övningsuppgift 1
  4. Reverse Engineering Android-applikationer – DEX Bytecode
    • Övning 2
    • Övning 3
    • Övning 4
  5. Omvända Android-appar – Nativa bibliotek
    • Övning 5
    • Övning 6
  6. Omvänd teknik för Android-appar – Obfuscation
    • Övning 7
  7. Slutsats

Bygg en app

Ett av mina viktigaste förslag till folk som vill göra reverse engineering, vad det än må vara, är att försöka bygga det du vill bygga om. När det gäller Android har du tur eftersom det finns så många gratis resurser tillgängliga för att bygga din första applikation. Om du aldrig har byggt en Android-applikation tidigare föreslår jag att du börjar där. Välj någon av de tillgängliga handledningar och videor som väcker ditt intresse och börja bygga. När du förstår hur en utvecklare bygger något, blir det mycket lättare att förstå hur du ska göra reverse engineering av det.

Fundamentals Review

Great! Du har byggt en app eller lärt dig grundläggande principer för Android-apputveckling. Här är en genomgång av några av de viktiga punkterna. Den här sidan ”Application Fundamentals” i dokumentationen för Android-utvecklare är en bra genomgång.

  • Android-applikationer finns i filformatet APK. APK är i princip en ZIP-fil. (Du kan byta namn på filtillägget till .zip och använda unzip för att öppna och se dess innehåll.)
  • APK-innehåll (inte uttömmande)
    • AndroidManifest.xml
    • META-INF/
      • Certifikatet bor här!
    • classes.dex
      • Dalvik bytecode för tillämpning i filformatet DEX. Detta är den Java- (eller Kotlin-) kod som programmet kommer att köra som standard.
    • lib/
      • Nativa bibliotek för programmet, som standard, finns här! Under katalogen lib/ finns de cpu-specifika katalogerna. Ex: armeabi, mips,
    • assets/
      • Alla andra filer som kan behövas av appen.
      • Utöverskridande infödda bibliotek eller DEX-filer kan ingå här. Detta kan särskilt hända när författare av skadlig kod vill försöka ”gömma” ytterligare kod, inhemsk eller Dalvik, genom att inte inkludera den på standardplatserna.

Dalvik & Smali

De flesta Android-tillämpningar är skrivna i Java. Kotlin stöds också och är kompatibelt med Java. För enkelhetens skull kan du i resten av den här workshopen, när jag hänvisar till ”Java”, anta att jag menar ”Java eller Kotlin”. I stället för att Java-koden körs i Java Virtual Machine (JVM) som i skrivbordsapplikationer, kompileras Java i Android till bytecode-formatet Dalvik Executable (DEX). I tidigare versioner av Android översattes bytekoden av den virtuella Dalvik-maskinen. För nyare versioner av Android används Android Runtime (ART).
Om utvecklare skriver i Java och koden kompileras till DEX bytecode, arbetar vi i motsatt riktning för att göra reverse engineering.

Smali är den människoläsbara versionen av Dalvik bytecode. Tekniskt sett är Smali och baksmali namnen på verktygen (assembler respektive disassembler), men i Android använder vi ofta termen ”Smali” för att hänvisa till instruktionerna. Om du har gjort reverse engineering eller datorarkitektur på kompilerad C/C++-kod. SMALI är som ett assembleringsspråk: mellan källkoden på högre nivå och bytekoden.

För följande Hello World Java-kod:

public static void printHelloWorld() {System.out.println("Hello World")}

Smali-koden skulle vara:

.method public static printHelloWorld()V.registers 2sget-object v0, Ljava/lang/System;->out:Ljava/io/PrintStream;const-string v1, "Hello World"invoke-virtual {v0,v1}, Ljava/io/PrintStream;->println(Ljava/lang/String;)Vreturn-void.end method

Smali-instruktionssatsen finns här.

Men oftast behöver du inte arbeta i Smali när du bakåtkompilerar Android-applikationer. De flesta applikationer kan lyftas till en ännu högre nivå, dekompilerad Java. Som alla verktyg kan Java-dekompilatorer ha buggar. Mitt förslag till dig är att när den dekompilerade Java-utgången ser tvivelaktig ut, titta på Smali-utgången. Arbeta rad för rad med instruktionsreferensen för att ta reda på vad koden gör.

För att få fram Smali från DEX kan du använda verktyget baksmali (disassembler) som finns på https://github.com/JesusFreke/smali/wiki. Med smali-verktyget kan du sätta ihop smali tillbaka till DEX.

Applikationens ingångspunkter

En av de viktigaste punkterna vid reverse engineering är att veta var du ska börja din analys och ingångspunkter för kodutförande är en viktig del av detta.

Launcher-aktivitet

Launcher-aktiviteten är det som de flesta tänker på som ingångspunkten till en Android-applikation. Lanseringsaktiviteten är den aktivitet som startas när en användare klickar på ikonen för ett program. Du kan bestämma lanseringsaktiviteten genom att titta på programmets manifest. Lanseringsaktiviteten kommer att ha följande MAIN- och LAUNCHER-intenter listade.

Tänk på att inte alla program kommer att ha en lanseringsaktivitet, särskilt inte program utan användargränssnitt. Exempel på program utan användargränssnitt (och därmed en startaktivitet) är förinstallerade program som utför tjänster i bakgrunden, till exempel röstbrevlåda.

<activity android:name=".LauncherActivity"><intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER" /> </intent-filter></activity>

Tjänster

Tjänster körs i bakgrunden utan användargränssnitt. De kan startas på ett otal olika sätt och är därmed en ingångspunkt för program. Det standardmässiga sättet som en tjänst kan startas som en ingångspunkt för ett program är genom Intents.

När startService API:et anropas för att starta en tjänst utförs onStart-metoden i tjänsten.

Broadcast Receivers

Broadcasts kan ses som ett meddelandesystem och broadcast-mottagare är lyssnarna. Om ett program har registrerat en mottagare för en viss sändning utförs koden i den mottagaren när systemet skickar sändningen. Det finns två sätt för en app att registrera en mottagare: i appens manifest eller dynamiskt registrerad i appens kod med hjälp av registerReceiver() API-anropet.

I båda fallen, för att registrera mottagaren, sätts avsiktsfiltren för mottagaren. Dessa avsiktsfilter är de sändningar som ska utlösa mottagaren.

När de specifika sändningar som mottagaren är registrerad för sänds, exekveras onReceive i BroadcastReceiver-klassen.

Exporterade komponenter (Tjänster & Aktiviteter)

Tjänster och aktiviteter kan också ”exporteras”, vilket gör det möjligt för andra processer på enheten att starta tjänsten eller starta aktiviteten. Komponenterna exporteras genom att ställa in ett element i manifestet som nedan. Som standard android:exported="false" om inte detta element är inställt på true i manifestet eller om intent-filter har definierats för aktiviteten eller tjänsten.

<service android:name=".ExampleExportedService" android:exported="true"/><activity android:name=".ExampleExportedActivity" android:exported="true"/>

Application Subclass

Android-applikationer kan definiera en underklass av Application. Applikationer kan, men behöver inte definiera en egen underklass av Application. Om en Android-applikation definierar en Application-underklass instansieras den här klassen före alla andra klasser i applikationen.

Om metoden attachBaseContext definieras i Application-underklassen anropas den först, före metoden onCreate.

NÄSTA > 3. Komma igång med att vända Android-applikationer

Lämna ett svar

Din e-postadress kommer inte publiceras.