1. Wprowadzenie
2. Podstawy aplikacji na Androida
3. Początek z odwracaniem aplikacji na Androida
   • Ćwiczenie 1
4. Odwrócona inżynieria aplikacji na Androida -. DEX Bytecode
   • Ćwiczenie 2
   • Ćwiczenie 3
   • Ćwiczenie 4
5. Reverse Engineering Android Apps -. Native Libraries
   • Ćwiczenie 5
   • Ćwiczenie 6
6. Reverse Engineering Android Apps -. Obfuscation
   • Ćwiczenie 7
7. Conclusion

Build an App

Jedną z moich największych sugestii dla ludzi szukających odwrotnej inżynierii rzeczy, cokolwiek to może być, to spróbować i zbudować to, co chcesz odwrócić. W przypadku Androida, masz szczęście, ponieważ jest tak wiele darmowych zasobów dostępnych do zbudowania swojej pierwszej aplikacji. Jeśli nigdy wcześniej nie zbudowałeś aplikacji na Androida, sugeruję, abyś zaczął od tego. Wybierz dowolny z dostępnych tutoriali i filmów, które wzbudzają Twoje zainteresowanie i zacznij budować. Kiedy zrozumiesz, jak deweloper buduje coś, to sprawia, że dużo łatwiej zrozumieć, jak odwrócić inżynierię go.

Fundamentals Review

Great! Zbudowałeś aplikację lub nauczyłeś się podstawowych zasad tworzenia aplikacji na Androida. Poniżej znajduje się przegląd niektórych ważnych punktów. Ta strona „Podstawy aplikacji” w dokumentach programistów Androida jest świetnym przeglądem.

• Aplikacje Androida są w formacie pliku APK. APK jest w zasadzie plikiem ZIP. (Możesz zmienić nazwę rozszerzenia pliku na .zip i użyć unzip, aby otworzyć i zobaczyć jego zawartość.)
• Zawartość APK (Nie wyczerpuje tematu)
  • AndroidManifest.xml
  • META-INF/
    • Certificate lives here!
  • classes.dex
    • Dalvik bytecode dla aplikacji w formacie pliku DEX. To jest kod Java (lub Kotlin), który aplikacja będzie domyślnie uruchamiać.
  • lib/
    • Natywne biblioteki dla aplikacji, domyślnie, znajdują się tutaj! Pod katalogiem lib/, znajdują się katalogi specyficzne dla procesora. Na przykład: armeabi, mips,
  • assets/
    • Wszystkie inne pliki, które mogą być potrzebne aplikacji.
    • Dodatkowe biblioteki natywne lub pliki DEX mogą być dołączone tutaj. Może się to zdarzyć szczególnie wtedy, gdy autorzy złośliwego oprogramowania chcą spróbować „ukryć” dodatkowy kod, natywny lub Dalvik, nie włączając go do domyślnych lokalizacji.

Dalvik & Smali

Większość aplikacji na Androida jest napisana w Javie. Kotlin jest również obsługiwany i interoperacyjny z Javą. Dla ułatwienia, w pozostałej części tego warsztatu, kiedy odnoszę się do „Javy”, możesz założyć, że mam na myśli „Javę lub Kotlin”. Zamiast kodu Java uruchamianego w maszynie wirtualnej Java (JVM), jak w przypadku aplikacji desktopowych, w Androidzie Java jest kompilowana do formatu kodu bajtowego Dalvik Executable (DEX). Dla wcześniejszych wersji Androida, bajtkod był tłumaczony przez maszynę wirtualną Dalvik. Dla nowszych wersji Androida, Android Runtime (ART) jest używany.
Jeśli deweloperzy, piszą w Javie i kod jest skompilowany do DEX bytecode, do inżynierii wstecznej, pracujemy w przeciwnym kierunku.

Smali jest czytelną dla człowieka wersją kodu bajtowego Dalvik. Technicznie, Smali i baksmali to nazwy narzędzi (asembler i disassembler, odpowiednio), ale w Androidzie, często używamy terminu „Smali” w odniesieniu do instrukcji. Jeśli zrobiłeś inżynierię odwrotną lub architekturę komputerową na skompilowanym kodzie C / C ++. SMALI jest jak język montażowy: między kodem źródłowym wyższego poziomu a kodem bajtowym.

Dla następującego kodu Hello World Java:

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

Kod Smali byłby:

.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

Zestaw instrukcji Smali jest dostępny tutaj.

Najczęściej podczas inżynierii wstecznej aplikacji Android, nie będziesz musiał pracować w Smali. Większość aplikacji może być podniesiona do jeszcze wyższego poziomu, zdekompilowanej Javy. Jak wszystkie narzędzia, dekompilatory Java mogą mieć błędy. Moja sugestia dla ciebie jest taka, że za każdym razem, gdy zdekompilowane wyjście Java wygląda wątpliwie, spójrz na wyjście Smali. Pracuj linia po linii z referencją instrukcji, aby dowiedzieć się co robi kod.

Aby uzyskać Smali z DEX, możesz użyć narzędzia baksmali (disassembler) dostępnego w https://github.com/JesusFreke/smali/wiki. Narzędzie smali pozwoli ci złożyć smali z powrotem do DEX.

Punkty wejścia do aplikacji

Jednym z najważniejszych punktów inżynierii wstecznej jest wiedza, gdzie rozpocząć analizę, a punkty wejścia do wykonania kodu są ważną częścią tego.

Działanie launchera

Działanie launchera jest tym, o czym większość ludzi myśli jako o punkcie wejścia do aplikacji Androida. Aktywność launchera jest aktywnością, która jest uruchamiana, gdy użytkownik kliknie na ikonę aplikacji. Możesz określić aktywność launchera patrząc na manifest aplikacji. Aktywność launchera będzie miała następujące intencje MAIN i LAUNCHER wymienione.

Pamiętaj, że nie każda aplikacja będzie miała aktywność launchera, zwłaszcza aplikacje bez UI. Przykładami aplikacji bez UI (a więc aktywności launchera) są preinstalowane aplikacje, które wykonują usługi w tle, takie jak poczta głosowa.

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

Usługi

Usługi działają w tle bez UI. Istnieją niezliczone sposoby, na jakie można je uruchomić, dzięki czemu stanowią punkt wejścia dla aplikacji. Domyślnym sposobem, w jaki usługa może zostać uruchomiona jako punkt wejścia do aplikacji, jest Intents.

Gdy startService API jest wywoływane w celu uruchomienia Usługi, wykonywana jest metoda onStart w Usłudze.

Odbiorniki rozgłaszania

Odbiorniki rozgłaszania można myśleć o systemie przesyłania wiadomości, a odbiorniki rozgłaszania są słuchaczami. Jeśli aplikacja zarejestrowała odbiornik dla określonego przekazu, kod w tym odbiorniku jest wykonywany, gdy system wysyła przekaz. Istnieją 2 sposoby, w jakie aplikacja może zarejestrować odbiornik: w Manifeście aplikacji lub dynamicznie rejestrowany w kodzie aplikacji za pomocą wywołania registerReceiver() API.

W obu przypadkach, aby zarejestrować odbiornik, ustawiane są filtry intencji dla odbiornika. Te filtry intencji to transmisje, które powinny wyzwalać odbiornik.

Gdy wysyłane są określone transmisje, dla których odbiornik jest zarejestrowany, wykonywana jest onReceive w klasie BroadcastReceiver.

Eksportowane komponenty (Usługi & Działania)

Usługi i Działania mogą być również „eksportowane”, co pozwala innym procesom na urządzeniu uruchomić usługę lub uruchomić działanie. Komponenty są eksportowane przez ustawienie elementu w manifeście, jak poniżej. Domyślnie android:exported="false", chyba że ten element jest ustawiony na true w manifeście lub zdefiniowano intent-filters dla Aktywności lub Usługi.

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

Podklasa Aplikacji

Androidowe aplikacje mogą definiować podklasę Aplikacji. Aplikacje mogą, ale nie muszą definiować niestandardowej podklasy Aplikacji. Jeśli aplikacja Android definiuje podklasę Application, klasa ta jest instancjonowana przed każdą inną klasą w aplikacji.

Jeśli metoda attachBaseContext jest zdefiniowana w podklasie Application, jest ona wywoływana jako pierwsza, przed metodą onCreate.

NEXT > 3. Getting Started with Reversing Android Apps

.