Reverse Engineering w rozwoju mobilnym: co to jest, narzędzia i metody analizy

Czym jest Reverse Engineering?

Reverse Engineering (reversing) — dyscyplina analizy oprogramowania mająca na celu odtworzenie charakterystyk, logiki i struktury aplikacji z jej reprezentacji binarnej. Dla aplikacji mobilnych obiektami analizy są pliki APK (Android) i IPA (iOS), zawierające skompilowany kod, zasoby, manifesty i certyfikaty. Rezultatem reversingu jest wydobycie algorytmów, protokołów, kluczy szyfrowania, schematów API i logiki biznesowej.

Cele inżynierii odwrotnej dzielą się na legalne i nielegalne. Legalne: analiza złośliwego oprogramowania w celu tworzenia środków ochrony, audyt własnych aplikacji pod kątem podatności, zapewnienie zgodności z zamkniętymi protokołami, analiza patentowa i edukacja. Nielegalne: kradzież własności intelektualnej, obchodzenie ograniczeń licencyjnych, tworzenie pirackich kopii i modyfikacja aplikacji w celu kradzieży danych użytkowników. Według danych Google Play Protect (2025), 78% złośliwych modyfikacji aplikacji bankowych powstaje na podstawie oryginalnego APK przepuszczonego przez reverse engineering.

Metodologia reversingu obejmuje dwa główne kierunki: analizę statyczną (bez uruchamiania aplikacji) i analizę dynamiczną (w czasie wykonania). Każde podejście daje inny poziom informacji. Statyczna — pełny obraz kodu, ale bez danych czasu wykonania. Dynamiczna — rzeczywiste zachowanie, przepływ danych, wywołania sieciowe, ale tylko w ramach konkretnego scenariusza wykonania. Profesjonalny reversing zawsze łączy oba podejścia.

Narzędzia analizy statycznej

Analiza statyczna — pierwszy etap inżynierii odwrotnej. Oryginalny APK lub IPA jest rozpakowywany, a każdy komponent analizowany osobno. Główne cele: kod bajtowy DEX, zasoby, manifest, biblioteki natywne (.so, .dylib) i metadane.

jadx — dekompilator DEX do Java

jadx — główne narzędzie do analizy statycznej aplikacji Android. Przekształca kod bajtowy DEX w czytelny kod Java z minimalnymi stratami. jadx obsługuje: dekompilację multidex, rozpoznawanie lambd i wbudowanych klas Kotlin, eksport do projektu Gradle. Dla zaciemnionego kodu (ProGuard) jadx pokazuje kod z nazwami a, b, c, ale struktura klas i kolejność wywołań są zachowane. Według niezależnych testów, jadx poprawnie dekompiluje 85–92% kodu nawet z obfuskacją.

apktool — rozpakowywanie zasobów

apktool dekoduje APK do kodu smali (asembler DEX) i odtwarza zasoby w czytelnej postaci: AndroidManifest.xml jest przekształcany z AXML na czytelny XML, layouty — na znaczniki XML, strings.xml — na czysty tekst. apktool pozwala modyfikować zasoby i ponownie złożyć APK. Po rozpakowaniu przez apktool i podmianie zasobów aplikację można zainstalować ze zmodyfikowaną zawartością.

Ghidra — analiza bibliotek natywnych

Ghidra (NSA) — framework reverse engineering, niezastąpiony do analizy bibliotek .so Androida i .dylib iOS. Ghidra deasemblowuje kod ARM64, odtwarza pseudokod C i buduje graf wywołań. Dla mobilnego reversingu Ghidra jest używana do analizy natywnych implementacji kryptografii i mechanizmów DRM. Ghidra obsługuje skryptowanie w Python i Java do automatyzacji analizy.

# Rozpakowanie i dekompilacja APK
$ jadx -d output_dir app.apk

# Rozpakowanie zasobów przez apktool
$ apktool d app.apk -o app_unpacked

# Analiza biblioteki natywnej przez Ghidrę
$ ghidra app.apk/lib/arm64-v8a/libnative.so

# Wyszukiwanie stałych stringów w DEX
$ strings classes.dex | grep -i api_key

Narzędzia analizy dynamicznej

Analiza dynamiczna jest wykonywana na uruchomionej aplikacji. Analityk łączy się z procesem i przechwytuje wywołania funkcji, argumenty i wartości zwracane w czasie rzeczywistym.

Frida — uniwersalne narzędzie instrumentacji

Frida — wiodące narzędzie analizy dynamicznej aplikacji mobilnych. Frida wstrzykuje silnik JavaScript do procesu aplikacji (Android ART lub iOS app) i pozwala przechwytywać wywołania zarówno funkcji Java/Objective-C, jak i C/C++. Za pomocą Fridy inżynierowie odwrotni mogą: logować wszystkie wywołania metody AES.decrypt() z parametrami, podmieniać wartość zwracaną na dowolną, usuwać SSL-pinning przez Universal Android SSL Unpin, śledzić wywołania natywne przez Stalker. Frida działa bez modyfikacji APK/IPA, co czyni ją niezastąpioną w testach penetracyjnych.

Objection — nakładka na Fridę

Objection dostarcza gotowych poleceń do typowych zadań reversingu bez pisania skryptów JavaScript: disable-pinning (wyłączenie SSL pinning), dump-keychain (iOS), explore (przeglądanie hierarchii klas), memory search (wyszukiwanie stringów w pamięci). Objection pozwala przeprowadzić pełną analizę dynamiczną bez ani jednej linii kodu. Dla aplikacji iOS Objection automatycznie znajduje i loguje wywołania NSURLSession, CFNetwork i NSKeyedArchiver.

Xposed Framework

Xposed — framework dla Androida, działający przez podmianę pliku app_process w Zygote. W przeciwieństwie do Fridy, Xposed nie wymaga dostępu root po instalacji. Moduły Xposed mogą przechwytywać wywołania metod w dowolnej aplikacji. Do reversingu Xposed jest wygodny w dłu­goterminowej analizie: moduł jest instalowany i działa stale, logując zachowanie aplikacji w różnych scenariuszach. Xposed obsługuje Android do wersji 8.1; dla Android 9+ używany jest EdXposed oparty na SandHook.

// Frida: przechwytywanie metody decrypt() w aplikacji
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);
};

Proces inżynierii odwrotnej aplikacji Android

Standardowy workflow reversingu składa się z kolejnych kroków, z których każdy dostarcza określony poziom informacji.

Krok 1: Zbieranie danych wywiadowczych

Analityk bada APK na poziomie metadanych: targetSdk, uses-permission (jakie uprawnienia są wymagane), intent-filter i exported components. Na podstawie uprawnień można określić, które API są używane (android.permission.CAMERA → aparat, android.permission.RECORD_AUDIO → audio). Na podstawie exported activity określane są punkty wejścia bez autoryzacji. Ten etap jest wykonywany przez aapt lub ApkAnalyzer i zajmuje 1–2 minuty.

Krok 2: Dekompilacja DEX

APK jest rozpakowywany, classes.dex (lub multidex) jest przekazywany do jadx. Na wyjściu — kod Java/Kotlin w pakietach. Analityk szuka kluczowych klas: CryptoUtils, ApiClient, AuthManager, DatabaseHelper, i sprawdza, które algorytmy są używane. Jeśli w kodzie występują stringi AES/CBC/PKCS5Padding — aplikacja używa szyfrowania i trzeba znaleźć klucz. Na tym etapie określane są: zakodowane na stałe klucze, URL-e API, tokeny OAuth i sekrety. Bez obfuskacji cały kod aplikacji czyta się jak zwykły projekt Java.

Krok 3: Analiza ruchu

Konfigurując Fridę lub Objection do wyłączenia SSL-pinning, analityk uruchamia aplikację i przechwytuje ruch sieciowy przez Burp Suite lub mitmproxy. Na podstawie danych ruchu odtwarzany jest schemat API: jakie endpointy, jakie parametry, w jakim formacie. W miarę możliwości analityk modyfikuje żądania i sprawdza reakcję serwera na nieprawidłowe lub złośliwe dane. Brak walidacji po stronie serwera to bezpośrednia podatność wykryta na tym etapie.

Krok 4: Zapis do data.json

Wyniki analizy są zapisywane w ustrukturyzowanej formie. Dla każdego znalezionego podatnego miejsca wskazywane są: klasa i metoda, opis podatności, wektor eksploatacji i zalecenie naprawy. Ten zestaw danych jest przekazywany zespołowi developerskiemu lub używany do sporządzenia raportu z pentestu. W zautomatyzowanych środowiskach (MobSF) raport jest generowany automatycznie na podstawie analizy statycznej i dynamicznej.

Specyfika reverse engineering aplikacji iOS

Reverse engineering aplikacji iOS jest trudniejszy niż Android ze względu na bardziej rygorystyczną architekturę bezpieczeństwa Apple i brak bezpośredniego dostępu do systemu plików na standardowych urządzeniach. Do analizy iOS potrzebny jest jailbreak.

Analiza statyczna Mach-O

Archiwum IPA zawiera plik binarny Mach-O — uniwersalny format plików wykonywalnych Apple. Do dekompilacji używa się Hopper Disassembler lub IDA Pro. W przeciwieństwie do Android DEX, który dekompiluje się do Java z minimalnymi stratami, Mach-O zawiera natywny kod ARM64, który jest odtwarzany w pseudokod C z mniejszą dokładnością. Hopper radzi sobie z 60–70% odtworzenia, resztę trzeba analizować na poziomie asemblera.

Analiza dynamiczna z Fridą dla iOS

Frida na iOS wymaga jailbreaka i instalacji frida-server. Po podłączeniu Frida przechwytuje metody Objective-C przez API message routing. Dla aplikacji iOS typowy scenariusz: przechwytywanie metod NSURLSession.dataTaskWithRequest do logowania żądań HTTP, przechwytywanie NSKeyedUnarchiver do analizy danych serializowanych i śledzenie zapytań CoreData przez frida-trace. Frida stała się dostępna dla iOS 15–17 wraz z wydaniem jailbreaka Dopamine.

Modyfikacja IPA

Reversing może obejmować modyfikację IPA z późniejszym przepakowaniem i instalacją na urządzeniu. Narzędzia: ipatool do rozpakowywania, MachOView do przeglądania sekcji i optool do wstrzykiwania kodu. Po modyfikacji IPA jest podpisywany przez ldid lub fastlane sigh do instalacji na zjailbreakowanym urządzeniu. Dla iOS 16+ podpis kodu jest sprawdzany na poziomie Secure Enclave, a zmodyfikowane IPA nie uruchomi się na urządzeniu bez jailbreaka.

// Frida: przechwytywanie żądań HTTP w aplikacji iOS
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());
        }
    });
}

Metody ochrony przed reverse engineering

Ochrona przed inżynierią odwrotną opiera się na zasadzie layered security: żadna metoda nie zapewnia 100% ochrony, ale kombinacja sprawia, że reversing staje się ekonomicznie nieopłacalny.

Obfuskacja kodu

Podstawowy poziom — ProGuard dla Androida, który zastępuje nazwy klas i metod jednoznakowymi. Dla wzmocnienia używa się DexGuard, dodającego overload induction (kilka metod z różnymi sygnaturami i tą samą nazwą) oraz szyfrowanie stringów AES-256. Obfuskacja zwiększa czas analizy kodu z 5 minut do 5–20 godzin w zależności od poziomu. DexGuard dodatkowo zaciemnia przepływ sterowania, czyniąc kod nieczytelnym dla jadx.

Szyfrowanie stałych

Wszystkie stałe stringowe — URL-e, klucze, tokeny, zapytania SQL — są szyfrowane na etapie kompilacji i deszyfrowane w czasie wykonania. Chroni to przed statyczną analizą stringów pliku DEX. Atakujący, który uruchomi strings app.apk, nie zobaczy żadnego endpointu API. Nawet po dekompilacji wszystkie stringi wyglądają jak dane binarne. Dla każdego stringa można użyć osobnego klucza, co utrudnia deobfuskację.

RASP i kontrola integralności

Agent RASP wewnątrz aplikacji wykrywa Fridę i debugowanie w czasie wykonania. Kontrola integralności przez hash SHA-256 APK zapobiega uruchomieniu zmodyfikowanej wersji aplikacji. Jeśli hash APK nie zgadza się z wzorcowym (zapisanym w warstwie natywnej) — aplikacja się zamyka. Blokuje to ataki oparte na modyfikacji APK, w tym repackaging.

Ochrona serwerowa

Krytyczna logika biznesowa powinna być wykonywana na serwerze, a nie na kliencie. Nawet jeśli atakujący w pełni dekompiluje aplikację, kod serwerowy pozostanie niedostępny. Walidacja wszystkich żądań i parametrów po stronie serwera zapobiega eksploatacji podatności znalezionych podczas reversingu. Atestacja serwerowa przez Play Integrity API lub App Attest potwierdza, że żądanie pochodzi z autentycznej, niezmodyfikowanej aplikacji.