1. Inleiding
2. Android Application Fundamentals
3. Aan de slag met het reverse engineeren van Android Apps
   • Oefening 1
4. Reverse Engineering Android Apps – DEX Bytecode
   • Exercitie 2
   • Exercitie 3
   • Exercitie 4
5. Reverse Engineering Android Apps – Native Libraries
   • Exercitie 5
   • Exercitie 6
6. Reverse Engineering Android Apps – Obfuscation
   • Exercise 7
7. Conclusion

Build an App

Een van mijn grootste suggesties voor mensen die dingen willen reverse engineeren, wat ze ook mogen zijn, is om te proberen te bouwen wat je wilt omkeren. In het geval van Android, heb je geluk omdat er zo veel gratis middelen beschikbaar zijn om je eerste applicatie te bouwen. Als je nog nooit een Android applicatie hebt gebouwd, stel ik voor dat je daar begint. Kies een van de beschikbare tutorials en video’s die je interesse wekken en begin met bouwen. Wanneer u begrijpt hoe een ontwikkelaar iets bouwt, maakt het veel gemakkelijker om te begrijpen hoe het te reverse-engineeren.

Fundamentals Review

Geweldig! U hebt een app gebouwd of de basisbeginselen van Android app-ontwikkeling geleerd. Hier is een overzicht van enkele van de belangrijke punten. Deze “Application Fundamentals” pagina in de Android-ontwikkelaars ‘docs is een geweldige review.

• Android applicaties zijn in het APK-bestandsformaat. APK is in feite een ZIP-bestand. (U kunt de bestandsextensie hernoemen naar .zip en gebruik unzip te openen en de inhoud te zien.)
• APK Inhoud (Niet uitputtend)
  • AndroidManifest.xml
  • META-INF/
    • Certificaat woont hier!
  • classes.dex
    • Dalvik bytecode voor toepassing in het DEX-bestandsformaat. Dit is de Java (of Kotlin) code die de applicatie standaard zal draaien.
  • lib/
    • Native bibliotheken voor de applicatie, standaard, staan hier! Onder de lib/ directory, bevinden zich de cpu-specifieke directories. Bijvoorbeeld: armeabi, mips,
  • assets/
    • Alle andere bestanden die nodig kunnen zijn voor de app.
    • Extra native bibliotheken of DEX-bestanden kunnen hier worden opgenomen. Dit kan vooral gebeuren wanneer malware-auteurs willen proberen om extra code, native of Dalvik, te “verbergen” door deze niet op de standaardlocaties op te nemen.

  Dalvik & Smali

  De meeste Android-toepassingen zijn geschreven in Java. Kotlin wordt ook ondersteund en is interoperabel met Java. Voor het gemak, voor de rest van deze workshop, wanneer ik verwijs naar “Java”, kunt u ervan uitgaan dat ik bedoel “Java of Kotlin”. In plaats van dat de Java code wordt uitgevoerd in de Java Virtual Machine (JVM) zoals bij desktop applicaties, wordt de Java in Android gecompileerd naar het Dalvik Executable (DEX) bytecode formaat. Voor vroegere versies van Android werd de bytecode vertaald door de Dalvik virtuele machine. Voor recentere versies van Android wordt de Android Runtime (ART) gebruikt.
  Als ontwikkelaars in Java schrijven en de code is gecompileerd naar DEX bytecode, werken we voor reverse-engineering de andere kant op.
  
  

  Smali is de door mensen leesbare versie van Dalvik bytecode. Technisch gezien zijn Smali en baksmali de namen van de gereedschappen (respectievelijk assembler en disassembler), maar in Android gebruiken we vaak de term “Smali” om naar instructies te verwijzen. Als je aan reverse engineering of computer architectuur hebt gedaan op gecompileerde C/C++ code. SMALI is als de assembleertaal: tussen de hoger niveau broncode en de bytecode.

  Voor de volgende Hello World Java-code:

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

  De Smali-code zou zijn:

  .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

  De Smali-instructieset is hier beschikbaar.

  Bij het reverse engineeren van Android applicaties is het meestal niet nodig om in Smali te werken. De meeste toepassingen kunnen worden opgeheven naar een nog hoger niveau, gedecompileerde Java. Zoals alle tools, kunnen Java decompilers bugs hebben. Mijn suggestie aan jou is dat wanneer de gedecompileerde Java output er twijfelachtig uitziet, kijk dan naar de Smali output. Werk regel voor regel met de instructie referentie om uit te vinden wat de code aan het doen is.

  Om de Smali uit DEX te halen, kun je het baksmali gereedschap (disassembler) gebruiken dat beschikbaar is op https://github.com/JesusFreke/smali/wiki. De smali tool zal u toelaten om smali terug te assembleren naar DEX.

  Application Entry Points

  Een van de belangrijkste punten van reverse engineering is weten waar je analyse te beginnen en entry points voor de uitvoering van code is een belangrijk onderdeel van dat.

  Launcher Activity

  De launcher activiteit is wat de meeste mensen denken aan als het startpunt van een Android applicatie. De launcher activiteit is de activiteit die wordt gestart wanneer een gebruiker klikt op het pictogram voor een toepassing. U kunt de launcher activiteit bepalen door te kijken naar het manifest van de applicatie. De launcher activiteit zal de volgende MAIN en LAUNCHER intenties hebben vermeld.

  Houd in gedachten dat niet elke applicatie een launcher activiteit zal hebben, vooral apps zonder een UI. Voorbeelden van toepassingen zonder UI (en dus een launcher-activiteit) zijn vooraf geïnstalleerde toepassingen die op de achtergrond diensten uitvoeren, zoals voicemail.

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

  Services

  Diensten worden op de achtergrond uitgevoerd zonder een UI. Ze kunnen op talloze manieren worden gestart en vormen zo een toegangspunt voor toepassingen. De standaard manier waarop een service kan worden gestart als toegangspunt voor een applicatie is via Intents.

  Wanneer de startService API wordt aangeroepen om een Service te starten, wordt de onStart methode in de Service uitgevoerd.

  Broadcast Ontvangers

  Broadcasts kunnen worden beschouwd als een berichtensysteem en broadcast ontvangers zijn de luisteraars. Als een applicatie een ontvanger heeft geregistreerd voor een specifieke uitzending, wordt de code in die ontvanger uitgevoerd wanneer het systeem de uitzending verstuurt. Er zijn 2 manieren waarop een app een ontvanger kan registreren: in het Manifest van de app of dynamisch geregistreerd in de code van de app met behulp van de registerReceiver() API-aanroep.

  In beide gevallen, om de ontvanger te registreren, worden de intentiefilters voor de ontvanger ingesteld. Deze intent filters zijn de uitzendingen die de ontvanger moeten triggeren.

  Wanneer de specifieke uitzendingen worden verzonden waarvoor de ontvanger is geregistreerd, wordt onReceive in de BroadcastReceiver klasse uitgevoerd.

  Exported Components (Services & Activiteiten)

  Services en Activiteiten kunnen ook worden “geëxporteerd”, waardoor andere processen op het apparaat de service kunnen starten of de activiteit kunnen starten. De componenten worden geëxporteerd door een element in het manifest in te stellen zoals hieronder. Standaard is android:exported="false" tenzij dit element in het manifest op true is gezet of intent-filters zijn gedefinieerd voor de Activiteit of Dienst.

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

  Application Subclass

  Android-toepassingen kunnen een subklasse van Applicatie definiëren. Toepassingen kunnen een aangepaste subklasse van Application definiëren, maar dat hoeft niet. Als een Android-toepassing een subklasse van Application definieert, wordt deze klasse geïnstantieerd vóór elke andere klasse in de toepassing.

  Als de methode attachBaseContext is gedefinieerd in de subklasse Application, wordt deze eerst aangeroepen, vóór de methode onCreate.

  NEXT > 3. Aan de slag met het omkeren van Android-toepassingen