Omijanie Factory Reset Protection na Androidzie

tech • 893 słowa • 5 minut czytania

Trochę świątecznego czasu w minione Boże Narodzenie zabrała mi paskudna zabawa z telefonem Samsunga. W smartphonie występował dziwny problem z “uwalaniem” procesów lub sterowników Bluetooth-a. Uznałem, że najłatwiej będzie “zresetować” system do ustawień fabrycznych, czyli taki przysłowiowy “format”. Bo całkiem możliwe, że ten problem powstał po jakimś czasie od ostatniej aktualizacji. Czystkę zrobiłem “po chamsku” wprost spod bootloadera, myśląc, że tak będzie “lepiej” i “pro”… no i pojawiły się dodatkowe i niespodziewane problemy.

Telefon po długim uruchamianiu wreszcie wstał i pojawił się standardowy kreator, jak to bywa przy pierwszym uruchomieniu. Po przebrnięciu przez kilka ekranów system wywalił komunikat:

Miała miejsce nieautoryzowana próba przywrócenia domyślnych ustawień fabrycznych Twojego urządzenia. Połącz się z siecią Wi-Fi lub siecią komórkową, aby zweryfikować swoją tożsamość.

Po połączeniu z Internetem i dojściu do ekranu logowania z kontem Google na ekranie pojawiło się to:

Zweryfikuj konto. Urządzenie zostało zresetowane. Aby kontynuować, zaloguj się na konto Google, które było wcześniej synchronizowane na tym urządzeniu.

I wszystko byłoby w porządku, gdyby hasło do poprzednio używanego konta było znane. Niestety konto tam podpięte powstało tylko w jednym celu - na potrzeby tego telefonu i nigdzie indziej nie było wykorzystywane, dlatego właściciel nie pamiętał hasła. Wszelkie dostępne mechanizmy zresetowania hasła do konta również zakończyły się fiaskiem.

Za całe to zamieszanie odpowiada mechanizm “Factory Reset Protection” (FRP). Jest to zabezpieczenie, które zawitało do Androida bodajże w wersji 5.x. Ma ono chronić telefon, a raczej go blokować po próbie nieautoryzowanego zresetowania, co najczęściej następuje po kradzieży. Po takiej próbie system wymaga zalogowania się na to samo konto Google, które wcześniej było na nim używane.

Gdybym wiedział o tej niespodziance, to pewnie wcześniej bym wyrejestrował konto z systemu, albo chociaż skorzystał z autoryzowanego “resetu” (tego z GUI systemu, zamiast z menu bootloadera). No ale kto mógłby się tego spodziewać, zważywszy, że tematy smartphonowe mnie zbytnio nie interesują.

Oczywiście, jak można się domyślić, wszelkie pokazane w sieci metody obejścia tej autoryzacji za pomocą przeskoczenia do ustawień systemu w celu dodania konta Google czy użycia jakiejś aplikacji usuwającej dane FRP nie działały. W sumie to zrozumiale, bazowały one na błędach i niedoróbkach w systemie, więc z czasem zostały poprawione.

To przekonało mnie, że czas na flashowanie. Pierwsze moje flashowanie i do tego nie swojego telefonu. Choć po głowie chodziła myśl, że z dużym prawdopodobieństwem to zabezpieczenie jest na to odporne i dane FRP mogą być zapisane w miejscu, którego standardowe programowanie nie dotyka lub w nawet w dedykowanym security chipie. Moje podejrzenia się potwierdziły. Przeflashowanie nowym stockowym ROM-em nie przyniosło spodziewanego rezultatu.

Zacząłem kombinować z różnymi opcjami i wersją “Combination” oprogramowania przeznaczoną głównie dla serwisów. Kompilacja “Factroy Binary” uruchamiała się bezproblemowo, więc idealną dla mnie opcją byłoby odpalenie własnie tej wersji systemu, na bazie której “zbudowano” serwisową dystrybucję. Wtedy miałbym dostęp do pełnoprawnego systemu i może udałoby się podpiąć nowe konto Googla lub jakoś “zresetować” zapisane dane FRP.

Po różnych zabiegach i próbach udało mi się znaleźć sposób. Gdybym bardziej orientował się w systemie Andorid i jego architekturze to pewnie szybciej bym do tego doszedł. A wystarczyło podmienić kilka plików związanych z bootowaniem systemu, aby odpalić starszego Androida na zablokowanym telefonie. Poniżej zamieszczam krótką instrukcję z wyszczególnieniem istotnych kroków.

  1. Uruchom telefon w trybie “Download Mode” (flashowanie)
  2. Załaduj “Combination Firmware” do telefonu (Odin - pole AP)
  3. Uruchom telefon i sprawdź, czy poprawnie się uruchamia
  4. Uruchom telefon w trybie “Download Mode” (flashowanie)
  5. Z oficjalnego pakietu firmware (stock ROM) wyodrębnij pliki:
    boot.img.lz4, sboot.bin.lz4, system.img.lz4
    i “spakuj” je do archiwum TAR, np. my_system.tar
  6. Załaduj utworzony plik do telefonu (Odin - pole AP)
  7. Uruchom telefon

Telefon powinien uruchomić się z wersją systemu użytą do stworzenia “Combination Firmware”, a tym samym pominąć kroki związane z pierwszym uruchomieniem (wizardem), który sprawdza FRP, prosi o autoryzację i potwierdzenie tożsamości. W tym momencie można byłoby zabawę zakończyć, w końcu telefon “odżył”.

Niemniej chciałem, aby po całej operacji powrócić do oficjalnego (oryginalnego) oprogramowania. Dlatego po uruchomieniu i dostaniu się do opcji dodałem znane mi konto Googla. To nadpisało stare dane znajdujące się w miejscu przechowywania FRP. Następnie sflashwoalem ponownie telefon stockowym ROM-em, czyli zastosowałem standardowe kroki przy typowej zmianie oprogramowania:

  1. Uruchom telefon w trybie “Download Mode” (flashowanie)
  2. Załaduj stockowe pliki firmware (Odin - pole BL, AP, CP, CSC)
  3. Uruchom telefon

Po uruchomieniu system oczywiście znów wykrył nieautoryzowaną próbę przywrócenia telefonu do ustawień fabrycznych, ale tym razem bez problemu mogłem się zalogować i potwierdzić swoją tożsamość tym wcześniej dodanym kontem. Mozliwe, że gdybym przed ponownym flashowaniem wywalił dodane wcześniej konto nadpisujące stare dane FRP to w tym momencie system nie powinien zaprzątać nam tym problemem głowy.

Najważniejsze, że udało się ominąć blokadę, a przy okazji reflash (i powrót do ustawień fabrycznych) rozwiązał ten początkowy problem z Bluetooth-em, od którego zaczęła się cała ta zabawa z telefonem.

Niniejsza notatka powstała w celach dokumentacyjnych, bo kto wie, czy w przyszłości nie natrafię na podobny problem. Przynajmniej będę wiedział, jak ostatnio sobie z nim poradziłem i ewentualnie czego spróbować przy kolejnej próbie.

W czasie tworzenia tego tekstu natrafiłem na ciekawy wpis Morfika - Factory Reset Protection (FRP) w smartfonach z Androidem, który potwierdza moje przypuszczenia o dedykowanej partycji dla FRP. Prawdopodobnie następnym razem powinienem spróbować rozwiązać taki problem skupiając się właśnie na tym wycinku pamięci flash telefonu. Ponoć w niektórych telefonach są przewidziane w bootloaderze dedykowane opcje do zabawy z frp i oem lockiem. Kiedyś to przebadam, ale póki nie muszę, to nie wgłębiam się w tę otchłań technicznych bebechów dzisiejszych smartphone-ów ;)

Komentarze (7)

Zbychoo avatar
Zbychoo
20201031-014211-zbychoo

Niewiarygodne! To jest najlepszy poradnik ever. Sprawdziłem z Samsung Galaxy A5 2017. Telefon miał iść do śmietnika przez nieopatrzne czyszczenie danych, ale teraz posłuży jako nawigacja do samochodu. Wszelkie pseudoporadniki z oszukiwaniem wi-fi, czy przeglądarką chrome nie działają. Dzięki autorowi, telefon dostał kolejne życie, dobra robota.

MrKalembus avatar
MrKalembus
20201118-202331-mrkalembus

Cześć. Mam tylko jedno pytanie, nie mogę znależć pliku system.img.lz4. W którym archiwum ze stockowego romu się on znajduje? Super poradnik!!!

Malcom avatar
Malcom
20201118-203849-malcom

Ciężko mi powiedzieć, jak dobrze pamiętam to ten obraz “leży” w archiwum systemowym (AP). Najlepiej przejrzyj wszystkie archiwa w poszukiwaniu pliku system.img.

Bobek avatar
Bobek
20210809-142023-bobek

Mam podobny problem jak MrKalembus. Wypakowałem wszystkie pliki do folderów i nie mogę znaleźć tego jedynego pliku system.img.lz4. W pliku AP mam plik super.img.lz4.

Malcom avatar
Malcom
20210810-200117-malcom

Wygląda na to, że od wersji 10-tej Androida zmieniły się nieco partycje i ten super.img jest takim zbiorczym plikiem zawierającym kilka dynamicznych partycji. W sieci można znaleźć kilka sposobów na wyodrębnienie potrzebnych plików z takiego obrazu - choćby tutaj na forum xda: Editing system.img inside super.img and flashing our modifications.

Zbytnio nie interesuję się tym systemem, więc nie mogę bardziej pomóc, no chyba, że znów sam będę miał jakiś problem ;)

toor avatar
toor
20210814-213957-toor

Świetny poradnik, dzięki.

Pytanie: co w sytuacji kiedy Odin wyrzuca komunikat przy Combination File o treści: “Re-Partition operation failed.”?

Dokopałem się do 2 możliwości:

  1. Brak root (rzeczywiście go nie mam).
  2. Brak USB Debugging w ustawieniach (również nie zostało to zrobione przed wipe (nie ja robiłem wipe).

Jak można w takiej sytuacji ominąć FRP bez powyższych? Ma ktoś pomysł?

Dreduuu avatar
Dreduuu
20220313-004547-dreduuu

Pomoże ktoś w dostaniu tego pliku? To jest jakaś masakra…

Dodaj komentarz

/dozwolony markdown/

/nie zostanie opublikowany/