Marek Wesołowski

Zostaje koledze flashowanie z autoryzacją, tzw EDL lub prośba do Orange. Kolegi model ma zdaje się Qualcomm, a zatem sam bym robił głęboki flash przez adekwatny kabel czytając wcześniej specyfikację. Są na Ali za dolar z hakiem jak i na eBay. Trzeba zrobić research i nabyć, powinno pójść beż żadnych problemów. Wypadałoby mi też trochę wyjaśnić dla niewtajemniczonych Czym jest EDL (Emergency Download Mode)? TO tryb sprzętowy układów Qualcomm Snapdragon (oficjalna nazwa to Qualcomm HS-USB QDLoader 9008 służący do wgrywania firmware’u na najniższym poziomie. Niżej niż fastboot – CPU startuje z minimalnym bootloaderem z ROM-u maskowanego i komunikuje się przez port USB z komputerem. W praktyce „bootrom mode” dla Qualcomma. Są trzy metody wejścia w EDL: Kabel EDL (deep flash cable) – specjalny kabel za kilkanaście zł, który zwarciem linii D+ USB do GND (czasem na sekundę przy podłączaniu) wymusza wejście w EDL. Testpoint – fizyczne zwarcie padów na płycie głównej telefonu (opisywane w serwisówkach jako EDL/Test Point). Po zwarciu układ nie startuje normalnie, tylko od razu wchodzi w 9008. Komenda z fastboota – fastboot oem edl – kiedyś działało, teraz zablokowane (wymaga autoryzowanego konta Xiaomi), które o ile mi wiadomo kosztuje 1k USD rocznie jako tzw serwisówka. Ja robie jako koder niskopoziomowy i pisze głównie sterowniki + bezpieczeństwo jądra więc nie pomogę, ale ktoś z forumowiczów lub z linkedin na pewno ma dostęp. Trzeba pytać. MediaTek – ma ekwiwalent, który nazywa się po prostu BROM mode (BootROM). Można wejść zwarciem pinów / programowo lub wykorzystując exploita bypassa autoryzacji (np. SLA/DAA), więc można flashować bez oficjalnego konta. Ja bym robił opcję startu D+ zwieranie do GND, układ Qualcomma interpretuje to jako sygnał „uruchom EDL”. Offtopowo, =============== stworzyłem ostatnio dwa silne narzędzia pod windows 11 24h2 obchodzące wszelakie zabezpieczenia. Jedno loguje się jako TrustedInstaller zdobywając wszystkie prawa (enum /priv idzie na full), drugie może manipulować procesami PP/PPL z WinTCB i dowolnymi z jądrem w RING-0 bo wykorzystałem podpisany przez ms sterownik z dziurą. Jeszcze tego nie publikowałem, szukam adminów co by się pobawili w zrzucanie LSASS i przypisywanie praw GURU WinTcb, dostępy do wszystkich kluczy etc.. Kod źródłowy ma solidną architekturę – czytelny podział na klasy (Core, OffsetFinder, Controller), bezpieczeństwo – porządna obsługa błędów i użycie std::optional. Fine tuning to ubranie, ale artystą nie jestem, lubię stare, szybkie WinAPI, MFC ew. konsole. Pozdrawiam

Moim zdaniem nie chodzi o szczęście. Już Wam wyjaśniam jak to działa jako programista. Mechanizm powiązania konta i odblokowania bootloadera w Xiaomi ma dobowy limit zgłoszeń (quota) resetowany wg czasu w Chinach. Portal Xiaomi Community pilnuje tego limitu na froncie, ale API backendowe, z którego korzysta telefon, w momencie resetu ma krótki okres niespójności (race condition). Stąd możliwe jest „wstrzelenie się” w kilka sekund o północy czasu pekińskiego i powiązanie urządzenia mimo komunikatu o braku dostępnych slotów. Jaka akcja tu się dzieje? Jak wiecie bootloader to pierwszy fragment oprogramowania uruchamiany przez SoC (np. Qualcomm, MediaTek) zaraz po ROM-ie startowym (tzw. ROM-code). Ma on kilka ról: inicjalizacja sprzętu, weryfikacja podpisów kryptograficznych obrazów systemowych (tzw. Verified Boot), kontrola, czy użytkownik może wgrać inny system czy tylko uruchomić fabryczny. „Zablokowany bootloader” oznacza, że obrazy systemowe (boot.img, recovery.img itd.) muszą być podpisane kluczem producenta. Rozpiszę co dokładnie robi Xiaomi w kwestii odblokowania. W Xiaomi to jest system powiązany z kontem Mi i serwerami Xiaomi. W skrócie: Powiązanie konta W menu programisty urządzenie zapisuje w swojej pamięci unikalny identyfikator (IMEI/MEID, SN, czasem też hardware ID). Ten identyfikator jest przesyłany do serwerów Xiaomi i przypisany do Twojego konta Mi. Gdy wchodzisz w fastboot i uruchamiasz oficjalne narzędzie „Mi Unlock Tool” na komputerze, ono uwierzytelnia się na serwerach Xiaomi Twoim kontem, (zaufanie, sms) wysyła dane urządzenia (SN, chip ID, czasem hash z eFuse). No i mamy sprawdzanie czyli serwerową autoryzacje. Serwer Xiaomi sprawdza, czy konto i urządzenie są sparowane, i czy minął czas oczekiwania (np. 168h). Dopiero wtedy serwer zwraca token kryptograficzny pozwalający na odblokowanie. Technicznie: Token i eFuse Bootloader w SoC (Qualcomm lub MediaTek) ma mechanizm tamper flag / QFuse/eFuse albo odpowiednik OTP. Mi Unlock Tool przekazuje token od serwera do urządzenia. Bootloader weryfikuje podpis cyfrowy (RSA/ECC) Xiaomi. Jeśli jest poprawny, ustawia odpowiedni bit w pamięci (czasem w eFuse, czasem w NVRAM w zalezności od modelu), który zmienia stan „unlocked”. Od tego momentu bootloader już nie wymaga podpisanych obrazów Xiaomi (ale nadal pokazuje ostrzeżenie przy starcie). Dlaczego trzeba być online i dlaczego każą wyłączyć Wi-Fi na urządzeniu przy powiązaniu. Otóż moi drodzy połączenie idzie z telefonu i/lub z Mi Unlock Tool na PC → zawsze do serwerów Xiaomi w Chinach. Xiaomi wymusza używanie danych mobilnych tylko i wyłącznie w trakcie powiązania konta, aby zweryfikować kartę SIM i region operatora (czyli, że to faktycznie użytkownik, a nie automat czy emulator). To dodatkowa forma antyfraudowa, podobna do tego jak robią banki. Mi to przypomina Computrace (Absolute) w biosach Della czyli system MDM/anti-theft, który łączy komputer z centralnym serwerem i może wykonywać komendy zdalne (np. zablokować komputer). Xiaomi implementuje podobny mechanizm: telefon weryfikuje swoją tożsamość na serwerach producenta i tylko po kryptograficznym zatwierdzeniu odblokowuje bootloader. Różnica jest taka, że computrace działa cały czas i reaguje na polecenia, a Xiaomi używa tej logiki tylko przy operacji unlock. Co się faktycznie dzieje w chwili odblokowania Fastboot otrzymuje poprawny token podpisany kluczem prywatnym Xiaomi. Bootloader weryfikuje go kluczem publicznym zaszytym w SoC/firmware. Jeśli wszystko gra, stan unlocked zostaje zapisany w pamięci trwałej (eFuse lub w specjalnym obszarze NVRAM). Urządzenie od tej chwili nie sprawdza już podpisu Xiaomi dla obrazów systemowych (choć Verified Boot może działać dalej, np. z ostrzeżeniem). Zatem proces jest całkowicie po stronie serwera i kluczy kryptograficznych Xiaomi, użytkownik nigdy nie łamie zabezpieczeń lokalnie – tylko dostaje zgodę od Xiaomi, albo nie. Same tokeny są unikalne, podpisane i ważne krótko → nie da się ich ponownie użyć ani przechwycić. Mamy tu proces uwierzytelnienia klient–serwer z użyciem kryptografii asymetrycznej, w którym serwer Xiaomi generuje podpisany token pozwalający bootloaderowi ustawić trwałą flagę unlocked. Mechanizm wymaga centralnej zgody producenta, a nie tylko lokalnej operacji na urządzeniu. Teraz o okienku „application quota limited” w Community, i sprawnym kliknięciu w Opcjach programisty → Dodaj konto i urządzenie by ruszyło... .Spróbuję Wam to wyjaśnić od strony technicznej i sieciowej, jak Xiaomi zorganizowało infrastrukturę i limity po stronie serwerów. Formalnie Xiaomi wymaga, żeby użytkownik zgłosił chęć odblokowania przez portal/community. W praktyce portal to frontend webowy do tego samego API serwerów Xiaomi, które obsługują powiązanie konta. Oni wprowadzili quota (limit zgłoszeń dziennych na konto/region) – stąd komunikat "application quota limited". Serwery Xiaomi pracują wg czasu w Chinach (CST, UTC+8). Limit na zgłoszenia resetuje się o 00:00 CST czyli w Polsce latem wypada dokładnie o 18:00. Wszyscy „hunterzy odblokowań” wiedzą, że wtedy trzeba próbować i walą bootem. Teraz najciekawsze. Portal community i opcja w telefonie używają tego samego backendu API Xiaomi (powiązanie konta ↔ urządzenie). Gdy quota dobowa się kończy, portal webowy natychmiast pokazuje „application quota limited”. Tam jest walka o czas. A to tylko walidacja po stronie frontendu (aplikacja webowa/serwer community). Natomiast aplikacja systemowa w telefonie (Opcje programisty → powiązanie konta) wysyła żądanie bezpośrednio do tego API, z pominięciem części walidacji. W momencie resetu quota (00:00 CST) przez kilka sekund API jest jeszcze „otwarte”, a load balancer i serwery synchronizują się. W poprzednim i pierwszy poście nazwałem to bugiem. Jeśli użytkownik trafi w ten krótki czas okna (tzw. race condition), to request z telefonu przechodzi i urządzenie zostaje sparowane z kontem – nawet jeśli webowy portal nadal raportuje quota error. Mamy klasyczny timing issue / race condition między frontem (community) a backendem (serwer od powiązań). Backend resetuje quota o północy czasu pekińskiego. Ale cache/load balancer propaguje tę zmianę stopniowo między klastrami serwerów. W tej „fazie przejściowej” requesty z telefonu będą zaakceptowane, nawet gdy portal już pokazuje błąd. Po kilku sekundach wszystko się zsynchronizuje i quota znowu jest wyczerpana – dlatego liczy się refleks. Ale nieco inny niż większość myśli. Powiązanie nie wymaga, żeby fizycznie „ten” telefon wysyłał zgłoszenie przez Community – ważne jest tylko, by konto Mi miało poprawny status. Jeśli konto zostanie przyjęte w tym „okienku”, to kiedy właściwy telefon w Opcjach programisty zrobi żądanie → backend już widzi konto jako kwalifikowane i akceptuje pairing. Stąd obejście przez WSA jest zwyczajnie wygodne, ae można to zrobić na wiele innych sposobów jak przechwycenie tokena w przeglądarce, python etc.. Kluczem jest czas procesu wiązania na urządzeniu Proces przechodzi na każdym jednym telefonie Odnośnie późniejszych metod na portfel i revolut, zdecydowanie preferuję aPatch. Zresztą kod zassany z trabala oficjalnego kompiluję sobie prywatnie i mocno customizuję. Magisk to działania w ramdisku i maskowanie modó, aPatch jest w ring -1 do 0. Nie trzeba trików z overlayem bo „wstrzykuje” fragmenty kodu czy też modyfikuje istniejące instrukcje w gotowym kernelu łamiąc SELinuxa. Pozdrawiam i dawajcie znać. Pamiętajcie by na urządzeniu wyłączyć Wi-Fi

Szanowni Panowie, metoda odblokowania przez server ma błąd. Ponieważ d/d pod rząd odblokowałem już 7-my smartphone, w tym dziś niespełna godzinę temu opiszę w miarę szybko jak należy to zrobić. 1) Instalujemy na Windows 11 WSA, najlepiej od MustardChef z github WSA_2407.40000.4.0_x64_Release-Nightly-with-magisk-29.0.29000.-stable-GApps-13.0.7z, musimy mieć włączone Hyper-V w Windows 11, a to implikuje domyślnie włączone VT-X i VT-d w BIOS/EFI. 2) Wchodzimy do google play, logujemy się pobieramy xiaomi community logujemy się. Nie ma żadnego znaczenia LAN/WWAN/WiFi 3) Uruchamiamy sobie przed 18.00 czasu letniego tak by 17.59.59 do 18.00.02 kliknąć "Apply For Unlocking" Musimy na telefonie mieć tryb programisty i gotowość to powiązania konta "Dodaj konto i urządzenie". 4) Teraz uwaga, mimo, że z kompa otrzymamy komunikat "Application quota limit reached, please try again after XX/XX" Nie martwimy się. Natychmiast wolnym palcem o 18.00.01-do 18.00.05 (moje czasy) klikamy w "dodaj konto i urządzenie" z poziomu tel w oknie programisty - stan odblokowania MI i uprzedniej akceptacji ZGODY! w "Wymagane Uprawnienia". Pamiętajcie o tym by nie tracić czasu. 5) Po sekundzie ujrzycie komunikat o pomyślnym powiązaniu konta z urządzeniem "dodano..." W załączniku zrzuty w trakcie pisania postu. U mnie czas oczekiwania np. od dzisiejszej operacji to 72h. Jest on różny i losowy