Jak to zwykło się mawiać w świecie IT: ludzie dzielą się na te osobniki, które robią backup i te, co backup robić będą. Jakiś czas temu pochyliłem się nad zagadnieniem czy smartfon z Androidem bez Google Play Services ma sens. Poruszyłem tam problem tworzenia kopi zapasowej danych użytkownika zgromadzonych w telefonie. W tym podlinkowanym artykule zostało przestawione jak przy pomocy TWRP dokonać pełnego backupu całego systemu urządzenia i o ile pod względem technicznym takie podejście było jak najbardziej w pełni do zaakceptowania, to jednak to rozwiązanie miało dość istotną wadę, tj. na czas backup'u trzeba było wyłączyć smartfon. Parę dni temu natrafiłem na narzędzia OAndBackupX, które jest w stanie zrobić kopię zapasową wszystkich zainstalowanych w Androidzie aplikacji (oraz ich ustawień), wliczając w to nawet appki systemowe. OAndBackupX jest o tyle lepszym rozwiązaniem w stosunku do TWRP, że można przy jego pomocy robić kopię danych pojedynczych aplikacji, a nie od razu całego ROM'u, co nie tylko jest czasochłonne ale również zjada sporo miejsca na dysku komputera, czy gdzie ten backup zamierzamy przechowywać. Niestety OAndBackupX wymaga uprawnień root, zatem na stock'owym ROM'ie producenta naszego telefonu nie damy rady z tego narzędzia skorzystać. Jeśli jednak mamy alternatywny ROM na bazie AOSP/LineageOS, to przydałoby się rzucić okiem na ten kawałek oprogramowania, bo zdaje się ono być wielce użyteczne, zwłaszcza w przypadku osób mojego pokroju, czyli linux'iarzy, którzy o backup swoich danych chcą zatroszczyć się tylko i wyłącznie we własnym zakresie, zaprzęgając do pracy choćby Syncthing.

Raczej już nikogo nie dziwią różne moduły elektroniczne implementowane w smartfonach pokroju żyroskopu, akcelerometru, magnetometru czy też i innych czujników realizujących pewne określone funkcje. Te wszystkie rzeczy potocznie zwykło nazywać się sensorami i na dobrą sprawę zdążyły się one zadomowić na dobre w tych naszych telefonach i to do tego stopnia, że nawet sobie nie zdajemy sprawy, że w ogóle one istnieją i non stop działają w tle. Przekopując ostatnio ustawienia Androida, natknąłem się w opcjach deweloperskich na dość enigmatycznie brzmiącą opcję Sensors Off , która była ukryta pod Quick settings developer tiles . Zaznaczenie tej opcji sprawiło, że do dyspozycji użytkownika został oddany dodatkowy kafelek (dostępny z poziomu górnej belki), którego zadaniem jest sterowanie dostępem aplikacji do sensorów smartfona (nie tylko tych wymienionych wyżej ale też do kamery mikrofonu, czy nawet GPS). Postanowiłem się trochę pobawić tym mechanizmem i zobaczyć czy można z niego zrobić jakieś użyteczne narzędzie w kontekście ochrony prywatności.

Wiele osób nie pozostawia suchej nitki na mechanizmie geolokalizacji zaszytym w smartfonach z Androidem na pokładzie. No i faktycznie w sporej części przypadków zastrzeżenia jakie są kierowane pod adresem lokalizacji/GPS w kwestii permanentnego śledzenia nas przez Google nie są przesadzone. Niektórzy spierają się, że wystarczy włączyć tryb samolotowy (Airplane Mode) w telefonie i nasza pozycja przestaje być rejestrowana w czasie rzeczywistym ale nie jest to prawdą. Jakiś czas temu świat obiegła informacja, że Android rejestruje dane geolokalizacji nawet, gdy tryb samolotowy jest włączony, a telefon nie ma włożonych kart SIM i to przy jednoczesnym wyłączeniu WiFi i BT. Jak to do końca jest z tą lokalizacją i czy faktycznie nie da się jej wyłączyć w Androidzie? A może powinniśmy pójść w drugą stronę i zamiast starać się wyłączać lokalizację, to spróbować oszukać system przez jej pozorowanie? Taki zabieg jest możliwy ale wymagana jest zewnętrzna aplikacja do pozorowania lokalizacji, np. Fake Traveler, którą trzeba określić w ustawieniach deweloperskich Androida. Czy ten zabieg wpłynie pozytywnie na lokalizację w kontekście naszej prywatności? Czy może lepiej jest jednak zostawić telefon w domu i pójść na niejawne spotkanie bez tego urządzenia?

Czy przytrafiła może wam się taka sytuacja, w której to ktoś dzwonił do was z niewiadomego numeru i przy tym nie był to nikt, kto by zasługiwał na jakąś większą uwagę z waszej strony? Zwykle, gdy mam do czynienia z kimś takim, to nawet nie odbieram telefonu. Niemniej jednak, najwyraźniej jeden z moich numerów ostatnio stał się celem ataku jakiegoś spamera z bliżej nieokreślonego call center i ten czteroliterowy osobnik wydzwania do mnie od kilku dni średnio co 20 minut i to z wielu różnych numerów. Do tej pory spamerzy w zasadzie omijali mnie szerokim łukiem ale zachowanie tej dość nieuprzejmej osoby sprawiło, że postanowiłem opracować jakieś rozwiązanie na wypadek, gdyby takich osobników z gatunku "brakującego ogniwa ewolucji Homo sapiens" było więcej. Po chwili wertowania netu udało mi się znaleźć appkę, co się zwie Yet Another Call Blocker (YACB), która w zasadzie jest tym, czego standardowo brakuje w każdym smartfonie z Androidem na pokładzie, tj. dość zaawansowanego filtra rozmów przychodzących realizowanych w przestarzałej już technologi GSM, czyli w zwykłych rozmowach telefonicznych na komórkę. Jako, że ten YACB jest bardzo ciekawym kawałkiem oprogramowania i do tego w pełni OpenSource (dostępnym w repozytorium F-Droid), to postanowiłem napisać o nim kilka słów, bo jest to wręcz nieocenione narzędzie w walce z wszelkim syfem pokroju różnych spamerów z call center.

Odblokowanie bootloader'a w smartfonie Xiaomi Redmi 9 (Galahad/Lancelot) mamy już z głowy. Podobnie sprawa wygląda z wgrywaniem na partycję recovery obrazu TWRP i uzyskiwaniem praw administratora systemu root za sprawą Magisk'a. Te dwa kluczowe procesy otworzyły nam drogę do nieco bardziej zaawansowanych prac jeśli chodzi o konfigurację samego urządzenia. W tym artykule nie będziemy się jeszcze bawić we wgrywanie alternatywnych ROM'ów na bazie AOSP/LineageOS ale za to zainteresujemy się nieco bardziej procesem ładowania samej baterii w takim telefonie. Chodzi generalnie o fakt przedłużenia żywotności baterii smartfona za sprawą limitowania maksymalnej wartości, do jakiej można taką baterię podładować podłączając telefon czy to do portu USB komputera, czy też do pełnowymiarowej ładowarki. Taki stopień konfiguracji można osiągnąć zaprzęgając do pracy zaawansowany kontroler ładowania (Advanced Charging Controller, ACC), który manipuluje niskopoziomowymi ustawieniami kernela linux. W standardowym Androidzie tego typu funkcjonalności nie uświadczymy, przez co bateria zużywa się parokrotnie szybciej niż powinna, co przekłada się na wymianę urządzenia na nowe po niecałym roku czy dwóch jego użytkowania. Jeśli nie uśmiecha nam się wydawać hajsu co roku na nowy telefon tylko dlatego, że nie można w nim wymienić baterii, to powinniśmy rozważyć rozwiązanie jakie nam daje ACC.

Parę dni temu udało mi się odblokować bootloader w moim smartfonie Xiaomi Redmi 9 (galahad/lancelot). Nie licząc błędnego URI przy logowaniu na konto Mi wewnątrz appki XiaoMiTool, nie było zbytnio problemów z tym procesem. Takie odblokowanie bootloader'a w telefonie w zasadzie nic nam samo z siebie nie daje, no może poza ściągnięciem z niego zabezpieczeń, co ułatwia dostanie się syfu na Androida, no i też ułatwia złodziejom robotę, bo gdy takie odblokowane urządzenie wpadnie w ich łapki, to mamy praktycznie pozamiatane. Niemniej jednak, odblokowany bootloader daje nam możliwość wgrania custom recovery, np. TWRP, co z kolei otwiera nam drogę do uzyskania praw administratora systemu root, np. za sprawą zainstalowania Magisk'a. Mając dostęp do root, będziemy mogli takim urządzeniem dowolnie zarządzać. Naturalnie, TWRP daje nam też możliwość wgrania alternatywnych ROM'ów na bazie AOSP/LineageOS ale w tym artykule skupimy się jedynie na wrzuceniu TWRP recovery na tego Xiaomi Redmi 9 i ukorzenimy jego Androida przy pomocy wspomnianej już aplikacji Magisk.

Jakiś czas temu wpadł w moje łapki smartfon Xiaomi Redmi 9 (galahad albo lancelot, bo w różnych częściach systemu jest to inaczej określone), który miał preinstalowanego Androida 10 oraz MIUI 11. Przez parę miesięcy używania telefonu, dostał on dwa albo trzy większe update całego ROM'u, wliczając w to aktualizację MIUI do 12.0.1 ze stanem zabezpieczeń na dzień 2021-01-05. Zatem ostatnia aktualizacja zabezpieczeń tego telefonu miała miejsce zaraz na początku Stycznia. Od tego czasu cisza. Niby w przypadku tego modelu telefonu aktualizacje miały być wydawane co trzy miesiące do roku 2023 ale najwyraźniej coś jest nie tak i urządzenie od ponad pół roku nie dostało żadnych aktualizacji. Niby pod tym linkiem można wyczytać informację, że planowana jest aktualizacja do Androida 11 ale prawdę mówiąc jestem nieco zawiedziony opieszałością Xiaomi. Tak się złożyło, że przez przypadek trafiłem w to miejsce na forum XDA, gdzie z kolei znalazłem m.in. ten wątek. Zatem alternatywne ROM'y na mój smartfon istnieją i tego faktu nie byłem świadomy, bo w zeszłym roku jeszcze nic nie szło znaleźć. Postanowiłem zatem odblokować bootloader w swoim Xiaomi Redmi 9 i spróbować wgrać na niego TWRP i jeden (a może nawet kilka) przykładowy ROM na bazie AOSP/LineageOS. Proces odblokowania bootloader'a w urządzeniach Xiaomi nie wymaga zbytnio wysiłku i da się go przeprowadzić w całości pod linux korzystając czy to z XiaoMiTool, czy też przy pomocy maszyn wirtualnych na bazie QEMU/KVM. Ten proces nie do końca jest dla każdego taki oczywisty, dlatego postanowiłem go dokładnie opisać.

Użytkownicy Androida do przeglądania serwisu YouTube używają z reguły tej dedykowanej aplikacji od Google. Problem z tą appką jest taki, że serwuje ona całą masę reklam, których to nie można wykroić stosując popularne rozwiązania na bazie Blokada czy AdAway. Niektórzy starają się korzystać z innych aplikacji pokroju NewPipe czy SkyTube ale one mają swoje ograniczenia, np. nie można pisać komentarzy czy też nie działają powiadomienia push. Kiedyś by rozwiązać ten problem reklam w appce YouTube korzystałem z Magisk'a i jego modułu YouTube Vanced ale to rozwiązanie od jakiegoś czasu nie jest już wspierane, choć w dalszym ciągu można z niego korzystać. Jako, że od paru miechów nie zaglądałem na stronę YouTube Vanced, to postanowiłem sprawdzić czy coś w tej kwestii się zmieniło. Wygląda na to, że jednak coś drgnęło, bo teraz dostępny jest Vanced Manager, który to jest w stanie tak skonfigurować nasz telefon, by aplikacja YT Vanced działała bez problemu nawet na nieukorzenionym Androidzie (nie trzeba mieć root'a). Możemy zatem zachować całą funkcjonalność serwisu YouTube pozbywając się przy tym reklam oraz segmentów sponsorowanych, no i też nie musimy nic kombinować z telefonem, tj. odblokowywać bootloader'a czy wgrywać TWRP. Problematyczne może być jednak zainstalowanie YouTube Vanced, bo czasami powiadomienia (notyfikacje push) mogą nam nie działać poprawnie. Właśnie dlatego postanowiłem napisać parę słów na temat instalacji tej aplikacji z wykorzystaniem Vanced Manager w Androidach bez root, by uniknąć tego jak i innych problemów.

Zaszyfrowane systemy (desktopy/laptopy) mają jeden poważny problem, gdy chodzi o zapewnianie bezpieczeństwa chronionym plikom przechowywanym na dyskach twardych. Gdy siedzimy obok naszej maszyny, możemy czuć się bezpiecznie, bo przecież nikt nie może się włamać do jej systemu bez naszej wiedzy. Nawet jeśli ktoś będzie próbował się dostać do naszego PC, to istnieje spora szansa, że takie działanie zostałoby natychmiast przez nas wykryte, przez co moglibyśmy w odpowiedni sposób zareagować na zaistniałe zagrożenie. Co jednak w przypadku, gdy zostawiamy przykładowo naszego laptopa samego? Nawet jeśli zablokujemy mu ekran, wyłączymy go albo zahibernujemy, to ta maszyna wciąż nie jest odpowiednio zabezpieczona, by uniemożliwić osobom postronnym dostęp do naszych wrażliwych danych. Problem leży w fizycznym dostępie do sprzętu, który ludzie mogą uzyskać, gdy nas nie ma w pobliżu naszego komputera. W taki sposób osoby trzecie mogą wykorzystać fakt, że tracimy maszynę z oczu i być w stanie zastawić na nas różne pułapki. By uniknąć zagrożenia związanego z zostawieniem laptopa/desktopa bez nadzoru, nie możemy w zasadzie pozostawiać tego urządzenia samego, co jest zadaniem praktycznie nie do wykonania. Komputery stacjonarne czy nawet laptopy nie są urządzeniami o małych gabarytach i zwykle nie możemy ich wszędzie zabrać ze sobą, w przeciwieństwie do smartfonów. Postanowiłem zatem tak skonfigurować swojego linux'a, by jego zaszyfrowany dysk (LUKS + LVM) można było odszyfrować jedynie przy pomocy mojego telefonu z Androidem, z którym w zasadzie się nie rozstaję.

Przeglądając ostatnio listę sprzętów podłączonych do mojego routera WiFi, zauważyłem, że niektóre pozycje na niej w polu z hostname mają coś na wzór android-4c52c33baae0b4fa . Pierwsza część nazwy tego hosta wskazuje na system operacyjny, a drugi kawałek to unikalny numerek ID. Nie jestem zbytnio fanem rozgłaszania takich informacji publicznie, bo mogą one ułatwić ewentualne ataki, oraz też identyfikują jednoznacznie dane urządzenie (osobną kwestią jest adres MAC karty sieciowej). Ponadto, mając w sieci wiele mobilnych urządzeń, ciężko jest czasem połapać się który telefon ma przypisany konkretny adres IP (bez patrzenia w ustawienia telefonu). Z reguły na linux'owym desktopie czy laptopie zmiana hostname jest stosunkowo łatwym zadaniem ale w przypadku smartfona z Androidem ten zabieg okazał się niezmiernie trudnym procesem. Jak zatem zmienić hostname telefonu, by można było mu przypisać jakaś w miarę ludzką nazwę?