Zadanie 3 – zmiana, podpisanie i ponowna instalacjia aplikacji
Po dekompilacji pliku three.apk widzimy kod, który niezależnie od wyniku wywołuje metodę nope(), kawałek niżej widzimy też metodę yep()
return-object v0 zwróci nam napis „don’t wanna” i wydrukuje w aplikacji jako flagę, a my chcemy poznać wynik funkcji cilantro() z metody yep(). Zmieńmy zatem w linijce 25 wywołanie funkcji na inną.
Po zapisaniu zmian w aplikacji budujemy ją na nowo:
I instalujemy plik new_three.apk, żeby otrzymać błąd…
Problemem jest niepodpisana aplikacja .apk i to że mamy już taką aplikację zainstalowaną na emulatorze. Możemy poczytać o podpisywaniu aplikacji więcej w tym artykule, a ja w skrócie podam komendy które wygenerują nam klucz i podpiszą aplikację do użytku lokalnego.
Generowanie klucza (ważne jest to, żeby ścieżka do jdk/bin Javy była w zmiennej systemowej PATH, u mnie to C:\Program Files\Java\jdk1.8.0_211\bin).
1 | keytool -genkey -v -keystore mycustomname.keystore -alias mycustom_alias -keyalg RSA -keysize 2048 -validity 10000 |
Musimy po tym przejść przez krótki generator i podać trochę danych (nie muszą być prawdziwe. Ci idioci tego nie sprawdzają 😉 )
Następnie podpisujemy aplikację gdy mamy już wygenerowany klucz:
1 | jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore mycustomname.keystore new_three.apk mycustom_alias |
Powinniśmy otrzymać na koniec komunikat, że się udało:
Teraz możemy uruchomić naszą zmienioną aplikację na emulatorze i zobaczyć czy zadziałało.
Uwaga: zanim zainstalujemy aplikację na nowo musimy odinstalować starą ręcznie z emulatora androida (drag and drop do kosza z nią wystarczy). Chwilę po tym możemy cieszyć się flagą wpisując dowolne hasło:
Zadanie 4 – ostatnie
Zaczynamy od dekompilacji aplikacji four.apk
Metoda getFlag() jest dość skomplikowana i można by pokusić się o odwrócenie funkcji wyliczającej hasło, ale oczywiście breakpoint załatwi nam sprawę szybciej. Ustawiamy go na linię 228 pliku FlagstaffHill.smali i odpalamy aplikację
Widzimy hasło: alphabetsoup, którego nawet nie musieliśmy wyliczać odwracając skomplikowany kod. Ale… co stanie się po wpisaniu go do aplikacji? Kod zwróci obiekt v5, czyli napis „call it” w miejsce flagi. Hmmm, wygląda na to że programiści zapomnieli wywołać odpowiednią funkcję w tym miejscu…
Po analizie pliku widzimy w linii 16 tego pliku ciekawą metodę statyczną (to jest import z biblioteki zewnętrznej) cardamom().
1 | .method public static native cardamom(Ljava/lang/String;)Ljava/lang/String; |
Wywołajmy zatem poprawną metodę zmieniając liniję 234 . Nasz kod po zmianie powinien wyglądać tak:
Kompilujemy, podpisujemy i uruchamiamy aplikację (tak jak powyżej w zadaniu 3) wpisując tym razem poprawne hasło „alphabetsoup” i… flaga jest nasza.
W ten sposób rozwiązaliśmy wszystkie zadania picoCTF2019 dotyczące reverse engineeringu aplikacji na Androida.
Podsumowanie zadań
- Każdą aplikację androida możemy zdekompilować, przerobić i uruchomić zdalnie. Trzymanie jakichkolwiek sekretów (nawet zaszyfrowanych) w aplikacji udostępnionej klientowi jest nieskuteczne.
- Prawie każdy kod da się odwrócić (wyjątkiem są algorytmy hashujące)
- A nawet jak się nie da, to wystarczy ustawić w dobrym miejscu breakpoint.
- A jeżeli nie da się ustawić breakpointa, to zawsze można zmienić kod (np. if (userEntry == passwordHash) na if (userEntry != passwordHash)
- Nie ma idealnych zabezpieczeń dla aplikacji Androida, są tylko takie których złamanie zajmie więcej czasu (będzie bardziej kosztowne) niż zakup licencji…
Tym optymistycznym akcentem, zachęcam do udziału w kolejnych edycjach picoCTF wszystkich testerów i programistów. Spojrzenie z tej drugiej strony na aplikacje jest niezwykle rozwojowe 🙂