Jeśli mamy smartfon z Androidem na pokładzie, to zapewne każdy za nas zadawał sobie pytanie, czy da radę z takiego telefonu pozbyć się szeregu aplikacji, z których praktycznie nie korzystamy na co dzień. Część z tych programów można wyłączyć w ustawieniach systemowych ale są też i takie aplikacje (głównie producenta telefonu, czy też operatora GSM albo te od Google), których standardowo nie da się wyłączyć z poziomu działającego Androida. Nawet jeśli wymusimy zatrzymanie stosownych usług, to za chwilę (lub po restarcie urządzenia) one i tak nam automatycznie wystartują. Im więcej zbędnych aplikacji działa w tle, tym częstsze wybudzanie telefonu, a więc i szybsze wyczerpywanie się baterii. Dlatego też jeśli nie korzystamy z wbudowanego w ROM bloatware, to przydałoby się go usunąć lub chociaż trwale wyłączyć. Co ciekawe, tego typu proces nie musi odbywać się za sprawą administratora systemu (root), bo w zasadzie każda aplikacja w Androidzie może zostać zainstalowana/odinstalowana dla konkretnego użytkownika w systemie. Nie potrzebujemy mieć zatem nawet ukorzenionego Androida, by pozbyć się tego całego syfu z systemu, który naszemu urządzeniu spędza sen z powiek i nie daje mu się przy tym porządnie wyspać.

Bawiąc się ostatnio kernelem linux na dystrybucji Debian i opcjami mającymi poprawić jego bezpieczeństwo, włączyłem sobie mechanizm podpisywania modułów. W ten sposób żaden zewnętrzny moduł nie zostanie załadowany przez jądro operacyjne, no chyba, że taki moduł będzie podpisany przez ten sam klucz co i kernel. Zdziwiłem się odrobinę, gdy moim oczom pokazał się hash md4 w wyjściu polecenia modinfo . Jak się okazało później, to niezbyt dokładne zinterpretowanie wiadomości PKCS#7 przez kmod było (i nadal jest) wynikiem błędu obecnego w tym pakiecie od już paru lat. W efekcie modinfo nie jest w stanie zweryfikować tej sygnatury, a w moim umyśle zaistniało pytanie: czy istnieje w ogóle możliwość manualnego sprawdzenia czy ta sygnatura jest w porządku? Kernel co prawda ten cały zabieg przeprowadza automatycznie ale przydałoby się ręcznie zweryfikować poprawność sygnatury modułu i przy okazji obadać sobie co tak naprawdę się dzieje podczas tego procesu.

Domyślnie każdy proces uruchomiony na linux (w tym przypadku Debian) dziedziczy swoją przestrzeń nazw sieciowych (network namespaces) od procesu nadrzędnego, standardowo od procesu init (tego z pid 1). W takim przypadku, wszystkie procesy współdzielą tę samą przestrzeń nazw sieciowych, przez co mają dostęp do tych samych interfejsów sieciowych, tych samych tras routingu, a reguły firewall'a czy ustawienia serwerów DNS w jednakowym stopniu dotyczą wszystkich procesów i zmieniając sieciową konfigurację systemu robimy to globalnie dla wszystkich tych procesów jednocześnie. Czasami tego typu mechanika działania sieci nie jest zbyt pożądana z punktu widzenia bezpieczeństwa lub też prywatności użytkownika. Przykładem mogą być przeglądarki internetowe, np. Firefox, Opera czy Google Chrome/Chromium, które mogą zdradzić nasz lokalny adres IP (w przypadku stosowania NAT). Jako, że też zostawiamy wszędzie nasz namiar w postaci zewnętrznego adresu IP, to oba te adresy mogą nas bez większego problemu zidentyfikować w internecie. Można jednak postarać się, by ten adres lokalny, który zwróci przeglądarka internetowa, różnił się od tego, który przydziela nam nasz operator ISP.

Do tej pory zbytnio nie interesowałem się zagadnieniami dotyczącymi mechanizmu SafetyNet, który ma na celu utrudnić nieco życie użytkownikom smartfonów z Androidem lubiącym posiadać pełny dostęp do systemu swoich urządzeń za sprawą uzyskania praw administratora (root). To co się zmieniło na przestrzeni ostatnich paru miesięcy, to fakt, że coraz więcej aplikacji polega na tym całym SafetyNet, a przynajmniej ja zaczynam coraz częściej korzystać z tego typu oprogramowania. Jeśli jednak nasze urządzenie nie przejdzie testów SafetyNet, to funkcjonalność aplikacji polegających na tym mechanizmie może zostać dość znacznie ograniczona. Przykładem może być appka Revolut i jej odblokowanie za pomocą czytnika linii papilarnych. Bez SafetyNet trzeba podawać PIN za każdym razem, gdy się do tej aplikacji będziemy próbowali zalogować. Zwykle do obejścia SafetyNet używa się Magisk'a ale w pewnych sytuacjach, nawet i on nie jest w stanie z tym zdaniem sobie poradzić, przynajmniej nie bez dodatkowej konfiguracji. Jeśli na co dzień korzystamy z opcji debugowania ADB/USB, to może nas spotkać nie lada dylemat -- ADB/USB debug vs. SafetyNet. Okazuje się, że można pogodzić te dwie rzeczy.

Budując kernel linux'a trzeba zastanowić się nad kwestią modułów, które nie są wbudowane bezpośrednio w samo jądro operacyjne. Nie chodzi tutaj bezpośrednio o funkcjonalność kernela, którą można zbudować jako moduł w procesie jego kompilacji ale raczej o wszystkie zewnętrzne moduły, które przez zespół kernela są traktowane jako out-of-tree . By poprawić nieco bezpieczeństwo związane z takimi modułami, można wdrożyć podpisy cyfrowe, które takie moduły muszą okazać podczas próby załadowania ich w systemie. Gdy moduł nie został podpisany, to kernel go nie załaduje zwracając przy tym błąd modprobe: ERROR: could not insert 'module': Required key not available . W ten sposób można ochronić się przed częścią ataków, w których moduły pochodzenia trzeciego mogą zostać załadowane i poczynić nam ogromne spustoszenie w systemie. Problem w tym, że w dystrybucji Debian wykorzystywany jest mechanizm DKMS (Dynamic Kernel Module Support). Może i mamy dzięki niemu możliwość instalacji w systemie całej masy dodatkowych modułów ale ich również nie będzie można załadować, bo nie zostały podpisane kluczem, którego certyfikat został zaszyty w kernelu. Można jednak zmusić mechanizm DKMS, by wskazane przez nas moduły podpisywał automatycznie przy ich instalacji i aktualizacji.

Każda maszyna działająca pod kontrolą dystrybucji linux ma na swoim pokładzie kernel, czyli jądro operacyjne, które zarządza praktycznie każdym aspektem pracy takiego komputera. W dystrybucji Debian, kernel jest dostarczany w pakietach mających nazwy zaczynające się od linux-image-*. Te pakiety są budowane przez odpowiednie osoby z zespołu Debiana i udostępniane do łatwej instalacji użytkownikowi końcowemu. Niemniej jednak, taki kernel ma za zadanie działać na jak największej ilości komputerów, a przez to posiada całą masę modułów, które na naszej maszynie nigdy nie będą wykorzystane. Ten fakt nie wpływa w jakimś ogromnym stopniu na pracę maszyny, ale gdy później zachodzi potrzeba skonfigurowania kernela w nieco inny sposób, np. włączenie jednej czy dwóch opcji czy też nałożenie patch'a, który nie został zaaplikowany przez dev'ów Debiana, to trzeba taki kernel na nowo skompilować już samodzielnie, a to zajmie nam bardzo dużo czasu. Zamiast tego można pokusić się o przygotowanie kernela pod konkretny hardware wyłączając przy tym całą masę zbędnych rzeczy i ograniczając przy tym czas jaki jest potrzebny na zbudowanie całego jądra operacyjnego. Czy istnieje jakiś prosty sposób, by taki kernel zbudować sobie samemu mając przy tym minimalną wiedzę co do opcji kernela, które mogą nas przysporzyć o ból... głowy? Okazuje się, że tak i w tym artykule prześledzimy sobie cały ten proces.

Parę dni temu dowiedziałem się o projekcie /e/. Z racji, że ten ROM jest dostępny na mój smartfon LG G4C (jeszcze nieoficjalnie), to postanowiłem go sobie wgrać i zobaczyć jak się będzie sprawował. Podczas testów nowego oprogramowania spróbowałem zaszyfrować partycję /data/ . Problem w tym, że po automatycznym zresetowaniu się systemu, urządzenie już nie chciało się uruchomić. Przez dłuższy czas widniało logo LG, a po chwili pojawił się czarny ekran z informacją "Kernel Crash" lub niebieski ekran z informacją "Subsystem Crash". Czy telefon w takiej sytuacji nadaje się jedynie do wyrzucenia?

Nie bawiłem się ostatnio Neffos'ami ale w końcu udało mi się doprowadzić szyfrowanie w X1 Max (i pewnie X1 też) do ładu. Dla przypomnienia, to w tych modelach najwyraźniej system zapomniał by pytać użytkownika o hasło podczas konfiguracji, a że partycja z danymi użytkownikami jest zaszyfrowana w standardzie (bez możliwości zmiany), to ustawiane jest domyślne hasło tj. default_password . W ten sposób z technicznego punktu widzenia wilk jest syty i owca cała, no bo użytkownik nie jest dręczony dodatkowym hasłem przy uruchamianiu systemu (obok hasła blokady ekranu), no i dane są zaszyfrowane, no chyba, że ktoś wpisze ten nieszczęsny default_password .

Jeden z moich routerów, a konkretnie był to Archer C7 v2 wymagał, by powrócić jego firmware z LEDE/OpenWRT do tego, który widnieje na oficjalnej stronie TP-Link. Niby ta czynność nie jest zbyt skomplikowana ale jak zwykle coś poszło nie tak. Konkretnie to odłączyłem zasilanie nie w tej listwie co trzeba i w efekcie podczas flash'owania routera nowym firmware, to urządzenie się zwyczajnie wyłączyło. Zawału oczywiście nie dostałem, bo przecież obraz, który był wgrywany na router nie zawierał uboot'a, czyli części z bootloader'em, więc wiedziałem, że wystarczy przez tryb recovery wgrać obraz jeszcze raz i po sprawie. Problem w tylko w tym, że nie znałem w zasadzie ani nazwy pliku obrazu, ani też adresu IP, który jest wymagany dla połączenia w przypadku routera Archer C7 v2. Te dane można naturalnie znaleźć w sieci ale co w przypadku, gdy ubijemy sobie w taki sposób nasz jedyny router, przez co pozbawimy się jednocześnie dostępu do internetu? Czy istnieje jakiś sposób na ustalenie tych danych, inny niż przez konsolę szeregową?

Gdy kupujemy smartfon, to jego producent daje nam na ten sprzęt gwarancję i przez pewien okres czasu możemy nie martwić się o koszty ewentualnej naprawy. Niestety żyjemy w takich czasach, że sprzęt elektroniczny potrafi nam paść sam z siebie i to do tego jeszcze w niewyjaśnionych okolicznościach. Cześć wad jest fabrycznych (zwykle fizycznych) i te z reguły są oczywiste i łatwe do zdiagnozowania przez support producenta sprzętu, który nabyliśmy. Niemniej jednak, czasami wady są natury czysto programowej i tu z kolei ustalenie, gdzie dokładnie leży problem może już sprawiać kłopoty. Dlatego też producenci telefonów zabezpieczają się przed zmianą firmware przez użytkownika. W ten sposób wgrywając, np. TWRP recovery czy przeprowadzając proces root Androida, zwykle pozbawiamy się gwarancji i mamy problem, gdy telefon w późniejszym czasie popsuje się nie z naszej winy. Nawet jeśli wgramy stock'owe oprogramowanie, to i tak producent sprzętu jest w stanie ustalić czy coś w firmware mieszaliśmy. Zastanawialiście się może zatem skąd producent smartfona wie czy firmware takiego urządzenia został w jakiś sposób przez nas zmieniony?