Ranking

Wymiana baterii. Z tego co pamiętam Redmi 8 właśnie miał takie przygody kiedyś i wymiana baterii pomagała. W sumie jego rozbiórka jest dosyć łatwa więc możesz odpiąć baterię, podpiąć i zobaczyć co będzie albo przy okazji sprawdzić przyciski czyli niech się włączy i lekko podnieść plastikową kartą płytę główną by nie dotykała taśmy przycisków. Jak się włączy to oznacza wadę przycisków/taśmy a jak nie to bateria.

może zmień te ustawienia w dodatkowych? chyba że coś popsuli w tym sofcie ... trudno powiedzieć ... asystent i wylacz ...

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