Wyszukaj

Wyświetlanie wyników dla tagów 'morfitronik.pl' .



Więcej opcji wyszukiwania

  • Wyszukaj za pomocą tagów

    Wpisz tagi, oddzielając je przecinkami.
  • Wyszukaj za pomocą nazwy autora

Typ zawartości


Forum

  • Kategoria Główna
    • Regulamin Forum - zasady korzystania
    • Kształt forum - dyskusja, propozycje, opinie.
    • Serwer plików
    • FOTO GALERIA - TP-Link w twojej sieci
    • CONNECTED nr 4/2016 (13) - NOWY NUMER
  • TP-LINK Forum
    • ADSL, DSL, LTE, PLC, USB - jaki model TP-Linka kupić?
    • BAZAR - kupię sprzedam
    • DOMOWE SIECI KOMPUTEROWE
    • PORADNIKI - FAQ - KONFIGURACJA
    • FIRMWARE
    • NOWOŚCI
    • NEFFOS - wsparcie techniczne
    • OPINIE UŻYTKOWNIKÓW / OPINIE EKSPERTÓW
    • POGOTOWIE KONFIGURACYJNE TP-LINK
    • PORADY SERWISOWE
    • ZAUFANY DYSTRYBUTOR - SPRZEDAWCA TP-LINKa
  • TP-Link rozwiązania SOHO - katalog
    • Urządzenia bezprzewodowe - standard AD
    • Urządzenia bezprzewodowe - standard AC
    • Urządzenia bezprzewodowe Dual Band
    • Urządzenia bezprzewodowe - standard N, 300Mb/s
    • Urządzenia bezprzewodowe - standard N, 150Mb/s
    • Urządzenia ADSL
    • Wzmacniacze sygnału
    • Karty bezprzewodowe
    • Routery 3G/4G/LTE
    • Modemy 3G
    • Przełączniki SOHO - niezarządzalne
    • Transmitery sieciowe PLC
    • Kamery IP Cloud
    • Serwery druku
    • Anteny i akcesoria
    • Karty przewodowe
    • Wycofane z produkcji
  • TP-Link rozwiązania SMB - katalog
    • Katalog produktów SMB 2013
    • Katalog produktów SMB 2015
  • TP-Link alternatywne oprogramowanie
    • Kto i gdzie tworzy alternatywne oprogramowanie
    • Aktualny firmware Gargoyle, LEDE, DD-WRT, OpenWRT, Luci,
    • FAQ - alternatywne oprogramowanie
    • Pogotowie konfiguracyjne - alternatywne oprogramowanie
  • Sieci komputerowe, internet
    • FAQ - sieci komputerowe
    • Konfiguracja popularnych urządzeń sieciowych
    • Routery innych producentów
  • Inne dyskusje
    • Hydepark

Grupa podstawowa


AIM


MSN


Strona URL


ICQ


Yahoo


Jabber


Skype


Gadu-Gadu


Lokalizacja:


Zainteresowania


O mnie

Znaleziono 72 wyników

  1. Stosunkowo niedawno do polskiej oferty TP-LINK trafił smartfon Neffos X1. To urządzenie było dostępne już dłuższy czas na rynku (zaprezentowane w Berlinie na targach IFA we wrześniu 2016) ale do Polski trafiło ono z dość mocnym opóźnieniem. Tak czy inaczej, ten telefon można już nabyć w sklepach, przez co wypadałoby rzucić na niego okiem i przyjrzeć się mu nieco bliżej. Dzięki uprzejmości TP-LINK Polska, Neffos X1 trafił do mnie na testy i postanowiłem napisać krótką recenzję tego sprzętu w kontekście pozostałych smartfonów Neffos, którymi miałem okazję się bawić w przeszłości, tj. modelami C5, C5 MAX, Y5 i Y5L. Czy Neffos X1 jest nas w stanie czymś zaskoczyć w stosunku do wcześniejszych modelów tych TP-LINK'owych smartfonów? Zawartość opakowania Neffos X1 Poniżej znajdują się fotki opakowania, w którym trafił do mnie Neffos X1, oraz tego co było w środku: Specyfikacja Neffos X1 Wiemy zatem co TP-LINK wsadził do opakowania z Neffos X1. Przyjrzyjmy się teraz kluczowemu elementowi paczki, czyli samemu smartfonowi. Telefon nie jest w zasadzie duży i ciężki. Jego wymiary oscylują w granicach 142/71/7,95 mm. (dł/sz/gr). Waga zaś zamyka się w 135 gramach. Jako, że jest to smartfon o przekątnej ekranu 5", to wypadało by skontrastować te gabaryty z innymi smartfonami TP-LINK, które mają tę samą przekątną, czyli Neffos Y5 i C5. O ile długość i szerokość tych telefonów jest w zasadzie podobna, o tyle Neffos X1 jest cieńszy prawie o 1 mm. Stało się tak za sprawą zastosowania technologii "in-cell" w wyświetlaczu, co zredukowało ilość warstw, z których wyświetlacz smartfona się składa. Mniej warstw, to cieńszy wyświetlacz, a cieńszy wyświetlacz, to za razem cieńszy i lżejszy smartfon. Metalowa obudowa W przypadku Neffos X1 mamy do czynienia z obudową metalową (aluminium). Tę cechę można zaliczyć jak najbardziej na plus, bo metalowa obudowa poprawia znacznie nie tylko trwałość smartfona ale też i jego wygląd. Niemniej jednak, jeśli się uważniej przyjrzymy, to ta obudowa obok górnej i dolnej krawędzi ma plastikowe elementy. Może i za sprawą tej "nie do końca" metalowej obudowy Neffos X1 prezentuje się całkiem przyzwoicie ale też tego urządzenia nie da się za bardzo trzymać w sposób pewny. Ten metal jest bardzo śliski, a producent nie zadbał o to, by w jakiś sposób zabezpieczyć telefon przed wyślizgnięciem się z dłoni. Nawet ten plastik, który był obecny w poprzednich smartfonach Neffos zapewniał o wiele pewniejszy chwyt. Górna krawędź obudowy skrywa gniazdo słuchawkowe w standardzie minijack (3,5 mm) oraz mikrofon. Na dolnej krawędzi po lewej stronie mamy ulokowany mikrofon do rozmów. W środku mamy port mikro USB, a po prawej zaś jest głośnik multimedialny (mono). Jeśli chodzi zaś o lewą krawędź, to w Neffos X1 nie jest ona już niezagospodarowana. Mamy tutaj w zasadzie dwa elementy, których nie spotkamy w starszych modelach Neffos'ów. Jednym z nich jest przycisk (a właściwie przełącznik) Mute służący do wyciszania dźwięków smartfona. W sumie ciekawa rzecz. Niżej zaś jest wysuwana tacka na karty SIM/mikro SD, którą można wyciągnąć przez wsunięcie igły w dziurkę widoczną obok (igła w zestawie): Na prawej krawędzi zaś mamy standardowo przyciski głośności (VolumeUp/VolumeDown) oraz przycisk zasilania (Power). Przednia część w smartfonie Neffos X1 tuż pod górną krawędzią prezentuje się w zasadzie również standardowo. Mamy tutaj dwa czujniki (światła i zbliżeniowy), głośnik, aparat selfie oraz diodę powiadomień. Natomiast tuż przy dolnej krawędzi mamy trzy przyciski: wstecz, home, oraz lista używanych aplikacji: Wyświetlacz IPS 5.0" Wyświetlacz w Neffos X1 jest zrobiony w technologi IPS. Przekątna tego wyświetlacza to 5 cali, a rozdzielczość to 1280x720 px. Jak łatwo możemy wyliczyć, ilość punktów na cal (PPI) to około 293,7 i jest to akceptowane minimum, które moim zdaniem powinien spełniać dobry smartfon. Obraz jest ostry i bez przekłamań kolorów. Kąty widzenia również są bardzo dobre i pod względem samego wyświetlacza nie mogę złego słowa o Neffos X1 powiedzieć. Wyświetlacz jest chroniony szkłem Corning Gorilla Glass i jak widać na poniższej fotce, samo szkiełko jest zaokrąglone na krawędziach, co wpływa też bardzo pozytywnie na sam wygląd Neffos'a X1. Ta szybka ma mieć warstwę ochronną przed tłuszczem, brudem i innymi takimi zanieczyszczeniami, które mogą zostać naniesione na ekran smartfona przy jego codziennym użytkowaniu. Moim skromnym zdaniem, ta warstwa (jeśli jest) w zasadzie nic nie daje. Praktycznie po paru minutach używania telefonu, na ekranie była już cała masa odcisków. To co mnie jednak interesuje najbardziej pod względem ekranu, to jego responsywność na dotyk. Do tej pory tylko w przypadku Neffos'a Y5L były z tym elementem problemy i ekran działał tam trochę nie tak jak powinien (czasami po przyciśnięciu nie było żadnej reakcji). W pozostałych Neffos'ach ekran reagował przyzwoicie i dość precyzyjnie. Podobnie jest w przypadku Neffos X1, gdzie mizianie ekranu nie sprawia żadnych problemów. Nie bez znaczenia tutaj jest też fakt zastosowania technologii TDDI (Touch and Display Driver Integration), która poprawia reakcję wyświetlacza na dotyk, przez co wyświetlacz reaguje praktycznie natychmiast nawet na najdelikatniejsze muśnięcie powierzchni ekranu smartfona. Technologia TDDI niesie ze sobą także redukcję ilości energii, której wyświetlacz wymaga do pracy. W ten sposób Neffos X1 powinien nieco dłużej wytrzymać przy włączonym ekranie. No i oczywiście TDDI upraszcza produkcję samego wyświetlacza, co przekłada się też na jego niższy koszt. Ilość punktów dotykowych, które wyświetlacz w Neffos X1 jest w stanie rozpoznać w tym samym czasie, to co najmniej 10 (brakło palców do testów) i w zasadzie tylko Neffos Y5 był w stanie również pochwalić się takim wynikiem. Neffos C5 i C5 MAX miały tych punktów 5. Jasność maksymalna wyświetlacza jest bardzo dobra i w zasadzie nigdy nie miałem jej nic do zarzucenia w żadnym z testowanych przeze mnie smartfonów Neffos. Niemniej jednak, w poprzednich modelach, jasność minimalna była moim zdaniem trochę za duża, przez co nie dało się komfortowo pracować na tych urządzeniach w absolutnej ciemności. Ta kwestia minimalnego poziomu jasności została poprawiona w Neffos X1. Ekran w tym telefonie jest wyraźnie ciemniejszy na minimalnych ustawieniach jasności i to urządzenie się nadaje idealnie dla osobników działających w nocy, do których również i ja się zaliczam. Procesor Helio P10 (8 rdzeni) Pracując trochę ze smartfonami wyposażonymi w SoC od producentów Mediatek oraz Qualcomm, mam lekkie porównanie w stosunku do tego, co takie urządzenia są w stanie zaoferować miłośnikom ukorzeniania systemu Android i cieszę się, że TP-LINK postanowił wykorzystać SoC tego pierwszego producenta, jako że układy od Mediatek zapewniają większą odporność na ewentualne programowe uszkodzenie telefonu. W Neffos X1 mamy zatem SoC MT6755, w skład którego wchodzi min. procesor Helio P10 mający 8 rdzeni opartych o 64-bitową architekturę ARM Cortex-A53. Może i mamy w sumie 8 rdzeni ale cztery z nich są taktowane zegarem 1,8 GHz, natomiast pozostałe cztery zegarem 1 GHz. Do tej pory tylko Neffos C5 MAX posiadał 8 rdzeni ale tam wszystkie z nich były taktowane zegarem 1,3 GHz. Które z tych dwóch rozwiązań jest lepsze? Ja bym się skłaniał ku temu, które znalazło zastosowanie w Neffos X1, choć przydałaby się dokładna analiza pracy tych dwóch SoC, by mieć pewność. Proces technologiczny tego SoC'a to 28 nm, czyli dokładnie taki sam jak w przypadku SoC pozostałych Neffos'ów. W skład SoC MT6755 wchodzi również dwurdzeniowy układ graficzny ARM Mali-T860 MP2 taktowany zegarem 550 MHz. Ten układ nieco szybszy niż ten zastosowany w Neffos C5/C5 MAX, gdzie mieliśmy do dyspozycji ARM Mali-T720 MP2 taktowany zegarem 450 MHz. W specyfikacji układu graficznego Neffos'a X1 można wyczytać, że jest on w stanie wyświetlić obraz w 1920x1080 px (FHD) ale prawdopodobnie z racji mniejszego wyświetlacza (5") mamy rozdziałkę 1280x720 px (HD). Układ ARM Mali-T860 MP2 posiada wsparcie dla API OpenGL ES 3.1, OpenCL 1.2 oraz DirectX 11.1 . Pamięć RAM i flash (2G/16G) Neffos X1 w zasadzie ma dwie wersje. Pierwsza z nich jest nieco uboższa, bo posiada jedynie 2 GiB pamięci operacyjnej RAM oraz 16 GiB pamięci flash. Ta nieco bardziej rozbudowana wersja ma 3 GiB pamięci RAM i 32 GiB flash. Do mnie trafiła ta pierwsza wersja. TP-LINK w części w swoich smartfonów Neffos stosował już konfigurację 2/16 GiB i w momencie, gdy te telefony zaczynały trafiać na rynek (Styczeń 2016), to miały one nawet całkiem przyzwoite parametry, przynajmniej jak na niezbyt drogi sprzęt mobilny. Dziś jednak te 2 GiB pamięci RAM to już trochę mało i przydałoby się myśleć nad standardem 3 GiB. Podobnie sprawa wygląda w przypadku pamięci flash, gdzie 16 GiB może jeszcze zadowoli sporo osób ale na pewno nie na długo biorąc pod uwagę to do czego użytkownicy wykorzystują obecnie swoje telefony. Poniżej jest fotka obrazująca wykorzystanie pamięci RAM tuż po uruchomieniu się smartfona: No niestety system w Neffos X1 się rozrósł dość znacznie i te 700 MiB zjada praktycznie od tak. Dlatego te 2 GiB pamięci, to nie jest dużo przy tak żarłocznym systemie. Nie damy rady też w żaden sposób wyłączyć preinstalowanych aplikacji i możemy zapomnieć o odciążeniu w ten sposób systemu smartfona. Jeśli zaś chodzi o podział pamięci flash na partycje, to jest on podobny do tego, który mogliśmy obserwować w przypadku Neffos C5/C5 MAX. Partycja /system/ jest nieco mniejsza (o 0,5 GiB), przez co na dane użytkownika pozostaje nam mniej więcej tyle samo miejsca, tj. około 10 GiB. Biorąc pod uwagę, że w Neffos X1 rozmiar stock'owego ROM'u jest w granicach 3 GiB, to nic więcej nie uda nam się wyskrobać z tego układu partycji. Póki co nie wiem też za bardzo jak rozumieć podpięcie device mapper'a pod partycję /system/ . Być może ta sprawa się wyjaśni przy okazji próby ukorzenienia Androida w tym telefonie. Kamera główna 13 mpix i kamera selfie 5 mpix W Neffos X1 mamy zamontowane dwie kamery. W zasadzie są one ulokowane w standardowych miejscach, tj. jedna na tylnej części obudowy pod górną krawędzią, a druga z przodu tuż nad wyświetlaczem. Poniżej fotka głównej kamery: Ta główna kamera ma 13 mpix i pochodzi od SONY (sensor IMX258 z przysłoną f/2.0). Ma ona również zaimplementowany mechanizm PDAF (Phase Detection Auto Focus), przez co obiekty w ruchu są w zasadzie cały czas ostre (sporo mniej czasu zajmuje kamerze, by te obiekty wyostrzyć). Zdjęcia i materiały video z głównej kamery są przyzwoitej jakości, przynajmniej przy dobrym oświetleniu obiektu. Różnica w tej głównej kamerze w stosunku do poprzednich modelów smartfonów Neffos jest bardzo widoczna w momencie, gdy zmieniamy położenie smartfona i chcemy fotografować inny obiekt. W Neffos X1 możemy to robić praktycznie natychmiast, a w Neffos C5 MAX przykładowo trzeba było chwilę poczekać, aż autofokus złapie ostrość, co zwykle zajmowało 1-2 sekundy. W Neffos X1 to opóźnienie zostało niemalże wyeliminowane całkowicie. Trochę gorzej sprawa ma się, gdy zdjęcia trzeba robić w ciemnych miejscach, gdzie nie dociera już tak dużo światła, ewentualnie też po zmroku. W takich sytuacjach ilość szumu jaki można zaobserwować na zdjęciu jest już dość spora ale i tak Neffos X1 wypada lepiej niż Neffos C5 MAX, który do tej pory miał najlepszą kamerę. Tak czy inaczej przydałoby się popracować nad tym aspektem pracy smartfona. Kamera selfie też została podrasowana, choć w dalszym ciągu ma 5 mpix. To co się rzuca w oczy odnośnie tej kamery, to zwiększona rozdzielczość rejestrowania materiałów video w stosunku do tego co oferowały poprzednie modele Neffos. Dla przypomnienia, nawet Neffos C5 MAX (ten najmocniejszy do tej pory) oferował rejestrowanie obrazu z kamery selfie jedynie w 480p (640x480 px). Neffos X1 jest w stanie swoją kamerą selfie rejestrować obraz maksymalnie w rozdzielczości 1920x1080 px przy 30 FPS i można w zasadzie uznać, że era VGA w kamerach selfie w przypadku Neffos'ów jest już raczej za nami. Obraz i dźwięk z kamer jest zapisywany w kontenerze 3GP. Video jest kodowane przy pomocy H.264, a audio przy pomocy ACC. Poniżej znajdują się parametry obrazu, które można zarejestrować przy pomocy kamer w Neffos X1: Rozdzielczości zdjęć Kamera główna: 3120x4160 px, 3072x3072 px oraz 2304x4096 px Kamera selfie: 2560x1920 px, 1920x1920 px oraz 1440x2560 px Rozdzielczości video (przy 30 FPS) Kamera główna: 1920x1080 px, 1280x720 px oraz 640x480 px Kamera selfie: 1920x1080 px, 1280x720 px oraz 640x480 px Ja w zasadzie nacisk kładę jedynie na jakość głównej kamery, bo kamera selfie mnie zbytnio w ogóle nie interesuje. I o ile jakość fotek czy filmów z głównej kamery (przy dobrym oświetleniu) jest bardziej niż zadowalająca, to szkoda, że jakość audio w tych materiałach video nie jest najlepsza (bitrate 128 kbit/s). Moim zdaniem przydałoby się popracować trochę nad rejestrowaniem dźwięku tak, by dobić to tych 256/320 kbit/s. Dwie diody LED Tuż pod głównym aparatem, Neffos X1 ma umiejscowione dwie diody LED. Jedna z tych diod jest w kolorze białym, a druga w kolorze pomarańczowym. Podczas robienia zdjęć, obie te diody się zapalają i dość przyzwoicie doświetlają obszar, który fotografujemy. Niemniej jednak, diody w smartfonach służą nie tylko jako lampa błyskowa podczas cykania fotek ale też przydają się jako latarka. W przypadku Neffos'a X1 tylko jedna z tych diod się zapala (ta biała), gdy aktywujemy aplikację latarki. Ma to swoje wady i zalety. Jeśli chodzi o wady, to jedna jest oczywista, tj. sporo słabsze oświetlenie niż w przypadku, gdy dwie diody byłyby zapalone w tym samym czasie. Zaletą z kolei jest fakt, że dwukrotnie mniej energii idzie na zasilanie latarki, bo przecie świeci się tylko jedna dioda, przez co nie cierpi aż tak bardzo na tym bateria. Pewnie zdania będą podzielone w sprawie jednodiodowej latarki w przypadku, gdy smartfon dysponuje dwiema diodami. Ja jednak widząc różnice w oświetleniu sceny przez Neffos X1 i C5/C5 MAX (one też mają dwie diody) uważam, że latarka w tych starszych modelach wypada bez porównania lepiej i ja bym jednak skłaniał się ku opcji dwudiodowej latarki. Najlepiej to zawsze dorobić opcję w systemie umożliwiającą użytkownikowi określenie ile diod ma się zapalić i problem się automatycznie rozwiąże sam. Wbudowana bateria 2250 mAh i brak fast charging TP-LINK w modelu Neffos X1 zdecydował się na zastosowanie niewymiennej baterii. Trochę szkoda, choć z takim rozwiązaniem mogliśmy się już spotkać w Neffos C5 MAX ale tamten smartfon można było bez problemu rozkręcić i tę baterię wymontować. W przypadku Neffos X1 takiej opcji zostaliśmy niestety pozbawieni. Ja osobiście byłbym w stanie pójść na kompromis w przypadku wbudowanych baterii ale tylko i wyłącznie, gdy byłyby one nieco większe, tj. ~3000-4000 mAh. Niestety w przypadku smartfona Neffos X1 bateria nie należy do najpojemniejszych. Deklarowana przez TP-LINK pojemność to 2250 mAh, zatem nie jest to dużo. Do zestawu została dołączona ładowarka 5V/1A. Czas ładowania smartfona Neffos X1 od 0-100% wyniesie zatem około dwóch godzin. W ramach testu chciałem sprawdzić czy Neffos X1 jest w stanie wyciągnąć z mojej ładowarki (3,1A) nieco więcej niż z tej co jest dołączona do zestawu. Wygląda na to, że ten smartfon jest w stanie ładować się prądem w granicach 2A. Nie wiem jednak od czego zależy czy tak w istocie będzie, bo w większości przypadków ładowania, Neffos X1 nie chce pobierać więcej niż te 0,95A. Czasami jednak po zresetowaniu telefonu i podłączeniu go pod mocniejszą ładowarkę, można zaobserwować zwiększony pobór energii: Tempo w jakim Neffos X1 się rozładowuje podczas spoczynku jest raczej przeciętne. By rozładować w pełni naładowany smartfon potrzeba około 16-18 dni. W przypadku, gdy używamy urządzenia, to ten czas skróci się dość znacznie. W teście PC MARK, Neffos X1 osiągnął wynik około 6,5 godziny. Biorąc pod uwagę, że poprzednie wersje Neffos'ów miały wyniki w granicach 8-9 godzin, to Neffos X1 wypada pod tym względem dość słabo. Wysuwana tacka na karty SIM/mikro SD Obudowy w Neffos X1 nie da się łatwo ściągnąć, tak jak to miało miejsce w starszych modelach smartfonów TP-LINK'a. Trzeba zatem skorzystać z innego rozwiązania jeśli chodzi o położenie kart SIM oraz kary mikro SD. W poprzednich modelach Neffos zdejmowaliśmy obudowę i odsłanialiśmy tym samym dwa sloty na karty SIM i jeden slot na kartę mikro SD. Zwykle część z tych slotów była przysłonięta przez baterię. W przypadku Neffos X1, karty SIM i karta SD są umieszczana na tacce, którą trzeba wysunąć z lewej krawędzi smartfona: Tej tacki nie da rady wysunąć bez dedykowanego narzędzia (ewentualnie zwyczajnej igły do szycia). Czynność zmiany czy zamiany kart nie należy zatem do przyjemnych i raczej nie przeprowadzimy tego zabiegu w terenie, bo musimy przy sobie posiadać kawałek cienkiej igły, by tę tacę wysunąć. Wyłącznie karty SIM w standardzie nano Dziś już spora część operatorów GSM oferuje docięte karty SIM i w ten sposób możemy mieć standardową kartę SIM lub też jej wersję mikro/nano. Neffos X1 akceptuje jedynie karty w tym najmniejszym standardzie. Powoduje to oczywiste problemy w przypadku kart SIM niektórych operatorów, w tym Aero2. Oczywiście można spróbować tę kartę dociąć do standardu nano SIM ale jeśli nie mamy wprawy w przycinaniu kart, to możemy taką kartę sobie jedynie uszkodzić. Nie wiem czy Aero2 oferuje karty w standardzie nano ale w przypadku każdego innego operatora GSM można zwykle poprosić o duplikat karty w takim właśnie formacie, choć to zwykle wiąże się z dodatkowymi kosztami. Albo dual SIM, albo karta SD To co zaskakuje w przypadku Neffos X1, to rozwiązanie jakie zostało zastosowane w przypadku kart SIM i karty mikro SD. Ja jestem jak najbardziej za miniaturyzacją wszystkiego co się tylko da ale nie przepadam zbytnio za uszczuplaniem funkcjonalności właśnie za sprawą miniaturyzacji. Neffos X1 niby ma wsparcie dla dwóch kart SIM (obie 2G/3G/LTE) ale nie w momencie, gdy chcemy korzystać z karty mikro SD (SDXC do 128G). Mamy zatem niezbyt przyjemną sytuację, gdzie musimy wybrać między korzystaniem z dual SIM lub jednej karty SIM i karty mikro SD. W poprzednich smartfonach Neffos mogliśmy korzystać zarówno z dual SIM jak i karty SD. Czemu na takie samo rozwiązanie w przypadku Neffos X1 nie zdecydował się TP-LINK? Tego nie wiem ale dla mnie to poważny minus. Oczywiście osobom, które korzystają tylko z jednej karty SIM, tego typu rozwiązanie raczej nie będzie przeszkadzać. Podobnie w przypadku osób, które już odeszły od stosowania kart mikro SD. Ja jednak uważam, że jeśli smartfon ma flash o pojemności mniejszej niż te 64 GiB (no może niech będzie i 32 GiB), to powinien mieć dedykowany slot na kartę SD bez kombinowania przy tym z dual SIM. Idąc dalej, wypadało by wspomnieć o kłopotach jakie to powyższe rozwiązanie będzie sprawiać przy próbie wyciągania karty mikro SD z telefonu. Jako, że zarówno karta mikro SD jak i karta SIM znajdują się na tej samej tacce, to nie mamy możliwości wyciągnięcia samej karty mikro SD bez wyciągania jednocześnie karty SIM. Android umożliwia nam przecież odmontowanie systemu plików karty i usunięcie tego nośnika danych bez potrzeby wyłączania telefonu. Podobnie w przypadku, gdy nową kartę mikro SD chcemy podłączyć do smartfona. No niestety w przypadku Neffos X1 trzeba będzie ten smartfon wyłączać za każdym razem, bo w przeciwnym razie możemy coś sobie uszkodzić. Łączność 2G/3G/LTE Oba gniazda SIM są przystosowane do obsługi kart w trybie 2G, 3G i LTE. Niemniej jednak, przy korzystaniu z dual SIM, tylko jedna z kart może zostać przestawiona w tryb 3G/LTE. Ta druga karta będzie działać jedynie w trybie 2G. W Neffos X1 mamy modem LTE kategorii 4 (CAT4) umożliwiający transfer danych z prędkością do 150/50 mbit/s. Ten modem obsługuje standardowe europejskie pasma częstotliwości dla LTE w technologi FDD, kanały B1/B3/B5/B7/B8/B20 (2100/1800/850/2600/900/800 MHz). Neffos X1 jest także w stanie obsługiwać standardy DC-HSPA+/HSPA/UMTS: B1/B5/B8 (2100/850/900 MHz) oraz EDGE/GPRS/GSM: B2/B3/B5/B8 (1900/1800/850/900 MHz). Poniżej znajduje się fotka obrazująca transfer danych za pośrednictwem tego właśnie modemu: WiFi 2,4 GHz i 5 GHz Standardowo smartfony dysponują już radiami WiFi operującymi w paśmie częstotliwości 2,4 GHz. Wszyscy jednak wiemy, że to pasmo jest już zapchane i trzeba migrować na pasmo 5 GHz. Niemniej jednak, te niskobudżetowe smartfony zwykle nie posiadają radia 5 GHz. Zdziwiłem się trochę, gdy podczas wstępnej konfiguracji zobaczyłem na ekranie dwie moje sieci WiFi: Jedna z tych sieci jest na paśmie 2,4 GHz, a druga na 5 GHz. Zatem Neffos X1 jest w stanie łączyć się bezprzewodowo w obu pasmach, co znacznie pomoże nam w migracji na to mniej zatłoczone pasmo i tym samym poprawi komfort przy korzystaniu z internetu na smartfonie. Jak jednak prezentuje się transfer danych w obu tych pasmach? Spójrzmy na poniższą fotkę (po lewej 5 GHz, po prawej 2,4 GHz) Widzimy zatem, że w ilość przesyłanych danych w obu sieciach WiFi jest mniej więcej taka sama. Niestety producent nie podaje w specyfikacji informacji dotyczących właściwości czipów bezprzewodowych i w zasadzie nic poza uzyskaną prędkością transferu danych nie da się póki co napisać. Jeśli chodzi zaś o zasięg, to jest on w zasadzie przeciętny ale też dużą rolę tutaj ogrywa sam router, zwłaszcza w paśmie 5 GHz. Ja akurat mam router Archer C2600 i Neffos X1 jest w stanie komunikować się z routerem w obu sieciach nawet przez te 2-3 grubsze ściany, choć jakoś sygnału się dość mocno degraduje. Siła sygnału dla pasma 2,4 GHz: Siła sygnału dla pasma 5 GHz: Bluetooth 4.1 Wersja Bluetooth, która została zastosowana w Neffos X1 to 4.1 i w zasadzie ten standard powinien nam wystarczyć. Niemniej jednak, trzeba pamiętać o tym, że Bluetooth 4.1 już jest dość leciwy, bo został ogłoszony pod koniec 2013 roku. Od tamtego czasu do oficjalnej prezentacji Neffos'a X1 zdążył się już pojawić standard 4.2 (pod koniec 2014 roku). GPS/GLONASS/AGPS Jeśli chodzi zaś o GPS, to Neffos X1 został naturalnie w stosowny odbiornik wyposażony. Mamy tutaj również wsparcie dla mechanizmu A-GPS (Assisted GPS) oraz GLONASS (Globalnaja Nawigacionnaja Sputnikowaja Sistiema). Neffos X1 łapie FIX'a bardzo szybko (dosłownie parę sekund), zwłaszcza na otwartym terenie. Gdy znajdujemy się w pomieszczeniu, to ten czas będzie naturalnie dłuższy ale i tak zamknie się w granicach kilkunastu sekund. W specyfikacji Neffos X1 można wyczytać, że ten smartfon potrafi korzystać nie tylko z nawigacji GPS i GLONASS ale także Galileo. Niestety nie udało mi się nawiązać połączenia z żadnym europejskim satelitą. Radio FM W Neffos X1 nie mogło także zabraknąć odbiornika FM. Może i obecnie praktycznie wszystkie radiostacje są dostępne w internecie, a mając na smartfonie WiFi czy LTE, to możemy włączyć sobie ulubioną stację w prawie każdym zakątku świata. Niemniej jednak, cieszę się, że tego typu zabawka w dalszym ciągu jest implementowana w smartfonach. Wbudowany głośnik Do dźwięków wydobywających się z urządzenia jakim jest smartfon wielu z nas nie przykłada większej wagi. Ja akurat zaliczam się do tych osobników, których ten aspekt pracy telefonu interesuje w znacznym stopniu. Czasy, w których "telefon służył do dzwonienia" już dawno są za nami i ja od smartfona oczekuję czegoś więcej niż jedynie proste realizowanie rozmów głosowych czy wysyłanie SMS'ów. Jedną z tych rzeczy jest zdolność odtwarzania muzyki. O ile praktycznie każdy smartfon potrafi odtwarzać MP3 czy też i inne formaty muzyczne, o tyle jakość dźwięku wydobywającego się z wbudowanego w smartfon głośnika pozostawia zwykle wiele do życzenia. Po przygodach z poprzednimi smartfonami od TP-LINK'a nie sadziłem, że coś w kwestii dźwięku ulegnie zmianie. No bo jakby nie patrzeć, do tej pory jakość dźwięku w smartfonach tego producenta nie była za dobra. Załadowałem zatem na swojego Neffos'a X1 kilka ulubionych piosenek i wcisnąłem przycisk Play i tu nastąpiło niemałe zdziwienie z mojej strony. Okazuje się, że w Neffos X1 dźwięk jest naprawdę dobrej jakości i w zasadzie deklasuje to z czym mieliśmy do czynienia w Neffos C5, C5 MAX, Y5 czy Y5L. Nie sądziłem, że taka drastyczna zmiana i to na plus jest możliwa ale jak widać (a właściwie słychać) TP-LINK nad tym kluczowym jak dla mnie elementem smartfona przysiadł i trochę popracował, co mnie bardzo cieszy. Druga ważna kwestia tycząca się tego wbudowanego głośnika, to jego umiejscowienie. W końcu strumień dźwięku jest wypychany przez krawędź smartfona (w tym przypadku dolną), a nie przez tylną część obudowy tak jak to miało miejsce we wcześniejszych modelach Neffos. Dzięki takiemu zabiegowi, w końcu można położyć smartfon płasko na stole bez zasłaniania głośnika i tłumienia wydobywających się z niego dźwięków. Słuchawki Do smartfona Neffos X1 zostały dołączone także słuchawki. Prawdę mówiąc niezbyt przepadam za tego typu słuchawkami i gdyby miał wybierać, to jednak wolałbym te słuchawki, które były dołączane do zestawów z Neffos C5 czy C5 MAX. Nie chodzi o jakość dźwięku, bo ta zdaje się nawet być sporo na plus dla tych słuchawek dołączonych do Neffos X1 ale nie przypadł mi do gustu ich design. Niemniej jednak, dobrze, że słuchawki są w zestawie, a dźwięk który można w nich usłyszeć nie kaleczy uszu. Dioda powiadomień Pierwszym modelem Neffos jaki wpadł mi w łapki był C5. Nie posiadał on żadnej diody powiadomień. Późniejsze modele TP-LINK'owych smartfonów, którymi miałem okazję się bawić, miały już tę diodę ale tylko w modelu C5 MAX można było się spotkać z różnymi kolorami tej diody, a konkretnie były to kolory czerwony i zielony. Z tego co obserwuję, to ta dioda powiadomień została nieco podrasowana w Neffos X1. W przypadku tego modelu smartfona, ta dioda posiada standardowy kolor czerwony i zielony ale dodatkowo także został dodany kolor pomarańczowy. Dla wielu ludzi dioda powiadomień może być zbędnym wynalazkiem ale dzięki niej możemy w pewnych sytuacjach rozpoznać, o co chodzi naszemu smartfonowi i to bez potrzeby dotykania samego urządzenia. Im bardziej kolorowa jest ta dioda, tym lepiej. Czujniki Neffos X1 jest wyposażony w szereg czujników. W zasadzie to mamy do czynienia z tymi samymi czujnikami, co w przypadku pozostałych smartfonów TP-LINK'a ale z jedną drobną różnicą -- żyroskop. Mamy zatem do dyspozycji pięć czujników: akcelerometr, czujnik światła oraz czujnik zbliżeniowy (łapie z 5 cm), magnetometr (mamy wbudowany w smartfon kompas), no i wspomniany wcześniej żyroskop, którego mi najbardziej brakowało w poprzednich Neffos'ach: Czytnik linii papilarnych Wielu użytkowników smartfonów, w tym tez i ja, nie zbyt przepada za wynalazkami biometrycznymi, które są implementowane w tych urządzeniach. Chodzi oczywiście o różnego rodzaju skanery siatkówek czy odcisków palców. Neffos X1 został wyposażony właśnie w jeden taki czytnik, który umożliwia "zabezpieczenie" telefonu w oparciu o unikalny wzór jaki tworzą linie papilarne na naszych dłoniach. Oczywiście to zabezpieczenie daje nam jedynie fałszywe poczucie bezpieczeństwa, bo dłonie zawsze mamy przy sobie i jeśli ktoś chciały odblokować nasz telefon, to bez problemu może nas zmusić do przystawienia jednego czy drugiego palca do czytnika. Dlatego ja jednak wolę pozostać przy tradycyjnej metodzie zwykłego hasła (czy nawet kodu PIN), które może i ma o wiele mniej kombinacji niż układ linii papilarnych ale za to wydobycie go bez pozostawiania widocznych śladów jest o wiele trudniejsze. Taki czynnik odcisków nie jest też skazany z góry na porażkę. Można bowiem wykorzystać inne części ciała niż opuszek palca wskazującego naszej prawej ręki. Sprawdziłem jak sobie ten czytnik poradzi z losowym punktem na przedramieniu, gdzie odcisków palców raczej nikt z nas nie posiada (a może posiada?). Co ciekawe, bez problemu dało radę za pomocą takiego "odcisku palca" odblokować telefon. Można zatem wykorzystać chyba dowolny punkt na naszym ciele jako taki odcisk, a to z kolei już znacznie komplikuje odblokowanie telefonu komuś kto nie wie, który kawałek naszego ciała sobie zeskanowaliśmy. Oczywiście w dalszym ciągu można nas podpatrzeć podczas odblokowywania telefonu i ustalić z dużym przybliżeniem ten punkt. Android 6.0 Marshmallow W Neffos X1 mamy instalowany Android w wersji 6.0 (Marshmallow). Dobrze chociaż, że TP-LINK odszedł już od wersji 5.1 ale obecnie 6.0 jest już dość starym system i przydałoby się patrzeć nieco przychylniej na 7.1 (Nougat), zwłaszcza, że producent Neffos'ów nie chce zbytnio aktualizować starszych wersji Androida do nowszych. Zostawmy kwestię świeżości systemu i skupmy się bardziej na pracy tego Androida, który zagościł w Neffos X1. To oprogramowanie, które jest wgrane standardowo, działa bardzo płynnie i nie powinno to być zaskoczeniem, bo jakby nie patrzeć Neffos X1 jest wyposażony w 2 lub 3 GiB pamięci operacyjnej RAM i nawet na tym słabszym wariancie Android działa bez zacięć. To co może przysporzyć o ból... głowy, to niemal 3 GiB ROM i jest to wzrost prawie o 1 GiB w stosunku do poprzednich smartfonów Neffos. Jest to bardzo dużo biorąc pod uwagę fakt, że LineageOS ma około 600-700 MiB. Oczywiście wszystkie aplikacje od Google, które są standardowo w Neffos X1, zajmują dodatkowe 1 GiB ale co znajduje się na pozostałym 1 GiB przestrzeni? Póki co nie znam odpowiedzi na to pytanie. Idąc dalej. Neffos X1 utylizuje w znacznym stopniu pamięć RAM. Po uruchomieniu się systemu, ilość zjadanej pamięci jest w granicach 1 GiB. Dość sporo jak na stock'owe oprogramowanie, a przecież jeszcze do tego dojdą nam nasze własne aplikacje. Łatwo zatem wywnioskować, że instalując dodatkowe oprogramowanie zacznie nam brakować pamięci. Dlatego też jeśli mielibyśmy możliwość wyboru między Neffos X1 z 2 GiB i 3 GiB pamięci RAM, to decydujmy się na tę drugą opcję. USB-OTG Poprzednie modele Neffos'ów cierpiały na brak porządnego wsparcia dla USB-OTG (On-The-Go). W zasadzie to tylko Neffos C5 MAX był w stanie obsługiwać zewnętrzne myszki i klawiatury ale nie byliśmy w stanie już podłączyć do niego pendrive czy zewnętrznego dysku, no chyba, że na alternatywnym firmware. Wygląda na to, że kwestia USB-OTG została rozwiązana przez TP-LINK raz na zawsze w Neffos X1. Tutaj stock'owy firmware jest w stanie obsłużyć nie tylko myszkę czy klawiaturę ale również i pendrive czy dyski. Jedyny problem jaki napotkałem w przypadku tych zewnętrznych nośników informacji, to brak wsparcia dla innych systemów plików niż FAT. Android jest w stanie rozpoznać kilka partycji na tym samym nośniku ale jeśli będą one miały inny system plików niż FAT, to nie zostane uwzględnione wyżej na liście. Blokowanie niechcianych połączeń Następna rzecz, o której warto wspomnieć patrząc na system w Neffos X1, to automatyczne i do tego ciche blokowanie niechcianych połączeń głosowych (ew. też SMS'ów). Z tego typu opcją mogliśmy się już spotkać w modelu Y5 ale zabrakło jej w pozostałych Neffos'ach. Dzięki temu filtrowi, nasz smartfon jest w stanie odpowiadać sygnałem "zajęty" do określonych numerów telefonów bez powiadamiania nas o tym fakcie. Możemy nie tylko definiować całe numery ale również prefiksy (klasy numerów), a także możemy zabronić na kontakt numerom spoza naszej książki adresowej. Innymi słowy, telemarketerzy nie będą mieć łatwego życia. Oczywiście zdaję sobie sprawę, że są aplikacje tego typu, które są w stanie taki filtr nam w telefonie zaimplementować ale tutaj liczy się fakt, że stock'owe oprogramowanie już taki ficzer posiada, a my nie musimy podejmować żadnych kroków, by go u siebie wdrożyć. Temperatura kolorów wyświetlacza Pewnie każdy z nas spotkał się już z różnymi akcjami na temat niezbyt dobrego wpływu światła niebieskiego na nasz organizm, szczególnie po zmroku czy w miejscach słabo oświetlonych. Na rynku jest cała masa aplikacji oferujących minimalizowanie efektu jakie wywołuje właśnie to światło niebieskie, np. Twilight. W Neffos C5 i C5 MAX, Twilight nie działał poprawnie. Można było oczywiście korzystać z innych aplikacji ale one z kolei miały bardzo negatywny wpływ na procesor (100% wykorzystania przy przewijaniu ekranu). W Neffos Y5 i Y5L, z Twilight było już trochę lepiej, bo tam był on w stanie działać prawidłowo. W zasadzie ta aplikacja również działa na Neffos X1 ale potrzeba jej wykorzystania w tym modelu zdaje się powoli zanikać. Chodzi o to, że Android w tym smartfonie domyślnie oferuje nam wybór temperatury kolorów i możemy sobie z powodzeniem odfiltrować światło niebieskie: Niemnie jednak, ta funkcja systemu jest dość uboga w porównaniu do tego co oferuje Twilight ale grunt, że tego typu opcja znalazła się w systemie. Przydałoby się ja tylko nieco dopracować. Dostosowanie ustawień przycisków Sporo smartfonów na rynku posiada trzy przyciski przy dolnej krawędzi ekranu. Są to standardowe przyciski "wstecz", "home" i lista ostatnio używanych aplikacji. W Neffos'ach po lewej stronie był zawsze przycisk "wstecz", w środku mieliśmy zaś przycisk "home", a lista aplikacji była po prawej stronie. Ten układ uległ zmianie w Neffos X1 ale bez obaw. Jeśli przywykliśmy do starego układu i nie pasuje nam ten nowy, to bez problemu możemy sobie dostosować po której stronie ma być przycisk "wstecz": Pływający przycisk Do tej pory wszystkie smartfony TP-LINK'a mające przekątną ekranu 5" miały ten problem, że bardzo ciężko było nimi operować jedną dłonią. Najbardziej szło odczuć ten problem przy korzystaniu z tych trzech przycisków, o których mowa była wyżej. W zasadzie nie było możliwości komfortowego wciśnięcia tych przycisków i trzeba było do tego wykorzystać drugą dłoń. W przypadku Neffos X1 będziemy w stanie dogodnie używać tego smartfona jedną ręką, a to za sprawą pływającego przycisku. Ten przycisk ma zdefiniowanych 5 akcji: wstecz, home, lista używanych aplikacji, zrzut ekranu i zablokowanie ekranu. Położenie tego przycisku możemy sobie dostosować, z tym, że zostanie on przyciągnięty do lewej lub prawej krawędzi ekranu. Można zatem go wypozycjonować przy prawym górnym rogu ekranu i wciskać go kciukiem prawej dłoni, w której również trzymamy telefon: Turbo Pobieranie Z tych bardziej przydanych rzeczy, które potrafią okazać się wielce użyteczne, to można jeszcze wymienić Turbo Pobieranie. Rzecz znana z jednego z poprzednich modeli Neffos'ów, a konkretnie z C5 MAX. Dzięki temu ficzerowi możemy nieco przyśpieszyć pobieranie większych plików, za sprawą połączenia przepustowości WiFi oraz LTE. Wybór trybu pracy telefonu po podłączeniu go do portu USB Wersja Androida zainstalowana w Neffos X1 znana jest z niedogodności, którą niesie domyślny tryb pracy telefonu po podłączeniu go do portu USB. Deweloperzy tego systemu postanowili, że domyślnym trybem będzie tryb ładowania, a nie tryb przesyłania plików i za każdym razem będziemy musieli przełączać ten tryb ilekroć będziemy chcieli wymieniać dane na linii komputer-smartfon. Chyba każdy z nas właśnie po to ten telefon podłącza do portu USB komputera, a system z niezrozumiałego powodu wymaga od nas ciągłego przełączania trybu, a to czasami może człowieka lekko wyprowadzić z równowagi. Użytkownicy Neffos'ów Y5 i Y5L raczej wiedzą o czym mówię. Ten problem można było obejść w tych dwóch modelach smartfonów przez zainstalowanie odpowiedniej aplikacji, która wymagała uprawnień root. Na szczęście ten domyślny tryb pracy po podłączeniu smartfona do portu USB został zmieniony w Neffos X1 przez TP-LINK. W przypadku tego modelu telefonu, po podłączeniu go do portu USB zostaniemy poproszeni o wyrażenie zgody na dostęp do danych, co wygląda mniej więcej tak: Jeśli zezwolimy, to smartfon przełączy się w tryb przesyłania plików, a jeśli nie, to pozostanie w trybie ładowania. Moim zdaniem jest to dobry kompromis, choć wymaga od nas manualnej akcji ilekroć tylko podłączamy do komputera nasz smartfon. Temperatura pracy W spoczynku Neffos X1 jest w zasadzie chłodny. A jak sprawa wygląda podczas zwykłej pracy oraz pod obciążeniem 100% mocy procesora? Poniżej są czujniki temperatur i z lewej strony mamy sytuację zwykłego przeglądania internetu (YT@720p), natomiast po prawej mamy już zapuszczony stres na procesor przez około 3 minuty (liczenie liczb pierwszych w CPU Prime Benchmark). Trochę się ten procesor grzeje. Co ciekawe, podczas tego testu wyszło, że pierwsze cztery rdzenie procesora są taktowane częstotliwością 1 GHz. W ten sposób niezbyt wymagające aplikacje korzystają tylko z tych czterech rdzeni (przez większość czasu pracy smartfona). Jako, że te rdzenie mają obniżone taktowanie, to pobierają mniej energii. Dopiero jak brakuje systemowi mocy, to załączane są te pozostałe cztery rdzenie o wyższym taktowaniu i procesor pracuje pełną parą. Neffos X1 pod linux Neffos X1, podobnie jak i pozostałe modele smartfonów od TP-LINK, nie sprawia problemów pod linux'em, przynajmniej jeśli chodzi o dystrybucję, z której ja korzystam na co dzień, tj. Debian. Jedyny problem z jakim będziemy mogli się spotkać, to brak wsparcia dla tego modelu w bibliotece libmtp , przez co nie zamontujemy OOTB na linux systemu plików tego smartfona. Oczywiście stosowny raport już posłałem do deweloperów i prawdopodobnie w następnej wersji tej biblioteki Neffos X1 będzie już wspierany. W przypadku, gdy ktoś nie chce czekać na oficjalne wsparcie, to zawsze może sobie dopisać poniższą regułę dla UDEV'a, która umożliwi zwykłemu użytkownikowi systemu zamontowanie zasobów telefonu przy pomocy narzędzi takich jak jmtpfs : ATTR{idVendor}=="2357", ATTR{idProduct}=="033c", SYMLINK+="libmtp-%k", MODE="660", GROUP="audio", ENV{ID_MTP_DEVICE}="1", ENV{ID_MEDIA_PLAYER}="1" Transfer jaki udało mi się uzyskać przy kopiowaniu plików z komputera na flash Neffos'a X1 za pomocą protokołu MTP oscylował w granicach 25 MiB/s i jest to naprawdę przyzwoity wynik. Root Neffos X1 Jeszcze żadnych kroków pod kątem rootowania systemu w Neffos X1 nie przeprowadzałem ale myślę, że niedługo się za to przedsięwzięcie zabiorę. Link do artykułu zostanie tutaj dodany za parę dni. (link FIXME) TL;DR TP-LINK po raz kolejny pokazał, że można wyprodukować dość tani smartfon posiadający ośmiordzeniowy procesor, 2 GiB pamięci RAM, 16 GiB pamięci flash, 13 mpix na głównej kamerze, przyzwoity wyświetlacz IPS, bluetooth v4.1, dwa radia WiFi (2,4 GHz i 5 GHz), modem LTE oraz GPS. Wszystko to zamknięte w metalowej obudowie przy wyświetlaczu chronionym szkłem Corning Gorilla. W Neffos X1 kilka rzeczy zostało dopracowanych w stosunku do poprzednich modelów Neffos, min. dźwięk, kamera główna/selfie czy minimalna jasność ekranu. Na uwagę zasługują też wynalazki pokroju żyroskopu czy czytnika linii papilarnych, choć ten ostatni nie budzi u mnie aż takich emocji. Na Neffos X1 została też wgrana nowsza wersja Androida (Marshmallow) ale wielkość ROM'u nieco przytłacza. W tym systemie za to znalazło się zaś kilka użytecznych rzeczy, np. pełnie wsparcie dla USB-OTG, konfiguracja przycisków, filtr połączeń, dostosowanie temperatury kolorów, czy turbo pobieranie. Został też po części wyeliminowany problem z domyślnym trybem pracy po podłączeniu smartfona do portu USB. Oczywiście Neffos X1 nie jest idealny, przynajmniej patrząc z mojego punktu widzenia. Zabrakło wymiennej i do tego pojemnej baterii, a rozwiązanie typu "albo dual SIM abo jeden SIM i karta SD" lekko mnie od tego modelu odpycha. Ja zawsze będę optował za dual/triple SIM i możliwością łatwego rozbudowania pamięci flash smartfona za sprawą karty mikro SD. A każdy smartfon, który próbuje uszczuplać tę funkcjonalność, od razu będzie za ten fakt przeze mnie ganiony. Niemniej jednak, nie jest źle ale mogłoby być znacznie lepiej.
  2. Kamery do monitoringu ostatnimi czasy stają się coraz bardziej popularne. Na dobrą sprawę możemy je spotkać praktycznie wszędzie, zwłaszcza w miejscach, w których dochodzi do kradzieży czy innych przestępstw, które cechują się podwyższonym odsetkiem niewykrywalności sprawców przez służby mundurowe. Oczywiście taki profesjonalny sprzęt, którym można zabezpieczyć duże obiekty, trochę kosztuje. Niemniej jednak, kamery przemysłowe nadają się głównie do zastosowań firmowych i przeciętnego Kowalskiego te rozwiązania zwykle nie interesują ze względu na ich wysoką cenę. Może niekoniecznie każdy z nas posiada dużą firmę ale są sytuacje, w których taka kamera bardzo by nam się przydała. Garaż czy piwnica często są obiektami zainteresowań podejrzanych typów i narażone na włamania. Dlatego też od czasu do czasu warto zajrzeć w te miejsca, by się upewnić czy aby na pewno wszystko jest w porządku. Zwykle jednak nikt nie ma na to czasu, a gdy już ktoś nam się włamie, to nie dość, że orientujemy się parę dni/tygodni po fakcie, to jeszcze nawet nie mamy pojęcia kto, jak i kiedy się tego czynu zabronionego dopuścił. Dlatego monitoring warto sobie zainstalować i niekoniecznie musimy przy tym wydawać dziesiątki tysięcy złotych. TP-LINK ma w swojej ofercie kilka niedrogich kamer IP, które można wykorzystać do zastosować domowych. W tym artykule rzucimy sobie okiem na obrotową kamerę NC450, która jest w stanie zapisywać obraz i dźwięk na kartę SD. Zawartość pudełka NC450 Zaczniemy standardowo, czyli na początek fotki pudełka i jego zawartości. Specyfikacja kamery NC450 Jak widać, opakowanie jest duże, bo mamy dość sporo elementów. Najważniejszym z nich jest oczywiście to urządzenie w kształcie nieco przerośniętego kurzego jaja. Dokładne wymiary naszej kamery to: 144x109x106 mm. A tak się ono prezentuje z bliska: Na bokach kamery mamy szereg otworów, choć dziurki są tylko z jednej strony (może zapomnieli dowiercić z drugiej): Za tymi otworami skrywany jest dość głośny głośniczek, przez który możemy nadawać komunikaty głosowe. Na spodzie frontowej części obudowy mamy zielono-czerwoną diodę oraz mikrofon, przy pomocy którego osoba monitorowana może się z nami porozumieć: W ten sposób ta kamera NC450 zapewnia nam komunikację w obie strony, co bardzo cieszy, choć głośność tego wbudowanego głośniczka mogłaby być regulowana, bo serio mam wrażenie jakbym gadał przez megafon. Z tyłu urządzenia mamy zaś gniazdo na zewnętrzną antenę (złącze RP-SMA). Niżej jest slot na kartę mikro SD (max 32G). Obok mamy port Ethernet (RJ-45), gniazdo zasilania oraz przycisk WPS/RESET, dzięki któremu zresetujemy ustawienia kamery do fabrycznych i nawiążemy szybko połączenie z siecią bezprzewodową. Kamera NC450 została wyposażona w progresywny przetwornik obrazu CMOS 1/4 cala i soczewki F:2,0 (jasność obiektywu), f: 3,6 mm (ogniskowa). Kąt widzenia na podglądzie obrazu to około 75°. Poniżej jeszcze fotka samego obiektywu, nad którą mamy czujnik poziomu światła: To urządzenie jest w stanie rejestrować obraz w rozdzielczości 1280x720p (1 mpix) przy maksymalnie 30 FPS. Pliki zapisywane są w formacie H.264. Zasięg widzenia kamery NC450 Może i kąt widzenia na podglądzie obrazu to około 75° ale w zasadzie można ten parametr zignorować. To, co niewątpliwie odróżnia kamerę NC450 od innych TP-LINK'owych kamer, to możliwość obrotu kamery w poziomie (300°) oraz pionie (110°), co zapewnia dość szerokie pole widzenia w granicach 360° i 150° (poziom/pion). Co ciekawe, kamerą można obracać również programowo czy to przez aplikację na smartfona (tpCamera), czy też przez panel administracyjny z poziomu przeglądarki. Zatem możemy uzyskać podgląd z dowolnego miejsca monitoringu, o ile jest ono w zasięgu kamery. WiFi 2,4 GHz do 300 mbit/s i zewnętrzna antena Kamera NC450 jest w stanie komunikować się bezprzewodowo w paśmie 2,4 GHz w standardzie N do 300 mbit/s. TP-LINK podaje, że liczba jednoczesnych klientów, którzy mogą uzyskać podgląd z kamery to 13. Do zestawu została dołączona także taka oto zewnętrzna antena w celu poprawy zasięgu WiFi. A tak wygląda NC450 z podpiętą antenką: Niestety na stronie TP-LINK nie ma informacji na temat zysku energetycznego tej anteny. Podejrzewam jednak, że jest to standardowe 3 dBi. Tak czy inaczej, umożliwienie podłączenia zewnętrznej anteny można zaliczyć jak najbardziej na plus. Może niekoniecznie ta antena dołączona do zestawu urywa pewną część ciała ale do tego złącza RP-SMA można podłączyć, np. antenę TL-ANT2408C , która w pewnych sytuacjach może znacząco poprawić odbiór sygnału z domowego routera WiFi: Power over Ethernet (PoE) Kamera NC450 jest także wyposażona w jeden port RJ-45 (100 mbit/s), który może zostać wykorzystany do przewodowej komunikacji z tym urządzeniem. Jednak to, na co warto zwrócić największą uwagę, to fakt, że TP-LINK dołączył do zestawu adapter PoE: Możemy zatem bez problemu tę kamerę zasilić przez przewód Ethernet. Niemniej jednak, w dalszym ciągu w jakiś sposób musimy zasilić sam adapter: Jeśli stosujemy takie rozwiązanie i chcemy podłączyć kamerę przewodowo zamiast po WiFi, to naturalnie możemy pociągnąć drugą skrętkę z portu LAN adaptera i podpiąć przewód do routera. Tryb nocny Kamera NC450 posiada także zestaw diod podczerwieni, a konkretnie jest ich 8, co zapewnia dość dobrą widoczność w całkowitych ciemnościach na dystansie około 6-8 metrów. Pobór prądu W pudełku z NC450 można także doszukać się zasilacza 12V/1A wraz z przedłużaczem. Sam zasilacz ma przewód o długości około 1,5 metra. Natomiast przedłużacz jest w stanie jeszcze dołożyć kolejne 3 metry. Nasza kamera jest zatem w stanie pociągnąć do 12 Wat energii na godzinę. A jak jest w istocie? W zasadzie ta kamera podłączona przewodowo z podpiętym jednym klientem pobiera około 2,5W. W przypadku transferu po WiFi do jednego klienta, jest to już około 3W. Jak się załączy tryb nocny, to jeszcze trzeba doliczyć kolejny 1W, co daje w sumie już 4W. No i jeśli chcemy obracać kamerą, to trzeba liczyć na to również około 1W. W zasadzie można przyjąć, że kamera w spoczynku pobiera około 3W na godzinę. Elementy montażowe Kamerę NC450 można postawić na biurku czy na półce i tyle ale w zestawie mamy również elementy montażowe, które pozwalają przymocować to urządzenie do ściany lub sufitu. Poniżej znajduje się regulowana podstawka, którą można przykręcić do spodu kamery: Ta podstawka jest solidna, choć wykonana z plastiku. Jak widać wyżej, uchwyt ma możliwość regulacji. Dobrze, że w tej kamerze nie ma już tego śmiesznego kulkowego regulatora, który się odkręcał przy zmianie położenia kamery. Tutaj, by zmienić położenie kamery trzeba pierw poluzować widoczną wyżej śrubkę. Po zmianie położenia zaś wszystko można mocno i pewnie skręcić, co zapewnia nas, że kamera sama z siebie przypadkiem się nie przemieści. A tak wygląda NC450 na mocowaniu: Praca kamery NC450 pod linux To co może zaskoczyć w przypadku kamery NC450 to fakt, że w zasadzie działa ona bez zarzutu pod linux. Wcześniej miałem do dyspozycji kamerę NC250 i w jej przypadku podgląd jak i większość funkcji, które były dostępne przez panel administracyjny z poziomu przeglądarki, zwyczajnie nie działała. Problemem był niestandardowy plugin, który trzeba było zainstalować, a tak się składało, że TP-LINK nie wypuścił stosownej wersji pod linux i w zasadzie tamta kamera niezbyt się nadawała pod ten alternatywny system operacyjny. W przypadku kamery NC450, do jej obsługi z poziomu przeglądarki nie potrzeba żadnych dodatkowych wtyczek, a panel administracyjny działa pod linux bez zarzutu. Zarządzanie kamerą przez panel administracyjny Jako, że kamera NC450 to kamera IP, to przyłączanie do sieci tego urządzenia odbywa się przez nadanie mu stosownej adresacji. Ta z kolei jest uzyskiwana automatycznie od naszego routera WiFi. Do panelu administracyjnego można przejść wpisując w przeglądarce adres IP, który został przypisany kamerze. Kamerą sterować można za pomocą tego pokrętła z prawej strony podglądu obrazu. Pod poglądem mamy kilka opcji, które możemy przełączać. Są to: zrobienie zdjęcia, odwrócenie podglądu w pionie i poziomie oraz tryb auto/dzienny/nocny. Niżej jeszcze możemy dostosować sobie jasność/kontrast obrazu i nasycenie barw. Nie ma jednak przycisku do nagrywania obrazu/dźwięku. Kamerę NC450 można podłączyć do serwisu tplinkcloud i odbierać obraz z każdego miejsca na ziemi, o ile mamy tam internet. Kamerę trzeba pierw w tym serwisie zarejestrować, co możemy naturalnie zrobić z panelu administracyjnego: Później można już tylko przejść na stronę tplinkcloud.com i sprawdzić czy kamera została dodana do systemu. Niestety pod linux nie da rady przez ten serwis uzyskać podglądu z kamery. Natomiast jeśli dysponujemy smartfonem, to bez problemu obraz damy radę podejrzeć przez aplikację tpCamera. Jeśli chodzi zaś jeszcze o ustawienia samej kamery, które można dostosować z poziomu panelu administracyjnego, to mamy tam opcje video, gdzie możemy min. zmienić ilości klatek na sekundę. Do wyboru mamy 10, 15, 20, 25 i 30: Naturalnie to urządzenie wspiera także detekcję dźwięku i ruchu: Kolejna ciekawa rzecz, którą oferuje kamera NC450, to nagrywanie obrazu na kartę SD. Sama karta musi być w formacie mikro SDHC (maksymalna pojemność takiej karty to 32G). Kamera automatycznie robi zrzut ekranu oraz rozpoczyna nagrywanie obrazu po wykryciu dźwięku lub ruchu, w zależności od ustawień określonych wyżej. Nie widziałem jednak w tym panelu opcji, by rozpocząć nagrywanie na żądanie. Być może tylko pod linux brakuje tej opcji. W tym webowym panelu administracyjnym brakuje także opcji przesyłania powiadomień drogą email. Jedyną formę powiadomień jaką możemy skonfigurować to FTP: Niemniej jednak, jeśli włączymy aplikację tpCamera, to tam już można ustawić notyfikacje czy to via email czy przez aplikację w smartfonie. Sterowanie kamera NC450 przy pomocy smartfona Praktycznie każdą TP-LINK'ową kamerą, w tym też i NC450 można sterować z poziomu smartfona, tylko trzeba doinstalować aplikację tpCamera. Nie będę tutaj opisywał jak zainstalować i skonfigurować aplikację tpCamera, bo na ten temat był już osobny wpis. Zatem jeśli ktoś jest ciekaw co potrafi ta aplikacja to zachęcam do zapoznania się z tym wyżej podlinkowanym wpisem. TL;DR W stosunku do poprzednich TP-LINK'owych kamer, które miałem okazję testować, NC450 jest nieco lepiej przystosowana do pracy pod systemami z rodziny linux. Wszystkie funkcje panelu administracyjnego działają z poziomu przeglądarki, choć brakuje opcji nagrywania obrazu/dźwięku. Sam panel zdaje się być nieco uboższy w stosunku do tego, który spotkałem w kamerze NC250. Niemniej jednak, wszystkie te brakujące rzeczy są do ogarnięcia na smartfonie przez aplikację tpCamera. Niewątpliwą zaletą kamery NC450 jest slot na kartę SD oraz możliwość zapisu fotek jak i materiału video bezpośrednio na tym nośniku. Cieszę się też, że wymieniono w tej kamerze uchwyt do mocowania na ścianie/suficie na bardziej solidny. Niezastąpiony z kolei jest obrót samej kamery w poziomie i w pionie, przez co mamy możliwość dostosowania pola widzenia w zależności od potrzeb. W sumie to jest małe prawdopodobieństwo, że ktoś nam ucieknie poza kadr. Tryb nocny również jest bardzo przyzwoity, choć zasięg oświetlenia diodami podczerwieni mógłby być nieco większy. Te 6-8 metrów w zasadzie limituje zastosowanie tej kamery do nie za dużych pomieszczeń, choć trzeba pamiętać, że NC450 jest do zastosowania tylko i wyłącznie wewnątrz budynku. Wbudowany głośnik i mikrofon są tymi elementami, których mi najbardziej brakowało w modelu NC250. Dzięki takiemu rozwiązaniu możemy bez przeszkód komunikować się przez kamerę w obie strony, co eliminuje potrzebę zewnętrznej drogi komunikacji. Możliwość zdalnego monitoringu za pośrednictwem serwisu tplinkcloud również może być w pewnych sytuacjach wielce nieoceniona. Wystarczy kilka klików myszką i jesteśmy w stanie odbierać obraz z monitorowanego obiektu praktycznie z każdego miejsca na ziemi. Choć tutaj w grę wchodzi polityka prywatności, która nie zawsze pozwoli nam przesłać obraz i dźwięk przez zewnętrzny serwis TP-LINK. W zasadzie WiFi w standardzie N do 300 mbit/s wystarcza dla takich kamer jak ta NC450. Niemniej jednak, przydałoby się zaimplementować już w tych urządzeniach radia 5 GHz i brak tego WiFi to w zasadzie jedyny minus jaki mam pod adresem tego urządzenia.
  3. Większość z nas zawierała już jakaś umowę abonamentową na telefon z operatorami GSM. Ja jestem chyba jednym z nielicznych wyjątków, które tego jeszcze nie uczyniły. Mam prepaid'a od lat i w sumie nie uśmiecha mi się wiązanie na dłuższy okres czasu umową z operatorem, którego stosunek do użytkownika zwykle się drastycznie obniża tuż po podpisaniu papierowego świstka. Niemniej jednak, prepaid'y mają tę wadę (dla niektórych zaletę), że sami musimy zadbać o odpowiednie urządzenie, za pomocą którego będą realizowane usługi telefoniczne. Problem w tym, że te bardziej zaawansowane technicznie smartfony są w stanie kosztować niemałe pieniądze, przez co niewielu z nas jest w stanie pokusić się o ich zakup i z reguły pozostaje nam tylko opcja pakietowa przy zawieraniu umowy z operatorem GSM. Jeśli już się jednak zdecydujemy na zakup takiego sprzętu, to ciężko jest też znaleźć takie urządzenie, które będzie w miarę tanie i jednocześnie dostosowane do realiów otaczającej nas rzeczywistości. TP-LINK był chyba tego samego zdania i od jakiegoś już czasu wypuszcza na rynek smartfony. Czym ten producent może się pochwalić jeśli chodzi o te urządzenia? Na pewno niewygórowaną ceną. A jak sprawa wygląda w przypadku parametrów technicznych oferowanych nam telefonów? To trzeba by sprawdzić i tak się składa, że mam właśnie na wyposażeniu taki smartfon, a konkretnie jest to model Neffos C5 (TP701A). Zawartość opakowania Smartfon Neffos C5 to chyba jedyna rzecz, która dotarła do mnie za pośrednictwem Poczty Polskiej nietknięta. Nie jest to raczej zasługa tego przewoźnika, a raczej samego pudełka, które moim zdaniem jest Poczta-Polska-Proof. Samo pudełko jest w kolorze, którego faceci nie rozróżniają, a w nim znajduje się kilka ciekawych rzeczy: W zestawie mamy oczywiście smartfon Neffos C5, którego obudowa jest wykonana w całości z matowego plastiku, przez co nie zbiera tak łatwo odcisków palców i trudniej tez o zarysowania na powierzchni: Mamy także ładowarkę 5V/1A z standardowym gniazdem USB: Oraz przewód mikro USB, dzięki któremu będziemy w stanie podpiąć naszego Neffos'a C5 do ładowarki lub portu USB komputera: Do zestawu są także dołączone słuchawki posiadające złącze audio minijack (3,5 mm): Nie mogło też zabraknąć akumulatora 2200 mAh, model NBL-42A2200: Do zestawu jest także dołączona skrócona instrukcja obsługi w języku polskim i kilka innych papierzysk oraz kawałek plastikowej osłony naklejanej na wyświetlacz. Specyfikacja Neffos'a C5 No to już wiemy co było w pudełku. Pora przyjrzeć się nieco bliżej samemu smartfonowi. Poniżej znajduje się fotka obrazująca część urządzenia tuż nad wyświetlaczem: Najbardziej z lewej strony mamy aparat selfie 5 mpix. Rozdzielczość zdjęć wykonywanych przy pomocy tego aparatu to 2560 x 1920 pikseli. Można nim także tworzyć materiały video, z tym, że tutaj już rozdziałka nam nieco siada, bo nie damy rady wyjść poza granice 640 x 480 pikseli. Dalej mamy standardowy głośnik. A na prawo od głośnika znajduje się czujnik światła oraz czujnik zbliżeniowy. Z tyłu telefonu mamy zaś główny aparat 8 mpix z przysłoną f/2.0, oraz dwie diody w roli lampy błyskowej: Może i ten aparat ma 8 mpix ale jakość zdjęć pozostawia trochę do życzenia, szczególnie przy słabszym oświetleniu. W takich warunkach, autofokus ma problemy ze złapaniem ostrości, a jak już złapie, to bardzo szybko może ją stracić. Jeśli chcemy robić zdjęcia tym aparatem, to trzeba zadbać o dość przyzwoite oświetlenie, w przeciwnym wypadku nasycenie obrazu szumem będzie dość mocno widoczne. Na plus można za to zaliczyć bardzo mocne doświetlenie za sprawą lampy błyskowej. Te diody znakomicie znajdują zastosowanie także w przypadku latarki, która potrafiłaby pewnie przyćmić nawet sam blask Earendil'a. Choć przy niskim stanie baterii (poniżej 15%) nie damy rady jej włączyć. Rozdzielczość zdjęć wykonywanych przy pomocy tego aparatu to 3264 x 2448 pikseli. Jeśli zaś chodzi o rozdzielczość video, to tutaj jest już nieco lepiej, bo jesteśmy w stanie nagrywać filmy w rozdzielczości 1920 x 1080 pikseli, przy 30 FPS. Rodzaj wykorzystywanego kodeka to h264 (bitrate na poziomie 17250 kbps). Również z tyłu obudowy mamy głośnik multimedialny: Na prawej krawędzi obudowy mamy trzy przyciski: power, volume down i volume up: Z kolei zaś na górnej krawędzi znajduje się gniazdo słuchawkowe oraz mikrofon z redukcją szumów: No i standardowo na dolnej krawędzi mamy port mikro USB typ B oraz zwykły mikrofon do rozmów telefonicznych: Zajrzyjmy jeszcze do wnętrza Neffos'a C5: Mamy tutaj miejsce na akumulator oraz trzy sloty. Dwa z nich są na karty mini SIM. Jeśli mamy adapter mikro-mini, to możemy także korzystać z karty mikro SIM. Standardowych rozmiarów karty SIM są niestety za duże i trzeba będzie postarać się o mniejsze odpowiedniki. Trzeci zaś slot jest na kartę mikro SDHC (max 32 GiB). W to duże zagłębienie zaś wchodzi bateria i jak widać, przysłania ona wszystkie trzy sloty, przez co nie damy rady wyciągnąć żadnej karty bez wyciągania akumulatora i wyłączania telefonu: Procesor MediaTek MT6735 Smartfon Neffos C5 został wyposażony w 64-bitowy procesor MediaTek MT6735 (datasheet) dysponujący 4 rdzeniami opartymi na architekturze ARM Cortex-A53 taktowanymi zegarem od 300 MHz do 1,3 GHz (dynamicznie). Mamy też tutaj układ graficzny ARM Mali-T720 MP2 taktowany zegarem 450 MHz będący w stanie obsłużyć wyświetlacz w rozdzielczości 720 x 1280 pikseli (HD) oraz nagrywać i odtwarzać materiały wideo w rozdzielczości maksymalnej 1080p przy 30 FPS'ach. Procesor graficzny posiada także wsparcie dla API takich standardów jak OpenGL ES 1.1/2.0/3.0, OpenCL 1.0/1.1/1.2 oraz DirectX9. Proces technologiczny tego SoC'a to 28 nm. Pamięć RAM oraz flash Niewątpliwą zasługą bardzo płynnego działania systemu smartfona (Android 5.1) jest fakt, że ten Neffos C5 ma zainstalowane 2 GiB pamięci operacyjnej RAM (LPDDR3). Nie jestem pewien jaka jest częstotliwość tej pamięci. Wpadła mi w oczy wartość 640 MHz. Po wyłączeniu zbędnych rzeczy z autostartu, mamy około 1,4 GiB pamięci na odpalane w systemie aplikacje. Neffos C5 jest wyposażony także w pamięć flash o pojemności 16 GiB. Niemniej jednak, jak to zwykle bywa w smartfonach, część przestrzeni tego flash'a zjada nam już system operacyjny i preinstalowane aplikacje dodatkowe. Odliczając te rzeczy, zostaje nam do użytku nieco poniżej 10 GiB ale to i tak całkiem przyzwoita ilość miejsca. Dla wymagających zawsze jest opcja skorzystania z kart SD, które mogą pomóc nam tę pamięć rozbudować o dodatkowe 32 GiB. Pasywny Dual SIM Dual SIM działa w trybie pasywnym (Dual Standby), czyli możemy wykorzystywać tylko jedną kartę SIM w danym czasie. Oczywiście obie karty SIM działają równolegle i mamy możliwość skonfigurowania ich niezależnie pod rozmowy, SMS i pakiety danych. Karty SIM mogą być 2/3/4G przez co mamy wygodny dostęp do technologi LTE: Możemy także bez problemu skonfigurować limity danych dla każdej karty SIM osobno: Po zamianie kart miejscami w slotach, czy też po ich fizycznej podmianie, po włączeniu telefonu zostaniemy o tym fakcie powiadomieni i poproszeni o zdefiniowanie nowej konfiguracji dla dual SIM. Wyświetlacz IPS Cały smartfon ma wymiary 144 x 72 x 8,8 mm (wy/sz/gr). Waży nieco ponad 140 gram. Sporą część Neffos'a C5 zajmuje wyświetlacz 5.0" o rozdzielczości 720 x 1280 pikseli. Sam wyświetlacz jest zrobiony w technologi IPS (In-Plane Switching). Kąty widzenia są zadowalające i nie ma zbytniego przekłamania kolorów przy spoglądaniu na wyświetlacz stojąc obok osoby trzymającej w ręku telefon. W sumie mi więcej nie potrzeba, w końcu to jest małe urządzenie, które zwykle trzyma się w łapkach zaraz obok pyszczka. Automatyczna regulacja jasności ekranu działa z lekkim opóźnieniem. Chodzi o to, że przy przejściu z ciemnego pomieszczenia do jasnego, musimy odczekać około 5 sekund aż jasność ekranu zostanie dostosowana. Podobnie przy przechodzeniu z bardziej oświetlonej lokalizacji do pomieszczenia, gdzie mamy mniej światła. Niestety nie mamy możliwości dostosowania tego zachowania. Sama regulacja jasności jest bardzo płynna bez nagłych skoków podświetlenia/przyciemnienia ekranu. Maksymalna jasność ekranu tego smartfona jest nam w stanie zapewnić komfortową pracę na zewnątrz przy bardzo słonecznej pogodzie, co jest niewątpliwym plusem tego urządzenia. Wzrok nie meczy się od patrzenia na ekran i czytania tekstu, a literki są bardzo wyraźne. Gęstość upakowania pikseli w przypadku Neffos'a C5 to około 300 PPI. Warto tutaj zaznaczyć, że producenci zwykli zawyżać tę wartość. A jak sprawa wygląda w przypadku TP-LINK'a i jego Neffos'a C5? Jako, że znamy rozdzielczość wyświetlacza oraz jego przekątną, to bez problemu możemy wyliczyć ilość pikseli na cal ze wzoru sqrt((1280^2) + (768^2)) ∕ 5 . Co daje nam około 298 PPI (Pixel Per Inch). Jest to przyzwoita wartość, bo ludzkie oko z reguły nie jest w stanie dostrzec tak małych pikseli, choć na rynku są również wyświetlacze mające ponad 300 PPI. Zasada jest jedna: im więcej PPI, tym ostrzejszy obraz i mniej wzrok się będzie nam męczył od patrzenia na wyświetlacz. Nie wiem czy jest jakaś realna korzyść z wyświetlaczy 300+ PPI. Bateria Neffos C5 dysponuje akumulatorem litowo-jonowy o pojemności 2200 mAh, model NBL-42A2200. Nie należy on może do najpojemniejszych ale niewątpliwą jego zaletą jest możliwość wymiany bez odwiedzania serwisu, bo nie jest wmontowany na stałe. Czas ładowania od 0-100% przy zastosowaniu ładowarki 5V/2A wynosi około 3 godzin. Zatem to urządzenie nie wspiera szybkiego ładowania. Nie jest wspierane także ładowanie bezprzewodowe. Żywotność baterii przy włączonym ciągle module GPS i WiFi jest w granicach 12-14 godzin. W stanie czuwania bez tych wszystkich modułów, telefon potrafi wytrzymać jakieś 14 dni. Przynajmniej taka wartość została zwrócona przez ten wbudowany mechanizm szacujący czas rozładowania. Choć jeśli spojrzy się na wykres rozładowania baterii, to można zauważyć, że niewiele jej ubywa podczas stanu czuwania: Jeśli chodzi zaś o temperaturę baterii, to w stanie spoczynku telefonu ma ona w granicach 20 stopni. Ta wartość rośnie trochę podczas procesu ładowania akumulatora, choć rzadko przekracza 30 stopni. Maksymalna wartość temperatury do jakiej rozgrzała mi się ta bateria podczas pracy, to około 36 stopni (przeglądanie YT w 720p). Jak dla mnie, to nie są zbyt wysokie wartości. Napięcie baterii w stanie totalnego rozładowania jest na poziomie 3,4 V. Przy maksymalnym naładowaniu jakieś 4,35 V. Poniżej jest jeszcze fotka zestawiająca te trzy powyższe wykresy razem: Głośnik, słuchawki i wydobywający się z nich dźwięk Neffos C5 dysponuje niezbyt dobrej jakości głośnikiem. Do odtwarzania głosu może i się nada ale słuchanie muzyki na nim sprawia, że moje uszy krwawią. Nieco lepiej sprawa wygląda w przypadku tych dołączonych do zestawu słuchawek ale pewnej części ciała one nie urywają. Sprawdziłem jaka jest faktyczna jakość dźwięku wydobywająca się z tych słuchawek po podłączeniu ich do mojego leciwego już mp3player'a iAudio U2. Dlaczego akurat do niego? A to z tego względu, że to urządzenie dysponuje naprawdę przyzwoitym układem dźwiękowym. Dźwięk w słuchawkach był sporo lepszej jakości, zatem nie jest to problem z samymi słuchawkami, a raczej ze smartfonem, który niezbyt radzi sobie z obróbką dźwięku (te same piosenki, ten tam bitrate MP3/320). Niemniej jednak, temu mp3player'owi raczej niewiele urządzeń jest w stanie dorównać, choć jakby nie patrzeć, to w końcu dedykowany sprzęt do odtwarzania muzyki. W opcjach smartfona dotyczących poprawy dźwięku mamy niby kilka rzeczy, które teoretycznie mają za zadanie poprawiać jakoś odtwarzanej muzyki: By być szczerym, na moje ucho, to one tylko pogarszają jakość dźwięku zarówno przez głośnik jak i przez słuchawki. Nie powiem, że różnicy nie ma ale to jest w zasadzie taka różnica, że "nie wiem, które lepsze, ale żadne z nich mi się nie podoba". Generalnie to nie jest źle ale przydałoby się popracować nad jakością dźwięku. Same słuchawki mają przewód raczej standardowy o długości 120 cm zakończony wtykiem minijack 3,5 mm. Jeśli chodzi zaś o możliwości sterujące przy pomocy słuchawek, to przy mikrofonie mamy trzy przyciski. Dwa z nich regulują głośność, a ten trzeci służy do odbierania i rozłączania rozmów oraz do odpalania i pauzowania odtwarzacza muzyki. Czujniki Na pokładzie Neffos'a C5 mamy także zaszytych kilka czujników. Są to akcelerometr, czujnik zbliżeniowy, czujnik światła oraz magnetometr: Ten ostatni z kolei wykrywa zmiany w polu elektromagnetycznym przez co możemy przerobić nasz telefon na kompas. Trzeba tylko pilnować, by nie zbliżyć się zbytnio do jakiegoś magnesu, bo wtedy wynik może nie być zbyt wiarygodny. Te standardowe czujniki są w porządku ale zabrakło mi tutaj żyroskopu oraz wysokościomierza. Przydałby mi się też termometr, barometr no i oczywiście licznik Geigera, choć pewnie przesadzam nieco. Dobrze, że ten Neffos C5 nie posiada żadnego syfu biometrycznego. Chodzi oczywiście o różnego rodzaju czytniki linii papilarnych czy skanerów siatkówki. Takie bajery budują tylko fałszywe poczucie bezpieczeństwa. Do tego podnoszą tylko koszt samego smartfona nie dając przy tym realnie żadnej korzyści. 2G/3G/LTE Neffos C5 posiada wbudowany modem LTE kategorii 4 (Cat4) umożliwiający osiągnięcie maksymalnego transferu w tej technologi 150/50 mbit/s (download/upload). Przy mojej lokalizacji poniżej 900 metrów od BTS'a (widoczność zachowana), w nocy około 2-3 godziny, transfer jest na poziomie 40/20 mbit/s. Może jest to daleko do tych obiecanych 150/50 mbit/s ale i tak jest to prawie dwukrotnie lepiej co w przypadku zewnętrznego modemu Huawei E3372s (pomiary przeprowadzane w budynku). Ten modem obsługuje standardowe europejskie pasma częstotliwości w technologi FDD, kanały B1/B3/B7/B8/B20 (2100/1800/2600/900/800 MHz). Neffos C5 jest także w stanie obsługiwać standardy DC-HSPA+/HSPA/UMTS: B1/B8(2100/900 MHz) oraz EDGE/GPRS/GSM: 850/900/1800/1900 MHz. WiFi 2,4 GHz Nie mogło także zabraknąć obsługi bezprzewodowej sieci WiFi. Jeśli o nią chodzi, to Neffos C5 potrafi obsługiwać jedynie pasmo 2,4 GHz w standardzie 802.11 b/g/n do 150 mbit/s (pojedynczy strumień). Trochę szkoda, bo nie ułatwia to jakże wielce potrzebnej migracji na 5 GHz. Zasięg jest raczej przeciętny ze wskazaniem na dobry. Poniżej są fotki zasięgu z moich AP, które w czasie pomiaru były rozlokowane w różnych pomieszczeniach (ten sam pokój, 4m + ściana, 6m + trzy ściany): Jeśli chodzi zaś o rzeczywisty transfer, to jest on na poziomie trochę powyżej 100 mbit/s (mierzone w tym samym pomieszczeniu co główny router): Standardowo też nie mamy wsparcia dla roamingu WiFi i trzeba ratować się zewnętrzną aplikacją SWIFI, która i tak ma defekt w postaci realizowania jedynie roamingu w przypadku różnych ESSID. Udostępnianie połączenia 3G/LTE Jeśli nie dysponujemy routerem 3G/LTE, lub też nie posiadamy dedykowanego modemu 3G/LTE, a chcielibyśmy korzystać z internetu w tej technologi, to możemy pokusić się przerobienie naszego Neffos'a C5 na hotspot sieci WiFi i przy jego pomocy udostępnić połączenie 3G/LTE w sieci lokalnej (max. 8 użytkowników). Oczywiście trzeba liczyć się z większą utylizacją baterii ale ta funkcjonalność jest jak najbardziej wpierana przez ten smartfon. Neffos C5 jest także w stanie świadczyć połączenie przez Bluetooth czy nawet za pośrednictwem przewodu USB, tzw. Tethering. Po podłączeniu smartfona przez przewód USB do komputera, w systemie linux pojawia się nowy interfejs usb0 , który możemy skonfigurować sobie jak każdy inny interfejs przewodowy. Poniżej jest log ze zdarzenia: kernel: usb 2-1.3: new high-speed USB device number 7 using ehci-pci kernel: usb 2-1.3: New USB device found, idVendor=2357, idProduct=0318 kernel: usb 2-1.3: New USB device strings: Mfr=2, Product=3, SerialNumber=4 kernel: usb 2-1.3: Product: Neffos kernel: usb 2-1.3: Manufacturer: TP-LINK kernel: usb 2-1.3: SerialNumber: TSL7DA69OBSO49PJ kernel: usbcore: registered new interface driver cdc_ether kernel: rndis_host 2-1.3:1.0 usb0: register 'rndis_host' at usb-0000:00:1d.0-1.3, RNDIS device, ce:44:9f:7e:fc:dc kernel: usbcore: registered new interface driver rndis_host Jak widać, obsługą tego interfejsu usb0 będzie zajmował się moduł rndis_host . Transfer jaki udało mi się osiągnąć to 111 mbit/s (USB-WiFi), także całkiem przyzwoicie. Bluetooth v4.0 Jak w każdym smartfonie, również i tutaj mamy Bluetooth. Nie jest to może najnowsza wersja tego standardu bo jedynie 4.0 ale zawiera ona w sobie technologię Low Energy (LE), czyli ma zmniejszone zapotrzebowanie na energię kosztem prędkości transferu danych (max. do 1 mbit/s). Jeśli zatem gdzieś w naszym domu leżą odłogiem słuchawki Bluetooth, to możemy z nich zrobić teraz użytek i sparować je z Neffos'em C5. Oczywiście możemy także zamienić ten smartfon w pilot telewizyjny, o ile nasz TV wspiera Bluetooth. GPS Następna sprawa to GPS, czyli system nawigacji satelitarnej. Neffos C5 wspiera dwa ciekawe mechanizmy: A-GPS (Assisted GPS) oraz GLONASS (Globalnaja Nawigacionnaja Sputnikowaja Sistiema). A-GPS to system znacznie skracający czas potrzebny na pierwsze ustalenie położenia w systemie GPS (połączenie z satelitami). System ten wykorzystuje do działania serwery operatorów sieci GSM, przez co operator sieci komórkowej musi wspierać taką usługę. W przeciwnym razie będziemy mieli do dyspozycji jedynie zwykły GPS. GLONASS, z kolei to radziecki/rosyjski system nawigacyjny. To taka alternatywa dla amerykańskiego systemu GPS. Połączenie GPS i GLONASS daje możliwość bardzo akuratnych pomiarów, co przekłada się na szybsze i dokładniejsze ustalenie pozycji odbiornika. Tu jeszcze tylko taka informacja, że Neffos C5 ma wspólną antenę dla 2.4 GHz WiFi, 2.4 GHz Bluetooth i 1.575 GHz GPS. Radio FM Przydatną właściwością Neffos'a C5 jest również obsługa radia FM. Zakres częstotliwości tego radia to 87,5-108 MHz, z przeskokiem co 0,1 MHz. By korzystać z tego radia, musimy mieć podłączone słuchawki, bo przewód słuchawkowy robi w tym przypadku za antenę. Niemniej jednak, samego radia można także słuchać z tylnego głośnika. Android 5.1 Lollipop Na Neffos C5 jest wgrany Android 5.1 Lollipop. Nie mamy póki co możliwości aktualizacji tego Androida do nowszej wersji. Być może w przyszłości TP-LINK wypuści stosowną aktualizację. Jeśli jednak chcielibyśmy zaktualizować tego Androida do 6.0 ręcznie, to musimy root'ować telefon. Niemniej jednak, nie musimy się z tym spieszyć, bo TP-LINK wypuścił mniejszą aktualizację systemu, która jest dostępna jako Over-The-Air Update (OTA) i możemy ją sobie wgrać bez większego problemu korzystając z wbudowanego mechanizmu aktualizacji. System działa stabilnie i płynnie, a sam telefon się za nadto nie grzeje. Podczas dłuższego odtwarzania filmu na YT w rozdzielczości 720p, czujniki temperatury zlokalizowane wewnątrz smartfona wskazują poniższe wartości: Ten Android co jest w Neffos'ie C5 jest praktycznie czysty i zawiera jedynie prostą nakładkę TP-LINK'a. Nie będę o niej zbytnio pisał, bo to czy ona komuś przypadnie do gustu czy też nie, to raczej sprawa indywidualna każdego użytkownika. Trzeba samemu poużywać i dopiero zdecydować bez jałowego opierania się na kilku fotkach i subiektywnych uczuciach osób, których się na oczy nie widziało. Dla mnie użyteczny okazał się menadżer zainstalowanych w telefonie aplikacji. Dzięki niemu jesteśmy w stanie bardzo łatwo zweryfikować uprawnienia konkretnych aplikacji i w prosty sposób je sobie dostosować: Inną ciekawą rzeczą jest możliwość zaprogramowania Neffos'a C5 by ten się automatycznie włączał i wyłączał o określonej godzinie. Bardzo użyteczna rzecz zwłaszcza w przypadku godzin nocnych, gdzie podczas snu nie chcemy by nam ktoś dzwonił. No a skoro też w tym czasie nie korzystamy z telefonu w ogóle to czemu go nie wyłączyć na okres snu? Jedyny problem jaki mam z tym ficzerem to możliwość zaprogramowania tylko jeden akcji włączenia i jednej akcji wyłączenia. Kolejna ciekawa sprawa, to możliwość zaszyfrowania telefonu. Dokładnie nie wiem jak jest realizowane to szyfrowanie ale na necie znalazłem informację, że ten SoC MediaTek MT6735 ma wsparcie dla szyfrowania AES. Na pewno przyjrzę się tej opcji i sprawdzę, czy faktycznie jest ona godna rozważenia. Idąc dalej mamy tryb oszczędzania energii, który jest w stanie bardzo przyzwoicie ograniczyć funkcjonalność Neffos'a C5 ale też dość znacznie wydłużyć jego czas pracy na baterii. Przy wyłączonym wyświetlaczu jest to czas rzędu 14+ dni. Czy da radę przeprowadzić root na Neffos C5 Nie powiem, że proces root'owania Neffos'a C5 przebiegł bez większego problemu ale udało się ten telefon ukorzenić. Chodzi oczywiście o odblokowanie zabezpieczeń i uzyskanie administracyjnego dostępu do całego systemu plików na flash'u w telefonie (artykuł jest osobno). Praca pod linux'em Ja należę do grona linux'iarzy, którzy na co dzień korzystają z alternatywnych systemów operacyjnych. Niby zainstalowany w Neffos'ie C5 Android to również linux ale Android Androidowi nie jest równy i niektóre modele smartfonów mają jakieś dziwne problemy po podłączeniu ich do komputera z pełnowymiarowym pingwinem na pokładzie. Na szczęście z tym telefonem nie ma praktycznie żadnych problemów. Póki co biblioteka libmtp (v1.1.12) jeszcze nie rozpoznaje Neffos'a C5 ale wkrótce to się powinno zmienić. Niemniej jednak, system plików telefonu można zamontować za pomocą jmtpfs i bez trudu wymieniać dane z Androidem po USB. Transfer plików jest na poziomie 6-8 MiB/s. Podsumowanie Przeglądając znalezione na necie opinie użytkowników/recenzentów tego smartfona Neffos C5, nie wiem czemu spora część ludzi narzeka na ten telefon. Ma on praktycznie wszystkie potrzebne człowiekowi rzeczy. Pod pewnymi względami faktycznie mogłoby być lepiej (dopracowany dźwięk i aparat, wystarczy ten tylny). Jednym z zarzutów pod adresem Neffos'a C5 jest problem z grami. Nie wiem dlaczego ktoś w ogóle chciałby brać to pod uwagę. Komfort grania na stacjonarnym PC w full-mega HD z gamingową klawiaturą/myszą oraz z dźwiękiem 10.1 wyszedł już z mody? Na dobrą sprawę to nie wiem czemu taki smartfon zbiera baty za to, że na nim tną się gry. Mi to kompletnie nie przeszkadza, ale ja to w końcu linux'iarz, a my w gry przecie nie gramy. Innym zarzutem, który pada w komentarzach jest jakoś wykonania tego telefonu. No fakt, Neffos C5 nie jest zrobiony ze stali nierdzewnej i do tego nie ma totalnego ogumienia, dzięki któremu byłby w stanie wyjść bez szwanku puszczony w swobodnym spadku gdzieś z orbity. Ale czy na pewno tego typu ficzery są nam potrzebne? To jest przecie ogromny koszt, a do rzucania nadają się przecie o wiele lepiej inne rzeczy. Nie wiem czemu te dwa powyższe elementy są topowe pod względem wymienianych wad pod adresem tego smartfona. Dla mnie liczy się niezawodność sprzętu, jego funkcjonalność oraz zdolność realizowania powierzonych mu zadań, a pod tym względem nie mam Neffos'owi C5 prawie nic do zarzucenia.
  4. Jeszcze nie tak dawno temu ludzkość była w stanie obejść się bez komputera, a dzisiaj raczej już wszyscy mamy z nim styczność w większym lub mniejszym stopniu. Spora część osób nawet sobie tego faktu nie uświadamia mając jednocześnie w kieszeni smartfona czy jakiś inny telefon, a przecie te urządzenia są w zasadzie komputerami, tylko nieco mniejszymi w porównaniu do desktopowych odpowiedników. Na dobrą sprawę to właśnie dzięki tym sprzętom jesteśmy w stanie komunikować się z osobami na drugim końcu świata prawie w czasie rzeczywistym. Jakby wyglądał nasz świat bez tych malutkich i niepozornych stworzeń informatycznych, które towarzyszą nam w codziennym życiu praktycznie non stop? Na to pytanie raczej każdy z nas musi sobie sam udzielić odpowiedzi, bo ta technologia niekoniecznie zmieniła otaczającą nas rzeczywistość w stopniu jednakowym dla nas wszystkich. Niemniej jednak, rozwój technologiczny ciągle postępuje i obecnie mamy na rynku smartfony 4 czy nawet 8 rdzeniowe wyposażone w 2-4 GiB RAM. Jakiś czas temu byłem w stanie przetestować smartfon Neffos C5 od TP-LINK, który miał właśnie 4 rdzenie i 2 GiB pamięci operacyjnej. Niemniej jednak, ten producent ma również w ofercie i inne modele telefonów, min. Neffos C5 MAX (TP702A), który również trafił w moje łapki. Postanowiłem zatem go poddać testom i sprawdzić czy jest on w stanie zadowolić takiego wybrednego linux'iarza jak ja. Zawartość opakowania Opakowanie, w którym dotarł do mnie Neffos C5 MAX, jest raczej standardowe jak na pudełko skrywające w środku smartfon i bardzo podobne do tego, które miał Neffos C5, z tym, że nieco większe. Poniżej zaś znajduje się cała zawartość opakowania: Poza samym smartfonem, w zestawie mamy również słuchawki z wtykiem minijack 3,5 mm: Jest też ładowarka 2A/5V: Jak i również standardowy przewód USB, przy pomocy którego możemy podłączyć smartfon do ładowarki jak i bezpośrednio do portu USB komputera. Specyfikacja Neffos C5 MAX Ten model Neffos'a C5 MAX, który do mnie dotarł jest w kolorze białym, choć są również i czarne/grafitowe. Dla mnie kolor nie ma większego znaczenia o ile urządzenie działa i realizuje powierzone mu funkcje bez zarzutu. Sam smartfon jest za do dość sporych rozmiarów (wy/sz/gr): 152x76x9 mm. Jak dla mnie, to jest on trochę za duży. Dla porównania Neffos C5 idealnie leżał w mojej łapce. Z kolei waga Neffos'a C5 MAX to około 160 gramów. Obudowa i jej wnętrze Obudowa smartfona Neffos C5 MAX jest generalnie z plastiku. Na lewej krawędzi nie ma umiejscowionych żadnych przycisków czy gniazdek, za to na prawej krawędzi znajduje się przycisk głośności (VolumeUp i VolumeDown) oraz przycisk zasilania (Power). W dolnym rogu mamy lekkie wcięcie umożliwiające łatwe otworzenie obudowy telefonu: Na górnej krawędzi smartfona mamy zaś jedynie gniazdko słuchawkowe: Za to na dolnej krawędzi jest standardowo port mikro USB oraz mikrofon do rozmów telefonicznych: Jeśli zaś chodzi o przód smartfona, to większość zajmuje naturalnie wyświetlacz. Przy górnej krawędzi mamy zaś (patrząc od lewej strony) czujnik światła, głośnik oraz aparat przedni 5 mpix (2560x1920 px fotki, 640x480 px video). Między głośnikiem, a aparatem jest również czerwona/zielona dioda powiadomień. Z tyłu Neffos'a C5 MAX mamy z kolei aparat 13 mpix (3120x4160 px fotki, 1920x1080 px video) z przysłoną f/2.0 . Z lewej strony aparatu mamy zaś dwie diody robiące za lampę błyskową jak i za latarkę. Nad aparatem został zaś ulokowany mikrofon z redukcją szumu. Ten tylny aparat jest w moim odczuciu sporo lepszy w porównaniu do tego, który jest w Neffos C5. Chodzi generalnie o jakość fotek czy filmów robionych przy słabym oświetleniu. Neffos C5 MAX radzi sobie z tym zadaniem o wiele lepiej. Niemniej jednak przedni aparat nie zachwyca, a video w 640x480 px nie przekracza progów moich minimalnych standardów. Generalnie to ja bym się nie obraził, gdyby tego aparatu przedniego zabrakło, bo użytek z niego nie jest zbyt wielki. Niżej przy dolnej krawędzi obudowy mamy dziurki na głośnik multimedialny: Wewnątrz obudowy znajdziemy za to baterię 3045 mAh. Niestety jest to wbudowana bateria i nie damy rady jej wyciągnąć i ewentualnie sami wymienić, gdy zajdzie taka potrzeba. Na plus za to można zaliczyć umiejscowienie slotów oraz karty SIM i kartę mikro SD (max. 32 GiB). Karty nie są blokowane w żaden sposób i można je bez problemu usnąć bez potrzeby wyłączania telefonu. Może nie jest ten zabieg zalecany w przypadku kart SIM ale jest to bardzo użyteczna właściwość w przypadku karty SD, którą można ręcznie odmontować w systemie i wyciągnąć bez uszkadzania zgromadzonych na niej danych. Wyświetlacz IPS 5,5" Neffos C5 MAX dysponuje wyświetlaczem IPS (In-Plane Switching) 5,5 cala o rozdzielczości 1920x1080 px chroniony szkłem Corning Gorilla. Ilość punktów na cal (PPI) to 403, co przekracza minimalne 300, przy których ludzkie oko może lekko się buntować patrząc na ekran, zwłaszcza podczas czytania tekstu. Czcionki są ostre i raczej nie mam im nic do zarzucenia. Jeśli zaś chodzi o kolory i kąty widzenia, to nie ma przekłamań kolorów przy spoglądaniu na telefon nawet pod dość ostrymi kątami. Kontrast (1600:1) jak i jasność ekranu również jest bardzo zadowalająca. Nie mogę złego słowa powiedzieć o maksymalnej jasność i raczej nie powinniśmy mieć problemów z operowaniem na smartfonie w bardzo słoneczne dni w środku lata. Niemniej jednak, minimalna jasność mogłaby być nieco niższa, tj. ekran mógłby być nieco ciemniejszy, bo w nocy jednak idzie odczuć lekki dyskomfort. Automatyczne dostosowanie jasności działa z lekkim opóźnieniem ale jest płynne. Pasywny Dual SIM To co jest standardem w przypadku telefonów produkowanych przez TP-LINK, to fakt implementacji dual SIM w każdym modelu smartfona, który został przez tego producenta wypuszczony na rynek. Każdy z tych SIM'ów może być 2G/3G/4G. Ja akurat bardzo cenię sobie to rozwiązanie, bo korzystam z niego non stop i chyba nie zaprzestanę, zwłaszcza po ostatnich doniesieniach w sprawie darmowego internetu Aero2, który będzie działał jeszcze co najmniej trzy lata. Mając dual SIM w smartfonie, mam również i darmowy internet. Choć jakby nie patrzeć brakuje mi jeszcze jednego gniazdka na dodatkowy SIM, także chciałbym się doczekać Neffos'a oferującego triple SIM (albo może i quad SIM). Może to dla wielu ludzi wydawać się dziwne ale dla zagorzałego zwolennika prepaidów, posiadanie karty SIM u kilku operatorów GSM jest wielce praktyczne i znacząco obniża koszty rozmów. Procesor MTK MT6753 (8 rdzeni) Smartfon Neffos C5 MAX jest póki co najmocniejszym smartfonem TP-LINK'a dostępnym na polskim runku. To co najbardziej wyróżnia ten telefon od pozostałych modeli tego producenta, to fakt zastosowania w nim 64-bitowego procesora MediaTek MTK MT6753 (datasheet), który włada 8 rdzeniami opartymi na architekturze ARM Cortex-A53 taktowanymi dynamicznie zegarem od 300 MHz do 1,3 GHz. Układ graficzny, który został zastosowany w tym smartfonie to ARM Mali-T720 MP3 taktowany zegarem 450 MHz będący w stanie obsłużyć wyświetlacz w rozdzielczości 1280 x 1920 pikseli (FHD) oraz nagrywać i odtwarzać materiały wideo w rozdzielczości maksymalnej 1080p przy 30 FPS'ach. Procesor graficzny posiada także wsparcie dla API takich standardów jak OpenGL ES 1.1/2.0/3.0, OpenCL 1.0/1.1/1.2 oraz DirectX9. Proces technologiczny tego SoC'a to 28 nm. Pamięć RAM i flash Podobnie jak i w przypadku dual SIM, dla mnie standardem jest również stosowanie w obecnych smartfonach 2 GiB pamięci operacyjnej RAM. Raczej bym się nie odważył na zakup telefonu z Androidem w wersji 5, 6 czy 7, który ma mniej niż 2 GiB RAM. Jest bowiem spore prawdopodobieństwo, że taki system nie będzie działał płynnie. Na szczęście Neffos C5 MAX spełnia moje minimalne wymagania w zakresie dostępnej pamięci operacyjnej, tj. ma 2 GiB, z czego około 500 MiB jest używane przez system i wbudowane aplikacje: Jeśli zaś chodzi o pamięć flash Neffos'a C5 MAX, to dysponuje on 16 GiB. Niemnie jednak, do dyspozycji użytkownika jest około 10 GiB. Nie wiem czemu TP-LINK tak marnotrawi miejsce w tych smartfonach z serii Cx. Jak się popatrzy na układ partycji na flash tych modeli telefonów, to partycja /system/ ma 4 GiB. Z czego obraz ROM'u zajmuje około połowy. Zatem bez przeprowadzenia procesu root Androida, to miejsce pozostanie niewykorzystane i na dzień dobry tracimy prawie 2 GiB, z których 3/4 można by z powodzeniem dodać do partycji /data/ , tj. na dane użytkownika. To marnotrawstwo jakże cennego miejsca na pamięci flash smartfona zdaje się być ograniczone w nowszych seriach Neffos'ów, dla przykładu Yx. W ich przypadku partycja /system/ jest troszeczkę większa niż sam ROM. W efekcie zamiast 10 GiB na dane, mamy około 12 GiB. Nie wiem czy da radę jakoś zaradzić tej sytuacji w przypadku Neffos'ów z serii Cx ale widziałem na necie możliwość przepartycjonowania flash'a smartfona. Jeśli uda mi się przeprowadzić taki proces z powodzeniem, to z pewnością podlinkuję go tutaj. Oczywiście nie obejdzie się bez ukorzeniania Androida. (FIXME) Bateria Jak widzieliśmy na jednej z powyższych fotek, w Neffos C5 MAX bateria jest niestety zamontowana na stałe. Niemniej jednak, ma te swoje 3000 mAh z lekkim hakiem. Jak wygląda sprawa ładowania baterii tego smartfona? Niby w zestawie jest dołączona ładowarka 2A/5V ale z tego co zauważyłem, to Neffos C5 MAX nie pobiera podczas ładowania więcej niż 0,92 A - 0,95 A. Dlaczego zatem TP-LINK dorzucił do zestawu taką ładowarkę? Dla kontrastu, w pozostałych modelach jest już ładowarka 1A/5V i w tym przypadku również by ona wystarczyła. Zostawmy może w spokoju sprawę samej ładowarki i przejdźmy do bardziej interesującej kwestii czyli do czasu ładowania tego smartfona 0% do 100%. Wygląda na to, że ten czas oscyluje w graniach 4 godzin, czyli jest to bardzo dużo. Wiemy zatem, że ten model nie wspiera szybkiego ładowania, a szkoda. Poniżej są wykresy z procesu ładowania: Jeśli zaś chodzi o rozładowanie baterii, to tutaj już sprawa wygląda dość przyzwoicie. Z szacunków Androida, w pełni naładowany Neffos C5 MAX będący w spoczynku rozładowuje się jakieś 22 dni. Jeśli zaś chodzi o rozładowanie baterii podczas używania telefonu, to ten czas ulega dość znacznemu skróceniu i wynosi około 8 godzin 20 i minut. Przynajmniej tyle zwrócił test wydajności przeprowadzany w PCMark dla Neffos C5 MAX. Głośnik i słuchawki Myślałem, że może ten wbudowany głośnik jest nieco lepszej jakości w Neffos C5 MAX w stosunku do Neffos C5 ale jednak mam wrażenie, że to dokładnie ten sam hardware i nie słyszę praktycznie żadnej różnicy w wydobywającym się dźwięku. Może i wielu użytkowników smartfonów traktuje te urządzenia jako zwykle telefony i uważa, że nie powinny one zbytnio wydawać z siebie żadnych odgłosów, a ewentualną muzykę lepiej słuchać przez słuchawki ale ja, gdy tylko mogę, to unikam stosowania słuchawek. Niemniej jednak, dźwięk w słuchawkach tych dołączonych do zestawu jest sporo lepszej jakości, choć też do najlepszych nie należy. Jeśli chodzi o dźwięk, to jednak bym oczekiwał czegoś więcej. Za to na plus mogę zaliczyć przesyłanie dźwięku przez protokół bluetooth. Czujniki Czujniki, w które został wyposażony Neffos C5 MAX, są raczej standardowe. Mamy tutaj akcelerometr, czujnik zbliżeniowy, czujnik światła no i magnetometr umożliwiający przerobienie smartfona na elektroniczny kompas: Niemniej jednak, brakuje mi tutaj żyroskopu, wysokościomierza, termometru, barometr no i oczywiście licznika Geigera. To tak na wypadek apokalipsy zombi. Może przesadzam ale ten licznik Geigera bardzo by mi się przydał. Łączność 2G/3G/LTE Neffos C5 MAX zalicza się do tej grupy smartfonów, które mają wbudowany modem LTE kategorii 4 (Cat4). Teoretycznie jesteśmy w stanie osiągnąć transfer na poziomie 150/50 mbit/s (download/upload), a jak wygląda realna prędkość? Muszę przyznać, że trochę się zdziwiłem: W sumie nigdy wcześniej się nie zbliżyłem do 100 mbit/s po LTE ale najwyraźniej mój operator GSM poprawił nieco swoją infrastrukturę sieci w okolicy. Ten modem obsługuje standardowe europejskie pasma częstotliwości dla LTE w technologi FDD, kanały B1/B3/B7/B8/B20 (2100/1800/2600/900/800 MHz). Neffos C5 Max jest także w stanie obsługiwać standardy DC-HSPA+/HSPA/UMTS: B1/B8(2100/900 MHz) oraz EDGE/GPRS/GSM: 850/900/1800/1900 MHz. WiFi 2,4 GHz Podobnie jak i bez LTE, szanujący się smartfon nie może się obejść bez WiFi. Neffos C5 MAX może i posiada obsługę WiFi ale jedynie w paśmie 2,4 GHz, a wiemy, że to pasmo jest ździebko zapchane. Obecnie dla mnie standardem jest obsługa sieć WiFi w paśmie 5 GHz. Bezprzewodowe routery oferujące takie połączenia są już praktycznie w zasięgu każdej osoby. Dlatego też uważam, że WiFi 5 GHz powinno w smartfonie się znaleźć. Ten nadajnik WiFi, który jest w Neffos'ie C5 MAX, obsługuje standard N do 150 mbit/s, czyli pojedynczy strumień przestrzenny. Transfer jaki udało mi się uzyskać za pomocą tego telefonu po WiFi oscylował w granicach 100 mbit/s, czyli mniej więcej standardowo. Jeśli zaś chodzi o zasięg WiFi, to też jest on raczej przeciętny. Poniżej jest fotka moich trzech AP rozmieszczonych po domu w różnych pomieszczeniach. Kanał 11 obrazuje siłę sygnału docierającą do smartfona z AP zlokalizowanego w tym samym pokoju. Na kanale 6 jest AP w odległości około 4 metrów + ściana. Na kanale 1 jest AP w odległości 6 metrów + trzy ściany: Udostępnianie połączenia 3G/LTE oraz WiFi (tethering) Neffos C5 MAX wspiera naturalnie tethering, czyli możliwość udostępniania połączenia internetowego (3G/LTE) komputerom podłączonym do smartfona po WiFi. Jest też możliwość udostępnienia połączenia WiFi, jeśli komputer podepniemy do portu mikro USB w telefonie. Raczej nie powinno być problemów z podłączeniem się do AP, który skonfigurujemy sobie na smartfonie. Niemniej jednak, z tego co obserwuję, to w Neffos'ach ESSID sieci WiFi zawiera spacje. Spacje w nazwach sieci są znane z tego, że powodują problemy z połączeniem. Zatem jeśli dane logowania do sieci podaliśmy prawidłowe ale nie możemy nawiązać połączenia, to zmieńmy sobie nazwę sieci WiFi na taką bez spacji. Jeśli chodzi zaś o udostępnianie połączenia via USB, to na linux działa ono bez większego problemu. Poniżej jest log z mojego Debiana po podpięciu Neffos'a C5 MAX do portu USB komputera i przełączeniu telefonu w tryb tethering'u: kernel: usb 2-1.1: new high-speed USB device number 8 using ehci-pci kernel: usb 2-1.1: New USB device found, idVendor=2357, idProduct=031e kernel: usb 2-1.1: New USB device strings: Mfr=2, Product=3, SerialNumber=4 kernel: usb 2-1.1: Product: Neffos kernel: usb 2-1.1: Manufacturer: TP-LINK kernel: usb 2-1.1: SerialNumber: 8HCMMZFI89ROBI9H kernel: usbcore: registered new interface driver cdc_ether kernel: rndis_host 2-1.1:1.0 usb0: register 'rndis_host' at usb-0000:00:1d.0-1.1, RNDIS device, 26:fa:ce:b5:72:9d kernel: usbcore: registered new interface driver rndis_host Jedne co musimy zrobić, to skonfigurować adresację IP na interfejsie usb0 . Warto jeszcze tutaj zaznaczyć, że funkcja Turbo Pobieranie (o tym za moment) nie działa, gdy tethering jest aktywny. Bluetooth v4.0 (LE) W Neffos C5 MAX nie mogło zabraknąć również Bluetooth w wersji 4.0. Może nie jest to najnowsza wersja tego standardu ale najważniejsze, że mamy tutaj do czynienia z technologią Low Energy (LE), czyli w zamian za obniżony transfer danych, moduł bluetooth konsumuje o wiele mniej energii, co wydłuża czas pracy na baterii. A-GPS oraz GLONASS Korzystanie z analogowych map i kompasów raczej wychodzi z mody. Może warto jest mieć taki przeżytek jako backup na wypadek jakiegoś globalnego kataklizmu ale o wiele większe korzyści i komfort użytkowania daje nawigacja satelitarna, którą możemy mieć w telefonie o ile ten ma nadajnik GPS. Na szczęście Neffos C5 MAX takowe urządzenie również posiada. Ten smartfon wpiera takżę mechanizm A-GPS (Assisted GPS) oraz GLONASS (Globalnaja Nawigacionnaja Sputnikowaja Sistiema). A-GPS to system znacznie skracający czas potrzebny na pierwsze ustalenie położenia w systemie GPS (połączenie z satelitami). System ten wykorzystuje do działania serwery operatorów sieci GSM, przez co operator sieci komórkowej musi wspierać taką usługę. W przeciwnym razie będziemy mieli do dyspozycji jedynie zwykły GPS. GLONASS, z kolei to radziecki/rosyjski system nawigacyjny. To taka alternatywa dla amerykańskiego systemu GPS. Połączenie GPS i GLONASS daje możliwość bardzo akuratnych pomiarów, co przekłada się na szybsze i dokładniejsze ustalenie pozycji w terenie. Tu jeszcze tylko taka informacja, że Neffos C5 MAX ma wspólną antenę dla 2.4 GHz WiFi, 2.4 GHz Bluetooth i 1.575 GHz GPS. Radio FM Z radiem jest dokładnie taka sama sytuacja co w przypadku GPS. Mając internet raczej nie potrzebujemy już takiego wynalazku jak Radio FM, no bo przecie każda szanująca się rozgłośnia radiowa nadaje strumień w internecie, a mając dostęp do WiFi czy LTE/3G możemy bez problemu sobie dowolną stację włączyć i nie musimy przy tym się ograniczać do lokalnych stacji radiowych. Niemniej jednak, w przypadku cenzury, czy też na wypadek wojny, raczej internet zostanie zablokowany i dobrze jest mieć w zapasie zwykły odbiornik FM tak, by wiedzieć co się w świecie dzieje. By korzystać z tego radia trzeba mieć podłączone słuchawki, choć dźwięk można przesłać bezpośrednio na głośnik. OTG OTG to mechanizm umożliwiający podłączenie do portu mikro USB w smartfonie zewnętrznej klawiatury, myszy, dysku twardego, pendrive i innych tego typu urządzeń. Neffos C5 MAX jest póki co jedynym modelem, który wspiera OTG, choć w zestawie nie było dołączonego odpowiedniego adaptera. Generalnie taki przewód OTG nie jest drogi ale są dwie wersje. Ta bardziej ficzerzasta umożliwia dostarczenie zewnętrznego zasilania do podłączanych do smartfona urządzeń. Jeśli dysponujemy jedynie zwykłym adapterem, to taka klawiatura czy mysz jest zasilana przez smartfon. Ja akurat posiadam tylko zwykł kawałek przewodu ale mam też aktywny HUB USB 3.0 UH720, który może robić w roli zasilacza. Może i Neffos C5 MAX ma wsparcie dla OTG ale jest ono niepełne. Sprzęt taki jak klawiatura czy mysz będzie nam bez problemu na tym smartfonie działać, nawet bez dodatkowego zasilania ale już nie damy rady podłączyć dysku czy pendrive. Choć na dobrą sprawę nie wiem czemu, teoretycznie dioda na pendrive miga po podłączeniu do smartfona ale ten nie rozpoznaje urządzenia. Wygląda zatem na to, że brakuje w systemie jakiegoś modułu. Jestem zdania, że po ukorzenieniu Androida da radę obsługę zewnętrznych dysków włączyć, choć do końca jeszcze nie wiem jak ale jeśli będzie to możliwe to z pewnością to zrobię i podlinkuję tutaj stosowny artykuł. (FIXME) Turbo Pobieranie Kolejną ciekawą rzeczą, którą odróżnia smartfon Neffos C5 MAX od pozostałych modeli, to fakt wspierania czegoś co się nazywa Turbo Pobieranie. Standardowo w smartfonach z internetu możemy korzystać albo za sprawą domowego połączenia WiFi, albo też bezpośrednio przez łącze operatora GSM (dane pakietowe). Turbo Pobieranie oferuje nam możliwość wykorzystania obu tych łącz przy pobieraniu dużych plików. Gdy ta opcja jest aktywna, część pliku jest pobierana przez WiFi, a część przez operatora GSM. Jeśli zatem transfer na WiFi mamy 50 mbit/s i na łączu operatora GSM również 50 mbit/s, to taki plik będzie się pobierał w sumie 100 mbit/s. Wykorzystanie obu łącz jest monitorowane w czasie rzeczywistym: Android 5.1 Lollipop Smartfonem Neffos C5 MAX zarządza Android w wersji 5.1 (Lollipop). Szkoda, że jeszcze nie doczekaliśmy się aktualizacji do wersji 6.0. Nie wiem niestety czy i ewentualnie kiedy TP-LINK wypuści stosowny update. Niemniej jednak, ten system, który jest zainstalowany działa płynnie i nie mam mu praktycznie nic do zarzucenia. Komfort pracy na telefonie jest zadowalający. Smartfon się praktycznie nie grzeje i działa przyzwoicie. Jedyny minus to brak nowszej wersji systemu, no i może również fakt wykorzystywania oprogramowania FOTA od Adups, którego analiza wykazała, że przesyła ono prywatne informacje użytkowników gdzieś w świat. Poniżej jest zestawienie temperatur podczas standardowej pracy telefonu (po lewej) i przy 100% obciążeniu procesora (po prawej): Czy da radę przeprowadzić root na Neffos C5 MAX Proces ukorzeniania Androida na Neffos C5 MAX jest możliwy i jest on w miarę bezproblemowy. Opis jak przeprowadzić proces root smartfona Neffos C5 MAX jest dostępny tutaj. Jak Neffos C5 MAX sprawuje się pod linux Generalnie rzecz biorąc, Neffos C5 MAX nie sprawia problemów na linux'ie. Przynajmniej jeśli chodzi dystrybucję Debian, z której ja korzystam. Póki co biblioteka libmtp (v1.1.12) jeszcze nie rozpoznaje Neffos'a C5 MAX ale wkrótce to się powinno zmienić, bo odpowiednie zgłoszenie do developerów już posłałem. System plików telefonu można zamontować za pomocą jmtpfs i bez trudu można wymieniać dane z Androidem po USB. Transfer plików jest na poziomie 6-8 MiB/s. Podsumowanie Nie mam zbytnio większych zastrzeżeń do Neffos'a C5 MAX. W gry nie gram, a nawet jakbym grał, to z pewnością nie zadowoliłby mnie nawet smartfon za xxxx dolców (w x podstawić dowolną cyfrę). Aparat tylny mógłby być nieco lepszy i jeśli chodzi o mnie, to bez problemu bym poszedł na kompromis zakładający usunięcie przedniego aparatu, by tylko ten z tyłu smartfona robił zdjęcia w jeszcze lepszej jakości. Podoba mi się funkcja Turbo Pobierania jak i OTG. Skoda tylko, że OTG nie wspiera dysków czy pendrive. Najbardziej jednak mi się we znaki daje nie za dobra jakość dźwięku z głośnika no i brak WiFi 5 GHz. Gdyby te powyższe rzeczy poprawić, to w może w końcu trafię na niedrogi smartfon spełniający wszystkie moje oczekiwania.
  5. Analizując sobie fabryczny podział przestrzeni flash w TP-LINK'owych smartfonach, a konkretnie w modelach Neffos C5 i C5 MAX, doszedłem do wniosku, że producent tych urządzeń nieco zaszalał przeznaczając aż 4 GiB przestrzeni na partycję /system/ . W zasadzie ROM w tych telefonach zajmuje około 2 GiB. Zatem pozostałe 2 GiB zwyczajnie się marnuje i przeciętny użytkownik smartfona nie będzie w stanie tego obszaru w żaden sposób wykorzystać. Można by zatem inaczej przepartycjonować ten flash, tak by nieco skurczyć samą partycję /system/ , przeznaczając jednocześnie odzyskane miejsce na powiększenie partycji /data/ . W tym wpisie postaramy się właśnie taki zabieg zmiany rozmiaru partycji /system/ przeprowadzić dla tych dwóch wyżej wymienionych modeli smartfonów. Czy zmieniać układ flash'a na smartfonie Zarówno Neffos C5 jak i Neffos C5 MAX dysponują flash'em 16 GiB. Jak wspomniane zostało we wstępie, 4 GiB z tej przestrzeni jest zarezerwowane na partycję /system/ . Rzadko się jednak zdarzy tak, że stock'owy ROM TP-LINK'a będzie tyle zajmował. W zasadzie to raczej jest bardzo małe prawdopodobieństwo, że rozmiar tego ROM'u przekroczy 2,5 GiB. Możemy zatem spokojnie wykroić 1,5 GiB z tej partycji i mieć więcej miejsca na dane użytkownika, np. zdjęcia czy filmy. Oczywiście partycji /system/ nie można przyciąć za bardzo. Nawet jeśli wykroimy sobie dokładnie tyle miejsca, by zmieścił się nam na tej partycji stock'owy ROM, to w dalszym ciągu cześć aplikacji wymagających uprawnień root może chcieć zapisywać pewne informacje na partycji /system/ . Jeśli te programiki nie będą w stanie tego uczynić, to może to doprowadzić do niestabilności systemu, czy nawet problemów z uruchomieniem się Androida. Trzeba zatem zostawić trochę miejsca ale znowu bez przesady. Musimy także liczyć się z powiększeniem ROM'u po ewentualnych aktualizacjach, które będziemy w stanie pobrać via OTA Update. Te aktualizacje nie są duże, a sam ROM od nich zwykle nie tyje ale w przypadku gdyby TP-LINK wypuścił aktualizację Androida z Lollipop do Marshmallow, to już zmiana w rozmiarze ROM'u może być widoczna. W dalszym jednak ciągu uważam, że przeznaczenie 4 GiB na partycję /system/ to szaleństwo i przydałoby się nieco zoptymalizować podział flash'a. Fabryczny układ flash'a w Neffos C5 i Neffos C5 MAX Zacznijmy może od fabrycznego układu flash'a w Neffos C5 i C5 MAX. Układ w tych dwóch modelach jest bardzo podobny ale nie jest dokładnie taki sam. W zasadzie ta rzecz, która nas interesuje zdaje się być stała. Chodzi o kolejność partycji. W przypadku tych dwóch smartfonów, partycja /system/ na numer 20, partycja /cache/ ma numer 21, a partycja /data/ ma numer 22. Zatem mamy trzy partycje jedna po drugiej, które musimy usunąć i stworzyć na nowo. Telefon po usunięciu tych trzech partycji powinien się nam uruchomić bez problemu, choć z oczywistych względów nie załaduje nam systemu. Użytkowników smartfonów Neffos Y5 i Y5L, którzy zastanawiają się dlaczego nie opisuję w tym artykule również i tych dwóch urządzeń, informuję, że układ flash'a w tych dwóch telefonach znacznie się różni w stosunku do tego, z którym mamy do czynienia w Neffos C5 i C5 MAX. W przypadku Y5 i Y5L trzeba usunąć 9 z 29 partycji wliczając w to partycję /recovery/ . Istnieje zatem podwyższone ryzyko uwalenia telefonu na dobre, a biorąc pod uwagę, że przeprowadzane kroki i tak będą się różniły, to postanowiłem nie mieszać wszystkich czterech urządzeń i zrobić 2 osobne artykuły. Poniżej jest fotka obrazująca układ flash'a dla smartfona Neffos C5. Tworzenie nowego układu partycji na flash'u smartfona Wiemy zatem, że mamy usunąć trzy partycje: /system/ , /cache/ oraz /data/ . Problem w tym, że by usunąć partycję z flash'a smartfona, potrzebne nam są prawa administratora root. Nie koniecznie musimy przeprowadzać proces ukorzeniania Androida. Wystarczy wgrać na telefon obraz TWRP recovery, czy to przy pomocy fastboot , czy też via SP Flash Tool. Mając wgrany TWRP, odpalamy telefon w trybie recovery (przyciski VolUp+Power). Będąc w trybie recovery, podłączamy smartfon do portu USB komputera, na którym to uruchamiamy terminal i wpisujemy poniższe polecenie: # adb shell ~ # To polecenie zapewni nam dostęp root i będziemy mogli bardziej swobodnie operować na smartfonie przy pomocy naszego komputera. Backup tablicy partycji do pliku Zanim cokolwiek zaczniemy zmieniać w układzie partycji na flash'u smartfona, zróbmy sobie kopię tablicy partycji i zapiszmy ją w pliku gdzieś na karcie SD. Nie zapisujmy tego pliku w pamięci telefonu, bo jak coś uszkodzimy w układzie partycji, to nie będziemy mieć dostępu do backup'u. Backup tablicy partycji robimy w poniższy sposób: ~ # sgdisk --backup=/sdcard1/backup-partition-table /dev/block/mmcblk0 Jak usunąć partycje /system/ , /cache/ i /data/ Mając backup tablicy partycji, możemy przystąpić do usuwania wpisów z tej tablicy. Przed usunięciem jakiekolwiek partycji, trzeba ją pierw odmontować. Wpiszmy zatem w terminalu te poniższe polecenia: ~ # umount /cache ~ # umount /data ~ # umount /sdcard ~ # umount /system Teraz możemy usunąć te trzy partycje przy pomocy narzędzia sgdisk w poniższy sposób: ~ # sgdisk --delete=20 /dev/block/mmcblk0 ~ # sgdisk --delete=21 /dev/block/mmcblk0 ~ # sgdisk --delete=22 /dev/block/mmcblk0 Jak zmienić rozmiar partycji /system/ , /cache/ i /data/ Teraz tworzymy na nowo partycję /system/ , zaraz za partycją numer 19. Musimy określić trzy wartości. Numer tworzonej partycji, sektor początkowy oraz rozmiar partycji. Numer jest znany, tj. 20. Rozmiar też znamy, np. 2,5 GiB. Jak określić początek tej partycji? Możemy go wywnioskować z wyjścia poniższego polecenia: ~ # sgdisk --print /dev/block/mmcblk0 Number Start (sector) End (sector) Size Code Name ... 19 284672 360447 37.0 MiB 0700 metadata ... Ta partycja numer 19 była przed partycją /system/ . Widzimy, że mamy określony w tam końcowy sektor, tj. 360447 . Następna partycja ma zaczynać się na sektorze o jeden większym, czyli 360448 . Rozmiar nowej partycji /system/ podajemy jako +2560M, czyli 2,5G. W terminalu zatem wpisujemy poniższe polecenie: ~ # sgdisk --new=20:360448:+2560M /dev/block/mmcblk0 Nadajemy jeszcze nazwę tej partycji: ~ # sgdisk --change-name=20:system /dev/block/mmcblk0 Powyższy krok z tworzeniem partycji i zmianą nazwy powtarzamy dla partycji /cache/ : ~ # sgdisk --new=21:5603328:+512M /dev/block/mmcblk0 ~ # sgdisk --change-name=21:cache /dev/block/mmcblk0 Podobnie postępujemy w przypadku partycji /data/ , z tym, że tutaj jako rozmiar partycji podajemy sektor początkowy ostatniej partycji odejmując od tej wartości 1: ~ # sgdisk --new=22:6651904:30501887 /dev/block/mmcblk0 ~ # sgdisk --change-name=22:userdata /dev/block/mmcblk0 Ustawiamy typy nowo utworzonych partycji na 0700 : ~ # sgdisk --typecode=20:0700 /dev/block/mmcblk0 ~ # sgdisk --typecode=21:0700 /dev/block/mmcblk0 ~ # sgdisk --typecode=22:0700 /dev/block/mmcblk0 Podejrzenie nowego układu flash'a Po utworzeniu nowych partycji i określeniu ich rozmiaru, nazw oraz typów sprawdzamy czy wszystko się zgadza: Jak widać, w tej chwili nasz smartfon ma około 11,5 GiB na partycji /data/ w stosunku do starych 10 GiB, czyli zysk na poziomie 15%. Formatowanie partycji Jeśli nowy układ partycji spełnia nasze oczekiwania, to wypadałoby teraz sformatować wszystkie trzy partycje systemem plików EXT4 przy pomocy narzędzia mke2fs : ~ # mke2fs -t ext4 /dev/block/mmcblk0p20 ~ # mke2fs -t ext4 /dev/block/mmcblk0p21 ~ # mke2fs -t ext4 /dev/block/mmcblk0p22 Montujemy te zasoby, czy to przy pomocy polecenia mount , czy też z GUI TWRP. Sprawdzamy też, czy te partycje zostały poprawnie zamontowane w systemie: ~ # mount | grep -i block /dev/block/mmcblk0p20 on /system type ext4 (rw,seclabel,relatime,data=ordered) /dev/block/mmcblk0p21 on /cache type ext4 (rw,seclabel,relatime,data=ordered) /dev/block/mmcblk0p22 on /data type ext4 (rw,seclabel,relatime,data=ordered) Powyższy wynik świadczy o tym, że repartycjonowanie flash'a w naszym smartfonie przebiegło z powodzeniem. Problemy z wgraniem systemu z pliku update.zip przez ADB Sideload Nasz smartfon w tej chwili nie ma jeszcze wgranego żadnego systemu operacyjnego. Musimy zatem jakoś ten system zainstalować. Opcji jest kilka. Najprostszym rozwiązaniem wydawałoby się postaranie się o plik update.zip i wgranie go via ADB Sideload z poziomu TWRP recovery. Plik z firmware można pobrać ze strony TP-LINK/Neffos, lub też z tego miejsca. Problem w tym, że tak łatwo nie będzie i wgranie systemu z pliku update.zip zakończy się niepowodzeniem. Z początku nie wiedziałem w czym rzecz. No bo przecież TP-LINK'owy ROM do Neffos C5 i C5 MAX ma około 2 GiB, a przy wgrywaniu go za pomocą ADB Sideload przez TWRP recovery, system wyrzuca informację o braku miejsca: sideload-host file size 993462838 block size 65536 Installing zip file '/sideload/package.zip' I:Update binary zip I:Zip contains SELinux file_contexts file in its root. Extracting to /file_contexts I:Legacy property environment initialized. ====== Updater-Script: getprop("ro.product.device") == "C5" || abort("This package is for \"C5\" devices; this is a \"" + getprop("ro.product.device") + "\"."); show_progress(0.750000, 0); ui_print("Patching system image unconditionally..."); block_image_update("system", package_extract_file("system.transfer.list"), "system.new.dat", "system.patch.dat"); show_progress(0.050000, 5); assert(package_extract_file("boot.img", "/tmp/boot.img"), write_raw_image("/tmp/boot.img", "bootimg"), delete("/tmp/boot.img")); assert(package_extract_file("mobicore.bin", "/tmp/tee1.img"), write_raw_image("/tmp/tee1.img", "tee1"), delete("/tmp/tee1.img")); show_progress(0.200000, 10); apply_sig(package_extract_file("sig/boot.sig"), "bootimg"); Patching system image unconditionally... blockimg version is 2 erasing 1048576 blocks blkdiscard failed: Invalid argument writing 521761 blocks of new data ioctl(): blank: Invalid argument write failed: No space left on device lseek64 failed: Invalid argument Updater process ended with ERROR: 1 I:Legacy property environment disabled. I:Install took 274 second(s). I:Signaling child sideload process to exit. I:Waiting for child sideload process to exit. sideload_host finished Postanowiłem poszukać informacji na ten temat i użytkownicy @maxprzemo oraz @piskorfa z forum.android.com.pl nakierowali mnie na właściwy trop. Okazuje się bowiem, że trzeba będzie się trochę napracować, by wgrać system ze stock'owego pliku update.zip . Rozchodzi się o to, że aktualizacja czy też instalacja systemu z pliku update.zip w Androidach począwszy od wersji 5.0 (Lollipop) wykorzystuje zapis blokowy. Ten mechanizm zatem będzie próbował wgrać na partycję /system/ obraz o pewnym określonym rozmiarze (w tym przypadku 4 GiB). Nie można więc skrócić tej partycji do 2,5 GiB, tak jak to zrobiliśmy wyżej, tzn. można ale by zainstalować system z pliku update.zip , trzeba go pierw przepakować i zmienić w nim informację dotyczącą rozmiaru obrazu z tych 4 GiB na 2,5 GiB. Przepakowanie stock'owego obrazu system.img z pliku update.zip Wiemy co mamy czynić, zatem do roboty. Przede wszystkim, musimy się zaopatrzyć w odpowiednie narzędzia. W repozytorium dystrybucji Debian znajduje się pakiet android-tools-fsutils . W nim zaś mamy narzędzia takie jakie make_ext4fs , img2simg oraz simg2img . Brakuje jednak dwóch narzędzi, których będziemy również potrzebować, tj. sdat2img oraz img2sdat. Trzeba te dwa skrypty dociągnąć z GitHub'a. Dokładna instrukcja przepakowania obrazu znajduje się na forum XDA. Poniżej zaś znajduje się skrócony zapis poszczególnych kroków. Wypakowanie zawartości pliku update.zip Na sam początek pobieramy ze strony TP-LINK/Neffos plik firmware dla Neffos C5 lub C5 MAX w zależności od tego, który z ww. modeli smartfona posiadamy. Ten plik trzeba wypakować. Zawartość tego pliku po wypakowaniu jest następująca: # tree -sh img img ├── [4.0K] META-INF │ ├── [1.5K] CERT.RSA │ ├── [1.2K] CERT.SF │ ├── [1.0K] MANIFEST.MF │ └── [4.0K] com │ ├── [4.0K] android │ │ ├── [ 129] metadata │ │ └── [1.4K] otacert │ └── [4.0K] google │ └── [4.0K] android │ ├── [564K] update-binary │ └── [ 738] updater-script ├── [7.2M] boot.img ├── [ 32K] file_contexts ├── [ 60K] mobicore.bin ├── [ 431] scatter.txt ├── [4.0K] sig │ ├── [ 256] boot.sig │ └── [ 256] recovery.sig ├── [2.0G] system.new.dat ├── [ 0] system.patch.dat ├── [ 778] system.transfer.list └── [ 1] type.txt 6 directories, 17 files Obraz partycji /system/ znajduje się w pliku system.new.dat . Ten plik, jak widzimy wyżej, zajmuje 2 GiB, a nie 4 GiB. Jest on zatem w jakiś sposób skompresowany i musimy go pierw zdekompresować. Dekompresja pliku system.new.dat do surowego obrazu EXT4 Do dekompresji pliku system.new.dat posłuży nam skrypt sdat2img.py . Przyjmuje on trzy argumenty, z których pierwszy to ścieżka do pliku system.transfer.list , drugi to ścieżka do pliku system.new.dat , z trzeci na nazwa surowego obrazu zawierającego już system plików EXT4, który zostanie utworzony. Wpisujemy zatem w terminal poniższe polecenie: $ ./sdat2img.py img/system.transfer.list img/system.new.dat system.img sdat2img binary - version: 1.0 Android Lollipop 5.1 detected! Skipping command erase... Copying 32770 blocks into position 0... Copying 2 blocks into position 33025... Copying 31996 blocks into position 33539... ... Copying 2 blocks into position 983040... Copying 2 blocks into position 1015808... Done! Output image: /media/Kabi/neffos/system.img Po chwili w katalogu roboczym powinniśmy ujrzeć plik system.img : # ls -al system.img -rw-r--r-- 1 root root 4.0G 2017-04-03 09:29:38 system.img Jak widać, z 2 GiB zrobiło nam się 4 GiB i to jest właśnie surowy obraz, który można wgrać na partycję /system/ , gdy ta ma rozmiar 4 GiB. My ten rozmiar zmieniliśmy do 2,5 GiB i dlatego trzeba ten obraz nieco przyciąć. Tworzenie surowego obrazu EXT4 o mniejszym rozmiarze Musimy teraz wydobyć pliki ze starego obrazu i z nich wygenerować nowy surowy obraz EXT4. Wobec tego montujemy ten powyższy plik system.img w jakimś katalogu: # mount -t ext4 -o loop system.img /mnt Przy pomocy narzędzia make_ext4fs tworzymy obraz o określonym rozmiarze z zawartości katalogu, do którego podmontowaliśmy wcześniej obrazu system.img : # make_ext4fs -T 0 -S img/file_contexts -l 2684354560 -a system system_new.img /mnt/ Creating filesystem with parameters: Size: 2684354560 Block size: 4096 Blocks per group: 32768 Inodes per group: 8192 Inode size: 256 Journal blocks: 10240 Label: Blocks: 655360 Block groups: 20 Reserved block group size: 159 Created filesystem with 2788/163840 inodes and 526016/655360 blocks W parametrze -S musimy podać ścieżkę do pliku file_contexts . Natomiast opcja -l odpowiada za rozmiar (w bajtach) nowo wygenerowanego obrazu (2,5 GiB). Po zakończeniu procesu pakowania powinniśmy otrzymać plik system_new.img o zmniejszonym rozmiarze: # ls -al system_new.img -rw-r--r-- 1 root root 2.5G 2017-04-03 00:30:59 system_new.img No i nasz obraz ma już taki rozmiar jaki chcemy. Ten plik jeszcze trzeba skompresować. Kompresja surowego obrazu EXT4 Przy pomocy narzędzia img2simg kompresujemy wyżej utworzony obraz systemu: # img2simg system_new.img system_new.img-sparse # ls -al system_new.img-sparse -rw-r--r-- 1 root root 2.0G 2017-04-03 09:43:00 system_new.img-sparse Konwersja do pliku DAT Tak powstały plik system_new.img-sparse trzeba jeszcze przekonwertować do formatu DAT. Do tego celu wykorzystamy skrypt img2sdat.py podając w argumencie ścieżkę do skompresowanego obrazu: # ./img2sdat/img2sdat.py system_new.img-sparse img2sdat binary - version: 1.2 1. Android Lollipop 5.0 2. Android Lollipop 5.1 3. Android Marshmallow 6.0 4. Android Nougat 7.0 Choose system version: 2 Total of 655360 4096-byte output blocks in 2605 input chunks. Generating digraph... Finding vertex sequence... Reversing backward edges... 0/0 dependencies (0.00%) were violated; 0 source blocks stashed. Improving vertex order... Reticulating splines... max stashed blocks: 0 (0 bytes), limit: Done! Output files: . W katalogu roboczym powinny zostać utworzone trzy nowe pliki: system.new.dat , system.patch.dat oraz system.transfer.list : # ls -al -rw-r--r-- 1 root root 2.0G 2017-04-03 09:54:11 system.new.dat -rw-r--r-- 1 root root 0 2017-04-03 09:54:11 system.patch.dat -rw-r--r-- 1 root root 43K 2017-04-03 09:54:11 system.transfer.list Tworzenie nowego pliku update.zip Te trzy pliki trzeba podmienić w katalogu z zawartością, która została wyodrębniona z pliku update.zip : # mv system.new.dat system.patch.dat system.transfer.list ./img/ Następnie całość trzeba spakować: # cd ./img/ # zip -r update.zip * adding: META-INF/ (stored 0%) adding: META-INF/CERT.RSA (deflated 25%) adding: META-INF/MANIFEST.MF (deflated 46%) adding: META-INF/com/ (stored 0%) adding: META-INF/com/google/ (stored 0%) adding: META-INF/com/google/android/ (stored 0%) adding: META-INF/com/google/android/update-binary (deflated 35%) adding: META-INF/com/google/android/updater-script (deflated 56%) adding: META-INF/com/android/ (stored 0%) adding: META-INF/com/android/metadata (deflated 6%) adding: META-INF/com/android/otacert (deflated 28%) adding: META-INF/CERT.SF (deflated 51%) adding: boot.img (deflated 0%) adding: file_contexts (deflated 80%) adding: mobicore.bin (deflated 57%) adding: scatter.txt (deflated 52%) adding: sig/ (stored 0%) adding: sig/recovery.sig (stored 0%) adding: sig/boot.sig (stored 0%) adding: system.new.dat (deflated 52%) adding: system.patch.dat (stored 0%) adding: system.transfer.list (deflated 71%) adding: type.txt (stored 0%) W ten sposób przygotowany plik update.zip nadaje się do wgrania przez ADB Sideload ale tylko i wyłącznie z poziomu TWRP. Chodzi o to, że firmware wypuszczany przez TP-LINK/Neffos jest podpisany w przeciwieństwie do naszej paczki: My nie możemy wykorzystać klucza, którym takie archiwum zostało podpisane i nasza paczka nie będzie honorowana przez mechanizm aktualizacji. Na szczęście w ustawieniach TWRP można pominąć weryfikację pliku ZIP i wgrać system bez względu na to czy firmware jest podpisany czy też i nie jest. Wgrywanie świeżego systemu na partycję /system/ Wracamy na smartfon i włączamy tryb ADB Sideload z menu TWRP (Advanced => ADB Sideload). W terminalu na komputerze zaś wydajemy poniższe polecenie: # adb sideload update.zip Total xfer: 1.00x Z logu TWRP możemy wyczytać, że ta operacja zakończyła się powodzeniem: sideload-host file size 995870531 block size 65536 Installing zip file '/sideload/package.zip' I:Update binary zip I:Zip contains SELinux file_contexts file in its root. Extracting to /file_contexts I:Legacy property environment initialized. ====== Updater-Script: getprop("ro.product.device") == "C5" || abort("This package is for \"C5\" devices; this is a \"" + getprop("ro.product.device") + "\"."); show_progress(0.750000, 0); ui_print("Patching system image unconditionally..."); block_image_update("system", package_extract_file("system.transfer.list"), "system.new.dat", "system.patch.dat"); show_progress(0.050000, 5); assert(package_extract_file("boot.img", "/tmp/boot.img"), write_raw_image("/tmp/boot.img", "bootimg"), delete("/tmp/boot.img")); assert(package_extract_file("mobicore.bin", "/tmp/tee1.img"), write_raw_image("/tmp/tee1.img", "tee1"), delete("/tmp/tee1.img")); show_progress(0.200000, 10); apply_sig(package_extract_file("sig/boot.sig"), "bootimg"); Patching system image unconditionally... blockimg version is 2 writing 512 blocks of new data writing 512 blocks of new data writing 512 blocks of new data ... zeroing 1024 blocks zeroing 1024 blocks zeroing 1024 blocks ... writing 512 blocks of new data writing 512 blocks of new data writing 512 blocks of new data ... wrote 655360 blocks; expected 655360 max alloc needed was 4096 kernel_page_cnt:3117 ramdisk_page_cnt:565 second_page_cnt:0 partion_end_offset:0x731800 script result was [pass] I:Updater process ended with RC=0 I:Legacy property environment disabled. I:Install took 357 second(s). I:Signaling child sideload process to exit. I:Waiting for child sideload process to exit. sideload_host finished Czyścimy cache i robimy Factory Reset, by potwierdzić, że z pozostałymi partycjami nie ma żadnych problemów: Cały proces ze zmianą układu flash'a w smartfonach Neffos C5 i C5 MAX nie był jakoś szczególnie skomplikowany ale takie przepakowywanie pliku update.zip nie należy do przyjemnych. Na dobrą sprawę, każdy plik update.zip z nowszym firmware wypuszczony przez TP-LINK/Neffos, który będziemy chcieli wgrać na smartfon przy pomocy ADB Sideload, musimy w powyższy sposób przepakować. Oczywiście aktualizacje OTA Update będą działać bez zarzutu ale w przypadku uszkodzenia w jakiś sposób systemu telefonu, warto taką przerobioną paczkę .zip posiadać. Alternatywna metoda na wgranie obrazu system.img Ponowne instalowanie systemu z wykorzystaniem mechanizmu ADB Sideload nie jest jednak jedynym rozwiązaniem, które możemy wykorzystać, by przywrócić system w telefonie. Ten sposób jest nieco prostszy ale opiera się na backup'ie stock'owej partycji /system/ , który można wykonać albo przez SP Flash Tool, albo też z poziomu TWRP recovery przy pomocy narzędzia dd . Niezależnie od sposobu, na dysku powinniśmy mieć surowy obraz partycji /system/ o rozmiarze 4 GiB. Rozmiar tego pliku trzeba przyciąć do 2,5 GiB i wgrać na smartfon. Jak przyciąć stock'owy obraz system.img Wyciągnijmy sobie najpierw obraz system.img z backup'u flash'a. Montujemy obraz przy pomocy poniższego polecenia (być może trzeba będzie dostosować moduł loop): # losetup /dev/loop0 tp-link-neffos-c5-orig.img Upewniamy się co do numeru partycji /system/ w tym obrazie: # gdisk -l tp-link-neffos-c5-orig.img | grep system 20 360448 8749055 4.0 GiB 0700 system Kopiujemy zawartość tej partycji na dysk przy pomocy dd : # dd if=/dev/loop0p20 of=./c5-p20-system.orig Sprawdzamy system plików pod kątem błędów i zmieniamy rozmiar systemu plików w obrazie na 2,5 GiB: # e2fsck -f c5-p20-system.orig # resize2fs -p c5-p20-system.orig 2560M resize2fs 1.43.4 (31-Jan-2017) Resizing the filesystem on c5-p20-system.orig to 655360 (4k) blocks. Begin pass 2 (max = 147513) Relocating blocks XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Begin pass 3 (max = 32) Scanning inode table XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX The filesystem on c5-p20-system.orig is now 655360 (4k) blocks long. Po zakończonym procesie, rozmiar pliku c5-p20-system.orig powinien wynosić 2,5 GiB: # ls -al c5-p20-system.orig -rw-r--r-- 1 morfik morfik 2.5G 2017-04-03 02:08:18 c5-p20-system.orig Ten obraz trzeba teraz załadować na smartfon, z tym, że jeśli chcemy do tego celu wykorzystać SP Flash Tool, to musimy odpowiednio przepisać sobie plik scatter.txt . Możemy też naturalnie ten obraz przesłać przez ADB na partycję /data/ i wgrać go przy pomocy dd na stosowne urządzenie blokowe. Sposób z SP Flash Tool jest nieco mniej inwazyjny, bo nie trzeba zapisywać dwa razy pamięci telefonu. Którą opcję wybierzemy, to już zależy w zasadzie tylko od nas. Wgrywanie przyciętego obrazu przez SP Flash Tool Narzędzie SP Flash Tool operuje na pliku scatter.txt . Jeśli wykonaliśmy backup flash'a przy pomocy tego oprogramowania, to powinniśmy mieć ten plik. Niestety nie możemy go wykorzystać w momencie, gdy zmieniamy układ partycji na flash. W zasadzie, to musimy w tym pliku przepisać pozycje odpowiadające za opis partycji /system/ , /cache/ oraz /data/ , bo to one uległy zmianie. Przepisujemy te pozycje do poniższej postaci (zawsze możemy pomagać sobie plikiem /proc/partinfo ): ... - partition_index: SYS21 partition_name: system file_name: is_download: true type: EXT4_IMG linear_start_addr: 0xb000000 physical_start_addr: 0xb000000 partition_size: 0xa0000000 region: EMMC_USER storage: HW_STORAGE_EMMC boundary_check: true is_reserved: false operation_type: UPDATE reserve: 0x00 - partition_index: SYS22 partition_name: cache file_name: is_download: true type: EXT4_IMG linear_start_addr: 0xab000000 physical_start_addr: 0xab000000 partition_size: 0x20000000 region: EMMC_USER storage: HW_STORAGE_EMMC boundary_check: true is_reserved: false operation_type: UPDATE reserve: 0x00 - partition_index: SYS23 partition_name: userdata file_name: is_download: true type: EXT4_IMG linear_start_addr: 0xcb000000 physical_start_addr: 0xcb000000 partition_size: 0x2d7d80000 region: EMMC_USER storage: HW_STORAGE_EMMC boundary_check: true is_reserved: false operation_type: UPDATE reserve: 0x00 ... Zapisujemy plik scatter.txt i ładujemy go w SP Flash Tool. Wskazujemy także plik obrazu dla partycji /system/ no i oczywiście wciskamy przycisk "Download": Wgrywanie przyciętego obrazu przez TWRP recovery Odpalamy smartfon w trybie recovery (TWRP) i upewniamy się, że partycja /system/ nie jest zamontowana oraz, że partycja /data/ jest zamontowana. W terminalu na komputerze wpisujemy poniższe polecenie: # adb push c5-p20-system.orig /data/ Czekamy, aż plik zostanie przesłany. Następnie wgrywamy ten obraz na urządzenie blokowe odpowiadające za partycję /system/ : # adb shell ~ # dd if=/data/c5-p20-system.orig of=/dev/block/bootdevice/by-name/system 5242880+0 records in 5242880+0 records out 2684354560 bytes (2.5GB) copied, 530.597107 seconds, 4.8MB/s Sprawdzenie nowego układu partycji z poziomu Androida Po wgraniu systemu na smartfon dowolną metodą, restartujemy urządzenie. Telefon będzie się uruchamiał dłuższą chwilę ale ostatecznie powinniśmy zobaczyć ekran wyboru języka. Przechodzimy naturalnie przez proces wstępnej konfiguracji telefonu. Następnie sprawdzamy już tylko w ramach formalności czy system widzi poprawną ilość miejsca na partycji /system/ , /cache/ i /data/ , np. w aplikacji Diskinfo: Jak widać repartycjonowanie flash'a w smartfonach Neffos C5 i C5 MAX wyposażonych w system Android w wersji 5.1 (Lollipop) nie obyło się bez komplikacji. Grunt jednak, że smartfon nie ma problemów już z nowym układem flash'a, a my odzyskaliśmy 1,5 GiB, które możemy sobie dodatkowo przeznaczyć na dane użytkownika.
  6. Każdy z nas słyszał o alternatywnym firmware na bezprzewodowe routery WiFi. Mam tutaj na myśli oczywiście OpenWRT/LEDE oraz jego GUI Gargoyle i LUCI. Przy zabawach z takim oprogramowaniem bardzo łatwo jest uszkodzić router w sytuacji, gdy tak na dobrą sprawę nie wiemy co robimy. Mi się jeszcze nie zdarzyło ubić żadnej z moich maszyn, a mam ich kilka. Problem w tym, że tak naprawdę nie wiem jak wygląda proces odzyskiwania routera w przypadku zaistnienia takiego złego scenariusza. Dlatego też postanowiłem zainicjować zdarzenie, które doprowadziło do ubicia systemu w moim TL-WR1043ND V2 od TP-LINK. Co zrobić w takim przypadku, gdy system routera nie chce wystartować, a na obudowie diody sygnalizują nieprawidłową pracę urządzenia? W takiej sytuacji będziemy musieli rozebrać sprzęt i podłączyć się do portu szeregowego na PCB za pomocą adaptera USB-UART, najlepiej na układzie CP2102, który bez problemu działa pod linux. Ten artykuł nie powstałby (tak szybko), gdyby nie pomoc ze strony @Heinz. Jaki adapter USB-UART wybrać Przed przystąpieniem do procesu odzyskiwania władzy nad systemem routera, musimy się zaopatrzyć w odpowiednie narzędzia, które umożliwią na bardzo niskopoziomową komunikację z ubitym urządzeniem. Może i system takiego routera nie może się załadować ale jest duża szansa na to, że bootloader w dalszym ciągu pracuje prawidłowo (można to poznać po migających diodach), z tym, że z jakiegoś powodu nie może on uruchomić systemu. Jest wiele adapterów USB-UART, które możemy zakupić w sklepach internetowych. Co ciekawe, w fizycznych sklepach w ogóle o takich urządzeniach nie słyszeli (przynajmniej u mnie na wsi) i raczej pozostaje nam zakup zdalny. Cena takiego adaptera zamyka się w granicach 10-20 zł. Przy zakupie musimy brać pod uwagę jedną bardzo istotną rzecz. Chodzi o to, że standardowe napięcie w porcie USB komputera jest na poziomie 5 V. Te adaptery USB-UART na takim napięciu standardowo działają w przeciwieństwie do obwodu szeregowego w większości routerów. Nie możemy zatem się podłączyć do routera od tak. Jeśli ten obwód w naszym routerze jest zasilany innym napięciem, zwykle 3,3 V, to przed zakupem musimy się upewnić, że adapter USB-UART na pinach RX i TX będzie miał takie właśnie napięcie, ewentualnie będzie wyposażony w konwerter napięć. Patrząc na fotki urządzenia w sklepie możemy czasem na nich zobaczyć informacje o dwóch rodzajach napięć 3,3 V i 5 V. Popatrzmy na te poniższe adaptery USB-UART na układach CP2102: Na pierwszym adapterze konwerter napięć jest w postaci trzech padów i zespolenie dwóch z nich steruje napięciem. Na tym drugim zaś mamy nieco bardziej cywilizowane rozwiązanie, bo napięciem operujemy przy użyciu zworki. Niemniej jednak, w obu przypadkach sterujemy jedynie napięciem na pinie VCC, a nas interesują piny RX i TX. W przypadku adapterów na układzie CP2102 napięcie na pinach RX i TX jest zawsze takie samo i wynosi 3,3 V, zatem możemy zakupić dowolny adapter o ile jest on na tym właśnie układzie. Test napięcia w konwerterze USB-UART Jeśli nie jesteśmy pewni czy zakupiliśmy odpowiedni adapter USB-UART i nie chcemy spalić routera (czy tylko jego obwodu szeregowego), to zawsze możemy sprawdzić jakie napięcie na pinach RX/TX tego adaptera faktycznie jest. Do tego celu posłuży nam multimetr. Napięcie mierzymy między GND i RX lub TX. Powinniśmy uzyskać wskazanie na poziomie około 3,3 V, tak jak to widać na poniższej fotce: Jak widać z portu USB dostarczanych jest 5 V, a a między pinem GND i TX adaptera mamy już ~3,3 V. Możemy zatem bez obaw wykorzystać to urządzenie i wpiąć się do portu szeregowego routera. W tym przypadku położenie zworki nie ma żadnego znaczenia i wskazania są takie same nawet po jej usunięciu. W przypadku, gdyby zmiana położenia zworki dawała inne napięcia, to oczywiście wybieramy tę pozycję, która wskazuje 3,3 V. Warto też zaznaczyć, że oferty adapterów USB-UART znacznie się różnią pod względem dodatków, które dostajemy razem z adapterem. Zwykle kupujemy gołe urządzenie ale czasem też dorzucane są kolorowe kabelki albo też i goldpiny. Mi do jednego zestawu dorzucili kabelki, a drugiego trochę goldpinów: Jeśli jednak nabyliśmy taki adapter bez kabelków i goldpinów, to albo musimy dokupić je osobno, albo też zrobić je samemu. Port szeregowy routera (serial port) Port szeregowy znajduje się na płycie głównej routera. By się dostać do płyty, trzeba ściągnąć obudowę. Czasami nie jest to proste zadanie i trzeba poszukać odpowiedniej instrukcji. Zwykle informacje na ten temat są podane na wiki OpenWRT przy specyfikacji konkretnego modelu routera. Jeśli zaś chodzi o TL-WR1043ND, to raczej ze ściągnięciem górnej części obudowy nie powinno być problemu. Po odkręceniu śrubek, trzeba wypiąć ją z zatrzasków. Jest ich 8: 1 na tylnej krawędzi, 2 na prawej, 2 na lewej i 3 na przedniej. Są one rozlokowane w rogach i mniej więcej po środku. Otwieranie obudowy najlepiej zacząć od jednego z rogów przy tylnej krawędzi zahaczając palcami o wystający część obudowy i podnosząc ją lekko do góry, tak by można było w powstały otwór wsunąć cienki ale sztywny kawałek metalu czy czegoś podobnego. Później wystarczy przesunąć się jak najbliżej rogu i pewnie podważyć, zatrzask powinien bez problemu puścić. Później wystarczy przesuwać się wzdłuż krawędzi i powtarzać czynność podważenia w miejscu, w którym już nie możemy dalej się przemieścić. Po zdjęciu obudowy, mamy dostęp do płyty głównej. Port szeregowy, a właściwie tylko jego wyprowadzenia są ulokowane w lewej górnej części płyty, to te cztery dziurki widoczne na poniższej fotce: Trzeba tam przylutować jakaś wtyczkę albo chociaż gołe goldpiny. Niemniej jednak, by to zrobić, musimy wyciągnąć ten PCB z routera. Trzeba pierw odkręcić gniazda anten. Niektóre z nich mogą mieć problemy z przeciśnięciem się przez otwór. Trzeba nimi trochę pokręcić i poruszać na boki: Konstrukcja wtyczki dla portu szeregowego routera Po wyciągnięciu płyty z routera, możemy zabrać się za przylutowanie goldpinów czy wtyczki. Ja sobie skonstruowałem wtyczkę z elementów odzyskanych ze starej płyty głównej. Odlutowałem z niej 4 goldpiny i ściągnąłem kawałek plastiku, który był do nich przymocowany: Później takie ustrojstwo wsadziłem na płytę routera i przylutowałem. Całość się trzyma w miarę pewnie, choć ciężko było to przylutować (brak profesjonalnych narzędzi i wprawy). Tak czy inaczej, całość działa. Warto przed podłączeniem zasilania routera sprawdzić multimetrem czy nie ma tam czasem jakiegoś zwarcia. Jeśli miernik nie zabrzęczy, tzn. że jest wszytko w porządku. Konfiguracja linux'a na potrzeby połączenia szeregowego Ja korzystam z linux'a, a konkretnie z dystrybucji Debian. Dlatego też opiszę na jego przykładzie jak przebiega proces konfiguracji systemu pod kątem połączenia komputera z portem szeregowym routera. Przede wszystkim, podepnijmy sam adapter USB-UART do portu USB komputera. Układ CP2102 powinien zostać bez większego problemu rozpoznany w naszym systemie ( idVendor=10c4 , idProduct=ea60 ). Poniżej log ze zdarzenia: kernel: usb 2-1.3: new full-speed USB device number 6 using ehci-pci kernel: usb 2-1.3: New USB device found, idVendor=10c4, idProduct=ea60 kernel: usb 2-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 kernel: usb 2-1.3: Product: CP2102 USB to UART Bridge Controller kernel: usb 2-1.3: Manufacturer: Silicon Labs kernel: usb 2-1.3: SerialNumber: 0001 kernel: usbcore: registered new interface driver usbserial kernel: usbcore: registered new interface driver usbserial_generic kernel: usbserial: USB Serial support registered for generic kernel: usbcore: registered new interface driver cp210x kernel: usbserial: USB Serial support registered for cp210x kernel: cp210x 2-1.3:1.0: cp210x converter detected kernel: usb 2-1.3: cp210x converter now attached to ttyUSB0 Został zarejestrowany nowy interfejs ttyUSB0 i to przy jego pomocy będziemy się komunikować z routerem. Standardowo tylko użytkownik root oraz członkowie grupy dialout mają prawa dostępu do urządzenia /dev/ttyUSB0 . Dodajmy zatem standardowego użytkownika do tej grupy w poniższy sposób: # adduser morfik dialout Potrzebne nam jest także jakieś oprogramowanie, które zinterpretuje nasze polecenia i prześle je do routera. Musimy zatem mieć dostęp do terminala i zainstalować program do komunikacji szeregowej, np. minicom czy picocom . W Debianie znajdują się one w pakietach pod tymi samymi nazwami. Wybieramy sobie jeden z nich i instalujemy w systemie. Ja będę korzystał z picocom . Kolejna sprawa, to konfiguracja picocom . By skomunikować się z routerem za pomocą konsoli szeregowej, musimy zdefiniować kilka parametrów dla połączenia. Konkretne ustawienie zależą od sprzętu lub jego firmware. Zwykle będziemy musieli dostosować parametr baud, którego najczęściej używane wartości to 9600, 38400 lub 115200 bit/s. W przypadku korzystania tylko z 3 przewodów (na PCB routera widzieliśmy 4 piny), tj. RX, TX, GND, powinniśmy ustawić flow control: none. W zasadzie to są te najważniejsze rzeczy ale możemy także sprecyzować data bits: 8, parity: none, stop bits: 1. Oznaczenia pinów na adapterze USB-UART i PCB routera By zestawić połączenie z routerem potrzebujemy podłączyć do jego płyty co najmniej trzy przewody. Jeden z nich to masa (GND), drugi odpowiada za przesył danych (TX), a ostatni zaś za odbiór danych (RX). Jeśli chodzi zaś o sposób podłączenia przewodów, to łączymy następująco: GND-GND, RX-TX i TX-RX. Na Adapterze USB-UART mamy stosownie oznaczone piny. Pytanie tylko, które piny na płycie głównej routera to GND, RX i TX? Zwykle możemy te dane znaleźć na wiki OpenWRT. A co jeśli w przypadku naszego modelu routera tych danych nie znajdziemy na wiki? W takiej sytuacji trzeba ręcznie ustalić oznaczenia pinów, a do tego potrzebny nam będzie multimetr. Pin GND Wyłączamy zatem nasz router i przełączamy multimetr w tryb omomierza na brzęczyk. Podłączamy czarną sondę do znanego nam punktu masy na PCB routera. Jak ustalić gdzie znajduje się znany punkt masy na PCB routera? Najprościej skorzystać z zasilacza, a konkretnie z gniazda zasilania w routerze. Na zasilaczu mamy oznaczenia + i - . Wygląda to mniej więcej tak jak na force poniżej: W tym przypadku wiemy, że masa jest na zewnątrz. Gdybyśmy nie mieli oznaczeń na zasilaczu, to trzeba by sprawdzić ten stan rzeczy multimetrem. W tym celu podłączamy sam zasilacz do gniazdka i wtykamy jedną sondę we wtyczkę, a drugą sondą dotykamy zewnętrznej jej części, tak jak pokazane na poniższej fotce: Wskazanie multimetru przy takim podłączeniu przewodów zarówno do miernika jak i wtyczki zasilacza jest dodatnie, zatem wiemy, że masa jest tam, gdzie mamy podpięty czarny przewód, tj. na zewnątrz, co potwierdza oznaczenie na zasilaczu. Mając tę wiedzę, możemy przyjrzeć się bliżej routerowi. Ma on gniazdo zasilania: Widać tam bolec w środku i blaszkę na spodzie. Nasz znany punkt masy to właśnie ta blaszka, bo to ona styka się z zewnętrzną częścią wtyczki zasilacza. To do niej musimy podłączyć naszą czarną sondę, a czerwoną do każdego kolejnego pinu konsoli szeregowej. Przy jednym z pinów, multimetr zacznie nam brzęczeń, bo wskaże nam prawie zerową rezystancję. Oznacza to, że znaleźliśmy pin GND konsoli szeregowej: W przypadku pozostałych pinów, rezystancja będzie sporo wyższa: Pin VCC Mając pin GND, możemy włączyć router do prądu. Przełączamy multimetr w tryb woltomierza na zakres najbliższy 5 V (u mnie 20 DCV) i podpinamy czarną sondę do pinu GND, a czerwoną do każdego z pozostałych trzech pinów. Wynik jednego ze wskazań powinien nam pokazać 3,3 V (ewentualnie 5 V). Ten pin oznaczamy VCC. Lepiej wyprowadzić sobie kabelki z pinów na płycie, by czasem nie zewrzeć pinów, bo może nam to uszkodzić router. Pin RX i TX Pozostały nam dwa piny RX i TX. Odróżnienie ich odbywa się na zasadzie prób i błędów. Mamy w sumie dwie konfiguracje na linii komputer-router: RX-RX/TX-TX lub RX-TX/TX-RX. Niewłaściwe podłączenie przewodów sprawi, że na konsoli nie zobaczymy żadnego wyjścia lub też będzie ono w ogóle nieczytelne dla nas. Z kolei poprawne połączenie RX i TX powinno pokazać nam na konsoli komunikaty z fazy startu routera. Z reguły powinniśmy podłączyć te piny naprzemiennie, tj. RX-TX i TX-RX ale czasami oznaczenia RX/TX na adapterze USB-UART mogą już uwzględniać zamianę tych pinów i wtedy trzeba łączyć RX-RX i TX-TX i tak było w tym przypadku. Nawiązywanie połączenia z routerem za pomocą konsoli szeregowej Mając odpowiedni adapter USB-UART i oznaczone piny na routerze, możemy spróbować nawiązać połączenie z routerem przez konsolę szeregową. Podpinamy zatem przewody do adaptera USB-UART oraz do wtyczki konsoli szeregowej na płycie routera. Pamiętajmy, interesują nas jedynie piny GND, RX i TX. Adapter umieszczamy w porcie USB komputera. Odpalamy terminal i wpisujemy w nim to poniższe polecenie: $ picocom --baud 115200 --flow=none --parity=none --databits 8 /dev/ttyUSB0 port is : /dev/ttyUSB0 flowcontrol : none baudrate is : 115200 parity is : none databits are : 8 escape is : C-a local echo is : no noinit is : no noreset is : no nolock is : no send_cmd is : sz -vv receive_cmd is : rz -vv imap is : omap is : emap is : crcrlf,delbs, Terminal ready Teraz włączamy przycisk power na routerze. Urządzenie powinno się nam włączyć (zapalą się diody): Jednocześnie obserwujemy co się będzie działo na konsoli. Przy prawidłowej konfiguracji powinniśmy zobaczyć na niej jakieś komunikaty. Jak widać, pierwsza część logu to sekwencja bootloader'a. Na samym dole zaś mamy zainicjowany start kernela. Ta powyższa sytuacja dotyczy sprawnego routera. Co jednak w przypadku, gdy naszemu routerowi coś dolega? Jeśli jesteśmy w stanie dojść do momentu, gdzie widoczny jest napis Autobooting in 1 seconds (pod koniec logu na powyższej fotce), to jak tylko się on pojawi nam na ekranie, to musimy wpisać tpl . Nie jest to łatwe zadanie i pewnie będziemy musieli powtórzyć tę czynność parokrotnie. Gdy wpiszemy tę fazę w wyznaczonym czasie, pojawi się prompt: Mapa obszaru flash'a routera W przypadku, gdy udało nam się uzyskać dostęp do bootloader'a, możemy spróbować wgrać obraz firmware na router. Zanim jednak przejdziemy bezpośrednio do wgrywania obrazu, musimy ustalić kilka rzeczy. Gdy nasz router jest sprawny, lub też ktoś inny posiada dokładnie takie samo urządzenie, które działa bez zarzutu, można z niego wyciągnąć informacje na temat układu partycji na flash'u. Te dane są dla nas bardzo cenne, bo bez nich nie uda nam się z powodzeniem odratować naszego padniętego urządzenia. Układ flash'a routera można odczytać z dwóch plików: /proc/partitions oraz /proc/mtd . Poniżej jest zawartość pierwszego z nich: root@OpenWrt:/# cat /proc/partitions major minor #blocks name 31 0 128 mtdblock0 31 1 1158 mtdblock1 31 2 6841 mtdblock2 31 3 4352 mtdblock3 31 4 64 mtdblock4 31 5 8000 mtdblock5 Rozmiar bloku równy jest 1024 KiB. Z powyższych informacji wiemy, że jakiś bliżej nieznany nam obszar na flash'u routera ma ściśle określony rozmiar. Nie mamy jednak żadnych ludzkich nazw, które byłyby w stanie nam coś o tych przestrzeniach powiedzieć. Bardziej czytelnym plikiem jest zaś /proc/mtd : root@OpenWrt:/# cat /proc/mtd dev: size erasesize name mtd0: 00020000 00010000 "u-boot" mtd1: 00121b70 00010000 "kernel" mtd2: 006ae490 00010000 "rootfs" mtd3: 00440000 00010000 "rootfs_data" mtd4: 00010000 00010000 "art" mtd5: 007d0000 00010000 "firmware" Jak widać wyżej, poza rozmiarem konkretnego obszaru (wartość w HEX) mamy również jego ludzką nazwę. Cały obraz firmware routera TL-WR1043ND V2 ma 8192 KiB, czyli 8 MiB. Możemy to odczytać sumując u-boot, firmware i art. Da nam to wartość 0x00800000, czyli po przeliczeniu właśnie 8 MiB. Kernel i rootfs jest ulokowany w firmware. Z kolei rootfs_data zawiera się w rootfs. Jeśli nasz router nie chce się uruchomić z jakiegoś powodu ale mamy jednocześnie dostęp do bootloader'a przez konsolę szeregową, to znaczy, że obszar u-boot nie został naruszony i mamy sporą szansę na odzyskanie urządzenia. Niemnie jednak, musimy sobie zdawać sprawę, że nie będziemy zapisywać całej przestrzeni flash'a i z tego względu, ten proces jest iście niebezpieczny, bo źle wgrany firmware z poziomu bootloader'a może nam kompletnie uwalić router. Urządzenia po źle wgranym firmware już odratować się tak prosto nie da. Trzeba będzie odlutować flash z PCB routera i podpiąć go do zewnętrznego programatora. Jak się to robi, to nie mam zielonego pojęcia, więc lepiej się kilka razy zastanowić przed wydaniem jakichkolwiek poleceń będąc w konsoli bootloader'a. Procedura wgrania firmware z poziomu bootloader'a Przechodzimy zatem na stronę z obrazami firmware OpenWRT/LEDE i pobieramy plik dla modelu naszego routera mający w nazwie factory. Upewnijmy się też, że ten obraz jest przeznaczony na wersję sprzętową taką, którą router ma wypisaną na spodzie obudowy. Mając pobrany obraz z firmware, musimy go jakoś przesłać na router. Do tego celu wykorzystuje się protokół TFTP (uboższa wersja protokołu FTP). Do zestawienia połączenia wymagany jest klient i serwer. Klientem będzie router. Serwerem zaś nasz komputer. Bootloader routera posiada odpowiednie oprogramowanie kliencie (narzędzie tftp ). Na komputerze musimy zaś postawić serwer. Konfiguracja serwera TFTP pod linux W dystrybucji Debian jest kilka pakietów mających w nazwie tftp . Nas interesują pakiety zawierające demona umożliwiającego postawienie serwera TFTP, np. atftpd lub tftpd . Instalujemy zatem pierwszy z brzega, tj. atftpd . W procesie ratowania routera nie działa WiFi. Musimy zatem łączyć się przy wykorzystaniu przewodu. Nie będzie nam działał też serwer DHCP, przez co nie uzyskamy adresacji dynamicznej dla komputera. Musimy określić ją statycznie w poniższy sposób: # ifdown eth0 # ip link set dev eth0 up # ip addr add 192.168.1.100/24 brd + dev eth0 Adres widoczny wyżej (192.168.1.100) nie może być przypadkowy. Będąc w konsoli bootloader'a, przy pomocy printenv możemy podejrzeć kilka zmiennych, które u-boot wykorzystuje do swojej pracy. Tam z kolei mamy min. te dwie poniższe: ipaddr=192.168.1.111 serverip=192.168.1.100 Zatem router będzie miał adres 192.168.1.111 i będzie próbował połączyć się z adresem 192.168.1.100 . Dlatego to ten adres musimy ustawić w konfiguracji karty sieciowej komputera. Jeśli kogoś interesują pozostałe zmienne zwrócone przez printenv , to są one opisane na wiki OpenWRT. Musimy jeszcze uruchomić serwer TFTP. W tym celu edytujemy pierw plik /etc/default/atftpd i przepisujemy go do poniższej postaci: USE_INETD=false OPTIONS="--tftpd-timeout 300 --retry-timeout 5 --maxthread 100 --verbose=5 --bind-address=192.168.1.100 /srv/tftp-openwrt" Tworzymy jeszcze katalog /srv/tftp-openwrt/ i nadajemy mu odpowiednie uprawnienia: # mkdir /srv/tftp-openwrt/ # chown nobody:nogroup /srv/tftp-openwrt/ Teraz stawiamy serwer poniższym poleceniem, weryfikując przy tym czy został on faktycznie uruchomiony: # /etc/init.d/atftpd start # netstat -tupan | grep atftpd udp 0 0 192.168.1.100:69 0.0.0.0:* 25408/atftpd Jak wgrać firmware przez konsolę szeregową z poziomu bootloader'a Serwer TFTP został uruchomiony, a jego katalog główny to /srv/tftp-openwrt/ . Do tego katalogu musimy wrzucić plik z obrazem firmware, nazywając go przy tym, np. obraz.bin , nazwa dowolna: # cp /home/morfik/Desktop/openwrt-15.05-ar71xx-generic-tl-wr1043nd-v2-squashfs-factory.bin /srv/tftp-openwrt/obraz.bin Przechodzimy teraz do konsoli szeregowej. U-boot dysponuje kilkoma użytecznymi poleceniami. My będziemy wykorzystywać tftp , erase oraz cp.b . Poniżej znajdują się polecenia, które ja wykorzystałem przy ratowaniu swojego TL-WR1043ND V2. Polecenie tfpt pobierze plik obrazu firmware z dysku komputera i wrzuci go do pamięci RAM routera. Ta komenda przyjmuje dwa argumenty. Są nimi adres pamięci RAM, od którego obraz firmware będzie zapisywany, oraz nazwa pliku firmware, który zostanie pobrany z serwera TFTP naszego komputera. Nazwę znamy ale problematyczne może być określenie adresu pamięci RAM. O tym będzie w dalszej części artykułu. ap135> tftp 0x80060000 obraz.bin Using eth1 device TFTP from server 192.168.1.100; our IP address is 192.168.1.111 Filename 'obraz.bin'. Load address: 0x80060000 Loading: ################################################################# Bytes transferred = 8126464 (7c0000 hex) Polecenie erase służy do zerowania pamięci flash. Przyjmuje ono również dwa argumenty. Pierwszym z nich jest adres pamięci flash, od którego ma się rozpocząć zerowanie. (ustalenie go również może być problematyczne). Drugim argumentem jest ilość bajtów, które zostaną wyzerowane (musi pasować do 0x7c0000). Operację zerowania musimy wykonać ze względu na budowę komórek pamięci flash. Dopiero po wyzerowaniu interesującego nas obszaru, możemy zacząć umieszczać na nim dane z firmware. ap135> erase 0x9f020000 +0x7c0000 Erasing flash... First 0x2 last 0x7d sector size 0x10000 125 Erased 124 sectors Polecenie cp.b ma za zdanie skopiować firmware z pamięci RAM i wgrać je na pamięć flash. Tutaj z kolei musimy określić trzy argumenty. Pierwszym z nich jest początkowy adres pamięci RAM, czyli to miejsce, w którym znajduje się początek obrazu firmware. Drugim argumentem jest początkowy adres pamięci flash, od którego zamierzamy zacząć wgrywać firmware. Trzecim zaś argumentem jest ilość bajtów, które zostaną skopiowane z pamięci RAM na pamięć flash routera. ap135> cp.b 0x80060000 0x9f020000 0x7c0000 Copy to Flash... write addr: 9f020000 done Teraz można zrestartować router. Jeśli nie pomyliliśmy adresów i przeprowadziliśmy powyższe kroki prawidłowo, to będziemy w stanie się zalogować na router z wykorzystaniem protokołu telnet. Jak ustalić odpowiednie adresy pamięci RAM i flash routera Powyższe adresy są unikatowe dla konkretnego modelu routera. Nie możemy zatem korzystać z nich w przypadku każdego routera, który nawali z jakiegoś bliżej nieznanego nam powodu. Nasuwa się zatem pytanie: jak ustalić te adresy? Zwykle tego typu informacje powinny być podane na wiki OpenWRT. W przypadku części routerów,polecenie printenv (wydane z poziomu bootloader'a) jest nam w stanie zwrócić kilka zmiennych zawierających pewne polecenia. Poniżej przykład z mojego routera: ... bootcmd=bootm 0x9f020000 ... lu=tftp 0x80060000 ${dir}u-boot.bin&&erase 0x9f000000 +$filesize&&cp.b $fileaddr 0x9f000000 $filesize lf=tftp 0x80060000 ${dir}ap135${bc}-jffs2&&erase 0x9f050000 +0x630000&&cp.b $fileaddr 0x9f050000 $filesize lk=tftp 0x80060000 ${dir}vmlinux${bc}.lzma.uImage&&erase 0x9f680000 +$filesize&&cp.b $fileaddr 0x9f680000 $filesize ... Na podstawie użytych tutaj adresów można ustalić adres pamięci RAM i flash, od których powinniśmy zacząć zapisywać dane. W bootcmd mamy adres pamięci flash, który ma zostać odczytany podczas fazy startu routera. Przed nim znajduje się tylko obszar bootloader'a. Wiemy zatem od którego adresu trzeba będzie flash wyczyścić. Znając rozmiar firmware (ten wgrany do pamięci RAM), wiemy jaki obszar należy wyzerować. W lu widzimy zaś tftp 0x80060000 . Jako, że polecenie tftp ładuje obraz do pamięci RAM routera, to mamy adres pamięci od którego możemy zacząć zapisywać dane w RAM. Nie zawsze tego typu zmienne będziemy mieć dostępne w środowisku bootloader'a i odpowiednie adresy trzeba będzie ustalić w bliżej mi nie znany jeszcze sposób. Warto tutaj nadmienić, że wyżej widoczny adres odnoszący się do pamięci flash, tj. 0x9f000000, zostawiamy w spokoju. Określa on początek pamięci i nie możemy się nim posługiwać. Przy czyszczeniu i wgrywaniu danych na pamięć flash ( erase i cp.b ) musimy uwzględnić offset na bootloader. Standardowo jest to 128 KiB, które w zapisie HEX przyjmują wartość 0x20000. Trzeba zatem tę wartość dodać do 0x9f000000 i w ten sposób otrzymamy początkowy adres pamięci flash, od którego możemy zacząć kasować/zapisywać dane z firmware, tj. 0x9f020000, czyli uzyskaliśmy dokładnie taki sam adres co w bootcmd . Trzeba także uważać na długość wgrywanego obrazu (ilość bajtów). Na końcu flash'a routera mającego podzespoły od Qualcomm Atheros znajduje się obszar art (Atheros Radio Test). Zawiera on dane kalibracyjne dla WiFi (EEPROM). Informacje zawarte na tej partycji są unikatowe dla każdego indywidualnego routera. Jeśli uszkodzimy ten obszar, np. zapisując zbyt wiele danych, to trwale uwalimy WiFi w routerze, no chyba, że mamy backup tej przestrzeni albo i całego flash'a routera i będziemy w stanie ten obszar odtworzyć. Przykład z życia, czyli planowe ubicie TL-WR1043ND Nigdy mi się jeszcze nie zdarzyło ubić żadnego z posiadanych przeze mnie sprzętów. Niemniej jednak, przydałoby się odpowiedzieć na kilka pytań, a do tego potrzebny jest test na żywym organizmie. Postanowiłem zatem wgrać na mój router TL-WR1043ND V2 kilka różnych obrazów, w tym też te nieprzeznaczone dla niego. Obrazy są różne: oficjalne (z/bez boot) oraz OpenWRT/LEDE factory/sysupgrade. Przetestowałem też zanik zasilania podczas wgrywania firmware. Wszystko po to, by sprawdzić co tak naprawdę jest w stanie uszkodzić router i w jakim stopniu. Czy obraz "factory" uszkodzi router z OpenWRT/LEDE Mając wgrany firmware OpenWRT/LEDE zwykle flash'ujemy go obrazem mającym w nazwie sysupgrade . Jak jednak zareaguje nasz router po podaniu mu pełnego obrazu factory ? W sumie zawsze chciałem to sprawdzić ale jakoś nigdy nie było okazji. Kopiujemy zatem firmware do pamięci routera via scp , logujemy się na router i wgrywamy firmware via sysupgrade : Jak widzimy wyżej, router działa bez problemu. Zatem wiemy, że obrazy OpenWRT/LEDE mające w nazwie factory nie ubiją nam routera. Niemniej jednak, w porównaniu do tych mających w nazwie sysupgrade są zwykle parokrotnie większe przez co lepiej jest korzystać z tych drugich, a factory używać jedynie przy zmianie firmware z oficjalnego na OpenWRT/LEDE. Czy obraz przeznaczony na inną wersję/model routera uszkodzi router Wgranie obrazu firmware przeznaczonego na inną wersję/model routera powinno uszkodzić router. W przypadku innej wersji sprzętowej nie zawsze jest to regułą. Pytanie zwykle sprowadza się do różnicy w podzespołach routera. Jeśli te się zmieniły nieznacznie, to jest duża szansa, że router wstanie, choć może nie działać tak jak byśmy tego oczekiwali. Ja dysponuję routerem TL-WR1043ND w wersji V2, a on się zmienił dość znacznie w porównaniu do wersji V1. Możemy zatem przypuszczać, że wgranie firmware dla wersji V1 ubije router. Sprawdźmy zatem co faktycznie się stanie (bez znaczenia czy użyjemy sysupgrade czy factory ). Nie mamy możliwości wgrania firmware przeznaczonego na inną wersję sprzętową routera. Podobnie sprawa będzie wyglądać w przypadku zupełnie innego modelu routera. Jak widać w powyższym komunikacie, został porównany ID: Invalid image, hardware ID mismatch, hw:10430002 image:10430001 . Zatem ID sprzętu nie pasuje do ID uzyskanego z obrazu, w efekcie system odmawia próby wgrania takiego firmware z oczywistych względów. Może i mechanizmy obronne wbudowane w firmware OpenWRT/LEDE działają i są w stanie nas ochronić przed tak banalnymi błędami, to w dalszym ciągu możemy uszkodzić router wgrywając oprogramowanie na siłę przez sysupgrade (przełącznik -F ). Innym sposobem flash'owania, który może nam napytać biedy, jest nieumiejętne korzystanie z narzędzia mtd , przy pomocy którego można wykonywać operacje bezpośrednio na pamięci flash. Jeśli zatem zamierzamy przy pomocy sysupgrade -F lub mtd write wgrywać jakiś obraz firmware, to upewnijmy się, że nie jest on przeznaczony na inne wersje sprzętowe routerów albo i całkowicie inne modele. Czy zanik prądu uszkodzi router z OpenWRT/LEDE Zanik prądu jest znanym mordercą routerów. Niemniej jednak, z racji różnicy w oficjalnym firmware TP-LINK'a i firmware OpenWRT/LEDE, sprawa może się inaczej potoczyć. Przede wszystkim, zanik prądu może pojawić się w różnych momentach. W przypadku obrazów TP-LINK'a mających w nazwie boot , system będzie próbował przepisać bootloader (bez części konfiguracyjnej). By to zrobić musi wyczyścić ten obszar. Jeśli w tym czasie nastąpi zanik napięcia, to nie tylko router zostanie uszkodzony ale też już nie damy rady go odzyskać przez konsolę szeregową i trzeba będzie korzystać z programatora. W przypadku firmware OpenWRT/LEDE nie musimy się aż tak martwić, bo tutaj nie jest ruszany w ogóle bootloader. W efekcie nawet jeśli nastąpi zanik napięcia, to obszar u-boot zostaje nietknięty i możemy wgrać się później przez konsolę szeregową. Podobnie sprawa ma się w przypadku obrazów oficjalnych bez frazy boot w nazwie. Tutaj również nie jest przepisywany bootloader i przy zaniku napięcia będziemy w stanie odzyskać router. Sprawdźmy zatem co się stanie po puszczeniu procesu aktualizacji firmware via sysupgrade i odłączeniu zasilania routera tak po trzech sekundach. Oczywiście flash'ujemy router z poziomu sysupgrade na firmware OpenWRT/LEDE: W momencie uwiecznionym powyżej nastąpił symulowany zanik zasilania. System routera po włączeniu nie startuje. Zapalają się wszystkie diody, po czym część z nich gaśnie. Dioda Power, System i WPS świecą się ciągle. Dioda WLAN jest zgaszona cały czas, natomiast wszystkie pięć diod od portów ethernet miga. Ten proces zdaje się być zapętlony, czyli jakaś aktywność routera się zachowała. Jako, że diody migają i router się cały czas restartuje, oznacza to, że bootloader działa raczej prawidłowo i jego obszar nie uległ przepisaniu. Niemniej jednak, bootloader nie jest w stanie podnieść systemu. Napotyka jakiś "bliżej nieznany błąd" i restartuje system mając nadzieję, że to coś da. Poniżej jest komunikat, który można zobaczyć na konsoli szeregowej: Autobooting in 1 seconds ## Booting image at 9f020000 ... Uncompressing Kernel Image ... ERROR: LzmaDecode.c, 543 Decoding error = 1 LZMA ERROR 1 - must RESET board to recover Router jest do odzyskania ale musimy zrobić użytek z konsoli szeregowej i opisanym wyżej sposobem wgrać firmware z poziomu bootloader'a. Czy obraz przeznaczony na inną wersję/model routera ubije router z oficjalnym firmware Podobnie jak w przypadku firmware OpenWRT/LEDE, oficjalny firmware TP-LINK'a również weryfikuje obrazy przed wgraniem ich przez panel administracyjny. Nie musimy się zatem obawiać, że przez przypadek wgramy obraz nieprzeznaczony dla naszego modelu/wersji routera. Czy wgranie oficjalnego firmware z "boot" w nazwie via sysupgrade uszkodzi router z OpenWRT/LEDE Firmware OpenWRT/LEDE nie dotyka praktycznie wcale obszaru flash, w którym siedzi bootloader. Jeśli teraz zamierzamy powrócić do oficjalnego firmware, to musimy pozyskać stosowny obraz. Wszystkie obrazy na stronie TP-LINK mają frazę boot . Oznacza to, że zawierają one część bootloader'a, którą proces flash'owania przepisuje podczas aktualizacji firmware z poziomu panelu administracyjnego TP-LINK'a. Jeśli taki obraz podamy w sysupgrade , to ta część bootloader'a z oficjalnego firmware powędruje na flash routera w miejsce, gdzie powinno znajdować się faktyczne oprogramowanie. W efekcie router nie będzie chciał się uruchomić ale będziemy w stanie go odzyskać przez konsolę szeregową. By uniknąć tego typu problemów, potrzebny nam jest obraz nieposiadający w nazwie frazy boot . Takie obrazy są dostępne w różnych miejscach: tutaj, tutaj, tutaj i pewnie jeszcze w wielu innych, o których nie wiem. Jeśli jednak dysponujemy obrazem mającym w nazwie boot i z jakiegoś powodu nie możemy pozyskać obrazu bez części bootloader'a, to możemy ten zbędny i niebezpieczny zarazem kawałek usunąć ręcznie. Możemy to zrobić przy pomocy dd z poziomu każdego linux'a (nawet OpenWRT/LEDE) w poniższy sposób: # dd if=firmware_z_boot.bin of=firmware_bez_boot.bin skip=257 bs=512 To powyższe polecenie usunie z początku obrazu pierwsze 131584 bajów (0x20200 w HEX) i taki obraz możemy już wgrać bez problemu na router via sysupgrade . Czy wgranie oficjalnego firmware NIEmającego "boot" w nazwie przez panel admina uszkodzi router Gdy oficjalny plik z firmware nie zawiera frazy boot w nazwie, to jest to mniej więcej taka sama wersja obrazu co w przypadku firmware OpenWRT/LEDE, który ma w nazwie factory . Wgranie oficjalnego obrazu bez boot z poziomu panelu administracyjnego TP-LINK'a nie uszkodzi naszego routera. Wgrywanie oficjalnych obrazów bez boot w nazwie jest nawet bezpieczniejsze, bo w tym przypadku nie jest przepisywany obszar u-boot. Dlatego też nawet w przypadku utraty zasilania podczas procesu flash'owania routera, będziemy w stanie odzyskać router przez konsolę szeregową. Czy obraz "sysupgrade" wgrany z panelu TP-LINK uszkodzi router Przy przechodzeniu z oficjalnego firmware na OpenWRT/LEDE stosuje się obrazy mające w nazwie factory . Z kolei zaś obrazy mające w nazwie sysupgrade są przeznaczone dla aktualizacji firmware routera. Czy wgrywając obraz sysupgrade można uszkodzić router? Sprawdźmy: Wygląda na to, że oficjalne oprogramowanie nie przyjmuje takiego obrazu zupełnie. Obraz factory i sysupgrade praktycznie niczym się nie różnią pod kątem zawartości. W przypadku factory na początku obrazu znajduje się tylko dodatkowy nagłówek i prawdopodobnie jego brak uniemożliwia wgranie obrazu na router z poziomu panelu administracyjnego TP-LINK'a. Backup pamięci flash router'a Jak widać z powyższych obserwacji bardzo ciężko jest doprowadzić router do stanu nieużywalności. Jeśli nie przytrafi nam się nagły zanik zasilania podczas procesu flash'owania, to raczej nie mamy możliwości uszkodzić routera, no chyba, że bardzo się o taki stan rzeczy postaramy. By uniknąć problemów przy ewentualnym eksperymentowaniu z routerem, najlepiej postarać się o backup całej przestrzeni flash. Backup z poziomu działającego firmware Jeśli nasz router działa bez problemu, możemy się na niego zalogować po ssh i przy pomocy dd zrzucić obrazy wszystkich pozycji, które widnieją w pliku /proc/mtd . Oczywiście moglibyśmy zrobić backup tylko u-boot, firmware i art ale później musielibyśmy kroić obraz by wyodrębnić konkretne jego części. Backup robimy przy pomocy dd zapisując dane w pamięci RAM routera: root@OpenWrt:/tmp# dd if=/dev/mtdblock0 of=/tmp/mtdblock0-u-boot.bin root@OpenWrt:/tmp# dd if=/dev/mtdblock1 of=/tmp/mtdblock1-kernel.bin root@OpenWrt:/tmp# dd if=/dev/mtdblock2 of=/tmp/mtdblock2-rootfs.bin root@OpenWrt:/tmp# dd if=/dev/mtdblock3 of=/tmp/mtdblock3-rootfs_data.bin root@OpenWrt:/tmp# dd if=/dev/mtdblock4 of=/tmp/mtdblock4-art.bin root@OpenWrt:/tmp# dd if=/dev/mtdblock5 of=/tmp/mtdblock5-firmware.bin Następnie tak utworzone pliki trzeba przesłać na komputer, np. via scp : $ scp root@192.168.1.1:/tmp/mtd\* ./ Odtwarzanie backup'u z poziomu firmware Odtworzenie backup'u uszkodzonego obszaru pamięci flash z poziomu działającego firmware jest stosunkowo proste. Załóżmy, że uszkodziliśmy sobie obszar art, w wyniku czego uszkodziliśmy WiFi. By przywrócić ten obszar, logujemy się na router i wrzucamy do pamięci plik backup'u. Później przy pomocy mtd write wgrywamy backup na odpowiedni obszar pamięci flash w poniższy sposób: # mtd write /tmp/mtdblock4-art.bin art Backup i odtwarzanie go z poziomu bootloader'a W przypadku, gdy nasz router znajduje się w stanie agonalnym ale mamy jeszcze możliwość zalogowania się do bootloader'a, to możemy pokusić się o zrobienie backup'u flash'a za sprawą konsoli szeregowej. Niemniej jednak, nie wszystkie wersje u-boot dysponują komendami umożliwiającymi przesłanie backup'u na serwer TFTP. Jeśli u-boot naszego routera takimi poleceniami nie dysponuje, to musimy postarać się o obraz initramfs, który załadujemy do pamięci RAM routera. W tym initramfs będą znajdować się potrzebne nam polecenia i backup wykonamy bez trudu. Obraz initramfs musimy sobie sami zbudować albo tez pozyskać od kogoś, kto już go zbudował. Jak przeprowadzić proces budowy obrazu initramfs wykracza poza ramy tego artykułu. (link FIXME). Jeśli zaś chodzi o kwestie odtworzenia backupu za pomocą bootloader'a, to raczej nie będziemy potrzebować takiej funkcjonalności. Poza tym, nie wszystkie bootloader'y dają nam możliwość skorzystania z mtd , tak jak to ma miejsce przy działającym firmware OpenWRT/LEDE. Nawet jeśli nasz bootloader wspiera taką możliwość, to trzeba uważać, bo nie zawsze obszary mtd widziane przez bootloader muszą się pokrywać z tymi udostępnianymi przez kernel w pliku /proc/mtd . Dlatego też lepiej posługiwać się offset'ami. Problemy z uruchomieniem routera przy podłączonym adapterze USB-UART Mój routera TL-WR1043ND V2 miał wgrany firmware OpenWRT Chaos Calmer. Był też jak najbardziej sprawny ale po podłączeniu adaptera USB-UART nie chciał się uruchomić. Zatrzymywał się na etapie bootloader'a z poniższą informacją: U-Boot 1.1.4 (Sep 10 2015 - 12:05:08) ap135 - Scorpion 1.0DRAM: sri Scorpion 1.0 ath_ddr_initial_config(211): (16bit) ddr1 init tap = 0x00000002 Tap (low, high) = (0xaa55aa55, 0x0) Tap values = (0x8, 0x8, 0x8, 0x8) 4 MB Niektóre adaptery USB-UART mogą uniemożliwić start routera. No to pojawia się pytanie jak próbować odzyskać router, gdy nie mamy możliwości zainicjowania bootloader'a? Najprościej jest kupić normalny adapter (jakieś polecane modele?), który nie zawiesi startu routera. Innym wyjściem jest podłączenie przewodu do pinu GND po włączeniu przycisku power routera. Trzeba tylko ustalić czas, po którym możemy ten pin GND podłączyć, a to już robimy metodą prób i błędów. W moim przypadku mogłem praktycznie od razu się podłączyć (tuż przed zgaśnięciem wszystkich diod na routerze). W innych sytuacjach trzeba będzie poczekać jedną czy kilka sekund i dopiero wtedy się wpiąć. Nie trzeba się oczywiście spieszyć z tym faktem, bo bootloader się będzie w kółko resetował, przez co i tak zobaczymy wszystkie komunikaty, które nam zostaną zwrócone.
  7. Po uszkodzeniu jednego z moich smartfonów TP-LINK i skasowaniu na nim wszystkich danych na partycji /system/ trzeba było pomyśleć nad przywróceniem tego urządzenia do życia. Jednym z rozwiązać było binarne wgranie obrazu systemowej partycji bezpośrednio na flash przy pomocy narzędzia dd. Co jednak w przypadku, gdy nie mamy dostępu do backup'u lub tez zwyczajnie go nie zrobiliśmy? Co w takiej sytuacji uczynić i czy jest jakaś nadzieja dla naszego telefonu? Odpowiedź jest naturalnie twierdząca ale wymagane są dwie rzeczy: działający tryb recovery (najlepiej TWRP) ze wsparciem dla trybu "ADB sideload" oraz paczka update.zip z firmware, którą można pobrać bezpośrednio ze strony TP-LINK/Neffos. By ulżyć nieco osobom, które do mnie piszą z zapytaniem o pomoc w przypadku skasowania danych na partycji /system/ (czy uszkodzenia jej w jakiś sposób), postanowiłem napisać krótkie howto na temat używania trybu ADB sideload. W tym artykule w rolach głównych weźmie udział Neffos Y5 ale bez problemu można te kroki przeprowadzić chyba na każdym innym smartfonie. Objawy usunięcia danych z partycji /system/ Usuwając dane z partycji /system/ pozbawiamy nasz telefon praktycznie całego oprogramowania. Taki smartfon nie może działa bez Androida czy innego systemu operacyjnego i w zasadzie urządzenie resetuje się co około minutę po włączeniu. W takim stanie po włączeniu smartfona, na ekranie można zobaczyć jedynie loga TP-LINK i Androida. Natomiast w logu systemowym mojego Debiana można zaobserwować poniższe komunikaty: kernel: usb 2-1.1: new high-speed USB device number 7 using ehci-pci kernel: usb 2-1.1: New USB device found, idVendor=2357, idProduct=0328 kernel: usb 2-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 kernel: usb 2-1.1: Product: Android kernel: usb 2-1.1: Manufacturer: Android kernel: usb 2-1.1: SerialNumber: 90169635 kernel: usb 2-1.1: USB disconnect, device number 6 Gdy dane z partycji /system/ zostały usunięte, to nie damy rady wgrać nic na smartfon przy pomocy narzędzia fastboot . Dlatego właśnie wymagany jest działający tryb recovery. Jeśli ten również z jakiegoś powodu nie działa, to niestety uwaliliśmy telefon na dobre i trzeba będzie go odesłać do serwisu. Działający TWRP recovery z trybem ADB sideload Dla osób, które nie wiedzą czym jest ADB sideload, wyjaśniam, że jest jeden z trybów pracy ADB. Standardowo przy pomocy adb możemy rozmawiać z systemem smartfona przez wysyłanie do niego różnych poleceń i w zasadzie możemy operować na takim urządzeniu mniej więcej tak jakbyśmy działali na zwyczajnym linux'ie. W przypadku trybu ADB sideload, te standardowe polecenia są nieaktywne ale mamy za to dostęp do komendy adb sideload , która jest w stanie wgrać świeży firmware z paczki update.zip . TWRP recovery począwszy od wersji 2.3 wspiera tryb ADB sideload. Dlatego też trzeba się upewnić, że mamy wgraną na smartfonie w miarę nową wersję tego oprogramowania. Gotowe obrazy TWRP recovery dla smartfonów Neffos (aktualnie C5 MAX, Y5 i Y5L) są dostępne w tym wątku. W przypadku, gdy mamy starszą wersję TWRP (< 2.3), no to niestety musimy zaktualizować to oprogramowanie wgrywając binarnie obraz przy pomocy dd mniej więcej w taki sam sposób jak zostało to opisane przy okazji odzyskiwania partycji /system/ (link we wstępie). ADB sideload i stock'owy recovery Nie jestem pewien czy ADB sideload działa na stock'owym recovery. Wiem, że smartfony oferują możliwość wgrywania pliku update.zip z trybu recovery ale nie wiem jak się zachowa system, gdy jedna lub kilka partycji ( /boot/ , /system/ , /recovery/ ) zostały w jakiś sposób zmienione. Dlatego to HOWTO dotyczy jedynie TWRP recovery, na którym pomyślnie udało mi się przetestować ADB sideload. Pozyskanie pliku update.zip zawierającego firmware smartfona ADB sideload potrzebuje pliku z obrazem firmware (ROM). Stock'owy ROM można pobrać ze strony TP-LINK/Neffos. Linki do działu download: Neffos Y5, Neffos Y5L, Neffos C5, Neffos C5 MAX. Pliki są w miarę duże i ważą około 1 GiB. Każdy z tych plików w nazwie zawiera oznaczenie modelu, np. C5_Max_TP702A , Y5L_TP801 . Tutaj mamy TP702 i TP801 oraz w przypadku tego pierwszego mamy również literkę A , która odpowiada za wersję geograficzną i w tym przypadku A jest dla smartfonów na rynku europejskim. Jak wgrać update.zip przez ADB sideload z poziomu TWRP recovery Pobrany firmware jest w postaci spakowanego pliku .zip . Tego pliku nie wypakowujemy. Zostanie on załadowany do pamięci RAM komputera, a jego zawartość w locie przesłana na smartfon bez potrzeby wgrywania tego pliku na flash urządzenia. Ta paczka zawiera nie tylko oprogramowanie, które jest wgrywane na partycję /system/ ale również obraz partycji /boot/ , za sprawą którego zostanie wygenerowany też świeży obraz partycji /recovery/ . Wszystkie te trzy partycje będą poddane procesowi flash'owania i po jego ukończeniu powinniśmy powrócić do stock'owego firmware. Pliki update.zip są podpisane cyfrowo i domyślnie nie damy rady ich wgrać przez TWRP recovery, bo zostanie nam wygenerowany poniższy błąd: sideload-host file size 968174348 block size 65536 Installing zip file '/sideload/package.zip' Verifying zip signature... I:read key e=3 hash=20 I:1 key(s) loaded from /res/keys I:comment is 1428 bytes; signature 1410 bytes from end I:TWFunc::Set_Brightness: Setting brightness control to 5 I:TWFunc::Set_Brightness: Setting brightness control to 0 I:failed to verify against RSA key 0 E:failed to verify whole-file signature I:Zip signature verification failed: 1 Zip signature verification failed! I:Signaling child sideload process to exit. I:Waiting for child sideload process to exit. sideload_host finished Problem jak widać dotyczy weryfikacji sygnatury pliku .zip . Musimy zatem poinstruować TWRP by nie weryfikował sygnatury. Możemy to zrobić odhaczając opcję ZIP signature verification w ustawieniach: Teraz możemy aktywować tryb ADB sideload przechodząc w Advanced => ADB Sideload: Czyszczenie cache jest opcjonalne ale można je zaznaczyć. Dane użytkownika i tak pozostaną nietknięte, zatem bez obaw. Niemniej jednak, trzeba pamiętać, że w przypadku modyfikacji partycji /system/ , np. przez Xposed, możemy napotkać dziwne problemy, które mogą uniemożliwić start lub też poprawne działanie systemu i wymagane będzie przeprowadzenie procesu Factory Reset. Po przesunięciu trzech strzałek na prawą stronę, ADB przełączy się w tryb sideload. Teraz wracamy na komputer i ładujemy plik update.zip przy pomocy poniższego polecenia (trzeba doinstalować narzędzie adb): # adb sideload /neffos/Y5_H10S100D00B20161207R1344_update.zip serving: '/neffos/Y5_H10S100D00B20161207R1344_update.zip' (~24%) Proces flash'owania plikiem update.zip zajmie dłuższą chwilę ale ostatecznie powinien zakończyć się powodzeniem: Uruchamiamy smartfon ponownie i ignorujemy przy tym informację, że to urządzenie nie mam zainstalowanego systemu operacyjnego (w zasadzie właśnie go zainstalowaliśmy): Po chwili powinien nam się załadować ekran z wyborem języka systemu: Po skonfigurowaniu systemu warto sprawdzić czy są dostępne jakieś aktualizacje. To na wypadek, gdybyśmy chcieli wgrać sobie jeszcze raz TWRP recovery czy przeprowadzać proces root Androida. W przypadku wprowadzenia jakichkolwiek zmian na partycji /boot/ , /system/ lub /recovery/ nie będziemy w stanie tych aktualizacji wgrać na smartfon i warto o tym pamiętać.
  8. Każdy z nas ma już raczej w swoim posiadaniu telefon, czy jego nieco bardziej zaawansowaną wersję określaną mianem smartfona. Te urządzenia to w zasadzie przenośne i do tego bardzo małe komputery, które umożliwiają nam komunikowanie się z osobami na całym świecie. Wykonywanie połączeń głosowych, przesyłanie SMS'ów/MMS'ów czy też korzystanie z Internetu w naszych komórkach od dawna jest już standardem i ciężko byłoby nam się obejść bez tej technologii obecnie. Problem w tym, że nasza komunikacja jest narażona na podsłuch. W przypadku Internetu większość połączeń jest już szyfrowana na linii dwóch klientów (E2E, End To End). Natomiast jeśli chodzi o telefony, to tutaj sprawa kuleje i to bardzo poważnie, bo w zasadzie nasze połączenia głosowe czy SMS'y są do wglądu dla każdych służb, które z jakiegoś powodu uznają, że mogą naruszać naszą prywatność. Jedyna opcja, która jest w stanie zabezpieczyć nas przed tego typu praktykami, to szyfrowanie rozmów. Tak się składa, że jest kilka aplikacji na Androida, które są w stanie realizować tego typu przedsięwzięcie. Jedną z nich jest darmowa i otwartoźródłowa aplikacja Signal, której się przyjrzymy nieco bliżej w tym artykule. Czym jest aplikacja Signal Aplikacją Signal zainteresowałem się głównie dlatego, że, jak można wyczytać na stronie producenta, ma ona poprawiać w znacznym stopniu prywatność naszej korespondencji, którą prowadzimy za pośrednictwem telefonu dzięki zastosowaniu Signal Protocol. Jeśli zamierzamy korzystać z aplikacji Signal, to musimy ją zainstalować na swoim smartfonie z Android/iOS. Tej aplikacji jesteśmy też w stanie używać na zwykłym desktopie, z tym, że tutaj musimy mieć zainstalowaną przeglądarkę Google Chrome. Każdy kontakt, z którym zamierzamy się w jakiś sposób komunikować, również musi zainstalować Signal. W przeciwnym razie nie damy rady zestawić zaszyfrowanego połączenia. Posiadanie odpowiedniego urządzenia i zainstalowanie aplikacji Signal to jednak nie wszystko. Na dobrą sprawę, Signal jedynie imituje standardową aplikację telefonu w naszych smartfonach i cały ruch, jaki generujemy za pomocą tej aplikacji, jest przesyłany tak na prawdę przez Internet. Wymagane zatem jest posiadanie połączenia sieciowego w komórce, np. pakiety danych 3G/LTE lub WiFi. Gdy wyjdziemy poza zasięg sieci bezprzewodowej, to nie będziemy w stanie połączyć się z żadnym z kontaktów, które mamy podpięte pod Signal. Oczywiście w dalszym ciągu będzie działało połączenie tradycyjne przez sieć GSM, które możemy wykorzystać do powiadomienia osoby, by przełączyła się ona na Signal. Jako, że Signal bazuje na połączeniu z globalną siecią Internet, to nie tylko wiadomości tekstowe jesteśmy w stanie przesyłać za jego pomocą. Za pośrednictwem tego komunikatora jesteśmy w stanie przesłać każdą informację, którą można zapisać w postaci binarnej. Innymi słowy, możemy nawiązywać połączenia głosowe, video i przesyłać pliki dowolnego formatu. W zasadzie Signal jest to taki Skype ale bardziej ficzerzasty i, co najważniejsze, wolny i otwartoźródłowy. Signal również eliminuje bariery dystansowe, przez co nie musimy się martwić o koszty roamingu i bez problemu możemy rozmawiać z osobami na całym świecie, o ile one i my mamy dostęp do Internetu. Przygotowanie aplikacji Signal do pracy Wiemy zatem, że do zestawienia kanału komunikacyjnego między dwoma kontaktami potrzebne nam są dwa urządzenia i zainstalowana aplikacja Signal na każdym z nich. Ja dysponuję jedynie smartfonami Neffos z system Android 5.1 (Lollipop) i 6.0 (Marshmallow) i na tych dwóch systemach ta aplikacja działa bez większego problemu: Warto w tym miejscu zaznaczyć, że aplikacja Signal może zostać zainstalowana spoza sklepu Google Play i działać nawet, gdy usługi Google w naszym smartfonie są wyłączone lub w ogóle nie są zainstalowane. Można zatem używać Signal bez Google, co bardzo cieszy. Po zainstalowaniu aplikacji Signal musimy z nią powiązać nasz numer telefonu, tj. zarejestrować go ale ta rejestracja nie jest rejestracją rozumianą w znaczeniu potocznym. Po prostu numer telefonu unikalnie identyfikuje dany kontakt i można ten fakt wykorzystać. Za każdym razem, gdy odinstalujemy aplikację Signal, krok rejestracji numeru (nawet tego samego) trzeba będzie powtórzyć. Dzieje się tak dlatego, że przy rejestracji numeru są tworzone klucze szyfrujące wykorzystywane do zabezpieczenia komunikacji. Niektóre z kluczy wykorzystywanych w Singal są generowane czasowo, np. do zaszyfrowania pojedynczej wiadomości, którą komuś przesyłamy. Natomiast jest też generowany jeden klucz, który jest przypisany do naszego urządzenia. Jeśli teraz reinstalujemy aplikację Signal, to ten klucz jest usuwany i trzeba go wygenerować jeszcze raz. Po zarejestrowaniu numeru, dobrze jest rzucić jeszcze okiem na opcje w ustawieniach. W szczególności zwróćmy uwagę na pozycję dotyczącą domyślnej aplikacji SMS, ochrony ekranu oraz potwierdzeń zmienionych kluczy naszych kontaktów. Czy Signal obsługuje smartfony bez numeru Numer telefonu, który podamy podczas rejestracji, będzie przypisany do aplikacji Signal i ten numer musi być prawidłowy z możliwością odbierania połączeń. Na niego dostaniemy wiadomość SMS z kodem potwierdzającym. Tylko jeden numer może być obsługiwany przez aplikację Signal w danym czasie, nawet jeśli nasz telefon posiada dual czy triple SIM. Może i do rejestracji jest wykorzystywany działający numer telefonu ale testując kilka ciekawych rzeczy udało mi się ustalić, że karta SIM z tym numerem nie musi być obecna w telefonie po zarejestrowaniu go w aplikacji. Możemy zatem korzystać z dwóch fizycznych smartfonów i przez jeden z nich będziemy się komunikować za pomocą aplikacji Signal, a drugi telefon posłuży nam do tradycyjnych rozmów i SMS'ów. Takie rozdzielenie ról może poprawić naszą prywatność, bo operator GSM w przypadku braku karty SIM może nie być w stanie ustalić położenia telefonu. Trzeba tylko pamiętać by wyłączyć moduł GSM, bo ten nawet w przypadku braku karty SIM w telefonie i tak umożliwia dzwonienie na numery alarmowe. Z kolei by móc je wykonywać, to z jakimś operatorem GSM jesteśmy zawsze połączeni. Moduł GSM można wyłączyć aktywując Tryb Samolotowy. Aplikacja Signal i Aero2 Posiadacze kart SIM od Aero2 są w stanie wykorzystać transfer oferowany w usłudze darmowego Internetu tego operatora. Może transfer nie przekracza 512 kbit/s (64 KiB/s) ale z tego co zauważyłem, to nawet taki słaby transfer nie stanowi większego wyzwania dla aplikacji Signal. Jesteśmy w stanie bez problemu rozmawiać głosowo oraz też przesyłać obraz video. Szacunkowo, transfer jaki jest zjadany przez aplikację Signal przy połączeniu video w czasie jednej minuty, to około 1,5 MiB do 2 MiB. Jest to zatem około 300 kbit/s (nieco ponad połowa prędkości oferowanej przez Aero2. Jako, że na kartach SIM od Aero2 nie mamy możliwości odbierania SMS'ów, to nie damy rady numeru tej karty zarejestrować w aplikacji Signal. Nie powinno to stanowić problemu, bo zawsze możemy sobie zakupić jakiegoś prepaida, by tylko taki numer otrzymać, a dalej możemy już jechać na Aero2. Jedyny problem przy korzystaniu z aplikacji Signal w przypadku Aero2, to naturalnie kod CAPTCHA, który trzeba wpisywać co godzinę. Nawet jeśli nie będziemy tego robić regularnie, to i tak zawsze możemy ten kod wpisać tuż przed nawiązaniem połączenia. Problematyczne za to może być odbieranie SMS'ów i rozmów, bo gdy ponownie trzeba będzie ten kod CAPTCHA wpisać, to do momentu aż to uczynimy będziemy offline i nikt z nami nie będzie w stanie się skontaktować. Zawsze też możemy wykupić sobie pakiet 3 GiB za 5 zł na miesiąc i zapomnieć o CAPTCHA. Weryfikacja kontaktów w aplikacji Signal Wysyłając w aplikacji Signal jakąś wiadomość tekstową, ta zostanie uprzednio zaszyfrowana i przesłana do drugiej osoby. Skąd jednak wiemy, że ta druga strona w ogóle otrzymała daną wiadomość oraz, że tylko ona ją odebrała? Każdy przecież może taką rozmowę przechwycić i podszyć się pod nasz kontakt. Signal ma naturalnie wbudowany mechanizm weryfikacji kontaktu, tj. czy numer, który my widzimy na ekranie naszego telefonu pasuje do tego, którym dysponuje nasz kontakt. Ten numer możemy zweryfikować ręcznie lub przez zeskanowanie kodu QR, który zostanie wyświetlony na ekranie telefonu tej drugiej osoby. Przykładowa weryfikacja numeru bezpieczeństwa wygląda mniej więcej tak: By przeprowadzić proces weryfikacji, trzeba te wszystkie wyżej wygenerowane cyferki sprawdzić pod kątem poprawności na drugim urządzeniu. Skanowanie kodu QR jest automatyczne i o wiele szybsze i bardziej dokładne. Jeśli weryfikacja zakończy się powodzeniem, to znaczy, że komunikacja jest należycie zabezpieczona i nikt nie jest w stanie jej podsłuchać. Jeśli nasz rozmówca w późniejszym czasie przeinstaluje aplikację Signal, to nam zostanie wyświetlony komunikat, że ten kontakt dysponuje innym kluczem szyfrującym, bo ten przecież został na nowo wygenerowany podczas ponownej instalacji programu. Tutaj trzeba jednak uważać, bo informacja o zmianie klucza może również oznaczać, że ktoś między nami i naszym kontaktem próbuje przechwycić rozmowę: W takim przypadku, niezbędna będzie weryfikacja numeru bezpieczeństwa w sposób opisany powyżej. Bez weryfikacji nie będziemy w stanie wymieniać wiadomości. Można oczywiście tę weryfikację pominąć ale wtedy możemy narazić się na podsłuch. Jak tylko zweryfikujemy numer, to przy wiadomości pojawi się znaczek podwójnego ptaszka oznaczającego, że wiadomość dodarła do odbiorcy oraz, że została ona z powodzeniem odczytana. Nie zawsze jednak pojawią się dwa ptaszki. Może też pojawić się tylko jeden. Jeden ptaszek oznacza, że wiadomość została poprawnie zaszyfrowana i wysłana do odbiorcy ale z racji, że nasz kontakt może być offline, to może się zdarzyć tak, że wiadomość nie została do niego dostarczona natychmiast. Jak tylko nasz kontakt podłączy się do Internetu, to ta wiadomość zostanie mu przekazana przez serwer. Po jej dostarczeniu i odczytaniu przez odbiorce, w logu rozmowy powinien pojawić się nam drugi ptaszek. Wykonywanie szyfrowanych rozmów głosowych Osoby, które chciałyby wykonać szyfrowaną rozmowę głosową, mogą ją zainicjować bez większego trudu. Po przejściu do historii wiadomości danego kontaktu, w prawym górnym rogu jest ikonka słuchawki z kłódką. Po jej przyciśnięciu rozpocznie się dzwonienie do tej osoby: Jeśli kontakt będzie offline, to cały czas na ekranie będzie widniał zapis "WYBIERANIE". Po jakiejś minucie od rozpoczęcia procesu dzwonienia i nie odebraniu połączenia przez drugą ze stron, proces ten zostanie automatycznie przerwany. W przypadku, gdy kontakt będzie online, to "WYBIERANIE" przejdzie w stan "DZWONI". A tak wygląda odbieranie rozmowy po drugiej stronie: Standardowo mamy aktywną tylko funkcję rozmowy głosowej ale nic nie stoi na przeszkodzie by włączyć kamerę selfie i zacząć przesyłać obraz i dźwięk jednocześnie. Szyfrowane archiwum wiadomości Wiadomości oraz wszystkie załączniki, które w nich zamieścimy, np. zdjęcia czy filmy, są przechowywane w lokalnej bazie danych na obu końcach połączenia, tj. u nas i u naszego kontaktu. Nawet jeśli nasz telefon oferuje szyfrowanie partycji /data/ , to i tak przydałoby się zaszyfrować niezależnie wszystkie konwersacje w aplikacji Signal. By tego typu szyfrowanie aktywować, musimy ustawić hasło w aplikacji. To hasło trzeba będzie wpisywać za każdym razem, gdy będziemy chcieli uzyskać dostęp do listy kontaktów. Naturalnie można ustawić czas przechowywania hasła w pamięci RAM, co sprawi, że przez pewien czas hasło nie będzie wymagane. Zaszyfrowaniu ulegnie też klucz użytkownika wykorzystywany do deszyfrowania wiadomości. Niemniej jednak, część informacji pozostanie niezaszyfrowana, np. lista kontaktów oraz czas przesyłanych wiadomości. Bezpieczeństwo bazy danych będzie zależeć od stanu skomplikowania hasła, które sobie wybierzemy. Dlatego też jeśli decydujemy się na zaszyfrowanie bazy, to podejdźmy do tego zagadnienia należycie i stosujmy długie hasła. Gdy baza zostanie zaszyfrowana, to w dalszym ciągu jesteśmy w stanie odbierać wiadomości ale nie możemy ich odczytać do momentu podania hasła. Rozmowy głosowe natomiast można bez problemu odbierać. Automatyczne kasowanie wiadomości Przechowywanie wiadomości przez zbyt długi okres czasu może nie być zalecane, zwłaszcza jeśli nie powinien ich nikt zobaczyć. Zwykle bardzo rzadko kasujemy wiadomości ręcznie i dlatego w aplikacji Signal możemy ustawić, by wiadomości z bazy były usuwane automatycznie, gdy licznik przekroczy, np. 100. Tego typu kasowanie wiadomości dotyczy jednak tylko lokalnej bazy danych. Przesłane wiadomości będą przechowywane zgodnie z polityką, którą wybrał nasz kontakt. Może się zatem zdarzyć tak, że z naszego archiwum dana wiadomość zniknęła ale w archiwum naszego kontaktu w dalszym ciągu ona figuruje. Mając na uwadze powyższe, w aplikacji Signal został zaimplementowany ciekawy mechanizm ustawiania czasu ważności dla wiadomości. W taki sposób jedna ze stron może ustawić, np. czas na 5 minut i po upłynięciu tego okresu, ta wiadomość zostanie automatycznie skasowana zarówno u tej osoby jak i u jej rozmówcy. Trzeba tylko zdawać sobie sprawę, że ten czas jest liczony od momentu wyświetlenia się wiadomości na ekranie. U nas ta wiadomość się pojawia w zasadzie natychmiast ale u naszego kontaktu może się ona nie wyświetlić przez dni czy tygodnie, jeśli użytkownik był offline przez dłuższy czas. W każdym razie, ten timeout można ustawić wybierając opcję "Znikające wiadomości" z menu kontaktu. Po wybraniu okresu czasu, obok numeru pojawi się zegar ze stosowną informacją: Wszystkie wiadomości które zostaną napisane przy widocznym zegarze znikną automatycznie po czasie, który wskazuje zegar. Po wysyłaniu wiadomości, każda z nich będzie miała ikonkę animowanej klepsydry, która jest w stanie wizualnie odliczać pozostały czas. Ten czas zostanie również ustawiony automatycznie na drugim końcu połączenia. Konfiguracja diody powiadomień Ciekawą opcją jest też konfiguracja diody powiadomień. W przypadku standardowych SMS'ów czy nieodebranych połączeń nie mamy zwykle możliwości konfiguracji tej diody, a konkretnie chodzi o sposób (częstotliwość) jej migania. Dodatkowo jeśli nasz smartfon posiada wielokolorową diodę, to możemy także wybrać sobie i kolor. Ochrona ekranu przed robieniem zrzutów Co ciekawe, gdy aplikacja Signal jest na pierwszym planie, nie działa możliwość robienia zrzutów ekranu. W sumie jest to ciekawa opcja. Jakby nie patrzeć może i nasze wiadomości są przesyłane i przechowywane w formie zaszyfrowanej ale można by spróbować je wydobyć robiąc właśnie zrzut ekranu. Tę opcję ochrony można naturalnie wyłączyć w ustawieniach samej aplikacji ale nie zalecałbym tego robić. Mając włączoną ochronę ekranu, żadna aplikacja ani nawet skrót przycisków Power + VolDown nie będą w stanie zrobić zrzutu ekranu. Oczywiście po zminimalizowaniu czy zamknięciu aplikacji Signal, skrin będzie można już wykonać bez większego problemu. Dla kogo jest przeznaczona aplikacja Signal Gdy pierwszy raz usłyszałem o aplikacji Signal, to od razu wiedziałem, że jest to jeden z tych programików, które zagoszczą w moim smartfonie na stałe. Nie chodzi tutaj o to, że moje rozmowy ze Snowden'em czy szefem NSA są jakoś ściśle tajne i nie powinny ujrzeć światła dziennego ale moim zdaniem sieć GSM to przeżytek. Popatrzmy jak obecnie wygląda komunikacja przez Internet. Możemy rozmawiać w bezpieczny sposób szyfrując połączenie między dwoma punktami i praktycznie nie ponosimy z tego tytułu żadnych opłat, tj. ani nie płacimy za szyfrowanie, ani też za czas połączenia bez znaczenia przy tym gdzie znajduje się nasz rozmówca. A jak wygląda sprawa w przypadku sieci GSM (pomińmy już kwestię braku przyzwoitych zabezpieczeń E2E)? Spróbujmy pogadać przez telefon z kimś z US czy Rosji. Ile nas wyniesie rachunek za tego typu konwersację? Nawet te paru minutowe rozmowy mogą kosztować fortunę. Teraz, gdy upowszechnieniu uległy sieci bezprzewodowe WiFi (min. darmowe hotspoty) i LTE (choć ten zależy od operatora GSM), to nasze komórki mogą być praktycznie non stop podłączone do Internetu. Nawet jeśli nie mamy w okolicy żadnego punktu WiFi czy BTS'a z LTE, to w dalszym ciągu możemy korzystać z 3G w postaci darmowego połączenia od Aero2 (gdyby tylko zlikwidowali ten wredny kod CAPTCHA) i koszt telefonu (rozmowy głosowe, SMS i MMS) zostaje zredukowany praktycznie do 0 i to przy jednoczesnym wzroście prywatności użytkowników. Jeśli zależy nam na prywatności, to już dziś powinniśmy sobie tę aplikację Signal zainstalować i zacząć namawiać do tego swoich znajomych.
  9. Ten temat, choć w dalszym ciągu aktualny, zawiera sporo informacji zbędnych przeciętnemu użytkownikowi przeprowadzającemu proces root Androida w swoim smartfonie. Dlatego też powstała uproszczona wersja tego tutoriala wykorzystująca natywne obrazy TWRP, co daje możliwość ukorzenienia Androida w kilku prostych krokach. Link do nowego HowTO. Bawiąc się ostatnio smartfonem Neffos C5 MAX od TP-LINK, obiecałem sobie, że jak tylko będę miał chwilę czasu, to postaram się ukorzenić Androida, który w tym telefonie siedzi (Lollipop). Generalnie rzecz biorąc, sposób root'owania tego urządzenia jest bardzo podobny do tego, który miałem już możliwość przeprowadzić na innym modelu TP-LINK'a, tj. Neffos C5. Dlatego też poniższy artykuł jest bardzo zbliżony treścią, choć lekko zaktualizowany pod kątem Neffos'a C5 MAX. Grunt, że nie było żadnych problemów z przeprowadzeniem backup'u flash'a telefonu jak i samego procesu root. Narzędzia ADB i fastboot Przede wszystkim, by zabrać się za proces root'owania smartfona Neffos C5 MAX, musimy przygotować sobie odpowiednie narzędzia. Zapewnią one nam możliwość rozmawiania z telefonem. Będziemy potrzebować adb (Android Debug Bridge) oraz fastboot . Proces instalacji tych narzędzi na linux, a konkretnie w dystrybucji Debian, został opisany osobno. Narzędzie SP Flash Tool Kolejnym narzędziem, które będzie nam niezbędne jest SP Flash Tool. Niestety nie jest ono włączone do dystrybucji Debian i musimy posiłkować się paczką, którą można znaleźć w podanym wyżej linku. Tutaj ważna uwaga. SP FLash Tool jest przeznaczony tylko dla smartfonów mających SoC od Mediatek. Pobieramy paczkę .zip dla linux'a i wypakowujemy ją. Jako, że SP Flash Tool wykorzystuje do komunikacji interfejs /dev/ttyACM0 , to do poprawnej pracy wymaga on operowania na tym interfejsie. Standardowo tylko administrator systemu oraz członkowie grupy dialout są w stanie korzystać z tego interfejsu. Musimy zatem dodać naszego użytkownika do tej grupy w poniższy sposób: # gpasswd -a morfik dialout Kompletny backup flash'a Neffos C5 MAX Mając zainstalowane te powyższe narzędzia, możemy przejść do zrobienia backup'u całego flash'a, który jest w naszym smartfonie. Proces backup'u najprościej przeprowadzić za pomocą SP Flash Tool. Niemniej jednak, potrzebne nam są pewne informacje, które możemy uzyskać przy pomocy adb . Podpinamy zatem telefon do portu USB komputera i w terminalu wpisujemy poniższe polecenie: # adb shell cat /proc/partinfo Name Start Size pgpt 0x0000000000000000 0x0000000000080000 proinfo 0x0000000000080000 0x0000000000300000 nvram 0x0000000000380000 0x0000000000500000 protect1 0x0000000000880000 0x0000000000a00000 protect2 0x0000000001280000 0x0000000000a00000 lk 0x0000000001c80000 0x0000000000080000 para 0x0000000001d00000 0x0000000000080000 boot 0x0000000001d80000 0x0000000001000000 recovery 0x0000000002d80000 0x0000000001000000 logo 0x0000000003d80000 0x0000000000800000 expdb 0x0000000004580000 0x0000000000a00000 seccfg 0x0000000004f80000 0x0000000000080000 oemkeystore 0x0000000005000000 0x0000000000200000 secro 0x0000000005200000 0x0000000000600000 keystore 0x0000000005800000 0x0000000000800000 tee1 0x0000000006000000 0x0000000000500000 tee2 0x0000000006500000 0x0000000000500000 frp 0x0000000006a00000 0x0000000000100000 nvdata 0x0000000006b00000 0x0000000002000000 metadata 0x0000000008b00000 0x0000000002500000 system 0x000000000b000000 0x0000000100000000 cache 0x000000010b000000 0x0000000019000000 userdata 0x0000000124000000 0x0000000286780000 flashinfo 0x00000003aa780000 0x0000000001000000 sgpt 0x00000003ab780000 0x0000000000080000 Ten zwrócony wyżej wynik jest dla smartfona Neffos C5 MAX. W przypadku innych telefonów, ta tabelka może mieć inną postać i nie możemy kopiować z niej wartości jeśli mamy inne urządzenie. Generalnie rzecz biorąc, to te dane potrzebne nam są do zbudowania pliku scatter.txt , w oparciu o który działa SP Flash Tool. Ten plik to zwyczajna mapa przestrzeni flash'a telefonu, który podzielony jest na szereg widocznych wyżej partycji. Plik scatter.txt dla Neffos C5 MAX Tutaj znajduje się plik scatter.txt (mt6753-neffos-c5-max-tp-link-scatter.txt), który ja wykorzystałem do pracy z Neffos C5 MAX. Kluczowa sprawa, to opisanie każdej partycji. W sumie to musimy odpowiednio dostosować pole partition_index , które jest zwyczajnie kolejnym numerkiem. Z kolei w partition_name podajemy nazwę partycji, którą uzyskaliśmy przez adb . Dalej w linear_start_addr oraz physical_start_addr wpisujemy tę wartość, która została wypisana przez adb w kolumnie Start . Na podobnej zasadzie uzupełniamy partition_size , podając wartość, którą widzieliśmy w adb w kolumnie Size . I to w zasadzie wszystkie zmiany, które musimy wprowadzić do pliku scatter.txt . Póki co nie mam informacji co do pozostałych opcji w tym pliku, wiem tylko, że część z nich jest uzupełniana przez SP Flash Tool podczas przeprowadzania działań w tym programie. Tworzenie backupu Mając plik scatter.txt możemy go wskazać w SP Flash Tool. Przechodzimy zatem do katalogu z wypakowaną zawartością pobranej paczki i uruchamiamy SP Flash Tool wpisując w terminalu ./flash_tool . Powinniśmy zobaczyć okienko, z kilkoma zakładkami. Na jednej z nich widnie napis Download . W niej z kolei znajduje się pozycja Scatter-loading file . To tutaj musimy wskazać ścieżkę do pliku scatter.txt , który utworzyliśmy wcześniej: Teraz przechodzimy na zakładkę Readback i tam dodajemy nową pozycję w tabelce. To tutaj określamy przestrzeń flash'a w telefonie, która zostanie skopiowana na dysk komputera. Nas interesuje cały flash. Dlatego też początek ustawiamy na 0x0 , a koniec musimy obliczyć z danych dostarczanych przez adb . Interesuje nas ostatnia partycja. Ma ona początek na 0x3ab780000 , a jej rozmiar to 0x80000 . Te dwie wartości musimy do siebie dodać, w wyniku czego otrzymujemy 0x3ab800000 i to tę wartość wpisujemy w SP Flash Tool. Region określamy jako EMC_USER : Dodajemy również drugą pozycję, która zrobi nam backup preloader'a. Z tym, że tutaj wybieramy region EMMC_BOOT_1 i określamy początek jako 0x0 , a koniec jako 0x40000 : Teraz wyłączamy telefon. Następnie w SP Flash Tool aktywujemy proces backup'u Neffos'a C5 MAX przyciskając Read Back . Podłączamy telefon do portu USB komputera. Po chwili smartfon powinien nam zawibrować ale nie uruchomi się. Rozpocznie się za to kopiowanie danych z telefonu na dysk. Proces backup'u potrwa dłuższą chwilę. W moim przypadku trwało prawie dwie godziny (transfer na poziomie 3 MiB/s). Ten backup jest nas w stanie zabezpieczyć na wypadek popełnionych błędów przy flash'owaniu telefonu. Podejrzymy jeszcze ten obraz w fdisk/gdisk , by mieć absolutną pewność, że jest w nim faktyczna kopia flash'a Neffos'a C5 MAX: Jak odblokować bootloader w Neffos C5 MAX Mając zrobiony kompletny backup flash'a, możemy przejść do odblokowania bootloader'a. Chodzi o to, że na smartfonach zwykle jest ulokowana partycja /recovery/ . Na niej znajduje się oprogramowanie umożliwiające przeprowadzanie operacji na poziomie systemowym, np. backup lub też flash'owanie ROM'u. Problem w tym, że to oprogramowanie w standardzie zwykle za wiele nie potrafi i by przeprowadzić proces root'owania Androida, musimy pozyskać bardziej zaawansowany soft, np. ClockworkMod czy TWRP, i wgrać go na partycję /recovery/ . By to zrobić musimy pierw odblokować bootloader. Proces odblokowania bootloader'a usuwa wszystkie dane, które wgraliśmy na flash telefonu, tj. podczas odblokowywania jest inicjowany factory reset. Dane na karcie SD pozostają nietknięte. By ten proces zainicjować zaczynamy od przestawienia jednej opcji w telefonie. W tym celu musimy udać się w Ustawienia => Opcje Programistyczne i tam przełączyć Zdjęcie blokady OEM : Następnie wyłączamy telefon i włączamy go trzymając Volume Up + Power. Z menu wybieramy tryb fastboot. Następnie w terminalu wpisujemy poniższe polecenia: # fastboot devices 8HCMMZFI89ROBI9H fastboot # fastboot oem unlock Na ekranie smartfona powinno nam pokazać się poniższe ostrzeżenie: Unlock bootloader? If you unlock the bootloader, you will be able to install custom operating system software on this phone. A custom OS is not subject to the same testing as the original OS, and can cause your phone and installed application to stop working properly. To prevent unauthorized access to your personal data, unlocking the bootloader will also delete all personal data from your phone "factory reset". Press the Volume UP/Down buttons to select Yes/No. Wciskamy Volume Up, by potwierdzić chęć odblokowania bootloader'a, po czym restartujemy smartfon: # fastboot reboot Jako, że proces odblokowania bootloader'a usunął wszelkie ustawienia, to jeszcze raz musimy włączyć Opcje Programistyczne, a w nich tryb debugowania portu USB. Wyodrębnianie obrazu partycji /recovery/ z obrazu Neffos'a C5 MAX Mając zrobiony backup flash'a telefonu, możemy z niego wyciągnąć obraz partycji /recovery/ . Musimy tylko zamontować ten obraz w systemie za pomocą losetup . Pamiętajmy, że ten obraz ma wiele partycji. Trzeba zatem nieco dostosować moduł kernela, by wszystkie z tych partycji zostały zamontowane za pomocą jednego polecenia. Informacje na temat tego jak dostosować moduł loop znajdują się tutaj. Przechodzimy zatem w miejsce, w którym zapisaliśmy obraz i montujemy go w poniższy sposób: # cd /path/to/image/ # losetup /dev/loop0 ROM_0 Teraz tworzymy obraz partycji /recovery/ . W tym przypadku /dev/loop0p8 jest urządzeniem, które musimy podać dd : # dd if=/dev/loop0p8 of=./recovery.img # file recovery.img recovery.img: Android bootimg, kernel (0x40080000), ramdisk (0x44000000), page size: 2048, cmdline (bootopt=64S3,32N2,64N2) Pozyskanie obrazu recovery.img z TWRP Musimy także pozyskać obraz recovery.img zawierający TWRP. Niestety, póki co nie ma obrazów dla Neffos'a C5 MAX. Dlatego też musimy sobie taki obraz recovery.img stworzyć sami przerabiając inny obraz, który jest przeznaczony na telefon zbliżony parametrami do naszego urządzenia (ten sam SoC, wielkość flash i rozdzielczość ekranu). Tutaj znajduje się gotowy obraz recovery, który można wgrać na telefon (recovery-neffos-c5-max-tp-link-twrp.img). Warto tutaj zaznaczyć, że nie zawsze taki obraz będzie nam działać bez problemu. W takim przypadku trzeba próbować innych obrazów, aż któryś zadziała. Nie musimy się tez obawiać wgrania złego obrazu na partycję /recovery/ . Jeśli zdarzy nam się wgrać niedziałający obraz recovery.img , to nie uszkodzimy smartfona. Zamiast tego telefon się zrestartuje i przywróci sobie starą partycję /recovery/ , a nas zaloguje do systemu jak gdyby nigdy nic. Przepakowanie obrazu recovery.img z innego smartfona By przepakować obraz przeznaczony na inny smartfon, który jest zbliżony parametrami do naszego Neffos'a C5 MAX, musimy pierw pozyskać odpowiednie narzędzia. Na linux'ie możemy skorzystać tego celu z abootimg lub też ze skryptów Android Image Kitchen. Ja będę korzystał z tego drugiego rozwiązania. Tworzymy sobie jakiś katalog roboczy i kopiujemy do niego zarówno oryginalny obraz partycji /recovery/ jak i ten z innego smartfona. Następnie znajdując się w tym katalogu roboczym, pobieramy skrypty z github'a (wymagane zainstalowane narzędzie git w systemie) i przechodzimy do utworzonego w ten sposób katalogu. W nim zaś tworzymy dwa podkatalogi stock/ oraz port/ : $ git clone https://github.com/ndrancs/AIK-Linux-x32-x64/ $ chmod +x ./AIK-Linux-x32-x64/* $ chmod +x ./AIK-Linux-x32-x64/bin/* $ cd ./AIK-Linux-x32-x64/ $ mkdir stock/ port/ Kopiujemy oryginalny obraz partycji /recovery/ z katalogu nadrzędnego i wypakowujemy go za pomocą skryptu unpackimg.sh . Następnie przenosimy tak wyodrębnioną zawartość do katalogu stock/ : $ cp ../recovery_orig.img ./recovery.img $ ./unpackimg.sh recovery.img $ mv split_img/ ramdisk/ stock/ $ rm recovery.img Kopiujemy teraz obraz partycji /recovery/ mający TWRP i wypakowujemy go. Przenosimy jego zawartość do katalogu port/ : $ cp ../recovery_twrp.img ./recovery.img $ ./unpackimg.sh recovery.img $ mv split_img/ ramdisk/ port/ $ rm recovery.img Zgodnie z informacją zawartą w tym HOWTO (windows), musimy przekopiować kilka plików z oryginalnego obrazu naszego Neffos'a C5 MAX do obrazu TWRP: $ cp ./stock/split_img/recovery.img-kerneloff ./port/split_img/ $ cp ./stock/split_img/recovery.img-zImage ./port/split_img/ $ cp ./stock/ramdisk/fstab.mt6735 ./port/ramdisk/ $ cp ./stock/ramdisk/meta_init.modem.rc ./port/ramdisk/ $ cp ./stock/ramdisk/meta_init.project.rc ./port/ramdisk/ $ cp ./stock/ramdisk/meta_init.rc ./port/ramdisk/ $ cp ./stock/ramdisk/ueventd.rc ./port/ramdisk/ Z tak przygotowanych plików w katalogu port/ trzeba zrobić nowy obraz recovery.img przy pomocy skryptu repackimg_x64.sh : $ rm -R stock/ $ mv port/ramdisk ./ $ mv port/split_img ./ $ rmdir port/ $ ./repackimg_x64.sh W katalogu roboczym powinien zostać utworzony nowy plik o nazwie image-new.img . To jest właśnie nasz nowy obraz partycji /recovery/ , który musimy wgrać na telefon w trybie fastboot. Wgrywanie przepakowanego obrazu recovery.img na Neffos'a C5 MAX Wyłączamy telefon i podpinamy go do portu USB. Następnie włączamy go trzymając VolumeUP + Power. Z menu, które nam się pokaże na ekranie telefonu wybieramy tryb fastboot. Wracamy na komputer i przy pomocy narzędzia fasboot wgrywamy wyżej wygenerowany obraz na telefon. # fastboot flash recovery image-new.img target reported max download size of 134217728 bytes sending 'recovery' (12868 KB)... OKAY [ 1.125s] writing 'recovery'... OKAY [ 0.360s] finished. total time: 1.485s Restartujemy telefon ( fastboot reboot ) i wchodzimy w tryb recovery (VolumeUp + Power), by potwierdzić, że nasz nowy obraz recovery się wgrał pomyślnie. W przypadku wgrania poprawnego obrazu, powinniśmy zobaczyć logo TWRP. Jeśli wgrany obraz był nieprawidłowy, to zobaczymy jedynie czarny ekran i nasz Neffos C5 MAX się po chwili uruchomi ponownie w normalnym trybie przywracając oryginalną partycję /recovery/ . SuperSU, BusyBOX, RootCheck i emulator terminala Ostatnią rzeczą na drodze do zrobienia root na Neffos C5 MAX jest wgranie aplikacji umożliwiającej korzystanie różnym programom z praw administratora systemu w telefonie. My skorzystamy z SuperSU. Dodatkowo, musimy wgrać sobie BusyBOX, który zawiera minimalistyczne odpowiedniki linux'owych narzędzi, co pozwoli nam swobodnie operować w Androidzie, tak jakbyśmy to robili pod pełnowymiarowym pingwinem. Potrzebny nam także będzie jakiś emulator terminala, w którym to będziemy wpisywać wszystkie nasze polecenia. Instalacja SuperSU Zacznijmy od pobrania stosownej paczki z SuperSU. Jako, że my nie mamy jeszcze zrobionego root'a, to musimy pobrać TWRP / FlashFire installable ZIP . Tej paczki nie wypakowujemy, tylko wrzucamy ją w pobranej formie na kartę SD w telefonie. Odpalamy teraz tryb recovery w smartfonie (VolumeUp + Power) i przechodzimy do Instaluj (TWRP jest również w języku polskim): Następnie wskazujemy paczkę .zip , którą umieściliśmy na karcie SD. Tam z kolei zaznaczamy Weryfikuj sygnatury pliku zip i przeciągamy trzy strzałki na prawą stronę. Teraz możemy uruchomić ponownie Neffos'a C5 MAX i zainstalować jakąś aplikację, która pokaże nam czy nasz smartfon ma root'a. Sprawdzenie czy Neffos C5 MAX ma root'a Po uruchomieniu się systemu na smartfonie, instalujemy aplikację RootCheck, po czym uruchamiamy ją. Powinien się pojawić monit informujący, że ta aplikacja żąda praw administracyjnych, na co zezwalamy. Jeśli nasz telefon ma root'a, to powinien się pojawić stosowny komunikat: Instalacja BusyBOX Kolejnym krokiem jest instalacja BusyBOX'a. Po wgraniu tej aplikacji na smartfona, musimy ją uruchomić i wcisnąć w niej przycisk install . BusyBOX również nas poprosi o dostęp do praw administracyjnych: Po zainstalowaniu, weryfikujemy jeszcze, czy aby wszystko zostało pomyślne wgrane. Możemy to zrobić zarówno w samej aplikacji BusyBOX, jak i w CheckRoot: Instalacja terminala Z BusyBOX'em zostały dostarczone niskopoziomowe narzędzia, które mogą korzystać z uprawnień administratora systemu za sprawą SuperSU. Niemniej jednak, by móc odpalać te programiki, musimy w czymś je uruchomić. Do tego celu potrzebny jest nam shell oraz emulator terminala. Domyślny shell ash jest dostarczany razem z BusyBOX. Terminal musimy doinstalować osobno. Generalnie to znalazłem dwa terminale, które są OpenSource i bez reklam/opłat. Są to Android-Terminal-Emulator oraz Termux. Wybieramy sobie jeden z nich i instalujemy w systemie. Tutaj warto jeszcze zaznaczyć, że ten drugi terminal instaluje sobie również shell dash (domyślny shell w Debianie) . Również w jego przypadku możemy łatwo doinstalować sobie aplikacje za pomocą apt , podobnie jak w Debianie (do tego celu nie jest wymagany root). Jako, że ja korzystam na co dzień z Debiana, to instaluje Termux'a. Aplikacje i prawa administracyjne Teraz już pozostało nam tylko odpalenie terminala i zalogowanie się na użytkownika root. Do tego celu służy polecenie su . Wpiszmy je zatem w okienku Termux'a: I teraz możemy uruchamiać aplikacjie z prawami admina, tak jak to zwykliśmy robić w każdym innym linux'ie. Pamiętajmy tylko, że standardowo system plików jest zamontowany w trybie tylko do odczytu (RO) i by móc zmieniać pliki systemowe z poziomu tego terminala, musimy przemontować system plików w tryb do zapisu (RW). Robimy to w poniższy sposób: $ su # mount -o remount,rw /system Gdy skończymy się bawić, to montujemy ten system plików ponownie w tryb RO: # mount -o remount,ro /system
  10. Ten temat, choć w dalszym ciągu aktualny, zawiera sporo informacji zbędnych przeciętnemu użytkownikowi przeprowadzającemu proces root Androida w swoim smartfonie. Dlatego też powstała uproszczona wersja tego tutoriala wykorzystująca natywne obrazy TWRP, co daje możliwość ukorzenienia Androida w kilku prostych krokach. Link do nowego HowTO. Smartfony mają to do siebie, że ogromna większość z nich pracuje pod kontrolą systemu linux, a konkretnie jest to jakiś Android. Tak też jest w przypadku Neffos'a C5 od TP-LINK, gdzie mamy zainstalowaną wersję 5.1 (Lollipop). My linux'iarze chcemy mieć pełny dostęp do systemu operacyjnego, by bez większych przeszkód móc zarządzać urządzeniem, które pod jego kontrolą pracuje. Problem w tym, że ten Neffos C5 nie ma w standardzie root'a i nie mamy administracyjnego dostępu do całego systemu plików telefonu. Jest kilka metod root'owania smartfona, np. za pomocą Kingoroot/Kingroot ale nie działają one w przypadku tego telefonu (i całe szczęście). W tym artykule zostanie pokazany sposób na root systemu Neffos'a C5 przy zachowaniu wszelkich norm bezpieczeństwa, które w sytuacjach podbramkowych pomogą nam odzyskać kontrolę nad telefonem. Narzędzia ADB i fastboot Przede wszystkim, by zabrać się za proces root'owania smartfona Neffos C5, musimy przygotować sobie odpowiednie narzędzia. Zapewnią one nam możliwość rozmawiania z telefonem. Będziemy potrzebować adb (Android Debug Bridge) oraz fastboot . Proces instalacji tych narzędzi na linux, a konkretnie w dystrybucji Debian, został opisany osobno. Narzędzie SP Flash Tool Kolejnym narzędziem, które będzie nam niezbędne jest SP Flash Tool. Niestety nie jest ono włączone do dystrybucji Debian i musimy posiłkować się paczką, którą można znaleźć w podanym wyżej linku. Tutaj ważna uwaga. SP FLash Tool jest przeznaczony tylko dla smartfonów mających SoC od Mediatek. Pobieramy paczkę .zip dla linux'a i wypakowujemy ją. Jako, że SP Flash Tool wykorzystuje do komunikacji interfejs /dev/ttyACM0 , to do poprawnej pracy wymaga on operowania na tym interfejsie. Standardowo tylko administrator systemu oraz członkowie grupy dialout są w stanie korzystać z tego interfejsu. Musimy zatem dodać naszego użytkownika do tej grupy w poniższy sposób: # gpasswd -a morfik dialout Kompletny backup flash'a Neffos C5 Mając zainstalowane te powyższe narzędzia, możemy przejść do zrobienia backup'u całego flash'a, który jest w naszym smartfonie. Proces backup'u najprościej przeprowadzić za pomocą SP Flash Tool. Niemniej jednak, potrzebne nam są pewne informacje, które możemy uzyskać przy pomocy adb . Podpinamy zatem telefon do portu USB komputera i w terminalu wpisujemy poniższe polecenie: # adb shell cat /proc/partinfo Name Start Size pgpt 0x0000000000000000 0x0000000000080000 proinfo 0x0000000000080000 0x0000000000300000 nvram 0x0000000000380000 0x0000000000500000 protect1 0x0000000000880000 0x0000000000a00000 protect2 0x0000000001280000 0x0000000000a00000 lk 0x0000000001c80000 0x0000000000080000 para 0x0000000001d00000 0x0000000000080000 boot 0x0000000001d80000 0x0000000001000000 recovery 0x0000000002d80000 0x0000000001000000 logo 0x0000000003d80000 0x0000000000800000 expdb 0x0000000004580000 0x0000000000a00000 seccfg 0x0000000004f80000 0x0000000000080000 oemkeystore 0x0000000005000000 0x0000000000200000 secro 0x0000000005200000 0x0000000000600000 keystore 0x0000000005800000 0x0000000000800000 tee1 0x0000000006000000 0x0000000000500000 tee2 0x0000000006500000 0x0000000000500000 frp 0x0000000006a00000 0x0000000000100000 nvdata 0x0000000006b00000 0x0000000002000000 metadata 0x0000000008b00000 0x0000000002500000 system 0x000000000b000000 0x0000000100000000 cache 0x000000010b000000 0x0000000019000000 userdata 0x0000000124000000 0x000000027ed80000 flashinfo 0x00000003a2d80000 0x0000000001000000 sgpt 0x00000003a3d80000 0x0000000000080000 Ten zwrócony wyżej wynik jest dla smartfona Neffos C5. W przypadku innych telefonów, ta tabelka może mieć inną postać i nie możemy kopiować z niej wartości jeśli mamy inne urządzenie. Generalnie rzecz biorąc, to te dane potrzebne nam są do zbudowania pliku scatter.txt , w oparciu o który działa SP Flash Tool. Ten plik to zwyczajna mapa przestrzeni flash'a telefonu, który podzielony jest na szereg widocznych wyżej partycji. Plik scatter.txt dla Neffos C5 Tutaj znajduje się plik scatter.txt, który ja wykorzystałem do pracy z Neffos C5 (mt6735-neffos-c5-tp-link-scatter.txt). Kluczowa sprawa, to opisanie każdej partycji. W sumie to musimy odpowiednio dostosować pole partition_index , które jest zwyczajnie kolejnym numerkiem. Z kolei w partition_name podajemy nazwę partycji, którą uzyskaliśmy przez adb . Dalej w linear_start_addr oraz physical_start_addr wpisujemy tę wartość, która została wypisana przez adb w kolumnie Start . Na podobnej zasadzie uzupełniamy partition_size , podając wartość, którą widzieliśmy w adb w kolumnie Size . I to w zasadzie wszystkie zmiany, które musimy wprowadzić do pliku scatter.txt . Póki co nie mam informacji co do pozostałych opcji w tym pliku, wiem tylko, że część z nich jest uzupełniana przez SP Flash Tool podczas przeprowadzania działań w tym programie. Tworzenie backupu Mając plik scatter.txt możemy go wskazać w SP Flash Tool. Przechodzimy zatem do katalogu z wypakowaną zawartością pobranej paczki i uruchamiamy SP Flash Tool wpisując w terminalu ./flash_tool . Powinniśmy zobaczyć okienko, z kilkoma zakładkami. Na jednej z nich widnie napis Download . W niej z kolei znajduje się pozycja Scatter-loading file . To tutaj musimy wskazać ścieżkę do pliku scatter.txt , który utworzyliśmy wcześniej: Teraz przechodzimy na zakładkę Readback i tam dodajemy nową pozycję w tabelce. To tutaj określamy przestrzeń flash'a w telefonie, która zostanie skopiowana na dysk komputera. Nas interesuje cały flash. Dlatego też początek ustawiamy na 0x0 , a koniec musimy obliczyć z danych dostarczanych przez adb . Interesuje nas ostatnia partycja. Ma ona początek na 0x3a3d80000 , a jej rozmiar to 0x80000 . Te dwie wartości musimy do siebie dodać, w wyniku czego otrzymujemy 0x3a3e00000 i to tę wartość wpisujemy w SP Flash Tool. Region określamy jako EMC_USER : Dodajemy również drugą pozycję, która zrobi nam backup preloader'a. Z tym, że tutaj wybieramy region EMMC_BOOT_1 i określamy początek jako 0x0 , a koniec jako 0x40000 : Teraz wyłączamy telefon i podłączamy go do portu USB komputera. Następnie w SP Flash Tool aktywujemy proces backup'u Neffos'a C5 przyciskając Read Back . Włączamy teraz telefon przyciskając i trzymając przycisk Volume Up + Power do momentu aż nam zawibruje. Smartfon się nie włączy ale za to rozpocznie się kopiowanie danych z telefonu na dysk. Proces backup'u potrwa dłuższą chwilę. W moim przypadku trwało prawie dwie godziny (transfer na poziomie 3 MiB/s). Ten backup jest nas w stanie zabezpieczyć na wypadek popełnionych błędów przy flash'owaniu telefonu. Podejrzymy jeszcze ten obraz w fdisk/gdisk , by mieć absolutną pewność, że jest w nim faktyczna kopia flash'a Neffos'a C5: Jak odblokować bootloader w Neffos C5 Mając zrobiony kompletny backup flash'a, możemy przejść do odblokowania bootloader'a. Chodzi o to, że na smartfonach zwykle jest ulokowana partycja /recovery/ . Na niej znajduje się oprogramowanie umożliwiające przeprowadzanie operacji na poziomie systemowym, np. backup lub też flash'owanie ROM'u. Problem w tym, że to oprogramowanie w standardzie zwykle za wiele nie potrafi i by przeprowadzić proces root'owania Androida, musimy pozyskać bardziej zaawansowany soft, np. ClockworkMod czy TWRP, i wgrać go na partycję /recovery/ . By to zrobić musimy pierw odblokować bootloader. Proces odblokowania bootloader'a usuwa wszystkie dane, które wgraliśmy na flash telefonu, tj. podczas odblokowywania jest inicjowany factory reset. Dane na karcie SD pozostają nietknięte. By ten proces zainicjować zaczynamy od przestawienia jednej opcji w telefonie. W tym celu musimy udać się w Ustawienia => Opcje Programistyczne i tam przełączyć Zdjęcie blokady OEM : Następnie wyłączamy telefon i włączamy go trzymając Volume Up + Power. Z menu wybieramy tryb fastboot. Następnie w terminalu wpisujemy poniższe polecenia: # fastboot devices TSL7DA69OBSO49PJ fastboot # fastboot oem unlock Na ekranie smartfona powinno nam pokazać się poniższe ostrzeżenie: Unlock bootloader? If you unlock the bootloader, you will be able to install custom operating system software on this phone. A custom OS is not subject to the same testing as the original OS, and can cause your phone and installed application to stop working properly. To prevent unauthorized access to your personal data, unlocking the bootloader will also delete all personal data from your phone "factory reset". Press the Volume UP/Down buttons to select Yes/No. Wciskamy Volume Up, by potwierdzić chęć odblokowania bootloader'a, po czym restartujemy smartfon: # fastboot reboot Jako, że proces odblokowania bootloader'a usunął wszelkie ustawienia, to jeszcze raz musimy włączyć Opcje programistyczne, a w nich tryb debugowania portu USB. Wyodrębnianie obrazu partycji /recovery/ z obrazu Neffos'a C5 Mając zrobiony backup flash'a telefonu, możemy z niego wyciągnąć obraz partycji /recovery/ . Musimy tylko zamontować ten obraz w systemie za pomocą losetup . Pamiętajmy, że ten obraz ma wiele partycji. Trzeba zatem nieco dostosować moduł kernela, by wszystkie z tych partycji zostały zamontowane za pomocą jednego polecenia. Informacje na temat tego jak dostosować moduł loop znajdują się tutaj. Przechodzimy zatem w miejsce, w którym zapisaliśmy obraz i montujemy go w poniższy sposób: # cd /path/to/image/ # losetup /dev/loop0 ROM_0 Teraz tworzymy obraz partycji /recovery/ . W tym przypadku /dev/loop0p8 jest urządzeniem, które musimy podać dd : # dd if=/dev/loop0p8 of=./recovery.img # file recovery.img recovery.img: Android bootimg, kernel (0x40080000), ramdisk (0x44000000), page size: 2048, cmdline (bootopt=64S3,32N2,64N2) Pozyskanie obrazu recovery.img z TWRP Musimy także pozyskać obraz recovery.img zawierający TWRP. Niestety, póki co nie ma obrazów dla Neffos'a C5. Dlatego też musimy sobie taki obraz recovery.img stworzyć sami przerabiając inny obraz, który jest przeznaczony na telefon zbliżony parametrami do naszego urządzenia (ten sam SoC, wielkość flash i rozdzielczość ekranu). Warto tutaj zaznaczyć, że nie zawsze taki obraz będzie nam działać bez problemu. W takim przypadku trzeba próbować innych obrazów, aż któryś zadziała. Nie musimy się tez obawiać wgrania złego obrazu na partycję /recovery/ . Jeśli zdarzy nam się wgrać niedziałający obraz recovery.img , to nie uszkodzimy smartfona. Zamiast tego telefon się zrestartuje i przywróci sobie starą partycję /recovery/ , a nas zaloguje do systemu jak gdyby nigdy nic. Moje pierwsze podejście do wgrania obrazu recovery.img na Neffos'a C5 się nie powiodło. Prawdopodobnie obraz nie był odpowiednio przygotowany i w efekcie trzeba było wgrać inny obraz. Ja skorzystałem z obrazu podrzuconego przez użytkownika @GWJ. Musiałem go tylko dostosować pod Neffos'a C5 (recovery-neffos-c5-tp-link-twrp.img). Przepakowanie obrazu recovery.img z innego smartfona By przepakować obraz przeznaczony na inny smartfon, który jest zbliżony parametrami do naszego Neffos'a C5, musimy pierw pozyskać odpowiednie narzędzia. Na linux'ie możemy skorzystać tego celu z abootimg lub też ze skryptów Android Image Kitchen. Ja będę korzystał z tego drugiego rozwiązania. Tworzymy sobie jakiś katalog roboczy i kopiujemy do niego zarówno oryginalny obraz partycji /recovery/ jak i ten z innego smartfona. Następnie znajdując się w tym katalogu roboczym, pobieramy skrypty z github'a (wymagane zainstalowane narzędzie git w systemie) i przechodzimy do utworzonego w ten sposób katalogu. W nim zaś tworzymy dwa podkatalogi stock/ oraz port/ : $ git clone https://github.com/ndrancs/AIK-Linux-x32-x64/ $ chmod +x ./AIK-Linux-x32-x64/* $ chmod +x ./AIK-Linux-x32-x64/bin/* $ cd ./AIK-Linux-x32-x64/ $ mkdir stock/ port/ Kopiujemy oryginalny obraz partycji /recovery/ z katalogu nadrzędnego i wypakowujemy go za pomocą skryptu unpackimg.sh . Następnie przenosimy tak wyodrębnioną zawartość do katalogu stock/ : $ cp ../recovery_orig.img ./recovery.img $ ./unpackimg.sh recovery.img $ mv split_img/ ramdisk/ stock/ $ rm recovery.img Kopiujemy teraz obraz partycji /recovery/ mający TWRP i wypakowujemy go. Przenosimy jego zawartość do katalogu port/ : $ cp ../recovery_twrp.img ./recovery.img $ ./unpackimg.sh recovery.img $ mv split_img/ ramdisk/ port/ $ rm recovery.img Zgodnie z informacją zawartą w tym HOWTO (windows), musimy przekopiować kilka plików z oryginalnego obrazu naszego Neffos'a C5 do obrazu TWRP: $ cp ./stock/split_img/recovery.img-kerneloff ./port/split_img/ $ cp ./stock/split_img/recovery.img-zImage ./port/split_img/ $ cp ./stock/ramdisk/fstab.mt6735 ./port/ramdisk/ $ cp ./stock/ramdisk/meta_init.modem.rc ./port/ramdisk/ $ cp ./stock/ramdisk/meta_init.project.rc ./port/ramdisk/ $ cp ./stock/ramdisk/meta_init.rc ./port/ramdisk/ $ cp ./stock/ramdisk/ueventd.rc ./port/ramdisk/ Z tak przygotowanych plików w katalogu port/ trzeba zrobić nowy obraz recovery.img przy pomocy skryptu repackimg_x64.sh : $ rm -R stock/ $ mv port/ramdisk ./ $ mv port/split_img ./ $ rmdir port/ $ ./repackimg_x64.sh W katalogu roboczym powinien zostać utworzony nowy plik o nazwie image-new.img . To jest właśnie nasz nowy obraz partycji /recovery/ , który musimy wgrać na telefon w trybie fastboot. Wgrywanie przepakowanego obrazu recovery.img na Neffos'a C5 Wyłączamy telefon i podpinamy go do portu USB. Następnie włączamy go trzymając VolumeUP + Power. Z menu, które nam się pokaże na ekranie telefonu wybieramy tryb fastboot. Wracamy na komputer i przy pomocy narzędzia fasboot wgrywamy wyżej wygenerowany obraz na telefon. # fastboot flash recovery image-new.img target reported max download size of 134217728 bytes sending 'recovery' (12642 KB)... OKAY [ 1.301s] writing 'recovery'... OKAY [ 0.279s] finished. total time: 1.580s Restartujemy telefon ( fastboot reboot ) i wchodzimy w tryb recovery (VolumeUp + Power), by potwierdzić, że nasz nowy obraz recovery się wgrał pomyślnie. W przypadku wgrania poprawnego obrazu, powinniśmy zobaczyć logo TWRP. Jeśli wgrany obraz był nieprawidłowy, to zobaczymy jedynie czarny ekran i nasz Neffos C5 się po chwili uruchomi ponownie w normalnym trybie przywracając oryginalną partycję /recovery/ . SuperSU, BusyBOX, RootCheck i emulator terminala Ostatnią rzeczą na drodze do zrobienia root na Neffos C5 jest wgranie aplikacji umożliwiającej korzystanie różnym programom z praw administratora systemu w telefonie. My skorzystamy z SuperSU. Dodatkowo, musimy wgrać sobie BusyBOX, który zawiera minimalistyczne odpowiedniki linux'owych narzędzi, co pozwoli nam swobodnie operować w Androidzie, tak jakbyśmy to robili pod pełnowymiarowym pingwinem. Potrzebny nam także będzie jakiś emulator terminala, w którym to będziemy wpisywać wszystkie nasze polecenia. Instalacja SuperSU Zacznijmy od pobrania stosownej paczki z SuperSU. Jako, że my nie mamy jeszcze zrobionego root'a, to musimy pobrać TWRP / FlashFire installable ZIP . Tej paczki nie wypakowujemy, tylko wrzucamy ją w pobranej formie na kartę SD w telefonie. Odpalamy teraz tryb recovery w smartfonie (VolumeUp + Power) i przechodzimy kolejno do Instaluj (TWRP jest również w języku polskim): Następnie wskazujemy paczkę .zip , którą umieściliśmy na karcie SD. Tam z kolei zaznaczamy Weryfikuj sygnatury pliku zip i przeciągamy trzy strzałki na prawą stronę. Teraz możemy uruchomić ponownie Neffos'a C5 i zainstalować jakąś aplikację, która pokaże nam czy nasz smartfon ma root'a. Sprawdzenie czy Neffos C5 ma root'a Po uruchomieniu się systemu na smartfonie, instalujemy aplikację RootCheck, po czym uruchamiamy ją. Powinien się pojawić monit informujący, że ta aplikacja żąda praw administracyjnych, na co zezwalamy. Jeśli nasz telefon ma root'a, to powinien się pojawić stosowny komunikat: Instalacja BusyBOX Kolejnym krokiem jest instalacja BusyBOX'a. Po wgraniu tej aplikacji na smartfona, musimy ją uruchomić i wcisnąć w niej przycisk install . BusyBOX również nas poprosi o dostęp do praw administracyjnych: Po zainstalowaniu, weryfikujemy jeszcze, czy aby wszystko zostało pomyślne wgrane. Możemy to zrobić zarówno w samej aplikacji BusyBOX, jak w w CheckRoot: Instalacja terminala Z BusyBOX'em zostały dostarczone niskopoziomowe narzędzia, które mogą korzystać z uprawnień administratora systemu za sprawą SuperSU. Niemniej jednak, by móc odpalać te programiki, musimy w czymś je uruchomić. Do tego celu potrzebny jest nam shell oraz emulator terminala. Domyślny shell ash jest dostarczany razem z BusyBOX. Terminal musimy doinstalować osobno. Generalnie to znalazłem dwa terminale, które są OpenSource i bez reklam/opłat. Są to Android-Terminal-Emulator oraz Termux. Wybieramy sobie jeden z nich i instalujemy w systemie. Tutaj warto jeszcze zaznaczyć, że ten drugi terminal instaluje sobie również shell dash (domyślny shell w Debianie) . Również w jego przypadku możemy łatwo doinstalować sobie aplikacje za pomocą apt , podobnie jak w Debianie (do tego celu nie jest wymagany root). Jako, że ja korzystam na co dzień z Debiana, to instaluje Termux'a. Aplikacje i prawa administracyjne Teraz już pozostało nam tylko odpalenie terminala i zalogowanie się na użytkownika root. Do tego celu służy polecenie su . Wpiszmy je zatem w okienku Termux'a: I teraz możemy uruchamiać aplikacjie z prawami admina, tak jak to zwykliśmy robić w każdym innym linux'ie. Pamiętajmy tylko, że standardowo system plików jest zamontowany w trybie tylko do odczytu (RO) i by móc zmieniać pliki systemowe z poziomu tego terminala, musimy przemontować system plików w tryb do zapisu (RW). Robimy to w poniższy sposób: $ su # mount -o remount,rw /system Gdy skończymy się bawić, to montujemy ten system plików ponownie w tryb RO: # mount -o remount,ro /system
  11. Ten temat, choć w dalszym ciągu aktualny, zawiera sporo informacji zbędnych przeciętnemu użytkownikowi przeprowadzającemu proces root Androida w swoim smartfonie. Dlatego też powstała uproszczona wersja tego tutoriala wykorzystująca natywne obrazy TWRP, co daje możliwość ukorzenienia Androida w kilku prostych krokach. Link do nowego HowTO. Może i ten najtańszy smartfon w ofercie TP-LINK nie może popisać się najmocniejszymi podzespołami ale w zasadzie ten fakt nie przeszkadza nam, by przeprowadzić na Neffos Y5L (TP801A) proces root. Ten smartfon ma zbliżony SoC do Neffos Y5, a konkretnie mamy tutaj do czynienia z Snapdragon 210 (MSM8209) od Qualcomm'a. Ten fakt sprawia, że w przypadku Neffos Y5L cały proces uzyskiwania uprawnień administratora systemu przebiega bardzo podobnie do tego opisywanego wcześniej dla Neffos Y5. Dlatego też poniższy artykuł za bardzo się nie różni i w zasadzie został jedynie lekko przerobiony pod kątem zgodności ze smartfonem Neffos Y5L. Narzędzia ADB i fastboot Przede wszystkim, by zabrać się za proces root'owania smartfona Neffos Y5L, musimy przygotować sobie odpowiednie narzędzia. Zapewnią one nam możliwość rozmawiania z telefonem. Będziemy potrzebować adb (Android Debug Bridge) oraz fastboot . Proces instalacji tych narzędzi na linux, a konkretnie w dystrybucji Debian, został opisany osobno. Problematyczny backup flash'a smartfona Neffos Y5L W przypadku Neffos C5 i Neffos C5 MAX, do zrobienia backup'u całego flash'a można było wykorzystać narzędzie SP Flash Tool. Niemniej jednak, to oprogramowanie jest przeznaczone jedynie dla smartfonów mających SoC od MediaTek, a jak już zostało wspomniane we wstępie, Neffos Y5L ma SoC Snapdragon 210 (MSM8209) od Qualcomm'a. Jak zatem zrobić backup flash'a tego smartfona przed wprowadzaniem w nim jakichkolwiek zmian? Generalnie trzeba się zmierzyć z problemem jajka i kury, czyli by dokonać backup'u flash'a trzeba skorzystać z niestandardowego obrazu partycji /recovery/ , np. TWRP, a nie możemy go przecież wgrać na telefon, bo wprowadzimy w ten sposób zmiany. Możemy jednak wgrać taki obraz bezpośrednio do pamięci RAM telefonu i z niej go uruchomić. W takim przypadku będziemy w stanie zrobić backup flash'a telefonu bez wprowadzania żadnych zmian. Niemniej jednak, w dalszym ciągu obraz partycji /recovery/ musimy jakoś pozyskać. Pozyskanie obrazu recovery.img z TWRP Niestety, póki co nie ma obrazów dla Neffos'a Y5L. Dlatego też musimy sobie taki obraz recovery.img stworzyć sami przerabiając inny obraz, który jest przeznaczony na telefon zbliżony parametrami do naszego urządzenia (ten sam SoC, wielkość flash i rozdzielczość ekranu). Ja posłużyłem się obrazem dla Neffos'a C5L, którego SoC (MSM8909) jest bardzo podobny do tego zastosowanego w Neffos Y5L. W zasadzie rozdziałka ekranu i wielkość flash się zgadzają ale układ partycji jest nieco inny i trzeba będzie ten obraz trochę przerobić, a do tego celu potrzebny nam będzie stock'owy obraz boot.img lub recovery.img . Gotowy obraz recovery.img dla smartfona Neffos Y5L znajduje się tutaj: neffos_y5l-tp-link-twrp.img Jedyne co, to musimy go wgrać na telefon. Jeśli jednak ktoś jest ciekaw jak proces przepakowania tego obrazu przebiega, to jest on opisany poniżej. Pozyskanie stock'owego obrazu boot/recovery Proces dostosowania obrazu recovery.img z TWRP nieco się różni w przypadku Neffos Y5L w stosunku do poprzednio opisywanych przez mnie modeli Neffos C5 i Neffos C5 MAX ale jest mniej więcej taki sam co w przypadku Neffos Y5. Chodzi o to, że w zasadzie nie mamy jak wydobyć obrazu partycji /recovery/ z telefonu, no bo przecież nie możemy skorzystać z SP Flash Tool, a póki co nie jestem świadom alternatywnego oprogramowania, które by nam z tym zadaniem pomogło w podobny sposób. Niemniej jednak, obraz recovery.img w dalszym ciągu możemy zbudować ale potrzebny nam jest firmware Neffos'a Y5L, który na szczęście możemy pobrać ze strony producenta tego smartfona. Pamiętajmy by pobrać plik przeznaczony na ten konkretny model telefonu, który posiadamy (w tym przypadku TP801A). Poniżej jest pełna specyfikacja wgranego oprogramowania oraz dokładne numery mojego smartfona: W paczce .zip z firmware, którą pobraliśmy, znajduje się plik boot.img . Musimy go wydobyć w celu wyodrębnienia pewnych plików i wgrania ich na portowany obraz recovery.img . Przepakowanie obrazu recovery.img By przepakować obraz przeznaczony na inny smartfon, który jest zbliżony parametrami do naszego Neffos'a Y5L, musimy pierw pozyskać odpowiednie narzędzia. Na linux'ie możemy skorzystać do tego celu z abootimg lub też ze skryptów Android Image Kitchen. Ja będę korzystał z tego drugiego rozwiązania. Tworzymy sobie jakiś katalog roboczy i kopiujemy do niego zarówno oryginalny obraz boot.img , jak i obraz recovery.img z innego smartfona. Następnie znajdując się w tym katalogu roboczym, pobieramy skrypty z github'a (wymagane zainstalowane narzędzie git w systemie) i przechodzimy do utworzonego w ten sposób katalogu. W nim zaś tworzymy dwa podkatalogi stock/ oraz port/ : $ git clone https://github.com/ndrancs/AIK-Linux-x32-x64/ $ chmod +x ./AIK-Linux-x32-x64/* $ chmod +x ./AIK-Linux-x32-x64/bin/* $ cd ./AIK-Linux-x32-x64/ $ mkdir stock/ port/ Kopiujemy oryginalny obraz boot.img z katalogu nadrzędnego i wypakowujemy go za pomocą skryptu unpackimg.sh . Następnie przenosimy tak wyodrębnioną zawartość do katalogu stock/ : $ cp ../orig_boot.img ./recovery.img $ ./unpackimg.sh recovery.img $ mv split_img/ ramdisk/ stock/ $ rm recovery.img Kopiujemy teraz obraz partycji /recovery/ mający TWRP i wypakowujemy go. Przenosimy jego zawartość do katalogu port/ : $ cp ../recovery_twrp.img ./recovery.img $ ./unpackimg.sh recovery.img $ mv split_img/ ramdisk/ port/ $ rm recovery.img Kernel W zasadzie to musimy tylko przekopiować plik recovery.img-zImage z oryginalnego obrazu naszego Neffos'a Y5L do obrazu TWRP: $ cp ./stock/split_img/recovery.img-zImage ./port/split_img/ Fstab Musimy także dostosować nieco plik port/ramdisk/etc/recovery.fstab , bo flash telefonu, z którego wzięliśmy obraz recovery.img z TWRP ma inny nieco inny układ partycji. W oparciu o informacje uzyskane z aplikacji DiskInfo oraz z pliku /proc/partitions w telefonie, układ flash'a w przypadku Neffos Y5L prezentuje się następująco (kolumna najbardziej na prawo została dodana przeze mnie): # adb shell shell@Y5L:/ $ cat /proc/partitions major minor #blocks name 253 0 524288 zram0 179 0 7634944 mmcblk0 179 1 65536 mmcblk0p1 modem (/firmware/ , vfat) 179 2 512 mmcblk0p2 sbl1 179 3 512 mmcblk0p3 sbl1bak 179 4 1024 mmcblk0p4 aboot 179 5 1024 mmcblk0p5 abootbak 179 6 512 mmcblk0p6 rpm 179 7 512 mmcblk0p7 rpmbak 179 8 768 mmcblk0p8 tz 179 9 768 mmcblk0p9 tzbak 179 10 1024 mmcblk0p10 pad 179 11 1536 mmcblk0p11 modemst1 179 12 1536 mmcblk0p12 modemst2 179 13 1024 mmcblk0p13 misc 179 14 1 mmcblk0p14 fsc 179 15 8 mmcblk0p15 ssd 179 16 10240 mmcblk0p16 splash 179 17 32 mmcblk0p17 DDR 179 18 1536 mmcblk0p18 fsg 179 19 16 mmcblk0p19 sec 179 20 32768 mmcblk0p20 boot 179 21 1913652 mmcblk0p21 System (/system/ , ext4) 179 22 32768 mmcblk0p22 persist (/persist/ , ext4) 179 23 262144 mmcblk0p23 Cache (/cache/ , ext4) 179 24 32768 mmcblk0p24 recovery 179 25 1024 mmcblk0p25 devinfo 179 26 512 mmcblk0p26 keystore 179 27 65536 mmcblk0p27 oem 179 28 512 mmcblk0p28 config 179 29 5077999 mmcblk0p29 Data (/data/ , ext4) 179 32 512 mmcblk0rpmb mmcblk0rpmb Rozmiary poszczególnych partycji są w blokach, a każdy z nich ma 1024 bajty. Partycja mmcblk0 odpowiada za cały obszar flash'a. Będziemy zatem w stanie zrobić backup całego flash'a albo też poszczególnych jego partycji. Tak czy inaczej potrzebne nam są odpowiednie wpisy w pliku port/ramdisk/etc/recovery.fstab . Poniżej jest zawartość mojego pliku: # mmcblk0p1 (modem) /firmware vfat /dev/block/bootdevice/by-name/modem flags=display="Firmware";backup=1;mounttodecrypt # mmcblk0p2 (sbl1) /sbl1 emmc /dev/block/bootdevice/by-name/sbl1 flags=display="sbl1";backup=1 # mmcblk0p3 (sbl1bak) /sbl1bak emmc /dev/block/bootdevice/by-name/sbl1bak flags=display="sbl1bak";backup=1 # mmcblk0p4 (aboot) /aboot emmc /dev/block/bootdevice/by-name/aboot flags=display="aboot";backup=1 # mmcblk0p5 (abootbak) /abootbak emmc /dev/block/bootdevice/by-name/abootbak flags=display="abootbak";backup=1 # mmcblk0p6 (rpm) /rpm emmc /dev/block/bootdevice/by-name/rpm flags=display="rpm";backup=1 # mmcblk0p7 (rpmbak) /rpmbak emmc /dev/block/bootdevice/by-name/rpmbak flags=display="rpmbak";backup=1 # mmcblk0p8 (tz) /tz emmc /dev/block/bootdevice/by-name/tz flags=display="tz";backup=1 # mmcblk0p9 (tzbak) /tzbak emmc /dev/block/bootdevice/by-name/tzbak flags=display="tzbak";backup=1 # mmcblk0p10 (tzbak) /pad emmc /dev/block/bootdevice/by-name/pad flags=display="pad";backup=1 # mmcblk0p11 (modemst1) /efs1 emmc /dev/block/bootdevice/by-name/modemst1 flags=display="Modemst1";backup=1 # mmcblk0p12 (modemst2) /efs2 emmc /dev/block/bootdevice/by-name/modemst2 flags=display="Modemst2";backup=1 # mmcblk0p13 (misc) /misc emmc /dev/block/bootdevice/by-name/misc flags=display="Misc";backup=1 # mmcblk0p14 (fsc) /fsc emmc /dev/block/bootdevice/by-name/fsc flags=display="fsc";backup=1 # mmcblk0p15 (ssd) /ssd emmc /dev/block/bootdevice/by-name/ssd flags=display="ssd";backup=1 # mmcblk0p16 (splash) /splash emmc /dev/block/bootdevice/by-name/splash flags=display="splash";backup=1 # mmcblk0p17 (DDR) /ddr emmc /dev/block/bootdevice/by-name/DDR flags=display="DDR";backup=1 # mmcblk0p18 (fsg) /fsg emmc /dev/block/bootdevice/by-name/fsg flags=display="fsg";backup=1 # mmcblk0p19 (sec) /sec emmc /dev/block/bootdevice/by-name/sec flags=display="sec";backup=1 # mmcblk0p20 (boot) /boot emmc /dev/block/bootdevice/by-name/boot flags=display="Boot";backup=1 # mmcblk0p21 (System) /system ext4 /dev/block/bootdevice/by-name/system flags=display="System";backup=1;wipeingui;mounttodecrypt # mmcblk0p22 (persist) /persist ext4 /dev/block/bootdevice/by-name/persist flags=display="Persist";backup=1 # mmcblk0p23 (Cache) /cache ext4 /dev/block/bootdevice/by-name/cache flags=display="Cache";backup=1;wipeingui;wipeduringfactoryreset # mmcblk0p24 (recovery) /recovery emmc /dev/block/bootdevice/by-name/recovery flags=display="Recovery";backup=1 # mmcblk0p25 (devinfo) /devinfo emmc /dev/block/bootdevice/by-name/devinfo flags=display="devinfo";backup=1 # mmcblk0p26 (keystore) /keystore emmc /dev/block/bootdevice/by-name/keystore flags=display="keystore";backup=1 # mmcblk0p27 (oem) /oem emmc /dev/block/bootdevice/by-name/oem flags=display="oem";backup=1 # mmcblk0p28 (config) /config emmc /dev/block/bootdevice/by-name/config flags=display="config";backup=1 # mmcblk0p29 (Data) /data ext4 /dev/block/bootdevice/by-name/userdata flags=display="Data";backup=1;wipeingui;wipeduringfactoryreset;encryptable=footer;length=-16384 # #/mmcblk0rpmb emmc /dev/block/bootdevice/mmcblk0rpmb flags=display="mmcblk0rpmb";backup=1 # External /sdcard1 auto /dev/block/mmcblk1p1 flags=display="MicroSD";storage;wipeingui;removable #/usb-otg auto /dev/block/sda1 flags=display="USBOTG";storage;wipeingui;removable # Full partition images /firmware_image emmc /dev/block/bootdevice/by-name/modem flags=display="Firmware-Image";backup=1 /system_image emmc /dev/block/bootdevice/by-name/system flags=display="System-Image";backup=1 /persist_image emmc /dev/block/bootdevice/by-name/persist flags=display="Persist-Image";backup=1 /cache_image emmc /dev/block/bootdevice/by-name/cache flags=display="Cache-Image";backup=1 /data_image emmc /dev/block/bootdevice/by-name/userdata flags=display="Data-Image";backup=1 /full_flash emmc /dev/block/mmcblk0 flags=display="Full-Flash-Image";backup=1 Jeśli ktoś jest ciekaw użytych tutaj opcji, to są one wyjaśnione w tym wątku na forum XDA. Tworzenie obrazu recovery z TWRP dla Neffos Y5L Z tak przygotowanych plików w katalogu stock/ trzeba zrobić nowy obraz recovery.img przy pomocy skryptu repackimg_x64.sh : $ rm -R stock/ $ mv port/ramdisk ./ $ mv port/split_img ./ $ rmdir port/ $ ./repackimg_x64.sh W katalogu roboczym powinien zostać utworzony nowy plik o nazwie image-new.img . To jest właśnie nasz nowy obraz partycji /recovery/ , który musimy wgrać na telefon w trybie bootloader'a przez fastboot. Niemniej jednak, zanim będziemy w stanie to zrobić, musimy odblokować bootloader. Jak odblokować bootloader w Neffos Y5L Może nie mamy możliwości zrobić backup'u całego flash'a telefonu przed podjęciem jakichkolwiek prac ale też raczej nie powinniśmy znowu nic namieszać. Jedyna rzecz jaką musimy zrobić, to odblokować bootloader. Chodzi o to, że na smartfonach zwykle jest ulokowana partycja /recovery/ . Na niej znajduje się oprogramowanie umożliwiające przeprowadzanie niskopoziomowych operacji, np. backup lub też flash'owanie ROM'u. Problem w tym, że to oprogramowanie w standardzie zwykle za wiele nie potrafi i by przeprowadzić proces root'owania Androida, musimy pozyskać bardziej zaawansowany soft, np. ClockworkMod czy TWRP, i wgrać go na partycję /recovery/ . By to zrobić musimy pierw odblokować bootloader. Proces odblokowania bootloader'a usuwa wszystkie dane, które wgraliśmy na flash telefonu, tj. podczas odblokowywania jest inicjowany factory reset. Dane na karcie SD pozostają nietknięte. By ten proces zainicjować zaczynamy od przestawienia jednej opcji w telefonie. W tym celu musimy udać się w Ustawienia => Opcje Programistyczne i tam przełączyć Zdjęcie blokady OEM : Następnie w terminalu wpisujemy poniższe polecenia: # adb reboot bootloader # fastboot devices 8a8f289 fastboot # fastboot oem unlock-go Na ekranie smartfona powinien nam się pokazać zielony robocik informujący o przeprowadzaniu Factory Reset. Po chwili ten proces powinien dobiec końca, a smartfon uruchomi się ponownie na ustawieniach domyślnych. Wyłączamy urządzenie i włączamy je via przyciski VolumeDown + Power i sprawdzamy status blokady bootloader'a: # fastboot oem device-info ... (bootloader) Device tampered: false (bootloader) Device unlocked: true (bootloader) Charger screen enabled: true (bootloader) Display panel: OKAY [ 0.004s] finished. total time: 0.004s Jeśli przy Device unlocked: widnieje wartość true , to blokada bootloader'a została pomyślnie zdjęta. Jako, że proces odblokowania bootloader'a usunął wszelkie ustawienia, to jeszcze raz musimy włączyć Opcje programistyczne, a w nich tryb debugowania portu USB. Testowanie przepakowanego obrazu recovery.img Zanim jednak wgramy nowo stworzony obraz recovery.img , przydałoby się sprawdzić pierw, czy aby na pewno ten obraz działa jak należy. Podpinamy telefon do portu USB komputera i przy pomocy narzędzia fasboot przetestujmy wyżej wygenerowany obraz próbując uruchomić go z pamięci telefonu: # fastboot boot image-new.img W przypadku, gdyby pojawiła nam się informacja FAILED (remote: unlock device to use this command) , to prawdopodobnie zapomnieliśmy odblokować bootloader. Jeśli blokada została zdjęta, to wydanie tego powyższego polecenia powinno załadować do pamięci RAM telefonu zmieniony obraz partycji /recovery/ , oczywiście o ile obraz jest poprawny. Jeśli zamiast tego smartfon uruchomi się ponownie, to coś z takim obrazem jest nie tak i lepiej nie wgrywać go na telefon. Jak przeprowadzić backup flash'a Neffos Y5L Mając załadowany obraz recovery.img z TWRP do pamięci smartfona, możemy przejść do zrobienia backup'u całego flash'a telefonu. Opcje wyboru partycji, które będziemy mieć do uwzględnienia w backup'ie, zależą od pliku recovery.fstab , który edytowaliśmy sobie wcześniej. W tym przypadku mamy możliwość zrobienia backup'u całego flash'a, jak i jego poszczególnych partycji. Nie musimy jednak robić backup'u wszystkich partycji i możemy zdecydować się jedynie na niektóre z nich. Przede wszystkim, potrzebny nam będzie backup partycji /system/ , /boot/ i /recovery/ , bo to je zwykle będziemy poddawać edycji i wprowadzać w nich zmiany. Ja jednak wolę zrobić backup pozostałej części flash'a, tak na wszelki wypadek. No i skoro mam do zrobienia praktycznie backup całej pamięci flash, to można przecież upchnąć go w jednym pliku zrzucając zawartość urządzenia /dev/block/mmcblk0 . Można oczywiście zapisać sobie każdą partycję do osobnego pliku ale przecie z obrazu całego flash'a również można te poszczególne partycje wydobyć. W zasadzie cały backup zajmie około 2 GiB, chyba, że zrobiliśmy sobie pełną kopię. W przypadku tego drugiego rozwiązania potrzeba nam będzie karta SD o pojemności większej lub równej pojemności flash'a w telefonie. Dodatkowo, jako, że z reguły flash w smartfonach ma pojemność większą niż 4 GiB (zwykle 16-32 GiB), to w takim przypadku karta musi zostać sformatowana innym systemem plików niż FAT, bo ten ma ograniczenia wielkości pliku do 4 GiB, a obraz będzie przecie zajmował tyle ile zajmuje pamięć flash. TWRP obsługuje bez większego problemu karty SD sformatowane jako EXT4 i z tego systemu plików możemy skorzystać. Pamiętajmy jednak, że takiej karty Android nam nie będzie czytał standardowo. Niepełny backup z kolei można przeprowadzić zapisując go na flash'u smartfona, choć nie zaleca się tego robić, a to z tego względu, że kopia pamięci danego urządzenia powinna być zapisywana na zewnętrznym nośniku. Dlatego lepiej zakupić sobie kartę SD rozmiarem przypominającą flash telefonu. Różnica między robieniem obrazów partycji EXT4 i EMMC polega na tym, że w przypadku standardowych partycji EMMC, ich obraz można zamontować przez mount na dowolnym linux'ie. Natomiast obrazy EXT4, są w zasadzie zwykłymi archiwami plików, które można wypakować jak zwykłego ZIP'a. Druga różnica jest taka, że te spakowane paczki są dzielone na kawałki o rozmiarze 1,5 GiB, przez co można je bez problemu zapisywać na karcie SD, która ma system plików FAT. Warto w tym miejscu jeszcze dodać, że można pominąć backup partycji /cache/ i /data/ , bo one są i tak czyszczone podczas procesu Factory Reset. Jeśli zaś chcemy dokonać backup'u danych użytkownika, tj. partycji /data/ , to w jej przypadku lepiej jest spakować pliki zamiast robić backup całej partycji, bo wtedy robimy backup tylko danych i nie wchodzi w to wolne miejsce. Jak już ustalimy jakie partycje uwzględnimy w backup'ie, to przechodzimy do pozycji Backup i wybieramy kartę SD oraz zaznaczamy odpowiednie obszary pamięci flash, tak jak to widać na poniższej fotce: W przypadku robienia pełnego backup'u, cały proces może zająć dłuższą chwilę. Po jego ukończeniu, na karcie SD pojawi się obraz flash'a, który możemy sprawdzić w gdisk lub parted : Wgranie obrazu recovery z TWRP na Neffos Y5L Po sprawdzeniu czy obraz się bootuje poprawnie i dokonaniu backup'u określonych obszarów pamięci flash, możemy ten obraz wgrać na telefon lub też możemy zainstalować jedynie samo SuperSU. Ja postanowiłem wgrać TWRP recovery na mojego Neffos'a Y5L. W sumie ta procedura się za wiele nie różni od testowania samego obrazu w pamięci telefonu. Jedyne co trzeba zrobić to zrestartować telefon do trybu bootloader'a i wgrać obraz recovery przy pomocy fastboot w poniższy sposób: # adb reboot bootloader # fastboot flash recovery image-new.img # fastboot reboot SuperSU, BusyBOX, RootCheck i emulator terminala Ostatnią rzeczą na drodze do zrobienia root na Neffos Y5L jest wgranie aplikacji umożliwiającej korzystanie różnym programom z praw administratora systemu w telefonie. My skorzystamy z SuperSU. Dodatkowo, musimy wgrać sobie BusyBOX, który zawiera minimalistyczne odpowiedniki linux'owych narzędzi, co pozwoli nam swobodnie operować w Androidzie, tak jakbyśmy to robili pod pełnowymiarowym pingwinem. Potrzebny nam także będzie jakiś emulator terminala, w którym to będziemy wpisywać wszystkie nasze polecenia. Instalacja SuperSU Zacznijmy od pobrania stosownej paczki z SuperSU. Jako, że my nie mamy jeszcze zrobionego root'a, to musimy pobrać TWRP / FlashFire installable ZIP . Tej paczki nie wypakowujemy, tylko wrzucamy ją w pobranej formie na kartę SD w telefonie. Odpalamy teraz tryb recovery w smartfonie (VolumeUp + Power) i przechodzimy do Install i wskazujemy paczkę .zip , którą umieściliśmy na karcie SD. Tam z kolei zaznaczamy ZIP signature verification i przeciągamy trzy strzałki na prawą stronę. Teraz możemy uruchomić ponownie Neffos'a Y5L i zainstalować jakąś aplikację, która pokaże nam czy nasz smartfon ma root'a. Sprawdzenie czy Neffos Y5L ma root'a Po uruchomieniu się systemu na smartfonie, instalujemy aplikację RootCheck, po czym uruchamiamy ją. Powinien się pojawić monit informujący, że ta aplikacja żąda praw administracyjnych, na co zezwalamy. Jeśli nasz telefon ma root'a, to powinien się pojawić stosowny komunikat: Instalacja BusyBOX Kolejnym krokiem jest instalacja BusyBOX'a. Po wgraniu tej aplikacji na smartfona, musimy ją uruchomić i wcisnąć w niej przycisk install . BusyBOX również nas poprosi o dostęp do praw administracyjnych. Po zainstalowaniu, weryfikujemy jeszcze, czy aby wszystko zostało pomyślne wgrane. Możemy to zrobić zarówno w samej aplikacji BusyBOX, jak w CheckRoot: Instalacja terminala Generalnie rzecz biorąc, terminal jako taki nie jest obowiązkowy, bo SuperSU jak i BusyBOX są wymagane przez konkretne aplikacje do poprawnego ich działania. Niemniej jednak, jeśli zamierzamy korzystać z tych niskopoziomowych narzędzi dostarczonych przez BusyBOX, czy też innych narzędzi obecnych standardowo w Androidzie na uprawnieniach root, to terminal jak najbardziej się nam przyda. Znalazłem dwa terminale, które są OpenSource i bez reklam/opłat. Są to Android-Terminal-Emulator oraz Termux. Wybieramy sobie jeden z nich i instalujemy w systemie. Jako, że ja korzystam na co dzień z Debiana, to instaluję Termux'a. Aplikacje i prawa administracyjne Teraz już pozostało nam tylko odpalenie terminala i zalogowanie się na użytkownika root. Do tego celu służy polecenie su . Wpiszmy je zatem w okienku Termux'a: I teraz możemy uruchamiać aplikacje z prawami admina, tak jak to zwykliśmy robić w każdym innym linux'ie. Pamiętajmy tylko, że standardowo system plików jest zamontowany w trybie tylko do odczytu (RO) i by móc zmieniać pliki systemowe z poziomu tego terminala, musimy przemontować system plików w tryb do zapisu (RW). Robimy to w poniższy sposób: $ su # mount -o remount,rw /system Gdy skończymy się bawić, to montujemy ten system plików ponownie w tryb RO: # mount -o remount,ro /system
  12. Stock'owe Androidy w smartfonach mają ten problem, że zawierają całą masę preinstalowanych aplikacji od Google. Nie to by jakoś mnie to bolało, no może za wyjątkiem braku możliwości ich wywalenia czy wyłączenia. To co mnie trochę irytuje, to fakt obecności reklam w aplikacji YouTube. Nie da rady się ich pozbyć praktycznie w żaden sposób. Zdaję sobie sprawę, że serwis YT można przeglądać w Firefox'ie i jeśli mamy zainstalowanego w telefonie adblock'a, np. AdAway, czy też wdrożony podobny filtr na domowym routerze WiFi z LEDE/OpenWRT, to te reklamy mogą zostać z powodzeniem odfiltrowane, przynajmniej w Firefox'ie. Jestem też świadom istnienia aplikacji NewPipe , która jest zubożonym klientem YouTube. Niemniej jednak, te opisane wyżej sposoby mają jedną podstawową wadę. Mianowicie tracimy lwią część funkcjonalności serwisu YouTube. Przykładem mogą być powiadamiania w przypadku, gdy na jeden z subskrybowanych kanałów zostanie wrzucony jaki materiał video. Taką opcję ma ta aplikacja od Google ale klikając w powiadomienie jest niemal pewne, że włączy nam się jakaś wredna reklama o wiele głośniejsza niż sam filmik, który zamierzamy obejrzeć. Innym problemem w przypadku tej góglowskiej aplikacji jest brak możliwości odtwarzania video w tle czy też przy zgaszonym wyświetlaczu. Postanowiłem w końcu wziąć się za ogarnięcie tej góglowskiej aplikacji YouTube i wyeliminować te drażniące mnie problemy instalując w smartfonie framework Xposed wraz z odpowiednimi modułami: YouTube Background Playback oraz YouTube AdAway. Jako, że nie jest to proces łatwy, to postanowiłem go opisać krok po kroku. Ukorzeniony Android (root) oraz backup flash'a smartfona Może i Instalator Xposed można zainstalować na Androidzie, który nie przeszedł procesu root, ale pełna funkcjonalność framework'a Xposed zostanie aktywowana dopiero w momencie, gdy ukorzenimy sobie system. Naturalnie ta pełna funkcjonalność obejmuje instalowanie dodatkowych modułów. Zatem jak widzimy, bez root sam instalator jest w zasadzie bezużyteczny. Ten artykuł jest pisany w oparciu o smartfony Neffos, a konkretnie o modele C5 MAX oraz Y5, jako, że dysponują one różnymi platformami sprzętowymi (Mediatek i Qualcomm) oraz różnymi wersjami Androida (Lollipop oraz Marshmallow). Jeśli dysponujemy smartfonami Neffos C5 lub Y5L, to naturalnie poniżej opisane kroki można zastosować również i do tych modeli. Niemniej jednak, by cokolwiek zacząć robić potrzebny jest ukorzeniony system. Stosowne howto można znaleźć w osobnych wątkach: Neffos C5 MAX, Neffos C5, Neffos Y5L i Neffos Y5. Druga sprawa, to backup danych zgromadzonych w telefonie. Niby nic naszemu smartfonowi nie powinno się stać z racji instalowania w nim framework'a Xposed ale lepiej dmuchać na zimne i zrobić sobie kopię zapasową partycji /system/ oraz /data/ , a w ogóle to najlepiej zrobić pełny backup flash'a i w razie problemów przywrócić konkretne partycje. Informacje na temat tworzenia kopi zapasowej flash'a w smartfonach Neffos można znaleźć w wyżej podlinkowanych artykułach dotyczących przeprowadzania procesu root. Poniższa część artykułu zakłada, że mamy już ukorzeniony system i w razie ewentualnych problemów wiemy jak cofnąć w nim wprowadzone zmiany. Instalacja instalatora Xposed W zasadzie to musimy zainstalować w systemie dwie rzeczy: Instalator Xposed do zarządzania modułami oraz właściwy framework Xposed. Oba te pliki są dostępne w oficjalnym wątku na XDA. Sam instalator instalujemy z poziomu działającego Androida. Jeśli mamy dodatkowo zainstalowany F-Droid lub XDA Labs, to z ich repozytoriów również możemy ten instalator sobie wgrać na smartfona. Natomiast framework można zainstalować przez instalator Xposed lub też z poziomu TWRP recovery (ręcznie lub inicjując proces za pomocą instalatora Xposed). Instalacja framework'a Xposed Plik instalatora Xposed jest wspólny dla każdej wersji Androida (5.0, 5.1 i 6.0). Natomiast plik z framework'iem Xposed trzeba dobrać w zależności od wersji Androida i architektury systemowej. W tym przypadku mamy Androida 6.0 Marshmallow oraz Androida 5.1 Lollipop. Architektury z kolei to ARM64 i ARM32. Framework Xposed i Android 6.0 (Marshmallow) Niezależnie od wybranego sposobu instalacji instalatora Xposed (ręczne wgranie pliku .apk , F-Droid czy XDA Labs), musimy jeszcze sobie zainstalować sam framework. Odpalamy zatem instalator Xposed i klikamy na numerku wersji, by zainstalować framework: Jak widzimy, mamy do wyboru dwie opcje. Ja wybrałem sobie "Install" ale można też bez problemu zainstalować przez TWRP recovery. Po chwili proces instalacji powinien się zakończyć powodzeniem, a smartfon uruchomi się ponownie: Urządzenie się będzie dość długo uruchamiać ponownie i nie powinniśmy się tym faktem przejmować. Pojawi się także informacja o optymalizowaniu wszystkich aplikacji w smartfonie, co potrwa dłuższą chwilę. Warto tutaj zaznaczyć, że to optymalizowanie aplikacji będzie miało miejsce zawsze po instalowaniu jak i usuwaniu framework'a Xposed. Mając zainstalowany framework możemy przejść do instalacji interesujących nas modułów. Framework Xposed i Android 5.1 (Lollipop) Instalacja framework'a Xposed na smartfonach Neffos C5 MAX oraz C5 sprawia nieco więcej problemów, niż w przypadku Neffos'ów Y5 i Y5L. Prawdopodobnie winna jest tutaj starsza wersja Androida, która nie jest zbytnio kompatybilna z samym framework'iem. Niemniej jednak, w dalszym ciągu Xposed może zostać zainstalowany i uruchomiony z powodzeniem o ile zastosujemy się do poniższych wskazówek. Przede wszystkim, nie możemy zainstalować najnowszej wersji frameworka (obecnie jest to v87). Ta wersja powoduje jakieś bliżej nieznane problemy objawiające się następującym komunikatem w oknie instalatora: Wersja 87 Xposed framework jest zainstalowana ale nie jest aktywna. Proszę sprawdzić logi, aby poznać szczegóły. Po zajrzeniu w logi, mamy taką informację: ----------------- Starting Xposed version 87, compiled for SDK 22 Device: Neffos C5 Max (TP-LINK), Android version 5.1 (SDK 22) ROM: H10S103D01B20160812R1035 Build fingerprint: Neffos/TP702A/C5_Max:5.1/LMY47D/H10S103D01B20160812R1035.160811:user/release-keys Platform: arm64-v8a, 64-bit binary, system server: yes SELinux enabled: yes, enforcing: yes : ----------------- : Added Xposed (/system/framework/XposedBridge.jar) to CLASSPATH : Detected ART runtime : Found Xposed class 'de/robv/android/xposed/XposedBridge', now initializing : Error while loading XResources class 'android/content/res/XResources': : java.lang.IncompatibleClassChangeError: xposed.dummy.XResourcesSuperClass : at java.lang.Class dalvik.system.DexFile.defineClassNative(java.lang.String, java.lang.ClassLoader, long) (DexFile.java:-2) : at java.lang.Class dalvik.system.DexFile.defineClass(java.lang.String, java.lang.ClassLoader, long, java.util.List) (DexFile.java:226) : at java.lang.Class dalvik.system.DexFile.loadClassBinaryName(java.lang.String, java.lang.ClassLoader, java.util.List) (DexFile.java:219) : at java.lang.Class dalvik.system.DexPathList.findClass(java.lang.String, java.util.List) (DexPathList.java:321) : at java.lang.Class dalvik.system.BaseDexClassLoader.findClass(java.lang.String) (BaseDexClassLoader.java:54) : at java.lang.Class java.lang.ClassLoader.loadClass(java.lang.String, boolean) (ClassLoader.java:511) : at java.lang.Class java.lang.ClassLoader.loadClass(java.lang.String, boolean) (ClassLoader.java:504) : at java.lang.Class java.lang.ClassLoader.loadClass(java.lang.String) (ClassLoader.java:469) : at java.lang.Class dalvik.system.DexFile.defineClassNative(java.lang.String, java.lang.ClassLoader, long) (DexFile.java:-2) : at java.lang.Class dalvik.system.DexFile.defineClass(java.lang.String, java.lang.ClassLoader, long, java.util.List) (DexFile.java:226) : at java.lang.Class dalvik.system.DexFile.loadClassBinaryName(java.lang.String, java.lang.ClassLoader, java.util.List) (DexFile.java:219) : at java.lang.Class dalvik.system.DexPathList.findClass(java.lang.String, java.util.List) (DexPathList.java:321) : at java.lang.Class dalvik.system.BaseDexClassLoader.findClass(java.lang.String) (BaseDexClassLoader.java:54) : at java.lang.Class java.lang.ClassLoader.loadClass(java.lang.String, boolean) (ClassLoader.java:511) : at java.lang.Class java.lang.ClassLoader.loadClass(java.lang.String) (ClassLoader.java:469) : at boolean de.robv.android.xposed.XposedBridge.initXResourcesNative() (XposedBridge.java:-2) : at void de.robv.android.xposed.XposedInit.hookResources() (XposedInit.java:217) : at void de.robv.android.xposed.XposedBridge.main(java.lang.String[]) (XposedBridge.java:87) : Cannot hook resources : Cannot load any modules because /data/data/de.robv.android.xposed.installer/conf/modules.list was not found : ----------------- Wersja, która zdaje się działać, to v85 i to ją musimy sobie wgrać na smartfona. Wystarczy, że w oknie instalatora Xposed, z prawego górnego rogu rozwiniemy menu i wybierzemy "Show outdated versions", a pojawi nam się lista wersji, które będziemy w stanie zainstalować. Jest tam też min. v85. Wybieramy i instalujemy ją: Naturalnie smartfon się będzie dłużej uruchamiał i w tym przypadku również doświadczymy optymalizowania aplikacji, co potrwa kilka minut. Po uruchomieniu instalatora Xposed, zobaczymy ten sam komunikat ostrzeżenia, który był widoczny wyżej. By go zlikwidować, trzeba wejść w Ustawienia i zaznaczyć opcję "Wyłącz zasoby konfliktów". Po zresetowaniu systemu, framework powinien już się załadować bez problemu: Ta opcja "Wyłącz zasoby konfliktów" powoduje, że część modułów Xposed nie będzie nam funkcjonować prawidłowo (min. YouTube AdAway). Niemniej jednak, dobrze chociaż, że jakiekolwiek moduły w ogóle będą w stanie działać. Instalacja modułów Xposed Moduły do Xposed możemy instalować bezpośrednio z instalatora. Możemy też do tego celu zaprzęgnąć aplikację XDA Labs, która również ma wbudowane repozytorium modułów Xposed. W tym przypadku interesują nas dwa moduły: YouTube Background Playback oraz YouTube AdAway. Ich instalacja sprowadza się do odszukania konkretnego modułu i pobrania go: Po zainstalowaniu modułów Xposed, te nie są z automatu aktywne, o czym jesteśmy informowani w notyfikacjach systemowych. Wszystkie moduły mają swój własny autostart i możemy je dowolnie włączać lub wyłączać: Wszystkie te wyżej zaznaczone moduły będą startowane wraz z systemem. Jeśli jakieś moduły chcemy czasowo wyłączyć, to nie musimy ich wywalać z systemu, tylko wystarczy odptakować stosowną pozycję na liście modułów. Każda zmiana konfiguracji modułów musi być załadowana ponownie, a do tego celu trzeba uruchomić ponownie system w telefonie. Odinstalowanie framework'a Xposed i jego modułów Cały framework Xposed wraz z jego modułami można naturalnie odinstalować. W tym celu wystarczy odpalić instalator Xposed i odinstalować framework: Tutaj również mamy opcje usuwania bezpośrednio z systemu jak i przez tryb TWRP recovery. Oba działają bez zarzutu. Jeśli mieliśmy wgrane jakieś moduły Xposed, to one nie zostaną usunięte przy deinstalacji framework'a. Każdy moduł trzeba ręcznie usunąć, np. przez XDA Labs lub instalator Xposed. Po usunięciu modułów, instalator można usunąć w XDA Labs lub F-Droid.
  13. System Android w większej lub mniejszej części zmienia się z wydania na wydanie. Te nowsze wersje zwykle zawierają całą masę nowych mechanizmów i rozbudowują te już istniejące, tak by ten OS w lepszym stopniu zaspokajał zachcianki użytkowników smartfonów. Problem w tym, że niektóre kroki deweloperów Androida potrafią wprawić w zastanowienie niejednego logicznie myślącego osobnika. Przykładem może być przestawienie domyślnego trybu USB w Marshmallow z MTP na Charge-Only (tylko ładowanie). Jedni mówią, że takie posunięcie jest podyktowane względami bezpieczeństwa, a inni, że chodzi o performance przy ładowaniu baterii, gdzie moduł USB nie działa w tym drugim trybie i nie konsumuje energii, przez co ładowanie ma przebiegać szybciej. Ile w tym prawdy, tego nie wiem ale ja za bardzo nie widzę żadnych wymiernych korzyści z przestawienia tego trybu na Charge-Only. Natomiast widzę bardzo wyraźnie utrudnienia przy interakcji telefonu z komputerem za sprawą tej zmiany. Poszukałem trochę informacji na ten temat i znalazłem rozwiązanie w postaci aplikacji MTP enabler. Domyślny tryb USB w Marshmallow i Lollipop W Androidzie 5.1 Lollipop nie było żadnego problemu. Podłączało się smartfon do komputera i można było wymieniać dane na linii tych dwóch urządzeń. Natomiast w Androidzie 6.0 Marshmallow trzeba dodatkowo ręcznie przestawić tryb USB ilekroć podłączamy telefon do portu USB. Ta czynność jest mało wygodna, gdy się często podłącza telefon do komputera i takie ciągłe przestawianie tego trybu może nawet spokojnego człowieka wyprowadzić z równowagi: Konfiguracja trybu USB w opcjach programistycznych Gdzieniegdzie można się spotkać z opinią, że domyślny tryb USB w Marshmallow można trwale przestawić w opcjach programistycznych. No i faktycznie stosowna opcja jest tam obecna: Jeśli teraz byśmy podłączyli smartfon do komputera, to naturalnie zostanie ustawiony tryb przesyłu plików, a nie ładowania. To czego ludzie zapominają zrobić, to przetestowanie trwałości tej konfiguracji przez proste odłączenie urządzenia od komputera i ponowne jego podłączenie do portu USB. W takim przypadku z niewiadomych przyczyn system wraca do trybu ładowania i musimy ręcznie go przestawić na przesył plików. Nie wiem, która opcja jest wygodniejsza. Root Androida i MTP enabler Niestety próżno szukać w ustawieniach Androida opcji, która mogłyby nam umożliwić wybranie domyślnego trybu USB. Dlaczego? O to już trzeba zapytać deweloperów tego systemu. W efekcie mamy do wyboru jeden z dwóch scenariuszy. Opcja pierwsza to zaakceptowanie domyślnego trybu, który został ustawiony w Marshmallow. Drugim rozwiązaniem jest naturalnie próba obejścia tego całego mechanizmu i zdefiniowanie sobie takiego trybu USB, który najlepiej nam odpowiada. Stosowna aplikacja, która umożliwi nam swobodne operowanie na porcie USB w naszym telefonie, niestety wymaga praw administratora root, czyli musimy posiadać ukorzenionego Androida. Innej opcji o zgrozo nie ma. Aplikacja, o której mowa, nazywa się MTP enabler, a link do jej darmowej wersji widnieje na forum XDA. Instalacja tej aplikacji raczej nie powinna sprawić żadnych problemów. Po zainstalowaniu tego programiku, uruchamiamy go. Tak prezentują się opcje tej aplikacji: Jak widać jest ich dość sporo. Ta najważniejsza opcja wyboru domyślnego trybu jest naturalnie dostępna. Wybranie tutaj MTP zamiast Charging zaowocuje przestawieniem trybu domyślnego i ilekroć tylko będziemy podłączać smartfon do portu USB, to ten tryb będzie automatycznie aplikowany. Jeśli chcemy, by przy każdym podłączeniu smartfona do komputera pojawiała nam się notyfikacja z opcjami wyboru konkretnego trybu (tak jak to widać na pierwszej fotce wyżej), to również mamy taką możliwość. Tryb przesyłu plików (MTP) można także sobie zabezpieczyć w oparciu o znany ESSID sieci bezprzewodowej WiFi. W przypadku podłączenia smartfona do komputera przy braku WiFi lub też będąc podłączonym do innej sieci, aplikacja MTP enabler załączy nam jedynie tryb ładowania. Nie mogło także zabraknąć notyfikacji dźwiękowych. Czy przestawienie domyślnego trybu USB jest bezpieczne Naprawdę ciężko mi jest zrozumieć dlaczego przestawienie domyślnego trybu USB z MTP na Charge-Only ma miejsce w Androidzie Marshmallow. Wątpię, by ktoś odczuł jakąś różnicę przy ładowaniu smartfona przez port USB komputera za sprawą tej zmiany. Natomiast jeśli chodzi o kwestię bezpieczeństwa, to i tak przecież hasło blokady ekranu uniemożliwia zamontowanie zasobów smartfona w systemie operacyjnym komputera, przez co mając domyślny tryb MTP i tak trzeba wpisać hasło, by móc cokolwiek ze smartfonem robić. Może ktoś dysponuje argumentami, które przemawiają za przestawieniem trybu USB na Charge-Only? Bardzo chętnie bym się z nimi zapoznał.
  14. Każdy nowszy smartfon z Androidem oferuje możliwość zaszyfrowania wszystkich danych użytkownika zlokalizowanych na partycji /data/ . Cały proces można przeprowadzić w bardzo prosty sposób i bez większych problemów. Raz zaszyfrowanego telefonu nie da rady cofnąć do stadium przed szyfrowaniem i w zasadzie to zabezpieczenie można zdjąć jedynie przez przywrócenie urządzenia do ustawień fabrycznych. My tutaj jednak nie będziemy zajmować się samym szyfrowaniem smartfona i skupimy się bardziej na hasłach zabezpieczających mających stać na straży dostępu do naszych cennych danych, które mamy w telefonie. Większość z nas wykorzystuje krótkie hasło do odblokowania ekranu. To samo hasło z kolei jest wykorzystywane do zaszyfrowania klucza używanego w procesie szyfrowania/deszyfrowania danych na flash'u smartfona. W ustawieniach Androida nie ma jednak opcji rozdzielenia tych haseł i można by pomyśleć, że wykorzystanie czterocyfrowego kodu PIN jako zabezpieczenie mija się z celem. Na pewno w części smartfonów tak ale niekoniecznie we wszystkich modelach. Tak się składa, że akurat leży u mnie nieużywany Neffos Y5 od TP-LINK, to postanowiłem przyjrzeć się nieco bliżej tej kwestii haseł i sprawdzić czy jest się czego obawiać stosując krótkie hasła w zaszyfrowanych Androidach. Krótkie hasło zabezpieczające i szyfrowanie danych Proces szyfrowania i deszyfrowania danych jest jako taki transparentny dla użytkownika ale by był on możliwy, potrzebny jest nam stosowny klucz szyfrujący. Taki klucz jest przechowywany zwykle na końcu partycji /data/ , na przestrzeni ostatnich 16 KiB. Nie jest to jednak reguła ale w przypadku tych TP-LINK'owych telefonów, klucz znajduje się właśnie w tym miejscu. W niektórych modelach smartfonów, do tego celu jest wykorzystywana osobna partycja ale generalnie zasada działania mechanizmu szyfrującego jest taka sama, tj. trzeba ten klucz załadować do pamięci telefonu. Gdyby ten klucz szyfrujący sobie leżał w formie czytelnej na partycji /data/ , to szyfrowanie danych byłoby pozbawione sensu. Dlatego też ten klucz trzeba również zaszyfrować i robi się to drugim kluczem, który pochodzi od hasła użytkownika. W taki sposób klucz szyfrujący dane na smartfonie nie jest przechowany w formie jawnej, co utrudnia, bądź też uniemożliwia, jego odzyskanie. No chyba, że do zaszyfrowania tego klucza zostało użyte krótkie hasło. Krótkie hasła mają ten problem, że są bardzo podatne na ataki siłowe mające na celu odgadnięcie hasła przez próbowanie wszystkich możliwych kombinacji. W przypadku standardowego kodu PIN, to jest raptem 10000 możliwości, a praktycznie każdy domowy komputer jest w stanie znaleźć ten właściwy kod w czasie paru czy parunastu minut. Może i nasz smartfon ma zabezpieczenia, które po kilku nieudanych próbach odblokowania ekranu spowolnią kolejne próby zdjęcia blokady lub też żądają zresetowania telefonu albo nawet przeprowadzają bez pytania proces Factory Reset ale ten mechanizm chroni nasz telefon jedynie, gdy ten działa. Nie ochroni nas on jednak w przypadku, gdy telefon wyłączymy i zrobimy sobie kopię binarną całej partycji /data/ , na której mamy zaszyfrowany klucz główny. Tutaj ogromne znaczenie ma skomplikowane i długie hasło, które potrafi wydłużyć czas jego łamania do rzędu dziesiątek czy setek lat. Jak już zostało wspomniane we wstępie, Android domyślnie korzysta z tego samego hasła zarówno w przypadku blokady ekranu jak i do odszyfrowania klucza szyfrującego dane na smartfonie. W ustawieniach Androida nie mamy praktycznie żadnej opcji zmiany hasła szyfrującego klucz główny, no chyba, że zmienimy również hasło blokady ekranu. Problem w tym, że raczej nikt z nas nie będzie wpisywał długiego hasła za każdym razem, gdy chce skorzystać z telefonu. Część smartfonów z nowszą wersją Androida (5.0+) wspiera sprzętowe szyfrowanie i tak samo jest w przypadku Neffos'a Y5. Tutaj główną rolę odgrywa TEE (Trusted Execution Environment). W starszych wersjach Androida, klucz główny jest szyfrowany kluczem wygenerowanym przez scrypt na podstawie hasła użytkownika i przechowywanej soli. W przypadku nowszych smartfonów, takie urządzenia mają zaszyty w SoC dodatkowy unikalny klucz szyfrujący, którego nie da rady w żaden sposób wydobyć. To właśnie ten dodatkowy klucz sprawia, że odszyfrowanie danych w trybie off-line jest praktycznie niemożliwe. Dlatego też hasło użytkownika nie ma tutaj zbyt dużego znaczenia. Trzeba jednak mieć na uwadze, że nie wszystkie smartfony posiadają wsparcie dla sprzętowego szyfrowania i w ich przypadku przydałoby się używać dwóch różnych haseł. Choć ja uważam, że również i w każdym innym przypadku dwa różne hasła są lepsze niż jedno. Zmiana hasła szyfrowania przez adb Technicznie rzecz biorąc, mając w smartfonie wsparcie dla sprzętowego szyfrowania możemy sobie darować zmianę hasła. Niemniej jednak, dla tych osób, które chcą jeszcze bardziej poprawić bezpieczeństwo danych przechowywanych na smartfonie, istnieje możliwość rozdzielenia haseł, tak by z jednej strony telefon miał krótkie hasło blokady ekranu, a zarazem długie hasło wykorzystywane przy szyfrowaniu danych. Możemy to zrobić w zasadzie na dwa sposoby: przy pomocy aplikacji Cryptfs Password (źródła) lub też przy pomocy adb . To co łączy te dwie metody, to niestety ukorzeniony system (root), a jak wiadomo większość użytkowników smartfonów nie posiada root'a. W przypadku tego Neffos'a Y5, proces root można przeprowadzić bez większego problemu i naturalnie mój model ma już ten proces za sobą. Jeśli nie zamierzamy instalować dodatkowych aplikacji w telefonie, to naturalnie możemy skorzystać z adb . Podłączamy zatem nasz telefon do portu USB komputera i logujemy się na użytkownika root: # adb shell shell@Y5:/ $ su root@Y5:/ # Luzujemy nieco politykę bezpieczeństwa SELinux tak, by widzieć komunikaty zwracane przez vdc . Zmiany są jedynie tymczasowe i po zresetowaniu smartfona wszystko wróci do normy. Same komunikaty potrzebne nam są natomiast do zweryfikowania czy polecenia, które będziemy wykonywać, wykonały się z powodzeniem, czy też wystąpił jakiś błąd. root@Y5:/ # supolicy --live 'allow vdc devpts chr_file {read write getattr ioctl}' supolicy v2.79 (ndk:armeabi-v7a) - Copyright (C) 2014-2016 - Chainfire Patching policy ... (Android M policy compatibility mode) -allow:vdc:devpts:chr_file:read=ok -allow:vdc:devpts:chr_file:write=ok -allow:vdc:devpts:chr_file:getattr=ok -allow:vdc:devpts:chr_file:ioctl=ok - Success W tym przypadku hasło do odblokowania ekranu jest ustawione na PIN 1111. By odszyfrować telefon, podczas jego startu również trzeba ten kod wprowadzić. Po zmianie hasła, kod do blokady ekranu zostanie taki sam, natomiast hasło przy starcie będzie już inne. Hasło zmieniamy w poniższy sposób (w zależności od wersji Androida, polecenia do zmiany hasła się różnią): root@Y5:/ # vdc cryptfs changepw password 1111 jakies-haslo 200 0 0 Te cyferki wyżej ( 200 0 0 ) wskazują, że hasło zostało zmienione. Gdyby tutaj było 200 0 -1 , wtedy wystąpił jakiś błąd przy zmianie hasła i dalej mamy stare hasło. To hasło można zweryfikować poniższym poleceniem: root@Y5:/ # vdc cryptfs verifypw jakies-haslo 200 0 -1 Problem jednak w tym, że jak widać wyżej po cyferkach, mamy błąd, a to oznacza, że przy pomocy tego hasła nie da rady odszyfrować telefonu. Do końca nie wiem w czym tkwi problem ale samo hasło działa jak najbardziej i można przy jego pomocy odszyfrować telefon. Być może są jakieś błędy w kodzie Androida, który jest wgrany na ten smartfon, np. podobne do tych opisanych tutaj. Niemniej jednak, to o czym warto pamiętać, to jeśli zmienimy to hasło i podczas startu smartfona nie będziemy w stanie go odszyfrować, to czeka nas przywracanie ustawień urządzenia do domyślnych, czyli utracimy bezpowrotnie wszelkie dane z partycji /data/ . Dlatego też lepiej na firmowym smartfonie nie przeprowadzać procesu zmiany hasła bez absolutnej pewności co do późniejszego odszyfrowania zawartości telefonu. Po zmianie hasła resetujemy telefon i podczas startu podajemy już nowe hasło. W taki oto prosty sposób mamy dwa różne hasła (jedno do blokady ekranu, a drugie do szyfrowania partycji /data/ ). Jeśli kogoś interesuje zagadnienie szyfrowania danych w Androidzie, to naturalnie może sobie poczytać o szczegółach tutaj, tutaj, tutaj oraz tutaj. Czy zmiana hasła blokady ekranu wpływa na hasło klucza szyfrującego Czytając kilka artykułów, natknąłem się na wzmiankę, że zmiana hasła do blokady ekranu ma zmieniać również hasło od klucza szyfrującego. Nie wiem jak jest w przypadku innych telefonów czy wersji Androida ale w przypadku Neffos'a Y5, tego typu problem nie występuje. Hasło do blokady można zmienić bez większego problemu w ustawieniach ale hasło od klucza pozostaje takie jak zostało ustawione przez adb .
  15. Gdy zamierzamy zbudować sobie własny ROM na smartfon z Androidem, np. LineageOS (CyanogenMod nie jest już rozwijany) czy nawet jedynie obraz recovery (TWRP albo CWM), to potrzebne nam jest stosowne urządzenie oraz odpowiedni kod źródłowy. Skoro chcemy budować te ww. rzeczy, to prawdopodobnie nasz telefon nie jest przez to oprogramowanie jeszcze wspierany lub też sam soft nie jest regularnie aktualizowany przez dewelopera. W zasadzie zarówno pełne ROM'y jak i obrazy recovery są budowane ze źródeł Androida. Niemniej jednak, oficjalny kod dostarczany przez Google budzi czasem wiele kontrowersji i ci nieco bardziej zaawansowani użytkownicy zmieniają go, np. czyniąc go w pełni OpenSource czy też implementując w nim pewną niestandardową funkcjonalność. Tak powstają Custom ROM'y, które w późniejszym czasie z racji swojej popularności przestają być "Custom" i zaczynają żyć swoim własnym życiem obok tego Góglowskiego Androida. W przypadku budowania obrazu recovery nie są nam potrzebne całe źródła konkretnego ROM'u. Jakby nie patrzeć, potrafią one zajmować trochę miejsca, a poza tym proces ich budowania jest stosunkowo czasochłonny. Tak czy inaczej, jakieś źródła trzeba pozyskać i przygotować je do dalszej pracy. W tym artykule nie będziemy sobie jeszcze budować całego ROM'u i skupimy się na zbudowaniu od podstaw jedynie obrazu TWRP recovery ze źródeł OMNI ROM. Ten proces zostanie pokazany na przykładzie smartfona Neffos Y5 od TP-LINK przy wykorzystaniu systemu linux, a konkretnie dystrybucji Debian. Android SDK Operowanie na oprogramowaniu, które mamy w naszych smartfonach, wymaga zainstalowania na komputerze pakietu Android SDK. W nim zawarte są narzędzia deweloperskie min. fastboot i adb , przy pomocy których będziemy w stanie przeprowadzić szereg akcji na smartfonie. Te narzędzia można zainstalować w systemie na kilka sposobów. Standardowo fastboot i adb są dostępne w repozytoriach Debiana w pakietach android-tools-adb oraz android-tools-fastboot . Proces instalacji i konfiguracji tych narzędzi na Debianie został opisany w osobnym wątku. Niemniej jednak, nie są to wszystkie narzędzia, które Android SDK dostarcza, a biorąc pod uwagę fakt, że obecnie w Debianie panuje spory nieporządek w pakietach, to lepiej zainstalować Android SDK lub Android Studio bezpośrednio ze strony Google. Narzędzia repo i git Do pobrania źródeł Androida jest wykorzystywane dedykowane narzędzie repo . W dystrybucji Debiana mamy taki pakiet i możemy go bez większego problemu zainstalować. Problem w tym, że wersja tego narzędzia może być nieaktualna. Obecnie jest to 1.23 . Najnowsza wersja repo jest dostępna zawsze pod tym linkiem. By ją zainstalować ręcznie w systemie, w terminalu wpisujemy poniższe polecenia: # curl https://storage.googleapis.com/git-repo-downloads/repo > /usr/local/bin/repo # chmod a+x /usr/local/bin/repo # chown root:staff /usr/local/bin/repo Narzędzie repo operuje na git i ten pakiet również musimy w systemie sobie zainstalować. Podstawy operowania na repozytorium GIT musimy znać. Warto zatem rzucić okiem na dokumentację git'a i ją sobie chociaż powierzchownie przejrzeć. Przygotowanie katalogu roboczego pod źródła Źródła Androida trzeba gdzieś pobrać. Stwórzmy sobie zatem dedykowany katalog roboczy i przejdźmy do niego: $ mkdir /Android/android-src/ $ cd /Android/android-src/ Od tej chwili wszystkie polecenia będą wydawane w tym właśnie katalogu. Inicjowanie repozytorium GIT Na samym początku trzeba zainicjować lokalne repozytorium. Różne smartfony działają pod kontrolą innych wersji Androida (Lollipop, Marshmallow, Nougat). Jeśli zamierzamy kompilować jedynie część modułów, a nie cały ROM, i to głównie dla siebie, to warto zadbać o to, by wersja źródeł Androida pasowała do wersji Androida, którą mamy w telefonie. Niemniej jednak, w przypadku obrazu TWRP recovery możemy korzystać z najnowszych źródeł, bo w zasadzie nie będziemy wgrywać żadnych plików bezpośrednio na partycję /system/ , która zawiera stock'owy ROM. Musimy zatem określić stosowną gałąź repozytorium GIT, którą zamierzamy sobie sklonować na dysk. Lista wszystkich gałęzi jest dostępna tutaj i z reguły Custom ROM'y przestrzegają tego nazewnictwa. Warto też określić parametr --depth=1 , który uchroni nas przed pobraniem wszystkich rewizji. Zamiast tego, zostanie pobrany jedynie ostatni snapshot wskazanej przez nas gałęzi, a to z kolei znacznie zmniejszy ilość danych, które trzeba będzie przetransferować przez sieć. Bez tej opcji zostałoby pobranych jakieś 30-40 GiB, a może nawet i więcej). Źródła TWRP recovery znajdują się tutaj. Niektóre ROM'y nie mają zawartego w sobie tego repozytorium i trzeba je ręcznie określić w pliku .repo/manifest.xml w katalogu ze źródłami Androida. My jednak będziemy korzystać ze źródeł OMNI ROM, które już to repozytorium zawiera. Zatem żadnych dodatkowych kroków nie będziemy musieli przeprowadzać. Lokalne repozytorium inicjujemy w poniższy sposób: $ repo init -u https://github.com/omnirom/android -b android-7.1 --depth=1 Po zainicjowaniu lokalnego repozytorium, w katalogu roboczym powinien pojawić się folder .repo/ . W nim z kolei znajduje się plik (właściwie link) manifest.xml . Zajrzyjmy do niego i upewnijmy się, że w default revision widnieje numerek wskazanej wyżej wersji Androida ( android-7.1.x ). Warto wspomnieć, że większość repozytoriów zdefiniowanych w pliku manifest.xml jest zbędna przy budowaniu samego obrazu TWRP recovery. Jeśli komuś nie zależy na oszczędzaniu transferu danych oraz ma dostatecznie dużo miejsca na dysku, to może pobrać całe źródła OMNI ROM. Dla tych, którzy skąpią miejsca na dysku i transferu jest okrojona wersja, którą można z powodzeniem wykorzystać. Poniżej jest polecenie inicjujące lokalne repozytorium z wykorzystaniem okrojonego pliku manifest.xml . $ repo init -u git://github.com/minimal-manifest-twrp/platform_manifest_twrp_omni.git -b twrp-6.0 --depth=1 W tym przypadku, lokalne repozytorium zostało zainicjowane w oparciu o ten okrojony plik manifest.xml . Trzeba tutaj jednak wyraźnie zaznaczyć, że niektóre konfiguracje sprzętowe (czy też opcje trybu recovery) będą wymagać dodatkowych repozytoriów, które trzeba będzie ręcznie dodać do pliku .repo/local_manifests/local_manifest.xml . Warto zatem poznać budowę tego pliku i nauczyć się na nim operować. Gdy już uporządkujemy sprawy związane z repozytoriami, to przy pomocy repo sync synchronizujemy źródła każdego repozytorium, które mamy zdefiniowane w pliku manifests.xml . Naturalnie im więcej ich mamy, tym więcej miejsca będą one zajmować i dłużej będzie trwał proces synchronizacji. W przypadku, gdy dysponujemy szybkim łączem internetowym, to możemy też zwiększyć liczbę jednoczesnych połączeń przy pomocy --jobs (domyślnie 4): $ repo sync --current-branch --jobs=4 Zależności potrzebne do zbudowania Androida ze źródeł Pobranie źródeł to jedna sprawa, a ich zbudowanie to całkiem inna kwestia. By uniknąć ewentualnych problemów będziemy musieli zainstalować w systemie kilka dodatkowych zależności. Poniżej jest lista potrzebnych rzeczy: # aptitude install git-core gnupg flex bison gperf build-essential \ zip curl zlib1g-dev gcc-multilib g++-multilib libc6-dev-i386 \ lib32ncurses5-dev x11proto-core-dev libx11-dev lib32z-dev ccache \ libgl1-mesa-dev libxml2-utils xsltproc unzip openjdk-7-jdk Bez tych pakietów, proces budowy obrazu będzie napotkał błędy podobne do tego opisanego tutaj. Przyśpieszenie procesu kompilacji z ccache Kompilacja to proces czasochłonny i dość zasobożerny. W zasadzie budując ten sam kod kilka razy, nie ma potrzeby ponawiania całego procesu kompilacji, bo w sporej części przypadków można odwołać się do już zbudowanych obiektów. Niemniej jednak, potrzebny jest nam jakiś cache dla kompilatora, którego standardowo w linux'ie nie ma. Dlatego właśnie powstało narzędzie ccache , które jest nam w stanie dość znacznie umilić życie, przy ciągłym budowaniu tych samych programów czy projektów. Narzędzie ccache musimy sobie odpowiednio skonfigurować. Na dobrą sprawę, to jedyne co musimy zrobić, to dodać te dwie poniższe zmienne do pliku ~/.bashrc lub ~/.zshrc : export USE_CCACHE=1 export CCACHE_DIR=/mnt/.ccache Rozmiar całego cache definiujemy w poniższy sposób (polecenie wywołane z głównego katalogu ze źródłami Androida): $ prebuilts/misc/linux-x86/ccache/ccache -M 50G Jeśli chcemy się upewnić, czy ccache działa prawidłowo, to odpalamy osobny terminal podczas procesu kompilacji, przechodzimy do katalogu ze źródłami i wydajemy poniższe polecenie: $ watch -n1 -d prebuilts/misc/linux-x86/ccache/ccache -s Tworzenie konfiguracji dla TWRP recovery pod konkretny model smartfona W zasadzie źródła już mamy przygotowane do budowania ale potrzebna nam jest jeszcze konfiguracja dla naszego smartfona. Musimy zatem stworzyć kilka plików i katalogów. Poniższe informacje dotyczą smartfona Neffos Y5 ale ten krok w zasadzie nie różni się w przypadku innych modeli telefonów. Jedyne co, to trzeba pozyskać pewne informacje na temat podzespołów urządzenia (min. SoC), dla którego zamierzamy zbudować obraz TWRP i wpisać te dane w stosowne miejsca. Najprościej jest zacząć od pliku /system/build.prop , który został zawarty w stock'owym firmware (można też wyciągać zawartość zmiennych przez getprop ). Podłączmy zatem na moment smartfon do komputera i przy pomocy adb patrzymy co siedzi w zmiennych ro.product.manufacturer oraz ro.product.name : # adb shell "getprop ro.product.manufacturer" TP-LINK # adb shell "getprop ro.product.name" TP802A Przechodzimy teraz do głównego folderu ze źródłami Androida i pod device/ tworzymy strukturę katalogów na zasadzie manufacturer/name . Wszystkie nazwy mają być pisane z małych liter: $ mkdir device/tp-link/tp802a/ W tak powstałym katalogu tworzymy konfigurację dla naszego smartfona, w tym przypadku Neffos Y5. Poniżej znajduje się krótkie objaśnienie co do struktury plików. Plik device.mk Zaczynamy od utworzenia pliku device.mk , gdzie będziemy definiować wszystkie niezbędne moduły i pliki wymagane do zbudowania obrazu TWRP recovery dla naszego smartfona. Plik omni_tp802a.mk Następnie tworzymy plik omni_tp802a.mk , w którym będą deklarowane informacje takie jak nazwa, model i producent smartfona. Plik AndroidProducts.mk Kolejny plik, który musimy utworzyć, to AndroidProducts.mk . W nim zamieszczamy wpis wskazujący na ten powyższy plik omni_tp802a.mk . Plik BoardConfig.mk Plik BoardConfig.mk jest w zasadzie sercem całej konfiguracji. To w tym pliku określamy min. to co tak naprawdę siedzi w naszym smartfonie. Znajdują się tutaj ustawienia platformy sprzętowej, architektury systemowej, konfiguracja kernela, rozmiary poszczególnych partycji oraz oczywiście opcje TWRP recovery. Wszystkie te parametry mogą się różnic w zależności od podzespołów smartfona, z którym mamy do czynienia. W zasadzie obraz TWRP recovery powinien działać bez zarzutu nawet przy minimalnej konfiguracji ale w przypadku budowania pełnego ROM'u, to już niestety będziemy musieli nieco bardziej się postarać, by nasz smartfon działał bez problemu na nowym oprogramowaniu. Część opcji, które trzeba określić w BoardConfig.mk , można wyciągnąć ze smartfona zaglądając do pliku /system/build.prop . Poniżej znajduje się też lekka rozpiska ułatwiająca pozyskanie informacji dla poszczególnych sekcji. Sekcja Platform Sekcję Platform może nam sprawić najwięcej problemów, zwłaszcza gdy nie mamy za bardzo pojęcia jakie podzespoły siedzą w naszym smartfonie. W tym przypadku mamy do czynienia z Neffos Y5 i on posiada SoC MSM8909 od Qualcomm. Konfiguracja konkretnego SoC jest w zasadzie stała i można ją przepisać ze źródeł innego smartfona, który ma ten sam SoC, zakładając oczywiście, że deweloper nie popełnił błędów w konfiguracji tamtego urządzenia. Sekcja Kernel Bawiąc się w ukorzenianie swoich Neffos'ów, jednym z wymaganych etapów było rozmontowanie obrazu boot.img za pomocą tych skryptów. Podczas tego procesu, w terminalu można było zanotować poniższe wyjście: Jak widzimy, praktycznie cała sekcja jest nam podana jak na dłoni i wystarczy uzupełnić stosowne parametry dodając przed ich wartościami 0x . Trzeba tutaj zaznaczyć, że my nie budujemy kernela ze źródeł Androida i załączamy tutaj plik kernela, który można wyciągnąć po rozmontowaniu stock'owego obrazu boot.img . Sekcja Qualcomm Sekcja Qualcomm definiuje szereg opcji specyficznych dla SoC tego producenta. W zasadzie to trzeba dostosować ścieżkę, która musi wskazywać na bazę platformy naszego smartfona. Ścieżka w tym przypadku wskazuje na katalog /sys/devices/soc.0/ ale z pominięciem /sys/ . Sekcja Encryption Nowsze wersje TWRP recovery wspierają szyfrowanie/deszyfrowanie partycji /data/ . Jeśli z poziomu Androida zaszyfrowaliśmy dane użytkownika, to TWRP standardowo nie będzie w stanie zamontować tej partycji, co będzie przyczyną całej masy błędów. Dlatego też musimy włączyć moduł szyfrowania. W zasadzie mamy dwa rodzaje szyfrowania: programowe i sprzętowe. To, które w naszym smartfonie zostało zaimplementowane możemy odczytać przechodząc w Ustawienia Androida => Zabezpieczenia => Typ Pamięci. W przypadku smartfona Neffos Y5, widzimy, że mamy do czynienia z szyfrowaniem sprzętowym, bo widnieje zapis "Wspomagana sprzętowo". Gdyby tam widniał zapis "Tylko programowa", to szyfrowanie byłoby jedynie programowe. Naturalnie szyfrowanie sprzętowe wymaga od nas dodatkowych nakładów pracy, by je skonfigurować. W zasadzie to trzeba będzie pozyskać szereg plików ze stock'owego firmware i uwzględnić je w obrazie TWRP. Bez tych plików, nie da rady odszyfrować danych na partycji /data/ nawet podając prawidłowe hasło. System za każdym razem zwróci nam taki oto błąd. To jakie pliki trzeba będzie uwzględnić w obrazie zależy od modelu smartfona. Nie da rady tego prosto ustalić i w zasadzie pozostaje nam dochodzenie do rozwiązania metodą prób i błędów. Możemy naturalnie podpierać się logami z trybu recovery, które mogą zawierać nazwy wymaganych bibliotek, a to już może nam wskazać dobrą drogę. Sekcja Partitions W oparciu o dane z pliku /proc/partitions lub /proc/emmc trzeba odpowiednio opisać kilka partycji smartfona. Chodzi generalnie o partycje /boot/ , /recovery/ , /system/ , /data/ oraz /cache/ . Do odczytania rozmiaru można też zaprzęgnąć różne aplikacje na Androida, np. diskinfo. Wartości podajemy w HEX. Możemy także skonfigurować sobie wsparcie dla szeregu dodatkowych systemów plików. Trzeba jednak pamiętać, że każde dodatkowe ficzery zajmują miejsce i w pewnych konfiguracjach może nam tej przestrzeni zwyczajnie zabraknąć. Tutaj mamy do dyspozycji 32 MiB i w zasadzie jest to dość sporo. Sekcja Recovery W sekcji Recovery musimy wskazać lokalizację do pliku fstab . To przy jego pomocy TWRP będzie w stanie operować na partycjach smartfona. Ten plik trzeba sobie zbudować samemu podpierając się wpisami w /proc/partitions lub /proc/emmc oraz aplikacjami na smartfona typu diskinfo. Sekcja TWRP W sekcji TWRP ustawia się opcje charakterystyczne dla TWRP recovery. Wszystkich opcji jest dość sporo i są one wyszczególnione pod tym linkiem. W zasadzie to musimy poprawnie ustawić zmienną TW_THEME , która odpowiada za rozdzielczość wyświetlacza smartfona. Do wyboru mamy: # portrait_mdpi = 320x480 480x800 480x854 540x960 # portrait_hdpi = 720x1280 800x1280 1080x1920 1200x1920 1440x2560 1600x2560 # watch_mdpi = 240x240 280x280 320x320 # landscape_mdpi = 800x480 1024x600 1024x768 # landscape_hdpi = 1280x800 1920x1200 2560x1600 Neffos Y5 ma rozdzielczość 720x1280, dlatego został wybrany portrait_hdpi . Może i mamy tutaj do wyboru dwa tryby wyświetlania (portrait i landscape) ale TWRP nie potrafi się przełączać między nimi dynamicznie. Jeśli chcemy mieć układ poziomy, to nie da rady przełączyć go w pionowy i vice versa. Pozostałe opcje mają raczej samo opisujące się nazwy. Plik vendorsetup.sh Za sprawą pliku vendorsetup.sh będziemy w stanie dodać nasze urządzenie do budowania. Ten plik będzie miał jedną linijkę, w której musimy określić dwie rzeczy: product_name oraz variant . Jeśli chodzi o product_name , to odczytujemy go z pliku omni_tp802a.mk ze zmiennej PRODUCT_NAME . Natomiast w variant możemy ustawić min. eng , user albo userdebug . Nas interesuje ta ostatnia opcja oferująca dostęp root i tryb debugowania. Budowanie obrazu TWRP recovery By przygotować środowisko pod budowę źródeł TWRP recovery, musimy wyeksportować szereg zmiennych. Nie robimy tego jednak ręcznie, a za pomocą pliku build/envsetup.sh w poniższy sposób: $ make clobber $ . ./build/envsetup.sh including device/tp-link/tp802a/vendorsetup.sh Jak widać wyżej, konfiguracja dla naszego smartfona została załączona. W przypadku korzystania z innego shell'a niż bash (w moim przypadku zsh ) wydanie tego powyższego polecenia zwraca takie oto ostrzeżenie: $ . ./build/envsetup.sh build/envsetup.sh:565: command not found: complete WARNING: Only bash is supported, use of other shell would lead to erroneous results Wygląda na to, że na czas budowy czegoś związanego z Androidem, trzeba korzystać z bash'a. Teraz możemy wpisać lunch i wybrać wcześniej stworzoną kombinację: $ lunch You're building on Linux Lunch menu... pick a combo: 1. aosp_arm-eng 2. aosp_arm64-eng 3. aosp_mips-eng 4. aosp_mips64-eng 5. aosp_x86-eng 6. aosp_x86_64-eng 7. omni_tp802a-userdebug Which would you like? Mamy na liście omni_tp802a-userdebug i to ją musimy wskazać. Możemy także od razu podać tę pozycję w lunch : $ lunch omni_tp802a-userdebug No i teraz pozostało nam już zbudowanie źródeł. Pamiętajmy tylko, że budujemy jedynie obraz TWRP recovery, a do tego celu służy poniższe polecenie: $ make clean && make -j2 recoveryimage Po kilku czy kilkunastu minutach, obraz recovery powinien nam się zbudować: Repozytorium git na Github'ie Po zbudowaniu obrazu TWRP sprawdzamy naturalnie czy działa on prawidłowo ładując plik out/target/product/tp802a/recovery.img na smartfon przy pomocy fastboot boot . Jeśli nie mamy zastrzeżeń co do działania trybu recovery, to możemy stworzoną w powyższy sposób konfigurację TWRP opublikować na GitHub'ie. Oczywiście musimy posiadać stosowne konto i stworzyć odpowiednie repozytorium. Nazwa tego repozytorium ma wskazywać na ścieżkę drzewa katalogów konfiguracji urządzenia. Przykładowo, mamy tutaj ścieżkę source/device/tp-link/tp802a/ , zatem nazwa repozytorium to android_device_tp-link_tp802a : Następnie przechodzimy do katalogu z plikami konfiguracyjnymi, z których zbudowaliśmy obraz TWRP recovery i inicjujemy w nim lokalne repozytorium: $ cd /Android/omni-twrp-6.0/device/tp-link/tp802a/ $ git init $ git remote add origin git@github.com:morfikov/android_device_tp-link_tp802a.git W pliku .git/config dopisujemy sobie te poniższe parametry: [user] name = Mikhail Morfikov email = morfik@nsa.com signingkey = 0xCD046810771B6520 [gpg] program = gpg Następnie dodajemy wszystkie plik, tworzymy commit i nową gałąź, którą nazywamy sobie, np. twrp-6.0 : $ git add --all $ git commit -S -m "first commit" $ git branch twrp-6.0 $ git checkout twrp-6.0 $ git add --all Teraz już wystarczy przesłać zmiany do zdalnego repozytorium na GitHub'ie: $ git push origin master $ git push origin twrp-6.0 I to w zasadzie cała robota. Wszelkie zmiany w repozytorium od tej pory będą rejestrowane przez system kontroli wersji. Możemy także przesłać całą konfigurację, tak by TWRP oficjalnie wspierało naszego smartfona.
  16. W Androidzie 6.0 Marshmallow został wprowadzony ciekawy mechanizm zwany Adoptable Storage, który umożliwia zamontowanie karty SD w smartfonie jako pamięć wewnętrzna. W ten sposób pamięć flash w telefonach, które mają jej niewiele, może zostać nieco rozbudowana. Jedyny problem z tym całym Adoptable Storage jest taki, że Android szyfruje zawartość karty SD automatycznie, przez co nie jesteśmy w stanie odczytać żadnych informacji z takiego nośnika na innych urządzeniach. Istnieje jednak sposób, by rozszyfrować i tym samym uzyskać dostęp do danych zgromadzonych na karcie SD z poziomu linux'a, np. dystrybucji Debian. W tym artykule prześledzimy sobie właśnie ten proces na przykładzie smartfona Neffos Y5 od TP-LINK. Ukorzeniony Android Marshmallow (root) Jako, że w grę wchodzi szyfrowanie danych, to ten proces zwykle jest należycie chroniony przez system w naszym telefonie. Dlatego też dostęp do interesujących nas plików (np. via adb ) jest bardzo ograniczony. By uzyskać dostęp do tych plików, musimy posiadać ukorzeniony system na smartfonie, tj. przeprowadzić na nim proces root. W przypadku tych TP-LINK'owych smartfonów dostępnych na polskim rynku, to tylko Neffos Y5 i Neffos Y5L mają wgranego Androida w wersji 6.0, dlatego też cały proces zostanie opisany w oparciu o jedno z tych urządzeń. W zasadzie mocniejszym sprzętem jest Neffos Y5 i dlatego zdecydowałem się nim posłużyć. Informacje na temat ukorzeniania Androida w Neffos Y5 znajdują się tutaj. Zakładam zatem w tym miejscu, że nasz smartfon przeszedł proces root. Formatowanie karty SD jako pamięć wewnętrzna Weźmy sobie zatem w łapki nasz smartfon i wsadźmy do niego jakąś kartę SD, którą zamierzamy sformatować jako pamięć wewnętrzna. Cały proces jest niemal automatyczny i wystarczy przejść do Ustawienia => Pamięć plików i kliknąć w "Karta SD". Mamy tam pozycję "Sformatuj jako pamięć wewn." i to w nią klikamy. Postępujemy zgodnie z informacjami na ekranie i po chwili karta powinna zostać przygotowana do pracy, tj. sformatowana, zaszyfrowana i zamontowana w systemie: Możemy też sprawdzić, gdzie Android montuje naszą kartę SD w systemie (przez adb) korzystając z polecenia mount : root@Y5:/ # mount | grep expand /dev/block/dm-0 /mnt/expand/9acfb46c-f218-43e7-a14a-a3592183af6d ext4 rw,dirsync,seclabel,nosuid,nodev,noatime 0 0 Poszukiwanie klucza szyfrującego dane karty SD Kartę SD można naturalnie wyciągnąć ze smartfona (pierw trzeba ją odmontować w Androidzie) i podłączyć do komputera przez czytnik kart SD. Gdybyśmy jednak taki zabieg zrobili, to okaże się, że nasz linux w komputerze nie rozpozna nam tego nośnika. W prawdzie gdisk będzie nam w stanie podać informacje o układzie partycji ale nie dostaniemy się do samego systemu plików: # gdisk -l /dev/sdb GPT fdisk (gdisk) version 1.0.1 Partition table scan: MBR: protective BSD: not present APM: not present GPT: present Found valid GPT with protective MBR; using GPT. Disk /dev/sdb: 3854336 sectors, 1.8 GiB Logical sector size: 512 bytes Disk identifier (GUID): 1281EE27-00C5-4CC7-8004-94DDBCEF829C Partition table holds up to 128 entries First usable sector is 34, last usable sector is 3854302 Partitions will be aligned on 2048-sector boundaries Total free space is 2014 sectors (1007.0 KiB) Number Start (sector) End (sector) Size Code Name 1 2048 34815 16.0 MiB FFFF android_meta 2 34816 3854302 1.8 GiB FFFF android_expand Nas tutaj interesuje ta druga partycja, bo to tam są zgromadzone zaszyfrowane dane. By informacje na tej partycji odszyfrować, potrzebny nam jest klucz szyfrujący, a ten z kolei znajduje się gdzieś na smartfonie, pytanie tylko gdzie? Wzór nazwy klucza można wyciągnąć w poniższy sposób: root@Y5:/ # which vold /system/bin/vold root@Y5:/ # strings /system/bin/vold | grep -i expand --change-name=0:android_expand /mnt/expand/%s %s/expand_%s.key Wiemy zatem, że klucz nazywa się expand_%s.key , z tym, że do końca nie wiem za co odpowiada %s . Tak czy inaczej, wszystkie klucze są przechowywane pod /data/misc/vold/ : root@Y5:/ # ls -al /data/misc/vold/ drwx------ root root 2017-02-08 22:40 bench -rw------- root root 16 2017-02-08 22:40 expand_06bc225178c5900fe64800e4b70efd25.key Ten plik z rozszerzeniem .key jest tworzony w momencie, gdy formatujemy kartę SD jako pamięć wewnętrzna. Podobnie jest on usuwany ilekroć tylko będziemy nakazywać Androidowi zapomnienie tego nośnika. Jak widać, mając ukorzeniony system, dostęp do tego klucza jest praktycznie niechroniony (do tego brak zabezpieczenia hasłem), zatem każdy może go skopiować. Będąc w posiadaniu tego klucza, możemy odszyfrować zawartość karty SD na dowolnej maszynie wyposażonej w pierwszą lepszą dystrybucję linux'a. Odszyfrowanie zawartości karty SD Znając położenie klucza szyfrującego na smartfonie, możemy ten klucz wydobyć w poniższy sposób (zakodowany w HEX): root@Y5:/ # od -t x1 /data/misc/vold/expand_06bc225178c5900fe64800e4b70efd25.key 37777776620 6c 33 be 5d df 7b a0 d0 ca 41 fe d7 a7 8f 75 db 37777776620 Ten widoczny wyżej ciąg 16 bajtów (128 bitów) tj. 6c33be5ddf7ba0d0ca41fed7a78f75db , to nasz klucz szyfrujący dane na karcie SD, który teraz trzeba wskazać w dmsetup na linux. Dodatkowo, potrzebnych jest nam jeszcze kilka parametrów. Musimy min. wiedzieć jaki rodzaj szyfru jest wykorzystywany w procesie szyfrowania i deszyfrowania informacji na karcie SD oraz musimy znać szereg offsetów. Zgodnie z informacjami jakie znalazłem tutaj, Android korzysta z aes-cbc-essiv:sha256 . Offsety mogą być różne ale za punkt wyjścia można obrać 0 . Zatem linijka z dmsetup przybierze poniższą postać: # dmsetup create sdcard --table "0 `blockdev --getsize /dev/sdb2` crypt aes-cbc-essiv:sha256 6c33be5ddf7ba0d0ca41fed7a78f75db 0 /dev/sdb2 0" Dokładne wyjaśnienie wszystkich opcji użytych powyżej znajduje się tutaj. Jeśli to powyższe polecenie nie zwróci żadnego błędu, to możemy spróbować zamontować ten zasób w systemie. System plików, który został utworzony przez Androida w tym zaszyfrowanym kontenerze znamy i jest to linux'owy EXT4. Odszyfrowany kontener zaś jest dostępny pod /dev/mapper/sdcard : # mount -t ext4 /dev/mapper/sdcard /mnt/ # ls -al /mnt total 36K drwxr-xr-x. 8 root root 4.0K 2017-02-08 22:40:50 ./ drwxr-xr-x 25 root root 4.0K 2017-01-14 10:22:16 ../ drwxrwx--x. 2 morfik morfik 4.0K 2017-02-08 22:40:31 app/ drwxr-x--x. 3 root root 4.0K 2017-02-08 22:40:38 local/ drwx------. 2 root root 4.0K 1970-01-01 01:00:00 lost+found/ drwxrwx---. 4 1023 1023 4.0K 2017-02-08 22:42:09 media/ drwxrwx--t. 3 morfik 9998 4.0K 2017-02-08 22:40:51 misc/ drwx--x--x. 3 morfik morfik 4.0K 2017-02-08 22:40:40 user/ Zatem udało nam się uzyskać dostęp do zaszyfrowanych danych. Jeśli teraz wgralibyśmy coś tutaj do katalogu user/ czy media/ , to naturalnie Android w naszym Neffos Y5 będzie w stanie bez problemu ten plik odczytać. Standardowo w przypadku, gdy zamierzamy sformatować kartę SD jako pamięć wewnętrzna, to musimy się liczyć z faktem bezpowrotnej utraty wszystkich danych zgromadzonych w telefonie, gdy ten ulegnie jakiejś większej awarii. Posiadając jednak ukorzenionego Androida, możemy taki klucz szyfrujący skopiować sobie na dysk komputera i tam go trzymać. Gdy telefon ulegnie uszkodzeniu, to dane z karty SD będziemy w stanie odczytać. Trzeba jednak również pamiętać o tym, że z telefonu ten klucz można wyciągnąć bez problemu o ile mamy w nim odblokowany bootloader (na potrzeby root, czy custom recovery), a że nie jest on w żaden sposób zabezpieczony (PIN, hasło, itp), to każdy kto zna się trochę na telefonach będzie w stanie uzyskać dostęp do danych zgromadzonych na tej karcie SD.
  17. Jakiś czas temu opisywałem kartę sieciową na USB UE200 od TP-LINK. Taki adapter jest bardzo przydatny w momencie, gdy nie posiadamy z jakiegoś powodu standardowej karty sieciowej, tak by za jej sprawą przewodowo połączyć komputer do domowej sieci. Jeden z moich komputerów cierpi właśnie na tego typu przypadłość z powodu jakiegoś bliżej nieznanego mi uszkodzenia jego wbudowanej karty sieciowej. Generalnie rzecz biorąc w ofercie TP-LINK poza tym wspomnianym UE200 jest także dostępny adapter UE300, który różni się głównie tym, że ma gigabitowy port Ethernet oraz karta jest na USB 3.0. Jako, że jestem w posiadaniu adaptera UE300, to postanowiłem sprawdzić jak (i czy w ogóle) jest rozpoznawany przez system z rodziny linux, a konkretnie na dystrybucji Debian, której używam na co dzień. Zawartość opakowania UE300 Na początek jak zawsze fotki omawianego urządzenia. W przypadku adaptera UE300 nie ma ich zbyt wiele, bo sam adapter jest w miarę prosty i niezbyt skomplikowany. Specyfikacja adaptera UE300 Adapter UE300 jakby nie patrzeć to w końcu zwykły kawałek sieciowego czipu w plastikowej obudowie z wyprowadzonym interfejsem USB 3.0 z jednej strony i gigabitowym portem Ethernet (RJ-45) z drugiej. Jeśli ktoś jest ciekaw wymiarów tego adaptera, to oto i one: 71x26x16 mm (dł/sz/wy). Na górnej części obudowy, znajduje się także biała dioda sygnalizująca stan połączenia/zasilania urządzenia: Czip RTL8153 Zgodnie z informacją podaną na stronie TP-LINK, adapter UE300 został wyposażony w czip RTL8153. Według producenta, ta karta powinna pracować bez większego problemu pod linux'em. Sprawdźmy zatem czy faktycznie te informacje zostaną potwierdzone. Po podłączeniu karty do portu USB, w logu systemowym są wypisywane poniższe komunikaty: kernel: usb: new SuperSpeed USB device number 2 using xhci-hcd kernel: usb 2-1.3: New USB device found, idVendor=2357, idProduct=0601 kernel: usb 2-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=6 kernel: usb 2-1.3: Product: USB 10/100/1000 LAN kernel: usb 2-1.3: Manufacturer: TP-LINK kernel: usb 2-1.3: SerialNumber: 000001000000 kernel: cdc_ether 2-1.3:2.0 eth0: register 'cdc_ether' at usb-0000:00:1d.0-1.3, CDC Ethernet Device, ec:08:6b:1c:87:0c kernel: usbcore: registered new interface driver cdc_ether Jak widzimy wyżej, karta została rozpoznawana w systemie jako idVendor=2357 oraz idProduct=0601 i obsługiwana jest przez moduł kernela cdc_ether . W systemie naturalnie pojawił się nowy interfejs sieciowy eth0 i w zasadzie, by korzystać z tego adaptera trzeba jedynie ten interfejs skonfigurować tak, by została mu przydzielona adresacja IP, a z tym zadaniem nie powinno być już większego problemu. Poniżej jest także załączone wyjście polecenia lsusb : # lsusb -vvv -d 2357:0601 Bus 004 Device 002: ID 2357:0601 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 3.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 9 idVendor 0x2357 idProduct 0x0601 bcdDevice 30.00 iManufacturer 1 TP-LINK iProduct 2 USB 10/100/1000 LAN iSerial 6 000001000000 bNumConfigurations 2 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 57 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 64mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 3 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 3 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0002 1x 2 bytes bInterval 8 bMaxBurst 0 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 98 bNumInterfaces 2 bConfigurationValue 2 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 64mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 2 Communications bInterfaceSubClass 6 Ethernet Networking bInterfaceProtocol 0 iInterface 5 CDC Communications Control CDC Header: bcdCDC 1.10 CDC Union: bMasterInterface 0 bSlaveInterface 1 CDC Ethernet: iMacAddress 3 EC086B1C870C bmEthernetStatistics 0x00000000 wMaxSegmentSize 1514 wNumberMCFilters 0x0000 bNumberPowerFilters 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0010 1x 16 bytes bInterval 8 bMaxBurst 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 10 CDC Data bInterfaceSubClass 0 Unused bInterfaceProtocol 0 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 1 bNumEndpoints 2 bInterfaceClass 10 CDC Data bInterfaceSubClass 0 Unused bInterfaceProtocol 0 iInterface 4 Ethernet Data Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 3 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 3 Binary Object Store Descriptor: bLength 5 bDescriptorType 15 wTotalLength 22 bNumDeviceCaps 2 USB 2.0 Extension Device Capability: bLength 7 bDescriptorType 16 bDevCapabilityType 2 bmAttributes 0x00000002 Link Power Management (LPM) Supported SuperSpeed USB Device Capability: bLength 10 bDescriptorType 16 bDevCapabilityType 3 bmAttributes 0x02 Latency Tolerance Messages (LTM) Supported wSpeedsSupported 0x000e Device can operate at Full Speed (12Mbps) Device can operate at High Speed (480Mbps) Device can operate at SuperSpeed (5Gbps) bFunctionalitySupport 2 Lowest fully-functional device speed is High Speed (480Mbps) bU1DevExitLat 10 micro seconds bU2DevExitLat 2047 micro seconds Device Status: 0x0000 (Bus Powered) Praca adaptera UE300 pod linux Może i adapter UE300 został rozpoznany bez większego problemu na Debianie ale sterownik tej karty (ten sam co przy UE200) nie daje nam zbytnio dostępu do zaawansowanych opcji konfiguracyjnych: # ethtool eth0 Settings for eth0: Current message level: 0x00000007 (7) drv probe link Link detected: no # ethtool -s eth0 autoneg off Cannot get current device settings: Operation not supported not setting autoneg # ethtool -i eth0 driver: cdc_ether version: 22-Aug-2005 firmware-version: CDC Ethernet Device expansion-rom-version: bus-info: usb-0000:00:1d.0-1.3 supports-statistics: no supports-test: no supports-eeprom-access: no supports-register-dump: no supports-priv-flags: no Niestety nie byłem w stanie przetestować faktycznej przepustowości tego adaptera, bo mój laptop nie ma portów USB 3. A na tych co ma, to maksymalny transfer jaki udało mi się uzyskać był w granicach 250 mbit/s, czyli około 30 MiB/s i to jest graniczna wartość transferu dla portów USB 2, mimo, że standard USB 2.0 mówi coś o 480 mbit/s. Niemniej jednak, jeśli dysponujemy faktycznym portem USB 3 w komputerze, to nie powinno być problemów z osiągnięciem tego 1 gbit/s.
  18. Smartfony towarzyszą nam w codziennym życiu praktycznie cały czas. Dlatego też zaczynamy przechowywać w tych urządzeniach coraz to więcej informacji osobistych, które są w stanie dość dokładnie opisać nasze życie prywatne. Co jednak w przypadku, gdy taki telefon zgubimy lub też zostanie nam on skradziony przez kogoś? Gdy chodzi o urządzenia z Androidem, to Google oferuje usługę, która jest w stanie połączyć się z naszym smartfonem i przy odrobinie szczęścia ujawnić nam jego położenie geograficzne lub też pozwolić nam na zdalne zablokowanie systemu w telefonie. Chodzi oczywiście o usługę "Znajdź telefon/smartfon" (find my phone), na którą rzucimy sobie okiem w tym artykule. Jak działa usługa "Znajdź telefon/smartfon" Generalnie rzecz ujmując, usługa "Znajdź telefon/smartfon" jest dostępna w praktycznie każdym Androidzie i jest automatycznie włączona. Nie musimy zatem nic dodatkowo instalować czy konfigurować, no chyba, że chcemy tę usługę wyłącz w obawie o naszą prywatność ale do tej kwestii przejdziemy nieco później. Na razie skupmy się na samej usłudze. By usługa "Znajdź telefon/smartfon" była w stanie działać prawidłowo, potrzebne jest powiązanie urządzenia z Androidem, w tym przypadku smartfon, z istniejącym kontem Google. Innymi słowy, trzeba się zalogować na jakieś konto Google na tym urządzeniu. Innym ważnym punktem, który musi być spełniony, jest dostęp telefonu do internetu. Nie ma przy tym znaczenia, czy ten dostęp jest po WiFi czy przez operatora GSM (dane pakietowe). Bez dostępu do internetu, Android nie połączy się z serwerami Google i usługa jest w zasadzie bezużyteczna. Nic więcej nam nie jest potrzebne, no chyba, że chcemy uzyskać położenie geograficzne i zlokalizować smartfon. W takim przypadku telefon musi mieć włączoną nawigację satelitarną (GPS), a ten moduł nie zawsze jest aktywny i dlatego też nie od razu uda nam się taki zgubiony/skradziony telefon odnaleźć na mapie. Idąc dalej, jako, że ta usługa działa w oparciu o przypisanie konta Google do urządzenia z Androidem, to zresetowanie ustawień do fabrycznych w taki sposób by obejść blokadę Factory Reset Protection Lock (FRP Lock), skutecznie uniemożliwia nam przeprowadzenie jakichkolwiek działań ratunkowych. Warto o tym fakcie pamiętać w przypadku, gdy many z jakiegoś powodu odblokowany bootloader lub też posiadamy niezbyt przyzwoicie zabezpieczony smartfon, który umożliwia przepisanie partycji frp w celu obejścia ww. blokady. Jeśli któraś z tych powyższych sytuacji ma miejsce, to biorąc pod uwagę kwestię prywatności, dobrze jest wyłączyć usługę "Znajdź telefon/smartfon". Jak włączyć/wyłączyć usługę "Znajdź telefon/smartfon" Usługę "Znajdź telefon/smartfon" można wyłączyć z poziomu ustawień systemu smartfona. W zasadzie zarówno w wersji 5.1 (Lollipop) jak i 6.0 (Marshmallow) stosowna konfiguracja znajduje się w Ustawienia => Zabezpieczenia => Administratorzy urządzenia: Jak widać na powyższej fotce, w tym przypadku mamy kilka aplikacji, które są w stanie w jakimś stopniu zarządzać naszym telefonem. Jeśli któreś z nich nie powinno tego robić, to naturalnie ze względów bezpieczeństwa lepiej jest je odhaczyć. Domyślnie jest zaptakowana tylko pierwsza pozycja, tj. Menadżer urządzeń Android (nie mylić z aplikacją, która ma dokładnie taką samą nazwę i jest do pobrania ze sklepu Google Play). Każda z tych pozycji po kliknięciu wyświetli nam informacje na temat operacji, które dana aplikacja będzie w stanie przeprowadzić. Poniżej jest rozpisany Menadżer urządzeń Android: No i widzimy, że Menadżer urządzeń Android umożliwia nam na zdalne przeprowadzenie procesu resetowania ustawień smartfona do fabrycznych, tj. Factory Reset. Oferuje on także zablokowanie ekranu i zmianę hasła, tak by niepowołane osoby nie były w stanie korzystać z tego telefonu. Poszukiwania zgubionego/skradzionego smartfona Załóżmy w tym momencie, że nie znamy położenia naszego telefonu oraz, że mamy pewne przypuszczenia, że ktoś nam to urządzenie podprowadził bez naszej świadomej zgody. Co w takiej sytuacji możemy zrobić? Musimy jak najszybciej uzyskać dostęp do zaufanego komputera i zalogować się na konto Google, które jest powiązane z uprowadzonym smartfonem. W zasadzie dla przyśpieszenia procesu, można w wyszukiwarce wpisać frazę "gdzie jest mój telefon" i zostaniemy przez Google odesłani pod właściwy adres usługi: Po wejściu w usługę "Znajdź telefon/smartfon", pojawią nam się urządzenia, które są powiązane z tym kontem Google, i na których była notowana ostatnio jakaś aktywność: Załóżmy, że zawieruszył się ten pierwszy TP-LINK'owy Neffos Y5. Trzeba kliknąć w tą pozycję i podać naturalnie hasło do konta Google. Pamiętajmy, by przy tego typu uwierzytelnianiu sprawdzić czy aby faktycznie jesteśmy na stronach Google i czy strona jest zabezpieczona przez zaufany certyfikat (info w zielonej kłódce obok URL). Po podaniu hasła zostaniemy przeniesieni do listy opcji, które pomogą nam odzyskać telefon: Jak widać, trochę tych opcji mamy. Przyjrzyjmy się im nieco bliżej. Aktywacja dzwonka Gdy mamy podejrzenie, że telefon wciąż jest gdzieś w pobliżu, to naturalnie możemy spróbować go wywołać aktywując w nim dzwonek. W taki sposób nasz telefon zacznie dzwonić z maksymalną siłą, nawet gdy dźwięki w urządzeniu zostały wyciszone. W sumie to ta opcja jest przydatna nie tylko na wypadek kradzieży ale też w momencie, gdy nie wiemy gdzie dokładnie położyliśmy telefon. Lokalizacja położenia geograficznego Zakładając, że nasz telefon ma włączony moduł GPS, Google jest w stanie ustalić położenie naszego smartfona praktycznie natychmiast. Zostanie nam również zwrócona mapka z dokładną lokalizacją zgubionego urządzenia: Problem w tym, że chwilę po zlokalizowaniu urządzenia, na ekranie smartfona zostanie wyświetlony monit o tym, że urządzenie zostało namierzone. Nie wiem kto projektował to zabezpieczenie ale dawać informację potencjalnemu złodziejowi, że "Urządzenie Zlokalizowane" raczej nie ułatwi w odnalezieniu ani smartfona, ani tego kto go sobie przywłaszczył. Można naturalnie ten problem wyeliminować ale trzeba wyłączyć notyfikacje dla aplikacji "Usługi Google Play". Problem w tym, że notyfikacje zostaną wyłączone nie tylko dla Menadżera urządzeń Android ale dla wszystkich usług Google. Nie wiem dlaczego tak ten mechanizm został zaprojektowany ale definitywnie kuleje on pod względem bezpieczeństwa/prywatności i wymaga jak najszybszego dopracowania. Tak czy inaczej jeśli chcemy się pozbyć tych notyfikacji, to w różnych wersjach Androida potrzebne nam opcje siedzą w nieco innych miejscach. W przypadku Androida 6.0 (Marshmallow) można je znaleźć przechodząc w Ustawienia => Menadżer powiadomień. Tam z kolei na liście aplikacji odszukujemy "Usługi Google Play" i wyłączamy w nich powiadomienia: W przypadku, gdy smartfon ma wyłączony moduł GPS, to naturalnie nie da rady go zdalnie włączyć przez usługę "Znajdź telefon/smartfon" i trzeba ewentualnie czekać na błąd złodzieja, np. będzie on próbował skorzystać z mapy czy innej tego typu aplikacji wymagającej do prawidłowego działania modułu GPS. Zablokowanie telefonu Czasami przestępcy są nieco bardziej zaawansowani pod względem intelektualnym i mogą być świadomi faktu, że właściciel telefonu może próbować ich namierzyć przez mechanizmy bezpieczeństwa wbudowane w to urządzenie. Dlatego też mogą oni świadomie unikać włączenia modułu GPS, a my przez to w ogóle możemy nie uzyskać lokalizacji smartfona. Jeśli zaś moduł GPS mieliśmy aktywny, to ci nieznani jeszcze sprawcy mogą podjąć kroki, by ten śledzący dodatek dezaktywować. W takim przypadku jeśli nie mamy ustawionej blokady ekranu w telefonie, to najlepiej jest zdalnie zablokować system telefonu. W zasadzie zablokowaniu ulegnie sam ekran. My zaś możemy dodatkowo dostosować informację, która na tym ekranie zostanie wyświetlona. Nie mamy jednak możliwości zmiany kodu PIN jeśli blokada ekranu jest już aktywna. Zatem jeśli złodziej zna nasz PIN, to mamy problem. W przypadku niekontrolowanej utraty telefonu powinniśmy w zasadzie jak najszybciej założyć blokadę ekranu. Bez niej, złodziej będzie w stanie zresetować ustawienia urządzenia do fabrycznych z poziomu działającego systemu. Taki zabieg nie dość, że praktycznie nam uniemożliwi zlokalizowanie telefonu, bo usługa Google przestanie zwyczajnie działać, to jeszcze nie zostanie nałożona na smartfon blokada Factory Reset Protection Lock. Oczywiście nie musimy z góry zakładać, że telefon wpadł w ręce złodzieja. Być może też jakiś przyzwoity człowiek znalazł nasz smartfon i nie wie on za bardzo co w takiej sytuacji ma zrobić. Jakby nie patrzeć na urządzeniu nie ma żadnej kartki z informacją czyj jest to smartfon. Kartki może i nie ma ale możemy krótką informację na ekranie wyświetlić i jeszcze podać numer telefonu, z którym znalazca zostanie połączony po kliknięciu ikonki słuchawki: Wylogowanie z telefonu Kolejną opcją, która nieco podnosi poziom naszej prywatności i bezpieczeństwa konta Google, to zdalne wylogowanie się z Androida na skradzionym urządzeniu. Oczywiście w dalszym ciągu system będzie traktował nasze konto jako powiązane z tym konkretnym urządzeniem i uniemożliwi zalogowanie się na inne konto. Niemniej jednak, pozostała funkcjonalność telefonu będzie do dyspozycji złodzieja, w tym również możliwość dzwonienia czy włączenia GPS. Taka osoba nie będzie mogła korzystać tylko z tej części systemu, która wymaga zalogowania się na konto. Warto w tym miejscu jednak zaznaczyć, że ten krok z wylogowaniem ochroni jedynie nasze konto Google. Wszystkie prywatne dane, takie jak numery telefonów, treści wiadomości SMS czy zdjęcia/filmy z aparatu już nie zostaną objęte ochroną i złodziej będzie mógł je swobodnie przejrzeć. Niemniej jednak, pozostawienie telefonu funkcjonalnym sprawi, że będzie można go namierzyć przez operatora GSM (ewentualnie GPS), o ile złodziej będzie z niego korzystał. Wypadałoby tylko zablokować kartę SIM (u operatora), tak by nie ponosić opłat z tytułu nadużywania naszej gościnności. Zdziwiłem się tylko, że mając tak zablokowane konto Google, zresetowanie ustawień telefonu do fabrycznych nie nakłada blokady Factory Reset Protection Lock. Dla mnie było oczywistym, że ta blokada powinna się pojawić ale widać ten Góglowski mechanizm blokowania urządzenia nie jest do końca dopracowany. Wykasowanie wszystkich danych Posiadając kopię zapasową danych zgromadzonych w telefonie, w sumie można od razu pokusić się o zdalne przeprowadzenie procesu Factory Reset, co przy okazji założy blokadę Factory Reset Protection Lock (FRP Lock). W ten sposób złodziej nie uzyska dostępu do danych zgromadzonych na flash'u urządzenia i w zasadzie nie będzie w stanie w ogóle korzystać z telefonu. Warto tutaj zaznaczyć, że jeśli w smartfonie podczas tego procesu czyszczenia będzie obecna karta SD, to dane zawarte na tym nośniku również zostaną wykasowane. Problem w tym, że inicjując takie zdalne czyszczenie pozbawiamy się jednocześnie możliwości zlokalizowania telefonu przez usługi Google. Mamy przynajmniej pewność, że nikt nie uzyska dostępu do naszych prywatnych informacji. Coś za coś. Aplikacja Android Device Manager Próby lokalizacji smartfona niekoniecznie muszą być przeprowadzane z poziomu standardowego komputera czy laptopa. Można do tego celu skorzystać z innego smartfona ale trzeba na nim zainstalować aplikację Android Device Manager. Można również korzystać ze standardowej przeglądarki ale ta opcja zostawia za dużo śladów. W przypadku aplikacji Android Device Manager jesteśmy w stanie zlokalizować smartfon w oparciu o dane GPS, zdalnie zablokować telefon, włączyć dzwonek i przeprowadzić proces Factory Reset, czyli mniej więcej te same kroki, które były dostępne w serwisie Google. Po za logowaniu się w aplikacji Android Device Manager, zostanie nam zwrócona lista urządzeń, które są powiązane z kontem Google, do którego dane wprowadziliśmy w formularzu logowania: Wybieramy tutaj urządzenie, które nam zaginęło i przy pomocy kilku tapnięć w ekran smartfona możemy w bardzo prosty sposób wywołać każdą z ww. akcji:
  19. Kupowanie telefonów czy smartfonów z Androidem z innych źródeł niż oficjalne punkty sprzedaży nie zawsze jest bezpieczną opcją. Gdy nabywamy takie urządzenie od znajomego, to raczej nie powinniśmy się martwić o to, że ten telefon może być kradziony. Niemniej jednak, po zakupie takiego urządzenia, poprzedni użytkownik zwykle resetuje jego ustawienia do fabrycznych, by klient miał świeży system i nie był w stanie uzyskać dostępu do prywatnych danych poprzedniego właściciela smartfona. Nie byłoby w tym nic nadzwyczajnego, gdyby nie fakt, że nabywca tak odsprzedanego telefonu może mieć pewne problemy ze skonfigurowaniem Androida, bo ten system zwróci mu komunikat: "Urządzenie zostało zresetowane. Aby kontynuować, zaloguj się na konto Google, które było wcześniej synchronizowane na tym urządzeniu", czyli telefon został zablokowany przez mechanizm Factory Reset Protection Lock (FRP Lock). Jeśli znajomy mieszka blisko nas, to naturalnie możemy się przejść do niego w celu zdjęcia tej blokady. A co w przypadku, gdy nabyliśmy urządzenie na odległość? Czy jest jakiś sposób na obejście tej blokady w przypadku smartfonów Neffos od TP-LINK? Factory Reset Protection Lock (FRP Lock) Urządzenia takie jak smartfony zwykle zabezpieczone są jakąś formą blokady ekranu, np.kodem PIN. By skorzystać z takiego telefonu trzeba ten kod pierw wprowadzić. Problem pojawia się w momencie, gdy tego kodu z jakiegoś powodu nie znamy. W przypadku, gdy jedynie zapomnieliśmy prawidłowej sekwencji odblokowującej ekran, to nic nie stoi na przeszkodzie, by taki telefon zresetować do ustawień fabrycznych przez tryb recovery. Stracimy co prawda wszystkie dane przechowywane na flash'u urządzenia ale będziemy w stanie sobie na nowo skonfigurować system. Niemniej jednak, tego typu sytuacja zwykle nie ma miejsca, natomiast dużo częściej zdarzają się kradzieże telefonów. Taki złodziej również byłby w stanie zresetować ustawienia telefonu do domyślnych w celu jego późniejszej sprzedaży gdzieś na targu. By utrudnić ten proceder, w Androidach począwszy od wersji 5.0 (Lollipop) został wprowadzony mechanizm Factory Reset Protection Lock (FRP Lock). Mając taki system, po zresetowaniu smartfona do ustawień fabrycznych przez tryb recovery, urządzenie w dalszym ciągu będzie zablokowane. Użytkownikowi podczas konfiguracji telefonu zostanie pokazany jedynie komunikat "Urządzenie zostało zresetowane...". By móc korzystać z takiego telefonu, trzeba podać dane do poprzedniego konta i innej opcji zwykle nie ma. Po aktywowaniu blokady FRP Lock, Android jest zwykle bezużyteczny. Możemy jedynie odbierać połączenia przychodzące i wykonywać połączenia alarmowe ale w zasadzie nic poza tym. Nie mamy dostępu do ustawień telefonu czy przeglądarki internetowej i z lwiej części funkcjonalności telefonu nie będziemy mogli skorzystać do momentu podania danych do konta, które było skonfigurowane na tym telefonie przed zakupem. W przypadku zakupu telefonu na odległość, raczej jest mało prawdopodobne, że poprzedni właściciel poda nam dane do swojego konta Google byśmy sami mogli ten telefon odblokować. Jakie inne opcje nam zatem pozostają? Zasada działania FRP Lock Szukając informacji na temat zasady działania tego całego FRP Lock, na jednym z forów Androida użytkownik piskorfa podesłał mi linki do dwóch chińskich blogów [1] i [2]. Chińskiego co prawda nie znam ale zawartość tych stron można przetłumaczyć na angielski w Google Translate. Zgodnie z informacjami zawartymi w tych powyższych artykułach, mechanizm FRP Lock działa w oparciu o dedykowaną partycję na flash'u telefonu. Nazwa tej partycji może być różna, choć zwykle przyjmuje wartość frp (od Factory Reset Protection). W smartfonach Neffos C5 i C5 MAX ta partycja figuruje na liście partycji. Nie ma jej jednak w przypadku modelów Neffos Y5 i Y5L ale to nic nie szkodzi. Nazwę tej partycji zawsze można ustalić przeglądając, np. za pomocą adb , plik /system/build.prop w telefonie: shell@C5_Max:/ $ cat /system/build.prop | grep -i frp ro.frp.pst=/dev/block/platform/mtk-msdc.0/by-name/frp shell@Y5:/ $ cat /system/build.prop | grep -i frp ro.frp.pst=/dev/block/bootdevice/by-name/config Widać, zatem że w tym drugim przypadku partycja, której szukamy, nazywa się config . Blokada FRP Lock jest zakładana na telefon w momencie powiązania z nim konta Google, tj. uzupełnienia formularza w celu zalogowania się, np. do sklepu Google Play. Blokadę tę można dezaktywować usuwając konto z telefonu lub też resetując smartfon do ustawień fabrycznych z poziomu działającego systemu. Zatem dodając lub usuwając konto Google, Android inicjuje pewną operację na partycji, która została zwrócona w ro.frp.pst . Jeśli teraz zresetujemy telefon do ustawień fabrycznych z poziomu trybu recovery, to system urządzenia nie przepisze nam tej partycji w żaden sposób, bo Android w trym trybie nie jest uruchomiony. Później jak przechodzimy przez proces wstępnej konfiguracji telefonu, system odczytuje dane z partycji frp i na ich podstawie decyduje czy przepuścić użytkownika, czy zablokować dostęp i zażądać uwierzytelnienia przez podanie danych do konta, które wcześniej było na tym telefonie skonfigurowane. W jaki sposób system rozpoznaje czy podaliśmy dane do odpowiedniego konta? Serwery Google w tym procesie nie biorą udziału. Te dane są zapisywane również na partycji frp , z tym, że raczej w formie jakieś hasha, który można uzyskać podając konkretny login i hasło. Podając prawidłowe dane, system jest w stanie wygenerować taki hash i porównać go z tym co zostało zapisane na partycji frp . Pewności do końca nie mam jak ten proces weryfikacji przebiega ale patrząc na zrzuty partycji w edytorze HEX, można dojść do wniosku, że system dodaje jakieś informacje na tej partycji po zalogowaniu się na konto Google. Jest to około 20 KiB, zatem dość sporo. Te dane jednak są w formie nieczytelnej dla człowieka, także nic więcej na ten temat nie powiem. Wiedząc, że partycja frp odgrywa kluczową rolę w zablokowaniu użytkownikowi dostępu do telefonu, można by się pokusić o ręczne wyczyszczenie tej partycji. Jeśli faktycznie serwery Google nie biorą udziału w tym całym procesie, to FRP Lock można by obejść lokalnie. Jak odblokować smartfon z aktywowanym FRP Lock Załóżmy, że zakupiliśmy sobie używanego smartfona na odległość oraz, że to urządzenie nie było kradzione. Naturalnie telefon nie został poprawnie zresetowany do ustawień domyślnych i my jako nowy właściciel mamy teraz problem, bo Android wyrzuca nam informacje o założeniu blokady FRP Lock. W zasadzie wiemy co mamy robić, tj. trzeba wyczyścić partycję frp . Problem w tym, że w różnych modelach smartfonów inaczej do tego przedsięwzięcia trzeba się zabrać. Kluczowe znaczenie ma zainstalowany w urządzeniu SoC, wersja Androida oraz ewentualne zabezpieczenia wprowadzone przez producenta telefonu. W przypadku smartfonów Neffos C5 i C5 MAX mamy do czynienia z SoC od MediaTek, model nie jest aż tak ważny. Android jest zaś w wersji 5.1 (Lollipop). Natomiast Neffos Y5 i Y5L mają SoC od Qualcomm i w tych telefonach siedzi Android w wersji 6.0 . Mamy zatem dwie różne sytuacje do rozważenia. Odblokowanie Neffos C5 i C5 MAX Jako, że te dwa modele smartfonów mają SoC od MediaTek, to nadpisanie partycji frp w ich przypadku jest stosunkowo proste, bo możemy do tego celu zaprzęgnąć SP Flash Tool. Problematyczne może być ustalenie gdzie na flash'u smartfona znajduje się partycja frp . Ja korzystałem ze swojego pliku scatter.txt: mt6753-neffos-c5-max-tp-link-scatter.txt, gdzie mam taki oto blok kodu: - partition_index: SYS18 partition_name: frp file_name: NONE is_download: true type: NORMAL_ROM linear_start_addr: 0x6a00000 physical_start_addr: 0x6a00000 partition_size: 0x100000 region: EMMC_USER storage: HW_STORAGE_EMMC boundary_check: true is_reserved: false operation_type: UPDATE reserve: 0x00 W zasadzie to, interesuje nas tutaj wartość 0x100000 , która wskazuje nam rozmiar partycji i jest to 1048576 bajtów, czyli 1 MiB. Trzeba zatem stworzyć plik wypełniony samymi zerami, który będzie miał dokładnie taki rozmiar. Możemy to zrobić przy pomocy dd z poziomu każdego linux'a: # dd if=/dev/zero of=./c5max-frp.orig bs=1K count=1024 Tak wygenerowany plik trzeba przy po mocy SP Flash Tool wgrać w odpowiednie miejsce na flash'u smartfona. Odpalamy zatem narzędzie SP Flash Tool i przechodzimy na zakładkę Download i tam zaznaczamy partycję frp i wskazujemy ścieżkę do pliku z zerami: Upewniamy się, że nad listingiem partycji mamy zaznaczone Download Only i wciskamy przycisk Download . W tym momencie SP Flash Tool będzie oczekiwał na podłączenie smartfona do portu USB komputera. Wyłączamy zatem telefon i podłączamy go do komputera. System powinien go automatycznie wykryć i zaaplikować mu wskazany plik: Jeśli są jakieś problemy z działaniem SP Flash Tool, to prawdopodobnie nie ma on uprawnień do urządzenia /dev/ttyACM0 i trzeba będzie dodać naszego użytkownika do grupy dialout . Po wgraniu pliku, włączamy smartfon i już nie powinniśmy mieć problemów z dodaniem nowego konta Google na naszym smartfonie. Odblokowanie Neffos Y5 i Y5L W przypadku smartfonów Neffos Y5 i Y5L sprawa nie wygląda tak różowo. Nie tylko nie mamy możliwości skorzystania z SP Flash Tool, bo SoC jest od Qualcomm'a, to jeszcze wygląda na to, że blokada OEM (ta w opcjach developerskich) działa i uniemożliwia odblokowanie bootloader'a. Bez odblokowanego bootloader'a z kolei nie damy rady wgrać obrazu przy pomocy narzędzia fastboot . Próbowałem obejść blokadę FRP Lock w tych telefonach na kilka różnych sposobów ale żadne ze znalezionych przeze mnie rozwiązań nie dało rady sprostać zabezpieczeniom, które w tych Neffos'ach zostały zaimplementowane. W Neffos Y5 i Y5L mamy praktycznie gołego Androida 6.0 i jedyne co możemy próbować zrobić, to uzyskać dostęp do ustawień telefonu w celu przeprowadzenia procesu Factory Reset z poziomu działającego systemu. Przynajmniej tak wynika z tych materiałów, z którymi się zdążyłem zapoznałem. Pytanie jest tylko jak wywołać ustawienia, skoro mamy zablokowaną możliwość operowania na smartfonie i jedyny obrazek jaki widzimy, to ten poniżej: Sposób z przeglądarką Może i na pierwszy rzut oka nic nie da się zrobić i FRP Lock spełnia swoje zadanie ale nawet w tym miejscu jesteśmy w stanie wywołać przeglądarkę internetową, która pozwoli nam uzyskać dostęp do ustawień systemu. W jaki sposób? Wyżej widzimy formularz, w którym mamy wpisać adres email lub numer telefonu. Generalnie nie wpisujemy tutaj tego, o co nas proszą. Zamiast tego wpisujemy dosłownie cokolwiek. Na ten wpisany w formularzu wyraz możemy kliknąć i pojawi nam się proste menu: Z tego menu wybieramy pozycję Podpowiedzi (przez te trzy kropki): I jak widzimy, odpaliła nam się przeglądarka Chrome. Nie logujemy się tutaj i wciskamy "Nie Dzięki". Na środku ekranu mamy standardowy formularz wyszukiwania, jak w każdej wyszukiwarce. W tym formularzu wpisujemy w zależności od wykorzystywanego języka w telefonie: ustawienia (PL) lub settings (EN). Jak tylko zaczniemy wpisywać kolejne znaki w polu formularza, na dole ekranu powinny nam się pojawić podpowiedzi: Mamy pozycję Ustawienia i naturalnie klikamy w nią. Powinien nam się ukazać znajomy widok ustawień systemowych. Zatem nawet mając aktywny mechanizm blokady telefonu, jesteśmy w stanie go ominąć i wejść w ustawienia telefonu. W tak uzyskanym menu przechodzi do pozycji Kopia zapasowa i reset , a z niej wybieramy Przywróć ustawienia Fabryczne : W ten sposób niby powinniśmy pozbyć się blokady, bo proces Factory Reset zostanie przeprowadzony z poziomu działającego systemu. Niestety najwyraźniej w nowszych wersjach Androida partycja frp nie jest przepisywana jeśli Factory Reset jest przeprowadzany z poziomu systemu, na którym nie ma skonfigurowanego konta Google. Zatem może i zresetujemy ustawienia ale w dalszym ciągu system przy konfiguracji telefonu będzie nas prosił o podanie danych do starego konta Google. Sposób ze zdjęciem blokady OEM Kluczem do zdjęcia blokady FRP Lock jest odblokowanie bootloader'a, a to można zrobić zdejmując pierw blokadę OEM z poziomu opcji developerskich. Mając dostęp do opcji telefonu, możemy wejść w "Informacje o telefonie" i spróbować postukać w numer kompilacji. Problem w tym, że ten sposób również nie działa i w tym przypadku stukanie w numerek kompilacji nic nie daje, a bez tego nie pojawią nam się opcje developerskie i nie ściągniemy blokady OEM. Sposób z wyłączeniem WiFi Innym sposobem, który znalazłem, miało być ogłupienie systemu przez rozłączenie sieci WiFi w odpowiednim momencie. Gdy jesteśmy na pozycji "Wybierz WLAN" przy konfiguracji telefonu, to naturalnie wskazujemy naszą sieć i uzupełniamy dane logowania do tej sieci. Później wracamy przyciskiem Wstecz do ekranu wyboru sieci. Powinniśmy widzieć listę sieci WiFi w naszej lokalizacji oraz powinniśmy być podłączeni do tej, którą sobie skonfigurowaliśmy: W tym miejscu dajemy "Dalej" i gdy na ekranie pojawi się informacja "Sprawdzam połączenie" ale przed "Aktualizuję oprogramowanie" (szybko przeskakuje) trzeba sieć WiFi rozłączyć. Można albo wyłączyć router WiFi przyciskiem, albo też w ustawieniach routera wyłączyć samo WiFi. Warto tutaj zaznaczyć, że w telefonie nie może być obecna karta SIM, bo wtedy dane mogą być wymieniane po 3G/LTE. W takim przypadku, smartfon nie będzie w stanie połączyć się z serwerami Google po uprzednim zapewnieniu, że połączenie działa. Taki stan rzeczy najprawdopodobniej sprawia, że system głupieje i pomija proces uwierzytelniania zwracając informację "Nie można się zalogować" i proces konfiguracji telefonu może być kontynuowany: Naturalnie klikamy Dalej i Dalej i w zasadzie wszystko wskazuje na to, że proces zostanie ukończony z powodzeniem. Niemniej jednak, z jakiegoś powodu system stwierdza, że nie jesteśmy zalogowani i każe nam cały proces powtórzyć. Sposób z linkami w opcjach języka i klawiatury Kolejnym sposobem, który może nam pomóc z ominięciem blokady FRP Lock, jest próba wywołania ustawień systemowych za pomocą linków, do których mamy dostęp z menu różnych aplikacji systemowych. W procesie wstępnej konfiguracji telefonu mamy dostęp do jednej takiej aplikacji, tj. ustawienia języka i klawiatury (czy jak to się tam nazywa). W opcje tej aplikacji można wejść przyciskając przez dłuższą chwilę znak @ na klawiaturze ekranowej. W ten sposób powinno nam się pojawić małe kółko zębate oferujące "Opcje wprowadzania": Po wejściu w te opcje, w prawym górnym rogu mamy trzy kropki z menu pomocy, które powinniśmy wywołać w celu uzyskania dostępu do upragnionego linku, za pomocą którego można by wywołać przeglądarkę i za jej pomocą wejść w główne ustawienia telefonu: Problem w tym, że żadna z tych opcji się nie da wcisnąć, czyli kolejna ślepa uliczka. Znacie jeszcze jakieś ciekawe pomysły na obejście tej blokady? Jak uniknąć zablokowania smartfona Wygląda na to, że w przypadku Neffos C5 i C5 MAX zabezpieczenie FRP Lock jest praktycznie bezużyteczne. Oczywiście w dalszym ciągu zdjęcie tej blokady dla przeciętnego Kowalskiego może być zbyt trudne ale jak widać jest ono możliwe. Natomiast póki co nie mam pojęcia jak obejść tę blokadę w Neffos Y5 i Y5L i w przypadku tych telefonów raczej nie chcielibyśmy tego FRP Lock'a złapać. Dlatego też zawsze przed odsprzedaniem komuś telefonu miejmy na uwadze to zabezpieczenie i manualnie usuwajmy konto Google z systemu. Nie zaszkodzi też usunięcie blokady ekranu przed zresetowaniem smartfona do ustawień fabrycznych. Jeśli zaś kupujemy telefon od kogoś, to poprośmy tę osobę o wykonanie procesu Factory Reset z poziomu trybu recovery, tak by ta czynność została wykonana przy nas. Po czym sprawdźmy czy w procesie wstępnej konfiguracji telefonu nie złapiemy FRP Lock'a.
  20. Zainspirowany wątkiem na forum JDtech na temat testów transferów w konkretnych pasmach/częstotliwościach LTE, postanowiłem sprawdzić jak ta sprawa wygląda w mojej okolicy. Generalnie ja obecnie u siebie mam modem Huawei E3372s-153 w wersji NON-HiLink podpięty do routera TP-LINK Archer C2600. Oczywiście na tym routerze jest wgrany alternatywny firmware LEDE/OpenWRT, bo inaczej nie miałbym możliwości skorzystać z tego modemu. Standardowa konfiguracja LTE w LEDE/OpenWRT daje nam jedynie możliwość wyboru między ustawieniami auto , gsm , umts , lte , preferumts oraz preferlte . W przypadku internetu LTE, zwykle wybieramy tutaj tryb auto , ewentualnie też lte , by wymusić konkretny tryb pracy modemu, co może mieć kolosalne znaczenie przy darmowym internecie od RBM/Play. Niemniej jednak, nawet w przypadku wyboru lte , częstotliwość na jakiej będzie pracował modem w dalszym ciągu jest dobierana automatycznie w oparciu o parametry sygnału docierającego z dostępnych w okolicy BTS'ów. W przypadku modemu E3372 można jednak wymusić, by połączenie LTE było realizowane na konkretnej częstotliwości, np. 2100/1800/2600/900/800 MHz i by taki stan rzeczy osiągnąć, trzeba nieco przerobić konfigurację tego alternatywnego oprogramowania znajdującego się w naszym routerze WiFi. Dostosowanie konfiguracji LEDE/OpenWRT na potrzeby LTE Przede wszystkim, by móc operować na modemie LTE z poziomu routera WiFi z wgranym firmware LEDE/OpenWRT, musimy pierw zainstalować stosowne oprogramowanie. Nie będę tutaj opisywał tego zagadnienia, bo to zostało zrobione już w osobnym wątku. Zakładam też, że nasz modem LTE działa bez większego problemu na routerze i nie mamy problemów ze zmuszeniem go do pracy. Nas tutaj bardziej interesować będzie konfiguracja modemu, a konkretnie plik /etc/gcom/ncm.json . To w tym pliku jest zawarta instrukcja, tj. poszczególne polecenia, które są przesyłane do modemu w celu jego konfiguracji. Jako, że my tutaj dysponujemy modemem LTE od Huawei, to interesuje nas sekcja "huawei": { } . Tam z kolei mamy podsekcję "modes": { } i tutaj właśnie są zlokalizowane konfiguracje trybów pracy modemu. Standardowo mamy tutaj te poniższe wpisy: "modes": { "preferlte": "AT^SYSCFGEX=\\\"030201\\\",3fffffff,2,4,7fffffffffffffff,,", "preferumts": "AT^SYSCFGEX=\\\"0201\\\",3fffffff,2,4,7fffffffffffffff,,", "lte": "AT^SYSCFGEX=\\\"03\\\",3fffffff,2,4,7fffffffffffffff,,", "umts": "AT^SYSCFGEX=\\\"02\\\",3fffffff,2,4,7fffffffffffffff,,", "gsm": "AT^SYSCFGEX=\\\"01\\\",3fffffff,2,4,7fffffffffffffff,,", "auto": "AT^SYSCFGEX=\\\"00\\\",3fffffff,2,4,7fffffffffffffff,," }, Mając dostępne tylko te powyższe tryby, nie da rady wymusić konkretnego pasma LTE, bo każdy z tych trybów ma 7fffffffffffffff , co odpowiada za obsługę wszystkich pasm. Możemy jednak zmienić tę wartość na taką, którą odpowiada za konkretną częstotliwość. Najprościej jest po prostu dodać kilka dodatkowych wpisów i odpowiednio przerobić 7fffffffffffffff , poniżej przykład: "lte-fdd-2100": "AT^SYSCFGEX=\\\"03\\\",3fffffff,2,1,1,,", "lte-fdd-1800": "AT^SYSCFGEX=\\\"03\\\",3fffffff,2,4,4,,", "lte-fdd-2600": "AT^SYSCFGEX=\\\"03\\\",3fffffff,2,4,40,,", "lte-fdd-900": "AT^SYSCFGEX=\\\"03\\\",3fffffff,2,4,80,,", "lte-fdd-800": "AT^SYSCFGEX=\\\"03\\\",3fffffff,2,4,80000,," Pierwsza wartość liczbowa w komendzie AT, czyli 03 , wymusza LTE, zatem modem ma pracować tylko w tym trybie. Ostatnia wartość liczbowa, tj. 1 , 4 , 40 , 80 oraz 80000 , odpowiada kolejno pasmom B1 (2100 MHz), B3 (1800 MHz), B7 (2600 MHz), B8 (900 MHz) i B20 (800 MHz) w technologi FDD. Każdy taki wpis, za wyjątkiem ostatniego, ma być zakończony przecinkiem ( , ). Jakie pasma/częstotliwości LTE są dostępne w mojej okolicy Dostosowanie konfiguracji dla modemu LTE to jedna rzecz ale trzeba także zrobić lekkie rozeznanie na temat tego jakie częstotliwości LTE są dostępne w okolicy naszego miejsca zamieszkania/przebywania. Tutaj nie ma prostej metody, by takie informacje zdobyć. Niby można posłużyć się serwisami w stylu BTSEARCH ale zawarte w nich dane dotyczące konkretnych stacji bazowych czasami są błędne lub też w ogóle ich tam nie znajdziemy. Możemy jednak przełączyć modem w każdy ze zdefiniowanych wyżej trybów i sprawdzić czy uda się uzyskać połączenie w pasmach obsługiwanych przez modem. Edytujemy zatem plik /etc/config/network na routerze. Interesuje nas sekcja konfigurująca interfejs sieciowy przypisany modemowi LTE: config interface 'lte' ... option mode 'lte-fdd-2600' ... Teraz już wystarczy tylko dostosować opcję mode wpisując nazwy zdefiniowane w pliku /etc/gcom/ncm.json oraz przeprowadzić szereg pomiarów prędkości łącza internetowego, np. w serwisie speedtest. Ja dla wygody testy robiłem z poziomu aplikacji na smartfona. Uzyskałem wyniki dla 2100 MHz, 1800 MHz, 2600 MHz i 800 MHz. Niestety na 900 MHz modem nie był w stanie zrealizować połączenia. Widać zatem, że największą prędkość udało się uzyskać w paśmie 2600 MHz i w zasadzie można tę częstotliwość wymusić. Niemniej jednak, jeśli zmieniamy dość często miejsce pobytu, to lepiej jest pozostać przy automatycznym doborze częstotliwości, bo nie zawsze będziemy w zasięgu, np. tego pasma 2600 MHz.
  21. W artykułach dotyczących przeprowadzania procesu root na smartfonach Neffos Y5 oraz Y5L był pokazany sposób na dokonanie backup'u całego flash'a tych urządzeń. Jeśli Android w naszym telefonie jest ukorzeniony albo chociaż mamy wgrany obraz TWRP na partycję /recovery/ , to jesteśmy w stanie przeprowadzać regularny backup wszystkich danych użytkownika z poziomu trybu recovery. Proces takiego backup'u będzie się nieco różnił w stosunku do tego opisywanego w wyżej podlinkowanych artykułach. W tym przypadku nie będziemy robić kopii binarnej, a jedynie zgramy sobie wszystkie pliki znajdujące się na partycji /data/ . W tym artykule zostanie pokazany sposób na przeprowadzanie procesu kopii zapasowej w smartfonie Neffos Y5. Niemniej jednak, taki regularny backup można przeprowadzać praktycznie w każdym smartfonie posiadającym recovery z TWRP. Kopia binarna czy kopia plików Dysponując obrazem z recovery TWRP w zasadzie jesteśmy w stanie przeprowadzić dwa rodzaje kopii zapasowych: kopia binarna i kopia zwykłych plików. Nas średnio interesuje kopia binarna, a to ze względu na fakt zgrywania z partycji /data/ każdego pojedynczego bita danych. Partycja /data/ jest największą partycją w naszych telefonach i zwykle ma ona rozmiar 10-12 GiB (przy rozmiarze flash'a 16 GiB). W tych bardziej wypasionych smartfonach, ta partycja może mieć sporo większy rozmiar. Jeśli teraz byśmy stworzyli kopię binarną takiej partycji, to system zrzuci nam wszystkie dane na niej zawarte wliczając w to wolne miejsce. W efekcie możemy mieć na tej partycji zajętych 2 GiB, a i tak zostanie utworzony plik o rozmiarze tych 12 GiB. Marnujemy zatem sporo miejsca, bo przecież taki backup trzeba gdzieś przechowywać. W przypadku kopii zapasowej plików, system zgrywa poszczególne pliki z partycji /data/ i robi z nich skompresowane archiwum, coś jak paczka .zip . W porównaniu do kopii binarnej, takie spakowane archiwum plików zajmuje parokrotnie mniej miejsca, no i oczywiście sam proces backup'u (i późniejszego kopiowania danych z telefonu na komputer) trwać będzie o wiele krócej. Odblokowany bootloader Technicznie rzecz biorąc, tryby recovery w smartfonach z Androidem mają różne opcje. Niektóre z nich oferują możliwość zrobienia backup'u partycji /data/ , a inne takiej funkcji nie posiadają. Jeśli stock'owy obraz partycji /recovery/ nie daje nam możliwości przeprowadzenia procesu kopii zapasowej, to nie pozostaje nam nic innego jak sięgnięcie po obraz recovery z TWRP. Problem z tym obrazem jest jednak taki, że musimy go albo wgrać na partycję /recovery/ , albo tez odpalić go w pamięci telefonu, tak by nie wprowadzać żadnych zmian na flash'u urządzenia. Rzecz w tym, by móc tego typu zabieg przeprowadzić, trzeba odblokować bootloader, a to, jak zapewne wiemy, inicjuje proces Factory Reset i czyści wszystkie dane użytkownika zgromadzone na partycji /data/ . Mając na uwadze ten fakt, kopia zapasowa plików użytkownika przez tryb recovery z TWRP dotyczy tylko i wyłącznie telefonów z odblokowanym bootloader'em. Zakładam w tym miejscu, że mamy już odblokowany bootloader w naszym smartfonie. Kopia zapasowa z poziomu aplikacji Inny problem, jaki może mieć dla nas znaczenie przy kopii zapasowej przez tryb recovery, to potrzeba chwilowego wyłączenia telefonu. Ten sposób nie jest zatem optymalny dla użytkowników, którzy muszą być ciągle online i nie mogą na te kilkanaście minut rozłączyć się ze światem. Jest za to kilka programików, które umożliwiają zrobienie tego typu backup'u z poziomu działającego telefonu. Ja jednak nigdy nie testowałem tego oprogramowania i za bardzo nie mogę nic na jego temat powiedzieć. Zwykle też oferowane za sprawą takich programików rozwiązania są płatne. Z kolei zaś obrazy TWRP, które możemy wgrać na swój telefon, mamy za free. Uruchamianie smartfona w trybie recovery Zwykle jak korzystamy z telefonu przez dłuższy czas, to jest wielce prawdopodobne, że sporo rzeczy zmieniliśmy w konfiguracji takiego urządzenia. Mamy zapewne też wgranych szereg niestandardowych aplikacji, których ustawienia również zostały przez nas dostosowane do naszych potrzeb. O ile pliki graficzne, dźwiękowe czy też video można sobie bez problemu zgrać na komputer, o tyle właśnie tych ustawień telefonu za bardzo nie mamy jak sobie skopiować. Wejdźmy zatem w tryb recovery naszego telefonu. W przypadku, gdy obraz TWRP jest wgrany na flash smartfona, to wyłączamy urządzenie i przyciskamy jednocześnie przyciski VolumeUp + Power. Jeśli zaś chcemy uruchomić TWRP w pamięci RAM telefonu, to musimy uruchomić to urządzenie w trybie bootloader'a i zaaplikować obraz z partycją /recovery/ za pomocą narzędzia fastboot . Instalacja i konfiguracja fastboot pod linux jest opisana w osobnym wątku. Niezależnie od wybranego sposobu, naszym oczom powinno ukazać się menu TWRP podobne do tego poniżej (w opcjach można wybrać język polski): Jak widać na obrazku, mamy dwie pozycje: Kopia i Przywróć. Jeśli zamierzamy dokonać backup'u, to naturalnie przechodzimy do pozycji Kopia. Jeśli zaś zamierzamy uprzednio utworzoną kopię zapasową odtworzyć, to przechodzimy do Przywróć . Tworzenie kopii zapasowej partycji /data/ przez TWRP Po przejściu do pozycji Kopia zostaną nam zaprezentowane opcje wyboru poszczególnych partycji, których kopie zamierzamy przeprowadzić. To jakie partycje znajdziemy w tym okienku zależy głównie od pliku fstab , który znalazł się w obrazie TWRP. Niektóre są bardziej rozbudowane, a inne ograniczają się jedynie do podstawowych wpisów. W każdym razie, partycja /data/ powinna być widoczna na liście: W tym przypadku na liście mamy dwie pozycje z nazwą Data . Ta zaznaczona pozycja odpowiada za zrobienie backup'u samych plików na partycji /data/ . Ta druga opcja umożliwia naturalnie zrobienie kopii binarnej ale nie będziemy z niej korzystać. Niemniej jednak, warto zauważyć różnice w ilości kopiowanych danych. Same pliki w tym przypadku mają nieco ponad 100 MiB, podczas gdy cała partycja ma ponad 12 GiB. Różnica jest ogromna. Po zaznaczeniu odpowiedniej pozycji upewniamy się jeszcze, że wybraliśmy stosowną pamięć do zapisu pliku kopii zapasowej, tj. Kartę SD. Jako, że tutaj nie ma dużo danych do zapisu, to można wykorzystać nawet małe karty SD, które mają rozmiar 1-2 GiB. Obraz partycji na taką małą kartę SD by nam się nie zmieścił, a same dane wejdą bez większego problemu. Warto tutaj jeszcze dodać, że w przypadku, gdy rozmiar danych na partycji /data/ jest duży, to plik backup'u zostanie podzielony automatycznie na mniejsze kawałki (~1,5 GiB). Nie ma zatem obawy o zapis takich plików na kartę SD sformatowaną system plików z rodziny FAT. Obraz całej partycji /data/ , jako, że przekracza on limit 4 GIB, trzeba by umieścić na karcie SD sformatowanej innym systemem plików, np. linux'owym EXT4. By zrobić backup, przesuwamy strzałki na prawą stronę: Po zakończeniu całego procesu, na karcie SD zostaną utworzone następujące pliki: data.ext4.win (archiwum TAR), data.ext4.win.md5 (zawiera sumę kontrolną archiwum), recovery.log (zawiera log z backup'u) oraz data.info (zawiera info na temat rozmiaru, typu i liczby plików archiwum). Lepiej nie kasować żadnego z tych plików, bo inaczej TWRP będzie miało prawdopodobnie problemy z odtworzeniem backup'u. Odtwarzanie kopii zapasowej partycji /data/ przez TWRP Kopię zapasową partycji /data/ można również odtworzyć. Nie zaleca się jednak wgrywania takiego backup'u w momencie, gdy był on sporządzany na innej wersji Androida. Dla przykładu załóżmy, że stworzyliśmy sobie kopię na Androidzie 5.1 Lollipop, zaktualizowaliśmy system do nowszej wersji i chcemy tę kopię odtworzyć na Androidzie 6.0 Marshmallow. Ja generalnie nie robiłbym tego, a to z tego względu, że różnice między tymi systemami są znaczne. Tak odtworzona kopia mogłaby uszkodzić system, w sensie takim, że nie uruchomiłby nam się on ponownie i trzeba by przeprowadzić proces Factory Reset. Odtworzenie kopii zapasowej w każdym innym przypadku, tj. na tym samym urządzeniu po uprzednim przywróceniu jego ustawień do fabrycznych, czy też na innych smartfonach mających tę samą wersję Androida, nie powinno raczej nam zaszkodzić. Choć w przypadku wgrywania backup'u na inne telefony również bym uważał. Zakładając jednak, że coś namieszaliśmy w systemie naszego smartfona i wiemy, że nie obędzie się bez przywracania go do ustawień fabrycznych, możemy naturalnie po zainicjowaniu Factory Reset wgrać uprzednio zrobiony backup również przez tryb recovery. Będąc w trybie recovery, w głównym menu TWRP wybieramy pozycję Przywróć . Tam z kolei mamy listę plików kopii zapasowych, które możemy przywrócić. Po kliknięciu na interesującą nas pozycję zostanie nam zwrócona informacja na temat danych, które w takim pliku się znajdują, tj. partycji, które zostały w tej kopii zawarte. W tym przypadku mamy dane z partycji /data/ : Na dole mamy również opcję Włącz weryfikację MD5 kopii zapasowych . Tę opcję można naturalnie zaznaczyć ale trzeba mieć na uwadze, że proces odtwarzania backup'u będzie trwał dłużej, zwłaszcza w przypadku, gdy danych w kopii jest dość sporo. Po zaznaczeniu stosownych opcji, przeciągamy strzałki na prawą stronę: Jak widać z komunikatów na fotce, nie ma potrzeby przeprowadzania wcześniej procesu Factory Reset, bo partycja przed wgraniem na nią backup'u jest automatycznie czyszczona. Problem z odblokowaniem ekranu po odtworzeniu backup'u Wiele osób ma zabezpieczony dostęp do telefon za pomocą kodu PIN. W takich przypadkach, by móc używać tego urządzenia w innych celach niż połączenia alarmowe trzeba podać cztery cyferki. Jeśli tego nie zrobimy, nie damy rady zdjąć blokady ekranu i nie dostaniemy się do systemu. Jeśli kopia partycji /data/ była przeprowadzana na telefonie, który miał włączoną blokadę ekranu, to w pewnych sytuacjach po odpaleniu systemu nie damy rady ściągnąć tej blokady nawet podając poprawny PIN: Problem naturalnie można poprawić ale trzeba odpalić telefon ponownie w trybie recovery. Tam z menu TWRP przechodzimy do Zaawansowane => Menadżer Plików: W menadżerze plików przechodzimy do katalogu /data/system/ , z którego to musimy skasować kilka plików. Kasujemy wszystko to co ma w nazwie .key oraz locksettings. : W tym przypadku skasowanych zostało 5 plików: gatekeeper.password.key , gatekeeper.pattern.key , locksettings.db , locksettings.db-shm oraz locksettings.db-wal . Po ich usunięciu restartujemy telefon i już powinniśmy być w stanie zalogować się w systemie. Jedyna różnica jest taka, że teraz nie byliśmy pytani o PIN, bo usunęliśmy wcześniej zarówno klucze jak ustawienia blokady. W przypadku, gdy blokada ekranu jest dla nas dość ważna, to naturalnie możemy ją ustawić sobie ponownie w tradycyjny sposób. Jak tylko blokada zostanie włączona, to system wygeneruje nowe klucze i nimi zabezpieczy nasz telefon. Pamiętajmy jednak, że mając TWRP na partycji /recovery/ , czy w ogóle odblokowany bootloader, to te klucze/ustawienia możemy usuwać bez problemu i w ten sposób obchodzić mechanizm blokady ekranu w telefonach z Androidem. Warto mieć zatem świadomość, że blokada ekranu w takich urządzeniach nie chroni nas zupełnie przed niczym. Oczywiście można nieco minimalizować zagrożenie przez wgrywanie TWRP tylko do pamięci telefonu, a na partycji /recovery/ trzymać stock'owy soft, choć i tak lepiej jest nie zostawić telefonu bez nadzoru na dłuższy czas.
  22. Przeprowadzenie procesu root na smartfonie Neffos Y5L od TP-LINK nie było tak łatwe jak w przypadku innych modeli telefonów tego producenta. Niemniej jednak, trzeba zdawać sobie sprawę, że ukorzenianie Androida niesie za sobą pewne zagrożenia. Nie chodzi tutaj tylko o niezaufane aplikacje ale też trzeba brać pod uwagę możliwość przypadkowego (przypadki nie istnieją) skasowania czy zmienienia plików systemowych, przez co nasz telefon może przestać nam działać poprawnie lub też przestanie się w ogóle uruchamiać. Jeśli natomiast wgraliśmy SuperSU i praktycznie w ogóle z niego nie korzystamy, to moim zdaniem lepiej jest przeprowadzić proces unroot i korzystać z Neffos'a Y5L, tak jak ze zwykłego urządzenia z Androidem na pokładzie. Proces cofania zmian w systemie nie jest jakoś specjalnie trudny ale trzeba uważać, by w jego trakcie nie uszkodzić smartfona. Ten artykuł ma na celu pokazanie jak cofnąć wszelkie zmiany wprowadzone w telefonie za sprawą dostępu do praw administracyjnych w Neffos Y5L. Odinstalowanie SuperSU (unroot) Zmiany wprowadzane w systemie za sprawą ukorzenionego Androida mogą być niewielkie lub też mogą dość znacznie ingerować w jego struktury. W zasadzie unroot przeprowadzany z poziomu SuperSU działa OOTB. Trzeba tutaj jednak wyraźnie zaznaczyć, że SuperSU nie usunie nam zmian wprowadzonych przez inne aplikacje wymagające praw administratora root. SuperSU jest w zasadzie zdolny odinstalować sam siebie oraz (opcjonalnie) przywrócić partycję /recovery/ do stanu fabrycznego. W przypadku, gdy nie chcemy zbytnio powracać do standardowego ROM'u, a jedynie nieco zabezpieczyć nasz smartfon przez uniemożliwienie logowania się aplikacjom na użytkownika root, to możemy w zasadzie odinstalować samo SuperSU. Chodzi generalnie o to, że wprowadzone przez nas zmiany na partycji /system/ , do przeprowadzenia których potrzebny nam był SuperSU, i tak przetrwają odinstalowanie tego programiku. Po skonfigurowaniu Androida, SuperSU jest nam zwyczajnie zbędny i stwarza on tylko niepotrzebne zagrożenie dla bezpieczeństwa systemu. SuperSU w Neffos Y5L możemy odinstalować z menu tejże aplikacji przechodząc w Ustawienia => Pełny Unroot. Jeśli nie chcemy przywracać partycji /recovery/ , to w ostatnim kroku wybieramy opcję NIE. Jeśli smartfon nie uruchomi się ponownie automatycznie, to naturalnie po całym procesie telefon restartujemy ręcznie. W przypadku, gdy proces usuwania SuperSU się zawiesi nam, to trzeba zrestartować smartfon i ponowić proces unroot bezpośrednio po włączeniu telefonu. Możemy naturalnie sprawdzić czy cały proces przebiegł zgodnie z planem i czy nasz Neffos Y5L w dalszym ciągu posiada root: Niemniej jednak, jeśli w Neffos Y5L chcemy przywrócić całą partycję /system/ usuwając tym samym wszelkie zmiany wprowadzone w telefonie, to trzeba do tej kwestii podejść nieco inaczej. Wydobywanie partycji /system/ , /recovery/ i /boot/ z obrazu flash'a W zasadzie mając zrobiony pełny obraz flash'a smartfona Neffos Y5L możemy wydobyć z niego określone partycje via dd i wgrać je w stosowne miejsca przez bootloader za pomocą fastboot. Zamontujmy zatem ten obraz backup'u w systemie (za pomocą losetup ) i sprawdźmy jak wygląda jego layout, np. w gdisk : Interesują nas partycje 21 ( /system/ ), 24 ( /recovery/ ) oraz 20 ( /boot/ ). Robimy ich zrzut do osobnych plików via dd : # losetup /dev/loop0 '/smartfon/Neffos Y5L/full_flash.emmc.win' # dd if=/dev/loop0p21 of=./neffos_y5l_orig_system.img # dd if=/dev/loop0p24 of=./neffos_y5l_orig_recovery.img # dd if=/dev/loop0p20 of=./neffos_y5l_orig_boot.img Przywracanie partycji /system/ via fastboot Przywrócenie partycji /system/ w trybie bootloader'a za pomocą narzędzia fastboot nie odtworzy automatycznie nam partycji /recovery/ . Musimy ją wgrać osobno. Na początek wgrajmy obraz partycji /system/ . Wyłączamy telefon i włączamy go ponownie trzymając przyciski VolumeDown + Power (powinno pojawić się logo TP-LINK'a i Android'a). Następnie podpinamy telefon do portu USB komputera i sprawdzamy, czy narzędzie fastboot jest w stanie wykryć nasz smartfon: # fastboot devices 8a8f289 fastboot Wgrywamy teraz wydobyty wcześniej obraz neffos_y5l_orig_system.img na smartfon przy pomocy poniższego polecenia: # fastboot flash system neffos_y5l_orig_system.img target reported max download size of 262144000 bytes Invalid sparse file format at header magi erasing 'system'... OKAY [ 1.532s] sending sparse 'system' (241786 KB)... OKAY [ 10.892s] writing 'system'... OKAY [ 24.863s] sending sparse 'system' (232980 KB)... OKAY [ 10.580s] writing 'system'... OKAY [ 27.701s] ... sending sparse 'system' (185348 KB)... OKAY [ 8.556s] writing 'system'... OKAY [ 22.117s] finished. total time: 308.857s Partycja /system/ przed wgraniem nowego obrazu została pierw wyczyszczona. Następnie obraz tejże partycji został podzielony na kawałki i przesłany na telefon, no i oczywiście wszystkie części obrazu zostały pomyślnie wgrane na flash smartfona. Czyszczenie partycji /data/ i /cache/ Jako, że wgraliśmy świeży obraz partycji /system/ , to przydałoby się także wyczyścić dane użytkownika znajdujące się na partycji /data/ : # fastboot format userdata Creating filesystem with parameters: Size: 5199867904 Block size: 4096 Blocks per group: 32768 Inodes per group: 8144 Inode size: 256 Journal blocks: 19835 Label: Blocks: 1269499 Block groups: 39 Reserved block group size: 311 Created filesystem with 11/317616 inodes and 42271/1269499 blocks target reported max download size of 262144000 bytes erasing 'userdata'... OKAY [ 3.013s] sending 'userdata' (83009 KB)... OKAY [ 3.543s] writing 'userdata'... OKAY [ 6.071s] finished. total time: 12.627s Dobrze jest także wyczyścić dane znajdujące się w cache: # fastboot format cache Creating filesystem with parameters: Size: 268435456 Block size: 4096 Blocks per group: 32768 Inodes per group: 8192 Inode size: 256 Journal blocks: 1024 Label: Blocks: 65536 Block groups: 2 Reserved block group size: 15 Created filesystem with 11/16384 inodes and 2089/65536 blocks target reported max download size of 262144000 bytes erasing 'cache'... OKAY [ 0.190s] sending 'cache' (6248 KB)... OKAY [ 0.278s] writing 'cache'... OKAY [ 0.936s] finished. total time: 1.405s Warto tutaj dodać, by nie korzystać z opcji erase w miejscu format . W przypadku erase system podczas ponownego startu złapie nam bootloop'a i trzeba będzie ponawiać czyszczenie partycji /data/ i /cache/ z wykorzystaniem format . Opcja erase przydaje się jedynie przed ponownym flash'owaniem. Przywracanie partycji /recovery/ i /boot/ via fastboot Podobnie jak w przypadku partycji /system/ , partycje /recovery/ i /boot/ również przywracamy z poziomu bootloader'a za pomocą narzędzia fastboot . Ten proces się zbytnio wcale nie różni, tylko wymaga wskazania pozostałych obrazów i wgrania ich na odpowiednie partycje: # fastboot flash recovery neffos_y5l_orig_recovery.img # fastboot flash boot neffos_y5l_orig_boot.img Ponowny restart Neffos'a Y5L Po wgraniu świeżego obrazu na partycję /system/ , /recovery/ i /boot/ oraz wyczyszczeniu partycji /data/ i /cache/ , możemy zresetować naszego Neffos'a Y5L i sprawdzić czy się uruchomi on ponownie. Wpisujemy zatem w terminal poniższe polecenie: # fastboot reboot Neffos Y5L powinien się uruchomić bez większych problemów, o ile przeprowadziliśmy powyższe kroki tak jak trzeba. Proces pierwszego startu zajmie dłuższą chwilę ale ostatecznie powinniśmy zobaczyć znajomy nam wszystkim ekran pierwszego logowania z wyborem języka systemu. Zablokowanie bootloader'a w Neffos Y5L To jednak nie jest koniec i w zasadzie możemy sobie darować konfigurację telefonu w tej fazie. A to z tego względu, że bootloader w dalszym ciągu jest odblokowany. Jeśli teraz byśmy skonfigurowali wstępnie system, to po zablokowaniu bootloader'a ponownie będziemy musieli wszystko ustawiać. Dlatego też wyłączamy telefon i uruchamiamy go w trybie bootloader'a za pomocą przycisków VolumeDown + Power. Następnie w terminalu wpisujemy poniższe polecenie: # fastboot oem lock Nasz Neffos Y5L powinien nam się uruchomić ponownie, a na jego ekranie powinniśmy zobaczyć zielonego robocika przeprowadzającego proces Factory Reset. Po chwili smartfon uruchomi się ponownie, a po jeszcze dłuższej chwili system powinien się załadować już na fabrycznych ustawieniach:
  23. Przeprowadzenie procesu root na smartfonie Neffos Y5 od TP-LINK nie było tak łatwe jak w przypadku innych modeli telefonów tego producenta. Niemniej jednak, trzeba zdawać sobie sprawę, że ukorzenianie Androida niesie za sobą pewne zagrożenia. Nie chodzi tutaj tylko o niezaufane aplikacje ale też trzeba brać pod uwagę możliwość przypadkowego (przypadki nie istnieją) skasowania czy zmienienia plików systemowych, przez co nasz telefon może przestać nam działać poprawnie lub też przestanie się w ogóle uruchamiać. Jeśli natomiast wgraliśmy SuperSU i praktycznie w ogóle z niego nie korzystamy, to moim zdaniem lepiej jest przeprowadzić proces unroot i korzystać z Neffos'a Y5, tak jak ze zwykłego urządzenia z Androidem na pokładzie. Proces cofania zmian w systemie nie jest jakoś specjalnie trudny ale trzeba uważać, by w jego trakcie nie uszkodzić smartfona. Ten artykuł ma na celu pokazanie jak cofnąć wszelkie zmiany wprowadzone w telefonie za sprawą dostępu do praw administracyjnych w Neffos Y5. Odinstalowanie SuperSU (unroot) Zmiany wprowadzane w systemie za sprawą ukorzenionego Androida mogą być niewielkie lub też mogą dość znacznie ingerować w jego struktury. W zasadzie unroot przeprowadzany z poziomu SuperSU działa OOTB. Trzeba tutaj jednak wyraźnie zaznaczyć, że SuperSU nie usunie nam zmian wprowadzonych przez inne aplikacje wymagające praw administratora root. SuperSU jest w zasadzie zdolny odinstalować sam siebie oraz (opcjonalnie) przywrócić partycję /recovery/ do stanu fabrycznego. W przypadku, gdy nie chcemy zbytnio powracać do standardowego ROM'u, a jedynie nieco zabezpieczyć nasz smartfon przez uniemożliwienie logowania się aplikacjom na użytkownika root, to możemy w zasadzie odinstalować samo SuperSU. Chodzi generalnie o to, że wprowadzone przez nas zmiany na partycji /system/ , do przeprowadzenia których potrzebny nam był SuperSU, i tak przetrwają odinstalowanie tego programiku. Po skonfigurowaniu Androida, SuperSU jest nam zwyczajnie zbędny i stwarza on tylko niepotrzebne zagrożenie dla bezpieczeństwa systemu. SuperSU w Neffos Y5 możemy odinstalować z menu tejże aplikacji przechodząc w Ustawienia => Pełny Unroot. Jeśli nie chcemy przywracać partycji /recovery/ , to w ostatnim kroku wybieramy opcję NIE. Jeśli smartfon nie uruchomi się ponownie automatycznie, to naturalnie po całym procesie telefon restartujemy ręcznie. W przypadku, gdy proces usuwania SuperSU się zawiesi nam, to trzeba zrestartować smartfon i ponowić proces unroot bezpośrednio po włączeniu telefonu. Możemy naturalnie sprawdzić czy cały proces przebiegł zgodnie z planem i czy nasz Neffos Y5 w dalszym ciągu posiada root: Niemniej jednak, jeśli w Neffos Y5 chcemy przywrócić całą partycję /system/ usuwając tym samym wszelkie zmiany wprowadzone w telefonie, to trzeba do tej kwestii podejść nieco inaczej. Wydobywanie partycji /system/ , /recovery/ i /boot/ z obrazu flash'a W zasadzie mając zrobiony pełny obraz flash'a smartfona Neffos Y5 możemy wydobyć z niego określone partycje via dd i wgrać je w stosowne miejsca przez bootloader za pomocą fastboot. Zamontujmy zatem ten obraz backup'u w systemie (za pomocą losetup ) i sprawdźmy jak wygląda jego layout, np. w gdisk : Interesują nas partycje 21 ( /system/ ) , 24 ( /recovery/ ) oraz 20 ( /boot/ ). Robimy ich zrzut do osobnych plików via dd : # losetup /dev/loop0 /smartfon/Neffos Y5/full_flash.emmc.win # dd if=/dev/loop0p24 of=./neffos_y5_orig_recovery.img # dd if=/dev/loop0p21 of=./neffos_y5_orig_system.img # dd if=/dev/loop0p20 of=./neffos_y5_orig_boot.img Przywracanie partycji /system/ via fastboot Przywrócenie partycji /system/ w trybie bootloader'a za pomocą narzędzia fastboot nie odtworzy automatycznie nam partycji /recovery/ . Musimy ją wgrać osobno. Na początek wgrajmy obraz partycji /system/ . Wyłączamy telefon i włączamy go ponownie trzymając przyciski VolumeDown + Power (powinno pojawić się logo TP-LINK'a i Android'a). Następnie podpinamy telefon do portu USB komputera i sprawdzamy, czy narzędzie fastboot jest w stanie wykryć nasz smartfon: # fastboot devices 90169635 fastboot Wgrywamy teraz wydobyty wcześniej obraz neffos_y5_orig_system.img na smartfon przy pomocy poniższego polecenia: # fastboot flash system neffos_y5_orig_system.img target reported max download size of 262144000 bytes Invalid sparse file format at header magi erasing 'system'... OKAY [ 1.048s] sending sparse 'system' (249905 KB)... OKAY [ 11.503s] writing 'system'... OKAY [ 21.036s] sending sparse 'system' (247311 KB)... OKAY [ 11.460s] writing 'system'... OKAY [ 21.086s] ... sending sparse 'system' (122860 KB)... OKAY [ 5.744s] writing 'system'... OKAY [ 10.501s] finished. total time: 245.337s Partycja /system/ przed wgraniem nowego obrazu została pierw wyczyszczona. Następnie obraz tejże partycji został podzielony na kawałki i przesłany na telefon, no i oczywiście wszystkie części obrazu zostały pomyślnie wgrane na flash smartfona. Czyszczenie partycji /data/ i /cache/ Jako, że wgraliśmy świeży obraz partycji /system/ , to przydałoby się także wyczyścić dane użytkownika znajdujące się na partycji /data/ : # fastboot format userdata Creating filesystem with parameters: Size: 13015953408 Block size: 4096 Blocks per group: 32768 Inodes per group: 8192 Inode size: 256 Journal blocks: 32768 Label: Blocks: 3177723 Block groups: 97 Reserved block group size: 775 Created filesystem with 11/794624 inodes and 90399/3177723 blocks target reported max download size of 262144000 bytes erasing 'userdata'... OKAY [ 6.614s] sending 'userdata' (137090 KB)... OKAY [ 6.278s] writing 'userdata'... OKAY [ 2.406s] finished. total time: 15.298s Dobrze jest także wyczyścić dane znajdujące się w cache: # fastboot format cache Creating filesystem with parameters: Size: 268435456 Block size: 4096 Blocks per group: 32768 Inodes per group: 8192 Inode size: 256 Journal blocks: 1024 Label: Blocks: 65536 Block groups: 2 Reserved block group size: 15 Created filesystem with 11/16384 inodes and 2089/65536 blocks target reported max download size of 262144000 bytes erasing 'cache'... OKAY [ 0.190s] sending 'cache' (6248 KB)... OKAY [ 0.308s] writing 'cache'... OKAY [ 0.173s] finished. total time: 0.671s Warto tutaj dodać, by nie korzystać z opcji erase w miejscu format . W przypadku erase system podczas ponownego startu złapie nam bootloop'a i trzeba będzie ponawiać czyszczenie partycji /data/ i /cache/ z wykorzystaniem format . Opcja erase przydaje się jedynie przed ponownym flash'owaniem. Przywracanie partycji /recovery/ i /boot/ via fastboot Podobnie jak w przypadku partycji /system/ , partycje /recovery/ i /boot/ również przywracamy z poziomu bootloader'a za pomocą narzędzia fastboot . Ten proces się zbytnio wcale nie różni, tylko wymaga wskazania pozostałych obrazów i wgrania ich na odpowiednie partycje: # fastboot flash recovery neffos_y5_orig_recovery.img # fastboot flash boot neffos_y5_orig_boot.img Ponowny restart Neffos'a Y5 Po wgraniu świeżego obrazu na partycję /system/ , /recovery/ i /boot/ oraz wyczyszczeniu partycji /data/ i /cache/ , możemy zresetować naszego Neffos'a Y5 i sprawdzić czy się uruchomi on ponownie. Wpisujemy zatem w terminal poniższe polecenie: # fastboot reboot Neffos Y5 powinien się uruchomić bez większych problemów, o ile przeprowadziliśmy powyższe kroki tak jak trzeba. Proces pierwszego startu zajmie dłuższą chwilę ale ostatecznie powinniśmy zobaczyć znajomy nam wszystkim ekran pierwszego logowania z wyborem języka systemu. Zablokowanie bootloader'a w Neffos Y5 To jednak nie jest koniec i w zasadzie możemy sobie darować konfigurację telefonu w tej fazie. A to z tego względu, że bootloader w dalszym ciągu jest odblokowany. Jeśli teraz byśmy skonfigurowali wstępnie system, to po zablokowaniu bootloader'a ponownie będziemy musieli wszystko ustawiać. Dlatego też wyłączamy telefon i uruchamiamy go w trybie bootloader'a za pomocą przycisków VolumeDown + Power. Następnie w terminalu wpisujemy poniższe polecenie: # fastboot oem lock Nasz Neffos Y5 powinien nam się uruchomić ponownie, a na jego ekranie powinniśmy zobaczyć zielonego robocika przeprowadzającego proces Factory Reset. Po chwili smartfon uruchomi się ponownie, a po jeszcze dłuższej chwili system powinien się załadować już na fabrycznych ustawieniach:
  24. Ten temat, choć w dalszym ciągu aktualny, zawiera sporo informacji zbędnych przeciętnemu użytkownikowi przeprowadzającemu proces root Androida w swoim smartfonie. Dlatego też powstała uproszczona wersja tego tutoriala wykorzystująca natywne obrazy TWRP, co daje możliwość ukorzenienia Androida w kilku prostych krokach. Link do nowego HowTO. Nie we wszystkich smartfonach Neffos da radę przeprowadzić proces root tak łatwo jak to miało miejsce w przypadku modeli Neffos C5 i Neffos C5 MAX. TP-LINK ma w swojej ofercie również model Neffos Y5 (TP802A) i on w odróżnieniu do tych dwóch poprzednich ma inne podzespoły, a konkretnie SoC, którzy pochodzi od producenta Qualcomm (Snapdragon 210, model MSM8909). Root smartfonów opartych o tego typu SoC przebiega nieco inaczej ale jest generalnie do zrobienia, choć trzeba trochę się przyłożyć do procesu backup'u flash'a telefonu. Pozostała część jest w miarę standardowa. W tym wpisie zostanie przeprowadzony proces root smartfona Neffos Y5. Narzędzia ADB i fastboot Przede wszystkim, by zabrać się za proces root'owania smartfona Neffos Y5, musimy przygotować sobie odpowiednie narzędzia. Zapewnią one nam możliwość rozmawiania z telefonem. Będziemy potrzebować adb (Android Debug Bridge) oraz fastboot . Proces instalacji tych narzędzi na linux, a konkretnie w dystrybucji Debian, został opisany osobno. Problematyczny backup flash'a smartfona Neffos Y5 W przypadku wspomnianych już Neffos'ów C5 i C5 MAX, do zrobienia backup'u całego flash'a można było wykorzystać narzędzie SP Flash Tool. Niemniej jednak, to oprogramowanie jest przeznaczone jedynie dla smartfonów mających SoC od MediaTek, a jak już również zostało powiedziane, Neffos Y5 ma SoC Snapdragon 210 (MSM8909) od Qualcomm'a. Jak zatem zrobić backup flash'a tego smartfona przed wprowadzaniem w nim jakichkolwiek zmian? Generalnie trzeba się zmierzyć z problemem jajka i kury, czyli by dokonać backup'u flash'a trzeba skorzystać z niestandardowego obrazu partycji /recovery/ , np. TWRP, a nie możemy go przecież wgrać na telefon, bo wprowadzimy w ten sposób zmiany. Możemy jednak wgrać taki obraz bezpośrednio do pamięci RAM telefonu i z niej go uruchomić. W takim przypadku będziemy w stanie zrobić backup flash'a telefonu bez wprowadzania żadnych zmian. Niemniej jednak, w dalszym ciągu obraz partycji /recovery/ musimy jakoś pozyskać. Pozyskanie obrazu recovery.img z TWRP Niestety, póki co nie ma obrazów dla Neffos'a Y5. Dlatego też musimy sobie taki obraz recovery.img stworzyć sami przerabiając inny obraz, który jest przeznaczony na telefon zbliżony parametrami do naszego urządzenia (ten sam SoC, wielkość flash i rozdzielczość ekranu). Po wielu dniach poszukiwań udało mi się znaleźć w końcu pasujący obraz. Posłużyłem się obrazem dla HTC Desire 626s. W zasadzie SoC i rozdziałka ekranu się zgadzają ale wielkość flash już jest inna i trzeba będzie nieco ten obraz przerobić, a do tego celu potrzebny nam będzie stock'owy obraz boot.img lub recovery.img . Gotowy obraz recovery.img dla smartfona Neffos Y5 znajduje się tutaj: recovery-neffos-y5-tp-link-twrp.img i jedyne co, to musimy go wgrać na telefon. Jeśli jednak ktoś jest ciekaw jak proces przepakowania tego obrazu przebiega, to jest on opisany poniżej. Pozyskanie stock'owego obrazu boot/recovery Proces dostosowania obrazu recovery.img z TWRP nieco się różni w przypadku Neffos Y5 w stosunku do poprzednio opisywanych przez mnie modeli Neffos C5 i Neffos C5 MAX. Chodzi o to, że w zasadzie nie mamy jak wydobyć obrazu partycji /recovery/ z telefonu, no bo przecież nie możemy skorzystać z SP Flash Tool, a póki co nie jestem świadom alternatywnego oprogramowania, które by nam z tym zadaniem pomogło w podobny sposób. Niemniej jednak, obraz recovery.img w dalszym ciągu możemy zbudować ale potrzebny nam jest firmware Neffos'a Y5, który na szczęście możemy pobrać ze strony producenta tego smartfona. Pamiętajmy by pobrać plik przeznaczony na ten konkretny model telefonu, który posiadamy (w tym przypadku TP802A). Poniżej jest pełna specyfikacja wgranego oprogramowania oraz dokładne numery mojego smartfona: W paczce .zip z firmware, którą pobraliśmy, znajduje się plik boot.img . Musimy go wydobyć w celu wyodrębnienia pewnych plików i wgrania ich na portowany obraz recovery.img . Przepakowanie obrazu recovery.img By przepakować obraz przeznaczony na inny smartfon, który jest zbliżony parametrami do naszego Neffos'a Y5, musimy pierw pozyskać odpowiednie narzędzia. Na linux'ie możemy skorzystać tego celu z abootimg lub też ze skryptów Android Image Kitchen. Ja będę korzystał z tego drugiego rozwiązania. Tworzymy sobie jakiś katalog roboczy i kopiujemy do niego zarówno oryginalny obraz boot.img , jak i obraz recovery.img z innego smartfona. Następnie znajdując się w tym katalogu roboczym, pobieramy skrypty z github'a (wymagane zainstalowane narzędzie git w systemie) i przechodzimy do utworzonego w ten sposób katalogu. W nim zaś tworzymy dwa podkatalogi stock/ oraz port/ : $ git clone https://github.com/ndrancs/AIK-Linux-x32-x64/ $ chmod +x ./AIK-Linux-x32-x64/* $ chmod +x ./AIK-Linux-x32-x64/bin/* $ cd ./AIK-Linux-x32-x64/ $ mkdir stock/ port/ Kopiujemy oryginalny obraz boot.img z katalogu nadrzędnego i wypakowujemy go za pomocą skryptu unpackimg.sh . Następnie przenosimy tak wyodrębnioną zawartość do katalogu stock/ : $ cp ../orig_boot.img ./recovery.img $ ./unpackimg.sh recovery.img $ mv split_img/ ramdisk/ stock/ $ rm recovery.img Kopiujemy teraz obraz partycji /recovery/ mający TWRP i wypakowujemy go. Przenosimy jego zawartość do katalogu port/ : $ cp ../recovery_twrp.img ./recovery.img $ ./unpackimg.sh recovery.img $ mv split_img/ ramdisk/ port/ $ rm recovery.img Kernel W zasadzie to musimy tylko przekopiować plik recovery.img-zImage z oryginalnego obrazu naszego Neffos'a Y5 do obrazu TWRP: $ cp ./stock/split_img/recovery.img-zImage ./port/split_img/ Fstab Musimy także dostosować nieco plik port/ramdisk/etc/recovery.fstab , bo przecie flash telefonu, z którego wzięliśmy obraz recovery.img z TWRP ma inny rozmiar, więc wielce prawdopodobne, że ma inny układ i rozmiar poszczególnych partycji. W oparciu o informacje uzyskane z aplikacji DiskInfo oraz pliku /proc/partitions w telefonie, układ flash'a w przypadku Neffos Y5 prezentuje się następująco (kolumna najbardziej na prawo została dodana przeze mnie): # adb shell shell@Y5:/ $ cat /proc/partitions major minor #blocks name 253 0 524288 zram0 179 0 15267840 mmcblk0 179 1 65536 mmcblk0p1 modem (/firmware/ , vfat) 179 2 512 mmcblk0p2 sbl1 179 3 512 mmcblk0p3 sbl1bak 179 4 1024 mmcblk0p4 aboot 179 5 1024 mmcblk0p5 abootbak 179 6 512 mmcblk0p6 rpm 179 7 512 mmcblk0p7 rpmbak 179 8 768 mmcblk0p8 tz 179 9 768 mmcblk0p9 tzbak 179 10 1024 mmcblk0p10 pad 179 11 1536 mmcblk0p11 modemst1 179 12 1536 mmcblk0p12 modemst2 179 13 1024 mmcblk0p13 misc 179 14 1 mmcblk0p14 fsc 179 15 8 mmcblk0p15 ssd 179 16 10240 mmcblk0p16 splash 179 17 32 mmcblk0p17 DDR 179 18 1536 mmcblk0p18 fsg 179 19 16 mmcblk0p19 sec 179 20 32768 mmcblk0p20 boot 179 21 1913652 mmcblk0p21 System (/system/ , ext4) 179 22 32768 mmcblk0p22 persist (/persist/ , ext4) 179 23 262144 mmcblk0p23 Cache (/cache/ , ext4) 179 24 32768 mmcblk0p24 recovery 179 25 1024 mmcblk0p25 devinfo 179 26 512 mmcblk0p26 keystore 179 27 65536 mmcblk0p27 oem 179 28 512 mmcblk0p28 config 179 29 12710895 mmcblk0p29 Data (/data/ , ext4) 179 32 4096 mmcblk0rpmb mmcblk0rpmb Rozmiary poszczególnych partycji są w blokach, a każdy z nich ma 1024 bajty. Partycja mmcblk0 odpowiada za cały obszar flash'a. Będziemy zatem w stanie zrobić backup całego flash'a albo też poszczególnych jego partycji. Tak czy inaczej potrzebne nam są odpowiednie wpisy w pliku port/ramdisk/etc/recovery.fstab . Poniżej jest zawartość mojego pliku: # Use platform/soc.0/7824900.sdhci or bootdevice in the path # mmcblk0p1 (modem) /firmware vfat /dev/block/bootdevice/by-name/modem flags=display="Firmware";mounttodecrypt;backup=1 # mmcblk0p2 (sbl1) /sbl1 emmc /dev/block/bootdevice/by-name/sbl1 flags=display="sbl1";backup=1 # mmcblk0p3 (sbl1bak) /sbl1bak emmc /dev/block/bootdevice/by-name/sbl1bak flags=display="sbl1bak";backup=1 # mmcblk0p4 (aboot) /aboot emmc /dev/block/bootdevice/by-name/aboot flags=display="aboot";backup=1 # mmcblk0p5 (abootbak) /abootbak emmc /dev/block/bootdevice/by-name/abootbak flags=display="abootbak";backup=1 # mmcblk0p6 (rpm) /rpm emmc /dev/block/bootdevice/by-name/rpm flags=display="rpm";backup=1 # mmcblk0p7 (rpmbak) /rpmbak emmc /dev/block/bootdevice/by-name/rpmbak flags=display="rpmbak";backup=1 # mmcblk0p8 (tz) /tz emmc /dev/block/bootdevice/by-name/tz flags=display="tz";backup=1 # mmcblk0p9 (tzbak) /tzbak emmc /dev/block/bootdevice/by-name/tzbak flags=display="tzbak";backup=1 # mmcblk0p10 (tzbak) /pad emmc /dev/block/bootdevice/by-name/pad flags=display="pad";backup=1 # mmcblk0p11 (modemst1) /efs1 emmc /dev/block/bootdevice/by-name/modemst1 flags=display="EFS";backup=1 # mmcblk0p12 (modemst2) /efs2 emmc /dev/block/bootdevice/by-name/modemst2 flags=backup=1;subpartitionof=/efs1 # mmcblk0p13 (misc) /misc emmc /dev/block/bootdevice/by-name/misc flags=display="Misc";backup=1 # mmcblk0p14 (fsc) /fsc emmc /dev/block/bootdevice/by-name/fsc flags=display="fsc";backup=1 # mmcblk0p15 (ssd) /ssd emmc /dev/block/bootdevice/by-name/ssd flags=display="ssd";backup=1 # mmcblk0p16 (splash) /splash emmc /dev/block/bootdevice/by-name/splash flags=display="splash";backup=1 # mmcblk0p17 (DDR) /ddr emmc /dev/block/bootdevice/by-name/DDR flags=display="DDR";backup=1 # mmcblk0p18 (fsg) /fsg emmc /dev/block/bootdevice/by-name/fsg flags=display="fsg";backup=1 # mmcblk0p19 (sec) /sec emmc /dev/block/bootdevice/by-name/sec flags=display="sec";backup=1 # mmcblk0p20 (boot) /boot emmc /dev/block/bootdevice/by-name/boot flags=display="Boot";backup=1 # mmcblk0p21 (System) /system ext4 /dev/block/bootdevice/by-name/system flags=display="System";backup=1;wipeingui # mmcblk0p22 (persist) /persist ext4 /dev/block/bootdevice/by-name/persist flags=display="Persist";backup=1 # mmcblk0p23 (Cache) /cache ext4 /dev/block/bootdevice/by-name/cache flags=display="Cache";backup=1;wipeingui;wipeduringfactoryreset # mmcblk0p24 (recovery) /recovery emmc /dev/block/bootdevice/by-name/recovery flags=display="Recovery";backup=1 # mmcblk0p25 (devinfo) /devinfo emmc /dev/block/bootdevice/by-name/devinfo flags=display="devinfo";backup=1 # mmcblk0p26 (keystore) /keystore emmc /dev/block/bootdevice/by-name/keystore flags=display="keystore";backup=1 # mmcblk0p27 (oem) /oem emmc /dev/block/bootdevice/by-name/oem flags=display="oem";backup=1 # mmcblk0p28 (config) /config emmc /dev/block/bootdevice/by-name/config flags=display="config";backup=1 # mmcblk0p29 (Data) /data ext4 /dev/block/bootdevice/by-name/userdata flags=display="Data";backup=1;length=-16384;wipeingui;wipeduringfactoryreset;encryptable=footer # #/mmcblk0rpmb emmc /dev/block/bootdevice/by-name/mmcblk0rpmb flags=display="mmcblk0rpmb";backup=1 # External /sdcard1 auto /dev/block/mmcblk1p1 flags=display="MicroSD";storage;wipeingui;removable;encryptable=footer /usb-otg auto /dev/block/sda1 flags=display="USBOTG";storage;wipeingui;removable # Full partition images /firmware_image emmc /dev/block/bootdevice/by-name/modem flags=display="Firmware-Image";backup=1 /system_image emmc /dev/block/bootdevice/by-name/system flags=display="System-Image";backup=1 /persist_image emmc /dev/block/bootdevice/by-name/persist flags=display="Persist-Image";backup=1 /cache_image emmc /dev/block/bootdevice/by-name/cache flags=display="Cache-Image";backup=1 /data_image emmc /dev/block/bootdevice/by-name/userdata flags=display="Data-Image";backup=1 /full_flash emmc /dev/block/mmcblk0 flags=display="Full-Flash-Image";backup=1 Jeśli ktoś jest ciekaw użytych tutaj opcji, to są one wyjaśnione w tym wątku na forum XDA. Tworzenie obrazu recovery z TWRP dla Neffos Y5 Z tak przygotowanych plików w katalogu stock/ trzeba zrobić nowy obraz recovery.img przy pomocy skryptu repackimg_x64.sh : $ rm -R stock/ $ mv port/ramdisk ./ $ mv port/split_img ./ $ rmdir port/ $ ./repackimg_x64.sh W katalogu roboczym powinien zostać utworzony nowy plik o nazwie image-new.img . To jest właśnie nasz nowy obraz partycji /recovery/ , który musimy wgrać na telefon w trybie bootloader'a przez fastboot. Niemniej jednak, zanim będziemy w stanie to zrobić, musimy odblokować bootloader. Jak odblokować bootloader w Neffos Y5 Może nie mamy możliwości zrobić backup'u całego flash'a telefonu przed podjęciem jakichkolwiek prac ale też raczej nie powinniśmy znowu nic namieszać. Jedyna rzecz jaką musimy zrobić, to odblokować bootloader. Chodzi o to, że na smartfonach zwykle jest ulokowana partycja /recovery/ . Na niej znajduje się oprogramowanie umożliwiające przeprowadzanie niskopoziomowych operacji, np. backup lub też flash'owanie ROM'u. Problem w tym, że to oprogramowanie w standardzie zwykle za wiele nie potrafi i by przeprowadzić proces root'owania Androida, musimy pozyskać bardziej zaawansowany soft, np. ClockworkMod czy TWRP, i wgrać go na partycję /recovery/ . By to zrobić musimy pierw odblokować bootloader. Proces odblokowania bootloader'a usuwa wszystkie dane, które wgraliśmy na flash telefonu, tj. podczas odblokowywania jest inicjowany factory reset. Dane na karcie SD pozostają nietknięte. By ten proces zainicjować zaczynamy od przestawienia jednej opcji w telefonie. W tym celu musimy udać się w Ustawienia => Opcje Programistyczne i tam przełączyć Zdjęcie blokady OEM : Następnie w terminalu wpisujemy poniższe polecenia: # adb reboot bootloader # fastboot devices 8a8f289 fastboot # fastboot oem unlock-go Na ekranie smartfona powinien nam się pokazać zielony robocik informujący o przeprowadzaniu Factory Reset. Po chwili ten proces powinien dobiec końca, a smartfon uruchomi się ponownie na ustawieniach domyślnych. Wyłączamy urządzenie i włączamy je via przyciski VolumeDown + Power i sprawdzamy status blokady bootloader'a: # fastboot oem device-info ... (bootloader) Device tampered: false (bootloader) Device unlocked: true (bootloader) Charger screen enabled: true (bootloader) Display panel: OKAY [ 0.004s] finished. total time: 0.004s Jeśli przy Device unlocked: widnieje wartość true , to blokada bootloader'a została pomyślnie zdjęta. Jako, że proces odblokowania bootloader'a usunął wszelkie ustawienia, to jeszcze raz musimy włączyć Opcje programistyczne, a w nich tryb debugowania portu USB. Testowanie przepakowanego obrazu recovery.img Zanim jednak wgramy nowo stworzony obraz recovery.img , przydałoby się sprawdzić pierw, czy aby na pewno ten obraz działa jak należy. Podpinamy telefon do portu USB komputera i przy pomocy narzędzia fasboot przetestujmy wyżej wygenerowany obraz próbując uruchomić go z pamięci telefonu: # fastboot boot image-new.img W przypadku, gdyby pojawiła nam się informacja FAILED (remote: unlock device to use this command) , to prawdopodobnie zapomnieliśmy odblokować bootloader. Jeśli blokada została zdjęta, to wydanie tego powyższego polecenia powinno załadować do pamięci RAM telefonu zmieniony obraz partycji /recovery/ , oczywiście o ile obraz jest poprawny. Jeśli zamiast tego smartfon uruchomi się ponownie, to coś z takim obrazem jest nie tak i lepiej nie wgrywać go na telefon. Jak przeprowadzić backup flash'a Neffos Y5 Mając załadowany obraz recovery.img z TWRP do pamięci smartfona, możemy przejść do zrobienia backup'u całego flash'a telefonu. Opcje wyboru partycji, które będziemy mieć do uwzględnienia w backup'ie, zależą od pliku recovery.fstab , który edytowaliśmy sobie wcześniej. W tym przypadku mamy możliwość zrobienia backup'u całego flash'a jak i jego poszczególnych partycji. Nie musimy jednak robić backup'u wszystkich partycji i możemy zdecydować się jedynie na niektóre z nich. Przede wszystkim, potrzebny nam będzie backup partycji /system/ , /boot/ i /recovery/ , bo to je zwykle będziemy poddawać edycji i wprowadzać w nich zmiany. Ja jednak wolę zrobić backup pozostałej części flash'a, tak na wszelki wypadek. No i skoro mam do zrobienia praktycznie backup całej pamięci flash, to można przecież upchnąć go w jednym pliku zrzucając zawartość urządzenia /dev/block/mmcblk0 . Można oczywiście zapisać sobie każda partycję do osobnego pliku ale przecie z obrazu całego flash'a również można te poszczególne partycje wydobyć. W zasadzie cały backup zajmie około 2 GiB, chyba, że zrobiliśmy sobie pełną kopię. W przypadku tego drugiego rozwiązania potrzeba nam będzie karta SD o pojemności większej lub równej pojemności flash'a w telefonie. Dodatkowo, jako, że z reguły flash w smartfonach ma pojemność większą niż 4 GiB (zwykle 16-32 GiB), to w takim przypadku karta musi zostać sformatowana innym systemem plików niż FAT, bo ten ma ograniczenia wielkości pliku do 4 GiB, a obraz będzie przecie zajmował tyle ile zajmuje pamięć flash. TWRP obsługuje bez większego problemu karty SD sformatowane jako EXT4 i z tego systemu plików możemy skorzystać. Pamiętajmy jednak, że takiej karty Android nam nie będzie czytał standardowo. Niepełny backup z kolei można przeprowadzić zapisując go na flash'u smartfona, choć nie zaleca się tego robić, a to z tego względu, że kopia pamięci danego urządzenia powinna być zapisywana na zewnętrznym nośniku. Dlatego lepiej zakupić sobie kartę SD rozmiarem przypominającą flash telefonu. Różnica między robieniem obrazów partycji EXT4 i EMMC polega na tym, że w przypadku standardowych partycji EMMC, ich obraz można zamontować przez mount na dowolnym linux'ie. Natomiast obrazy EXT4, są w zasadzie zwykłymi archiwami plików, które można wypakować jak zwykłego ZIP'a. Druga różnica jest taka, że te spakowane paczki są dzielone na kawałki o rozmiarze 1,5 GiB, przez co można je bez problemu zapisywać na karcie SD, która ma system plików FAT. Warto w tym miejscu jeszcze dodać, że można pominąć backup partycji /cache/ i /data/ , bo one są i tak czyszczone podczas procesu Factory Reset. Jeśli zaś chcemy dokonać backup'u danych użytkownika, tj. partycji /data/ , to w jej przypadku lepiej jest spakować pliki zamiast robić backup całej partycji, bo wtedy robimy backup tylko danych i nie wchodzi w to wolne miejsce. Jak już ustalimy jakie partycje uwzględnimy w backup'ie, to przechodzimy do pozycji Kopia i wybieramy kartę SD oraz zaznaczamy odpowiednie obszary pamięci flash, tak jak to widać na poniższej fotce: W przypadku robienia pełnego backup'u, cały proces może zająć dłuższą chwilę. Po jego ukończeniu, na karcie SD pojawi się obraz flash'a, który możemy sprawdzić w gdisk lub parted : Wgranie obrazu recovery z TWRP na Neffos Y5 Po sprawdzeniu czy obraz się bootuje poprawnie i dokonaniu backup'u określonych obszarów pamięci flash, możemy ten obraz wgrać na telefon lub też możemy zainstalować jedynie samo SuperSU. Ja postanowiłem wgrać TWRP recovery na mojego Neffos'a Y5. W sumie ta procedura się za wiele nie różni od testowania samego obrazu w pamięci telefonu. Jedyne co trzeba zrobić to zrestartować telefon do trybu bootloader'a i wgrać obraz recovery przy pomocy fastboot w poniższy sposób: # adb reboot bootloader # fastboot flash recovery image-new.img # fastboot reboot SuperSU, BusyBOX, RootCheck i emulator terminala Ostatnią rzeczą na drodze do zrobienia root na Neffos Y5 jest wgranie aplikacji umożliwiającej korzystanie różnym programom z praw administratora systemu w telefonie. My skorzystamy z SuperSU. Dodatkowo, musimy wgrać sobie BusyBOX, który zawiera minimalistyczne odpowiedniki linux'owych narzędzi, co pozwoli nam swobodnie operować w Androidzie, tak jakbyśmy to robili pod pełnowymiarowym pingwinem. Potrzebny nam także będzie jakiś emulator terminala, w którym to będziemy wpisywać wszystkie nasze polecenia. Instalacja SuperSU Zacznijmy od pobrania stosownej paczki z SuperSU. Jako, że my nie mamy jeszcze zrobionego root'a, to musimy pobrać TWRP / FlashFire installable ZIP . Tej paczki nie wypakowujemy, tylko wrzucamy ją w pobranej formie na kartę SD w telefonie. Odpalamy teraz tryb recovery w smartfonie (VolumeUp + Power) i przechodzimy do Instaluj i wskazujemy paczkę .zip , którą umieściliśmy na karcie SD. Tam z kolei zaznaczamy Weryfikuj sygnatury pliku ZIP i przeciągamy trzy strzałki na prawą stronę. Teraz możemy uruchomić ponownie Neffos'a Y5 i zainstalować jakąś aplikację, która pokaże nam czy nasz smartfon ma root'a. Sprawdzenie czy Neffos Y5 ma root'a Po uruchomieniu się systemu na smartfonie, instalujemy aplikację RootCheck, po czym uruchamiamy ją. Powinien się pojawić monit informujący, że ta aplikacja żąda praw administracyjnych, na co zezwalamy. Jeśli nasz telefon ma root'a, to powinien się pojawić stosowny komunikat: Instalacja BusyBOX Kolejnym krokiem jest instalacja BusyBOX'a. Po wgraniu tej aplikacji na smartfona, musimy ją uruchomić i wcisnąć w niej przycisk install . BusyBOX również nas poprosi o dostęp do praw administracyjnych. Po zainstalowaniu, weryfikujemy jeszcze, czy aby wszystko zostało pomyślne wgrane. Możemy to zrobić zarówno w samej aplikacji BusyBOX, jak w CheckRoot: Instalacja terminala Generalnie rzecz biorąc, terminal jako taki nie jest obowiązkowy, bo SuperSU jak i BusyBOX są wymagane przez konkretne aplikacje do poprawnego ich działania. Niemniej jednak, jeśli zamierzamy korzystać z tych niskopoziomowych narzędzi dostarczonych przez BusyBOX, czy też innych narzędzi obecnych standardowo w Androidzie na uprawnieniach root, to terminal jak najbardziej się nam przyda. Znalazłem dwa terminale, które są OpenSource i bez reklam/opłat. Są to Android-Terminal-Emulator oraz Termux. Wybieramy sobie jeden z nich i instalujemy w systemie. Jako, że ja korzystam na co dzień z Debiana, to instaluję Termux'a. Aplikacje i prawa administracyjne Teraz już pozostało nam tylko odpalenie terminala i zalogowanie się na użytkownika root. Do tego celu służy polecenie su . Wpiszmy je zatem w okienku Termux'a: I teraz możemy uruchamiać aplikacje z prawami admina, tak jak to zwykliśmy robić w każdym innym linux'ie. Pamiętajmy tylko, że standardowo system plików jest zamontowany w trybie tylko do odczytu (RO) i by móc zmieniać pliki systemowe z poziomu tego terminala, musimy przemontować system plików w tryb do zapisu (RW). Robimy to w poniższy sposób: $ su # mount -o remount,rw /system Gdy skończymy się bawić, to montujemy ten system plików ponownie w tryb RO: # mount -o remount,ro /system
  25. Energii nigdy nie jest za dużo. Problem w tym, że w przypadku jej nadmiaru, część zasobów zwyczajnie się marnuje. Można naturalnie takiemu stanu rzeczy przeciwdziałać próbując zmagazynować energię w jakimś obiekcie tak, by można ją było wykorzystać w późniejszym czasie, gdy zajdzie taka potrzeba. Większość sprzętów elektronicznych, takich jak smartfony, tablety czy nawet przenośne routery WiFi, posiada wbudowane baterie, które mają na celu umożliwić im działanie, gdy zostaną one odcięte od stałego źródła zasilania. Niemniej jednak, akumulator w takich urządzeniach zwykle nie wystarcza na długo, choć generalnie jego zużycie zależy od sposobu użytkowania. Dlatego też można pokusić się o zakupienie dodatkowych baterii zdolnych zmagazynować energię w większym stopniu niż samo urządzenie, które wymaga zasilania. Mowa oczywiście o power bankach, które cenowo nie są zbyt wygórowane, a w krytycznych sytuacjach są wręcz niezastąpione. W tym artykule rzucimy sobie okiem na power bank TL-PBG6700 od TP-LINK. Zawartość opakowania TL-PBG6700 No to zacznijmy może od samych fotek obrazujących pudełko i jego zawartość. W zasadzie to co się rzuca w oczy na samym początku, to fakt, że to urządzenie nie jest zbytnio dużych rozmiarów (97x45x25 mm, dł/sz/gr) ale trochę waży, bo około 140 gram. No i oczywiście na plus można mu zaliczyć wygląd, a konkretnie kolorystykę, bo ja niezbyt przepadam za urządzeniami w kolorze białym. Niżej są jeszcze fotki samego power banku TL-PBG6700 pokazujące jego detale: Jak widać wyżej, na obudowie mamy jeden przycisk Power, przy pomocy którego jesteśmy w stanie podejrzeć aktualny stan rozładowania akumulatora. Po przyciśnięciu tego przycisku zapalą nam się białe diody. Im więcej diod się zapali, tym pełniejsza jest bateria. Mamy co prawda 4 diody ale współczynnik naładowania akumulatora procentowo przedstawia się mniej więcej tak: 100-75 - 4 diody, 75-50 - 3 diody, 25-50 - 2 diody, 25-10 1 dioda, no i po niżej 10 ta jedna dioda będzie nam migać. Do zestawu jest także dołączony standardowy przewód mikro USB: Specyfikacja TL-PBG6700 Na stronie TP-LINK możemy wyczytać, że litowo-jonowe ogniwa zastosowane w TL-PBG6700 pochodzą od LG. Ktoś się orientuje co dokładnie siedzi wewnątrz tego power banku? Tak czy inaczej na obudowie możemy wyczytać, że ten akumulator ma deklarowaną pojemność 6700 mAh. W zasadzie jest to wartość nawet dość optymalna w stosunku do zachowanych rozmiarów i wagi, choć zawsze mogłoby być lepiej zarówno pod względem pojemności jak i fizycznych gabarytów. To co najbardziej cieszy w przypadku TL-PBG6700, to fakt zwiększa mu mocy zarówno wejściowej jak i wyjściowej (2,4A/5V). Standardowo prąd ładowania power banków wynosi zwykle 1A, a przez jego zwiększenie i zaimplementowanie technologi szybkiego i inteligentnego ładowania, proces napełnienia tego urządzenia energią jest znacznie krótszy. Prąd ładowania w przypadku TL-PBG6700 wynosi 2,4 A, no i można powiedzieć, że na mojej ładowarce 3,1A faktyczna wartość oscyluje w granicach 2,40 A - 2,65A, choć częściej 2,40A. TP-LINK deklaruje zachowanie oryginalnej pojemności TL-PBG6700 przez około 500 cykli ładowania tego urządzenia. Niemniej jednak, dokładnie nie wiem jak jest liczony taki cykl, bo zapewne zdajemy sobie wszyscy sprawę, że takie akumulatory litowo-jonowe cechują się inną żywotnością w zależności od tego czy je ładujemy/rozładujemy w pełni, czy też będziemy wykorzystywać je w widełkach 30% - 90%. Także, nie wiem do czego ta wartość 500 się odnosi. Pojemność TL-PBG6700 Ilość zgromadzonej energii w TL-PBG6700 jest nieco niższa niż faktycznie można zakładać po oznaczeniu czy deklarowanych przez producenta wartościach. Sprawdziłem bowiem czy da radę mojego smartfona Neffos C5 MAX, który ma baterię 3045 mAh, podładować bez większego problemu dwukrotnie. Okazało się, że nie dało rady. Sumaryczna wartość procentów wyniosła jakieś 136 punków. Generalnie ładowałem smartfona dwa razy. Pierwszy cykl od 1% - 77%, a drugi od 29% do 89%. Daje to zatem 76+60, czyli 136%. Ilość przesłanej energii to około 136%*3045=4141.2 mAh, czyli około 61-62% faktycznej pojemności power banku. Potwierdza to regułę 60% deklarowanej przez producenta pojemności. Można naturalnie policzyć w drugą stronę, tj. 6700 mAh (pojemność power banku) * 3,6V (standardowe napięcie ogniw) daje nam 24120 mWh energii. Na wyjściu power banku ma być napięcie rzędu 5V (bo to port USB). Zatem 24120 mWh / 5V = 4824 mAh. No i od tej wartości trzeba odjąć jeszcze straty spowodowane przez sprawność energetyczną, która zwykle jest na poziomie 90%, czyli 10% z powyższej wartości odejmujemy, co daje nam wartość 4341 mAh. Wartość jest mniej więcej porównywalna z tym co wyszło wyżej, a ewentualna nadwyżka 200 mAh spowodowana jest niedokładnym pomiarem stanu baterii w telefonie. Według TP-LINK, power bank TL-PBG6700 można naładować od 0% do 100% w około 2 godziny i 40 minut. Z moich obserwacji wynika, że ten czas wynosi około 3 godzin i 10 minut. Przyglądając się wskazaniom wyświetlacza mojego miernika mogę dodać jeszcze, że przez około dwie pierwsze godziny, power bank pobierał w zasadzie te 2,4A - 2,6A. Niemniej jednak po upływie tego czasu do końca procesu ładowania, ta wartość stopniowo malała i generalnie i tak około 40 minut przed zakończeniem tego procesu, urządzenie pobierało już niespełna 1A, no i tak co 5 minut ubywało kolejne 0,1A. Zabezpieczenia W każdym szanującym się power banku nie może zabraknąć ochrony przed czynnikami niepożądanymi. TL-PBG6700 posiada szereg zabezpieczeń, które chronią go przed zwarciami, przepięciami, przetężeniami elektrycznymi, nadmiernymi ładowaniami i rozładowywaniami, oraz przed przegrzaniem. Mamy zatem pewność, że użytkowanie tego urządzenia będzie bezpieczne. Warto dodać, że ten power bank podczas procesu ładowania prądem 2,4A trochę się grzeje. Po około 1,5 godziny obudowa już jest dość ciepła. Biorąc pod uwagę fakt zastosowanych zabezpieczeń termicznych, trzeba uważać, by nie ładować tego urządzenia w pobliżu źródeł ciepła, bo jest wielce prawdopodobne, że mechanizm bezpieczeństwa zadziała i uniemożliwi proces ładowania. Innym rozwiązaniem jest naturalnie ładowanie power banku prądem 1A czy 0,5A ale taki zabieg z kolei znacząco wydłuży proces ładowania. Można również pokusić się o zakup małego wiatraczka, który będzie chłodził zarówno ładowarkę jak i sam power bank. Podsumowanie Może i power bank TL-PBG6700 nie ma tych obiecanych 6700 mAh ale jakby nie patrzeć 4141 mAh to całkiem sporo. Dobrze też, że nie trzeba czekać pół dnia, by taki akumulator naładować. No i chyba najważniejsza zaleta tego banku energetycznego, to fakt bardzo szybkiego oddawania energii ładowanym urządzeniom. Ten mój smartfon Neffos C5 MAX na tej dołączonej do zestawu ładowarce, ładuje się około 4 godzin. A w przypadku tego power banku, do 77% naładował się w około 1,5 godziny.