Reverse Engineering inom mobilutveckling: vad det är, verktyg och analysmetoder

Vad är Reverse Engineering?

Reverse Engineering (reversing) — disciplinen för programvaruanalys inriktad på att återställa egenskaper, logik och struktur hos en applikation från dess binära representation. För mobilapplikationer är analysobjekten APK-filer (Android) och IPA-filer (iOS) som innehåller kompilerad kod, resurser, manifest och certifikat. Resultatet av reversing — extrahering av algoritmer, protokoll, krypteringsnycklar, API-scheman och affärslogik.

Målen med omvänd konstruktion delas in i legitima och illegitima. Legitima: analys av skadlig programvara för att skapa skyddsverktyg, revision av egna applikationer för sårbarheter, säkerställande av kompatibilitet med slutna protokoll, patentanalys och utbildning. Illegitima: stöld av immateriell egendom, kringgående av licensbegränsningar, skapande av piratkopior och modifiering av applikationen för att stjäla användardata. Enligt Google Play Protect (2025) skapas 78% av skadliga modifieringar av bankappar baserat på den ursprungliga APK som genomgått reverse engineering.

Metodologin för reversing omfattar två huvudriktningar: statisk analys (utan att starta applikationen) och dynamisk analys (under körning). Varje metod ger olika informationsnivå. Statisk — fullständig bild av koden, men utan körningsdata. Dynamisk — verkligt beteende, dataflöde, nätverksanrop, men endast inom ramen för ett specifikt körningsscenario. Professionell reversing kombinerar alltid båda metoderna.

Verktyg för statisk analys

Statisk analys — första steget i omvänd konstruktion. Den ursprungliga APK- eller IPA-filen packas upp och varje komponent analyseras separat. Huvudmål: DEX-bytekod, resurser, manifest, inbyggda bibliotek (.so, .dylib) och metadata.

jadx — avkompilator från DEX till Java

jadx — det främsta verktyget för statisk analys av Android-applikationer. Det omvandlar DEX-bytekod till läsbar Java-kod med minimal förlust. jadx stöder: avkompilering av multidex, igenkänning av lambdas och inbyggda Kotlin-klasser, export till Gradle-projekt. För obfuskerad kod (ProGuard) visar jadx kod med namn a, b, c, men klassstrukturen och anropsordningen bevaras. Enligt oberoende tester avkompilerar jadx korrekt 85–92% av koden även med obfuskering.

apktool — uppackning av resurser

apktool avkodar APK till smali-kod (DEX-assemblator) och återställer resurser i läsbar form: AndroidManifest.xml omvandlas från AXML till läsbar XML, layouter till XML-markup, strings.xml till vanlig text. apktool gör det möjligt att modifiera resurser och återsammanställa APK. Efter uppackning via apktool och utbyte av resurser kan applikationen installeras med modifierat innehåll.

Ghidra — analys av inbyggda bibliotek

Ghidra (NSA) — ramverk för reverse engineering, oumbärligt för analys av .so-bibliotek för Android och .dylib för iOS. Ghidra disassemblerar ARM64-kod, återställer C-pseudokod och bygger en anropsgraf. För mobil reversing används Ghidra för analys av inbyggda implementeringar av kryptografi och DRM-mekanismer. Ghidra stöder skriptning i Python och Java för automatisering av analys.

# Uppackning och avkompilering av APK
$ jadx -d output_dir app.apk

# Uppackning av resurser via apktool
$ apktool d app.apk -o app_unpacked

# Analys av inbyggt bibliotek via Ghidra
$ ghidra app.apk/lib/arm64-v8a/libnative.so

# Sökning efter strängkonstanter i DEX
$ strings classes.dex | grep -i api_key

Verktyg för dynamisk analys

Dynamisk analys utförs på en körbar applikation. Analytikern ansluter till processen och avlyssnar funktionsanrop, argument och returvärden i realtid.

Frida — universellt instrumenteringsverktyg

Frida — det ledande verktyget för dynamisk analys av mobilapplikationer. Frida injicerar en JavaScript-motor i applikationens process (Android ART eller iOS-app) och möjliggör avlyssning av anrop av både Java/Objective-C och C/C++-funktioner. Med Frida kan reverse-ingenjörer: logga alla anrop av metoden AES.decrypt() med parametrar, ersätta returvärdet med ett godtyckligt, ta bort SSL-pinning via Universal Android SSL Unpin, spåra inbyggda anrop via Stalker. Frida fungerar utan att modifiera APK/IPA, vilket gör den oumbärlig för penetrationsprovning.

Objection — lager ovanpå Frida

Objection tillhandahåller färdiga kommandon för typiska reversing-uppgifter utan att skriva JavaScript-skript: disable-pinning (avaktivering av SSL-pinning), dump-keychain (iOS), explore (genomgång av klasshierarki), memory search (sökning efter strängar i minnet). Objection möjliggör fullständig dynamisk analys utan en enda kodrad. För iOS-applikationer hittar och loggar Objection automatiskt anrop av NSURLSession, CFNetwork och NSKeyedArchiver.

Xposed Framework

Xposed — ramverk för Android som fungerar genom att ersätta filen app_process i Zygote. Till skillnad från Frida kräver Xposed inte root-åtkomst efter installation. Xposed-moduler kan avlyssna metodanrop i vilken applikation som helst. För reversing är Xposed lämpligt för långsiktig analys: modulen installeras och fungerar kontinuerligt, och loggar applikationens beteende i olika scenarier. Xposed stöder Android upp till version 8.1; för Android 9+ används EdXposed baserat på SandHook.

// Frida: avlyssning av metoden decrypt() i applikationen
let aesClass = Java.use("javax.crypto.Cipher");

aesClass.doFinal.overload(
    "[B", "int", "int"
).implementation = function(
    input, offset, len
) {
    console("[AES] decrypt called, len=" + len);
    return this.doFinal(input, offset, len);
};

Processen för omvänd konstruktion av Android-applikation

Standardarbetsflödet för reversing består av på varandra följande steg, som var och en ger en viss informationsnivå.

Steg 1: Insamling av underrättelser

Analytikern studerar APK på metadatanivå: targetSdk, uses-permission (vilka behörigheter som begärs), intent-filter och exported components. Utifrån behörigheter kan man avgöra vilka API:er som används (android.permission.CAMERA → kamera, android.permission.RECORD_AUDIO → ljud). Utifrån exported activity bestäms ingångspunkter utan auktorisering. Denna fas utförs via aapt eller ApkAnalyzer och tar 1–2 minuter.

Steg 2: Avkompilering av DEX

APK packas upp, classes.dex (eller multidex) matas in i jadx. Utmatningen — Java/Kotlin-kod i paket. Analytikern söker efter nyckelklasser: CryptoUtils, ApiClient, AuthManager, DatabaseHelper, och kontrollerar vilka algoritmer som används. Om strängar som AES/CBC/PKCS5Padding förekommer i koden — använder applikationen kryptering och nyckeln måste hittas. I denna fas bestäms: hårdkodade nycklar, API-URL:er, OAuth-tokens och hemligheter. Utan obfuskering läses hela applikationskoden som ett vanligt Java-projekt.

Steg 3: Trafikanalys

Genom att konfigurera Frida eller Objection för att inaktivera SSL-pinning startar analytikern applikationen och avlyssnar nätverkstrafik via Burp Suite eller mitmproxy. Baserat på trafikdata rekonstrueras API-schemat: vilka slutpunkter, vilka parametrar, i vilket format. Om möjligt modifierar analytikern förfrågningar och kontrollerar serverns reaktion på felaktiga eller skadliga data. Avsaknad av servervalidering — en direkt sårbarhet som upptäcks i detta steg.

Steg 4: Skrivning till data.json

Analysresultaten registreras i strukturerad form. För varje funnen sårbar plats anges: klass och metod, beskrivning av sårbarheten, exploateringsvektor och rekommendation för åtgärd. Denna datamängd överlämnas till utvecklingsteamet eller används för att sammanställa en pentestrapport. I automatiserade miljöer (MobSF) genereras rapporten automatiskt baserat på statisk och dynamisk analys.

Särdrag för reverse engineering av iOS-applikationer

Reverse engineering av iOS-applikationer är svårare än Android på grund av Apples strängare säkerhetsarkitektur och brist på direkt åtkomst till filsystemet på standardenheter. För iOS-analys krävs jailbreak.

Statisk analys av Mach-O

IPA-arkivet innehåller en Mach-O-binär — Apples universella format för körbara filer. För avkompilering används Hopper Disassembler eller IDA Pro. Till skillnad från Android DEX, som avkompileras till Java med minimal förlust, innehåller Mach-O inbyggd ARM64-kod som återställs till C-pseudokod med lägre precision. Hopper klarar 60–70% återställning, resten måste analyseras på assembler-nivå.

Dynamisk analys med Frida för iOS

Frida på iOS kräver jailbreak och installation av frida-server. Efter anslutning avlyssnar Frida Objective-C-metoder via API för meddelanderoutning. För iOS-applikationer är ett typiskt scenario: avlyssning av NSURLSession.dataTaskWithRequest-metoder för loggning av HTTP-förfrågningar, avlyssning av NSKeyedUnarchiver för analys av serialiserade data och spårning av CoreData-frågor via frida-trace. Frida blev tillgänglig för iOS 15–17 med lanseringen av Dopamine-jailbreak.

IPA-modifiering

Reversing kan innefatta modifiering av IPA med efterföljande återpaketering och installation på enheten. Verktyg: ipatool för uppackning, MachOView för visning av sektioner och optool för injicering av kod. Efter modifiering signeras IPA via ldid eller fastlane sigh för installation på en jailbreakad enhet. För iOS 16+ kontrolleras kodsignaturen på Secure Enclave-nivå och den modifierade IPA kommer inte att köras på en icke-jailbreakad enhet.

// Frida: avlyssning av HTTP-förfrågningar i iOS-applikation
if (ObjC.available) {
    let NSURLSession = ObjC.classes.NSURLSession;
    let dataTaskWithRequest = ObjC.protocol("NSURLSessionDelegate")
        .method("- URLSession:dataTask:didReceiveData:");
    Interceptor.attach(dataTaskWithRequest.implementation, {
        onEnter(args) {
            let data = ObjC.Object(args[3]);
            console("[HTTP Response]", data.toString());
        }
    });
}

Skyddsmetoder mot reverse engineering

Skydd mot omvänd konstruktion bygger på principen om skiktad säkerhet: ingen metod ger 100% skydd, men kombinationen gör reversing ekonomiskt olönsamt.

Kodobfuskering

Grundnivå — ProGuard för Android, som ersätter klass- och metodnamn med en tecken. För förstärkning används DexGuard, som lägger till overload induction (flera metoder med olika signaturer och samma namn) och AES-256-strängkryptering. Obfuskering ökar kodanalystiden från 5 minuter till 5–20 timmar beroende på nivå. DexGuard förvirrar ytterligare kontrollflödet och gör koden oläslig för jadx.

Kryptering av konstanter

Alla strängkonstanter — URL:er, nycklar, tokens, SQL-frågor — krypteras i byggfasen och dekrypteras i runtime. Detta skyddar mot statisk analys av DEX-filens strängar. En angripare som kör strings app.apk kommer inte att se någon API-slutpunkt. Även efter avkompilering ser alla strängar ut som binär data. För varje sträng kan en separat nyckel användas, vilket försvårar deobfuskering.

RASP och integritetskontroll

RASP-agenten inuti applikationen upptäcker Frida och felsökning i runtime. Integritetskontroll via SHA-256-hash av APK förhindrar körning av en modifierad version av applikationen. Om APK-hash inte matchar referensen (lagrad i det inbyggda lagret) — avslutas applikationen. Detta blockerar attacker baserade på APK-modifiering, inklusive återpaketering.

Server-skydd

Kritisk affärslogik bör utföras på servern, inte på klienten. Även om en angripare fullständigt avkompilerar applikationen förblir serverkoden otillgänglig. Servervalidering av alla förfrågningar och parametrar förhindrar exploatering av sårbarheter som hittats under reversing. Serverattestering via Play Integrity API eller App Attest bekräftar att förfrågan kommer från en äkta, omodifierad applikation.