Parę miesięcy temu natrafiłem na taki oto artykuł na blogu Cloudflare, który poświęcony jest poprawie prywatności wykonywanych przez klientów zapytań DNS za sprawą wykorzystania mechanizmu zwanego Oblivious DoH (ODoH). Oczywiście postanowiłem już wtedy zbadać czym ten ODoH jest ale standardowe narzędzia dostępne w linux'ie (Debian/Ubuntu) jeszcze (przynajmniej wtedy) nie dojrzały do obsługi ODoH. Obecnie już jest trochę lepiej ale Oblivious DoH wciąż jest w fazie eksperymentów (RFC9230). Póki co, jedynym znanym mi narzędziem, które posiada wsparcie dla ODoH jest dnscrypt-proxy, którego instalację i konfigurację do współpracy z dnsmasq już jakiś czas temu opisywałem. Mając wsparcie dla ODoH w dnscrypt-proxy możemy pokusić się o wdrożenie Oblivious DoH w swoim systemie i sprawdzić czy faktycznie taki zabieg przyczyni się do poprawy prywatności wykonywanych przez nas zapytań DNS i właśnie temu zagadnieniu będzie poświęcony niniejszy wpis.

Parę dni temu na mój telefon Xiaomi Redmi 9 (lancelot/galahad/shiva/lava) została wypuszczona aktualizacja ROM'u crDroid, który bazuje na AOSP/LineageOS. Ten update nie tylko miał uwzględnione najnowsze poprawki bezpieczeństwa ale również podbijał wersję Androida z 11 na 12. Problem w tym, że TWRP/SHRP recovery ma problemy z obsługą sposobu szyfrowania partycji /data/ , który najwyraźniej uległ przeobrażeniu w Androidzie 12. Efektem braku wsparcia dla szyfrowania w TWRP/SHRP jest naturalnie brak możliwości wgrywania danych na partycję /data/ . Niestety niesie to za sobą przykre konsekwencje w postaci uniemożliwienia użytkownikowi przeprowadzenia procesu patch'owania obrazu partycji /boot/ z poziomu trybu recovery, czego efektem jest brak możliwości zainstalowania Magisk'a w systemie smartfona. Bez Magisk'a nie damy rady ukorzenić systemu, tj. uzyskać w nim praw administratora root. Na szczęście nie wszystko stracone. Magisk'a można zainstalować w telefonie ręcznie przy pomocy ADB oraz trybu bootloader'a (fastboot) eliminując tym samym potrzebę przełączenia się w tryb recovery. Niniejszy artykuł ma na celu pokazanie jak zainstalować Magisk'a bez odwoływania się do trybu TWRP/SHRP recovery.

Gdy zapytamy użytkowników smartfonów z Androidem o to, czy taki sprzęt jest w stanie pracować z pominięciem układu baterii, zapewne wiele z tych osób odpowiedziałoby, że nie ma takiej opcji, bo przecież w tych telefonach od lat baterii się już nie da wyciągnąć. Nawet w tych starszych modelach, po wyjęciu baterii i podłączeniu ładowarki, system w takim urządzeniu nie chciał się uruchomić. Okazuje się jednak, że nie trzeba wyjmować akumulatora ze smartfona, by to urządzenie było w stanie działać z pominięciem układu baterii, tj. w tzw. trybie bezczynności baterii (battery IDLE mode), coś na wzór rozwiązania stosowanego od dekad w laptopach. Niemniej jednak, takiej funkcjonalności zwykle nie uświadczymy w stock'owych Androidach. Możemy się jednak o nią postarać ale do tego celu niezbędne będzie nam uzyskanie praw administratora systemu root, choć lepiej wgrać sobie na smartfon ROM na bazie AOSP/LineageOS. Bez ukorzenionego Androida nie mamy nawet co podchodzić do implementacji tego mechanizmu. Dodatkowo będzie nam potrzebny zaawansowany kontroler ładowania baterii ACC (w postaci modułu do Magisk'a) i opcjonalnie też graficzna nakładka ACCA (do pobrania z F-Droid). W poniższym artykule postaramy się odpowiedzieć na pytanie czy takie rozwiązanie na bazie IDLE mode w przypadku baterii w smartfonach z Androidem ma w ogóle sens i czy może nam się ewentualnie do czegoś przydać.

Jakiś już czas temu opisywałem temat konfiguracji progów ładowania baterii w laptopie Lenovo ThinkPad T430, tak by przedłużyć parokrotnie jej żywotność. Niemniej jednak, ustawienie na dłuższy czas progów 30-40% nie pozostaje bez wpływu na pracę maszyny. Może i same baterie litowo-jonowe nie posiadają efektu pamięci ale elektronika, która tymi bateriami zarządza, już tę pamięć może posiadać. Chodzi generalnie o to, że brak pełnych cyklów baterii (rozładowanie do 0% i ładowanie do 100%) może powodować różne błędy w ocenie ile faktycznie tego ładunku w takim akumulatorze pozostało. Efektem tych błędów są wskazania sugerujące, że nasz laptop może jeszcze popracować, np. 20-30 minut dłużej, gdy stan faktyczny na to nie pozwala, co skończyć może się utratą niezapisanych danych w skutek nagłego odcięcia zasilania. Dlatego też jeśli wykorzystujemy jedynie pewien zakres pojemności baterii w laptopie, to co pewien czas (co 30-50 takich niepełnych cykli albo raz na 2 miesiące) przydałoby się przeprowadzić w laptopie proces rekalibracji baterii (a raczej rekalibrację jej kontrolera/elektroniki), tak by ewentualne straty pojemności zostały uwzględnione w szacunkach systemu. Zabieg rekalibracji baterii można bez większego problemu przeprowadzić z poziomu dowolnej dystrybucji linux'a, np. Debian/Ubuntu, i tym zagadnieniem się zajmiemy w niniejszym artykule.

Pisząc ostatnio artykuł o tym jak uchronić nasz prywatny punkt dostępu do sieci WiFi przed zmapowaniem i umieszczeniem jego fizycznej lokalizacji w serwisach pokroju Wigle.net czy też w usługach Google/Mozilla, poruszony został temat ewentualnego usuwania wpisów z takich baz danych AP za sprawą dopisywania do nazwy sieci (ESSID) sufiksu _nomap . Nie wszystkie organizacje/firmy respektują naszą prywatność i raczej też nie będą tej końcówki w nazwie sieci honorować. Jako, że jednym z dwóch parametrów, na podstawie których takie mapowanie punktów dostępowych się odbywa, jest adres MAC interfejsu bezprzewodowego danego AP (BSSID), to możemy od czasu do czasu pokusić się o zmianę tego adresu. Jest to mniej więcej to samo rozwiązanie, co zastosowane przy klonowaniu adresu MAC dla portu WAN routera, które z reguły użytkownicy wykorzystują do obchodzenia zabezpieczeń tych bardziej wrednych ISP. Jako, że temat zmiany BSSID trochę się różni od zmiany adresu MAC dla portu WAN, to w niniejszym artykule postanowiłem opisać jak w routerze z wgranym firmware OpenWRT podejść do tego zadania.

Parę dni temu napisał do mnie megabajt z forum DUG z wiadomością, że nazwa mojego WiFi figuruje w bazie danych serwisu Wigle.net oraz, że lepiej nie zdradzać nazw swoich WiFi osobom trzecim, bo ktoś w oparciu o te dane może poznać nasze fizyczne położenie. Jak najbardziej istnieje taka możliwość, a sam serwis Wigle.net nie jest jedynym, który zbiera informacje o położeniach geograficznych punktów dostępowych WiFi, bo od lat robi to też Google i Mozilla. Niemniej jednak, podchodziłbym z pewną dozą ostrożności do danych zgromadzonych w serwisie Wigle.net (i tych pozostałych dwóch też), bo nie zawsze muszą one być akuratne. W zasadzie to nie zdziwiłem się zbytnio, że nazwa mojej sieci WiFi figuruje w bazie danych Wigle.net, bo sam ją tam umieściłem świadomie jakiś czas temu w ramach testów wykorzystując do tego celu aplikację WiGLE WiFi Wardriving, którą można wgrać przez F-Droid na każdy telefon z Androidem. Jako, że nadarzyła się okazja, to postanowiłem napisać parę słów na temat unikania bycia zmapowanym, tak by jakiś nieznany nam bliżej osobnik przez przypadek nie wrzucił lokalizacji naszych domowych/firmowych AP do bazy danych Google/Mozilla czy też wspomnianego wyżej serwisu Wigle.net, o ile oczywiście sobie tego nie życzymy.

Właściciele smartfonów mają zwykle podpisane umowy ze swoimi operatorami GSM na świadczenie usług telefonicznych. Pakiety rozmów oferowane przez tych operatorów już od dłuższego czasu są nielimitowane, co z kolei zachęca abonentów do głosowego komunikowania się przy pomocy tych małych lecz przy tym bardzo zaawansowanych technologicznie komputerów. Nie ma obecnie chyba sprawy, której nie można załatwić telefonicznie, a że coraz dłużej wisimy na słuchawce, to też sporo informacji z takich rozmów nam bezpowrotnie ucieka, np. imię i nazwisko osoby, z którą rozmawialiśmy, nie wspominając o całej masie innych rzeczy, które mogą paść podczas choćby negocjowania/przedłużania jakiegoś kontraktu. Gdy w późniejszym czasie zorientujemy się, że coś jest nie tak, to możemy mieć poważny problem z udowodnieniem swoich racji, np. że zostaliśmy celowo wprowadzeni w błąd. Gdybyśmy dysponowali nagraniem z takiej rozmowy, to bez problemu można by się do niego odnieść i nikt by nie miał wątpliwości po czyjej stronie byłaby racja. Niemniej jednak, smartfony z Androidem mają ogromny problem z nagrywaniem dźwięku audio podczas tego typu konwersacji, czego efektem jest brak możliwości niezależnego rejestrowania rozmów telefonicznych. Jeśli jednak posiadamy ukorzenionego Androida (dostęp do praw administratora root), to możemy te obostrzenia obejść zaprzęgając do pracy aplikację Call Recorder.

Od już dłuższego czasu (będzie parę lat) korzystam z internetu LTE zamiast tradycyjnego połączenia przewodowego. Głównie ze względu na fakt, że w mojej okolicy nie ma praktycznie żadnych szanujących się ISP, z którymi warto by wejść w interakcję i podpisać z nimi jakąś sensową umowę. Poza tym, dla osób mojego pokroju, które cenią sobie mobilność, internet stacjonarny i tak jest mało praktyczny. Dlatego w moim domowym routerze mam wgrany firmware OpenWRT umożliwiający zainstalowanie na tym urządzeniu odpowiedniego oprogramowania obsługującego modemy LTE podłączane przez port USB. Połączenie sieciowe ze światem zwykle działa prawidłowo ale z jakiegoś powodu jest ono zrywane. Zwykle taka sytuacja ma miejsce w środku nocy (czasami parokrotnie), zwłaszcza gdy przekroczę limit danych i do końca okresu rozliczeniowego muszę przemęczyć się z lejkiem 1 mbit/s. Gdy ten lejek jest aplikowany, to zwykle odpalam sobie torrent'a, tak by pobrać najnowsze obrazy ISO tej czy innej dystrybucji linux'a. Niemniej jednak, jak mi net rozłączą, to nie załączy się on ponownie sam z siebie. Modem Huawei E3372s-153 w wersji NON-HiLink zdaje się pracować poprawnie, bo świeci się na nim dioda sugerująca, że połączenie z internetem jest nawiązane. Dlatego też postanowiłem w końcu ten problem rozwiązać raz na zawsze i mieć przy tym nieco spokojniejszy sen.

W poprzednim artykule, który traktował o odszyfrowaniu kontenera LUKS przez SSH z poziomu initramfs/initrd na Raspberry Pi, została poruszona kwestia adresacji IP, która w opisanym tam rozwiązaniu miała pewne ograniczenia. Chodziło o to, że połączenie SSH do RPI mogło być realizowane jedynie przez przewodowy interfejs sieciowy eth0 . Trzeba było zatem się zastanowić nad rozwiązaniem, które umożliwiłoby korzystanie również z bezprzewodowego interfejsu WiFi, tj. wlan0 . Celem niniejszego wpisu jest pokazanie w jaki sposób można dorobić wsparcie dla połączeń WiFi w naszej malinie, tak by szło odszyfrować kontener LUKS przez SSH, w sytuacji gdy z jakiegoś powodu nie chcemy lub też nie możemy korzystać z przewodowego interfejsu sieciowego tego minikomputera z zainstalowanym system RasPiOS/Raspbian.

Od paru dni bawię się swoim Raspberry Pi w kontekście zaszyfrowania jego systemu RasPiOS/Raspbian. O ile samo zaszyfrowanie tego minikomputera przy pomocy mechanizmu LUKS nie było jakoś specjalnie trudne, to trzeba było pomyśleć nad rozwiązaniami mającymi ułatwić otworzenie takiego zaszyfrowanego kontenera przy starcie systemu. Póki co udało się wypracować w miarę zadowalające rozwiązanie wykorzystujące dedykowane urządzenia USB w roli klucza, bez którego system się nie uruchomi. Są jednak i inne rozwiązania, które mogą nam pomóc odszyfrować system RPI bez potrzeby fatygowania się do pomieszczenia i wtykania w jej port USB jakiegoś pendrive. Mowa o zaprzęgnięciu usługi SSH, która by została uruchomiona w fazie initramfs/initrd, chwilę przed wpisaniem hasła do kontenera LUKS. Takie rozwiązanie wymaga jednak zainstalowania innego serwera SSH, tj. Dropbear, pogodzenia go z serwerem OpenSSH oraz też trzeba odpowiednio przygotować sam obraz initramfs/initrd. Po pomyślnym skonfigurowaniu systemu, będziemy się logować do Raspberry Pi przez SSH i wpisywać hasło do kontenera LUKS, a jeśli to hasło będzie prawidłowe, to system zostanie odszyfrowany i uruchomiony.