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.
- Uruchom telefon w trybie “Download Mode” (flashowanie)
- Załaduj “Combination Firmware” do telefonu (Odin - pole AP)
- Uruchom telefon i sprawdź, czy poprawnie się uruchamia
- Uruchom telefon w trybie “Download Mode” (flashowanie)
- 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
- Załaduj utworzony plik do telefonu (Odin - pole AP)
- 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:
- Uruchom telefon w trybie “Download Mode” (flashowanie)
- Załaduj stockowe pliki firmware (Odin - pole BL, AP, CP, CSC)
- 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)
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.
Cześć. Mam tylko jedno pytanie, nie mogę znależć pliku
system.img.lz4
. W którym archiwum ze stockowego romu się on znajduje? Super poradnik!!!Ciężko mi powiedzieć, jak dobrze pamiętam to ten obraz “leży” w archiwum systemowym (
AP
). Najlepiej przejrzyj wszystkie archiwa w poszukiwaniu plikusystem.img
.Mam podobny problem jak MrKalembus. Wypakowałem wszystkie pliki do folderów i nie mogę znaleźć tego jedynego pliku
system.img.lz4
. W plikuAP
mam pliksuper.img.lz4
.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 ;)
Ś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:
Jak można w takiej sytuacji ominąć FRP bez powyższych? Ma ktoś pomysł?
Pomoże ktoś w dostaniu tego pliku? To jest jakaś masakra…