morfik

Moderators
  • Content count

    642
  • Joined

  • Last visited

Everything posted by morfik

  1. Jako, że w końcu udało mi się zbudować obraz TWRP recovery ze źródeł Androida dla jednego z moich smartfonów Neffos, to postanowiłem, że zbuduję sobie podobne obrazy dla pozostałych TP-LINK'owych telefonów. Cała konfiguracja pod konkretne modele Neffos'ów będzie wersjowana i trzymana na GitHub'ie. Tego typu rozwiązanie sprawi, że w niedługim okresie czasu, smartfony Neffos będą oficjalnie wspierane przez TWRP, no i otwiera to oczywiście drogę do budowy alternatywnych ROM'ów ale tu jeszcze trochę będzie trzeba posiedzieć. Tak czy inaczej własnoręczne budowanie ze źródeł obrazu daje możliwość bardzo prostej aktualizacji oprogramowania dla trybu recovery. Do tej pory w wątkach poświęconych ukorzenianiu smartfonów (root) były wykorzystywane pseudo porty obrazów z innych urządzeń zbliżonych pod kątem podzespołów. Te obrazy nie zawsze działały tak jak powinny i w zasadzie nadawały się jedynie dla procesu root. Poniżej zaś znajdują się gotowe obrazy recovery dla poszczególnych modeli Neffos'ów, które można pobrać i z powodzeniem wgrać na telefon via fastboot. Obok obrazów są także linki do repozytoriów z konfiguracją obrazów. Gotowy obraz recovery-twrp-tp-link-neffos-y5.img | Repo z konfiguracją dla Neffos Y5 Gotowy obraz recovery-twrp-tp-link-neffos-y5l.img | Repo z konfiguracją dla Neffos Y5L Gotowy obraz recovery-twrp-tp-link-neffos-c5.img | Repo z konfiguracją dla Neffos C5 Gotowy obraz recovery-twrp-tp-link-neffos-c5-max.img | Repo z konfiguracją dla Neffos C5 MAX By wgrać taki obraz na telefon, trzeba mieć zainstalowane w systemie wspomniane wyżej narzędzie fastboot. By dodatkowo móc wykonać szereg akcji z poziomu tego trybu recovery, potrzebne jest nam także narzędzie adb. Proces instalacji i konfiguracji tych narzędzi pod linux (Debian) został opisany tutaj.
  2. 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.
  3. Tryb preferowany, to nie to samo co wymuszony. Ustaw sobie samo LTE i zobacz czy ci będzie działać stabilnie. A jak nie, to będziesz musiał sobie załatwić anteny zewnętrzne i jakiś router LTE do tego, np, te podane wyżej MR200 i MR6400.
  4. A poza mieszkaniem jest?
  5. No to widać przecie, że problem nie jest w Neffos'ie tylko w tym telefonie z win. To tamten system (win) trzeba jakoś poprawnie skonfigurować, a tego to już ci nie powiem jak to zrobić.
  6. U mnie na linii Neffos Y5 <=> Neffos C5 MAX bez większego problemu SMS'y latają z polskimi znakami. Może ten telefon z win ma problemy z kodowaniem UTF-8? Masz inny telefon z Androidem, by sprawdzić czy on odbierze prawidłowo?
  7. No tam jest w opcjach, tylko wiesz, lepiej nie korzystać z systemu plików NTFS i jechać na natywnym linux'owym EXT4. Cała masa problemów odejdzie w ten sposób.
  8. No tak, GUI (QT/GTK) jest i ten panel web również jest, który w zasadzie jest standardem przy klientach torrent. Niemniej jednak, ci bardziej zżyci z linux'em użytkownicy używają transmission wyłącznie przez konsolę. GUI to tylko zbędne nakładki.
  9. A na pełnowymiarowych linux'ach używałeś?
  10. Gargoyle ma webowy panel administracyjny, podobny do tego TP-LINK'owego ale oczywiście nieco bardziej rozbudowany. Mimo to, nie wszystkie rzeczy da rade skonfigurować w tym panelu. W zasadzie to nie wiem czy jest jakiś plugin do transmission ale to narzędzie to jest typowo konsolowy klient torrent'a i jak chcesz go używać to niestety musisz się nauczyć operować na konsoli.
  11. W końcu sukces, choć jeszcze sporo rzeczy do poprawy, ale już widać custom ROM'a powoli.
  12. Na OpenWRT/LEDE/linux można postawić sobie serwer RADIUS w oparciu o freeradius i się bawić. Tutaj przykłady jak ktoś się chce bawić w te klocki. przykład z OpenWRT/LEDE, i przykład z Debianem.
  13. Tutaj masz emulator panelu administracyjnego dla tego routera, to sobie zobacz czy są tam funkcje, które chcesz.
  14. Jak już zapewne wielu użytkowników tego forum wie, ja posiadam kilka smartfonów, które mają ukorzenionego Androida, tj. został na tych urządzeniach przeprowadzony proces root. Tego typu zabieg wyłącza praktycznie wszystkie (albo większość) mechanizmów obronnych naszego telefonu. Biorąc pod uwagę fakt, że cała masa użytkowników smartfonów (nie tylko Neffos'ów od TP-LINK) ukorzenia te urządzenia bez wiedzy co tak naprawdę robi, to postanowiłem napisać kilka słów odnośnie problemów, którym użytkownik ukorzenionego systemu będzie musiał stawić czoła. Przede wszystkim, muszę tutaj zaznaczyć, że samymi smartfonami, a właściwie systemem Android, interesuję się od kilku miesięcy i w zasadzie nie poznałem go jeszcze w pełni. Niemniej jednak, od czasu do czasu rozpracowuje sobie pewne rzeczy w oparciu o dwie wersje Androida: 5.1 (Lollipop) oraz 6.0 (Marshmallow). Ten wpis ma na celu zebranie wszystkich artykułów, które pokazują jak proces root wpływa na bezpieczeństwo systemu oraz, które z jego funkcji przestają działać lub tez są w znacznym stopniu upośledzone. To, że akurat ja korzystam z ukorzenionego Androida, nie znaczy, że i ty powinieneś, zwłaszcza w przypadku, gdy bezpieczeństwo danych przechowywanych w telefonie ma dla ciebie nadrzędne znaczenie. W zasadzie wszystkie z czterech modeli smartfonów Neffos dostępnych na polskim rynku, tj. C5, C5 MAX, Y5 i Y5L, można zrootować bez większego problemu. W moim przypadku, proces root bardzo ułatwia mi rozpracowanie samego systemu i sprawia, że mam wgląd w miejsca, w które standardowy użytkownik telefonu zajrzeć nie może, bo Android odmawia mu dostępu właśnie ze względów bezpieczeństwa. Dlatego też jeśli nie potrzebujesz rootować systemu w telefonie, to tego po prostu nie rób. Problemy z lokalizacją skradzionego smartfona Jednym z bardziej podstawowych mechanizmów ochronnych, które oferuje Google w Androidzie, to usługa lokalizacji smartfona na wypadek jego utraty czy kradzieży. No w przypadku zwykłego zawieruszenia się naszego telefonu raczej nic nam nie grozi ale, gdy takie urządzenie zostanie nam skradzione, to wtedy mamy bardzo poważny problem. Przede wszystkim, mając odblokowany bootloader, który jest wymagany do ukorzenienia Neffos'ów, dajemy złodziejowi narzędzie zresetowania smartfona i obejścia tym samym blokady Factory Reset Protection Lock (FRP Lock). Gdy złodziej obejdzie tę blokadę jest w stanie przywrócić system urządzenia do ustawień fabrycznych, np. w celu odsprzedania telefonu komuś trzeciemu. W takim przypadku nasz smartfon nie będzie już dłużej powiązany z konkretnym kontem Google i zlokalizowanie go przez ww. usługę będzie zwyczajnie niemożliwe. Więcej informacji na temat lokalizacji zagubionych/skradzionych smartfonów można znaleźć w osobnym wątku. Możliwość obejścia blokady ekranu Standardowo każdy z nas korzysta z blokady ekranu w swoich telefonach. Ja akurat mam opcję "Przesuń palcem" ale jakby nie patrzeć, to też blokada. Ci z was, którzy wykorzystują PIN, wzór albo hasło, mogą nieco się zawieść, w przypadku, gdy mają ukorzenionego Androida. Cały ten mechanizm blokady ekranu opiera się o ustawienia stosownej aplikacji i klucz zabezpieczający. Wszystkie te dane są przechowywane w plikach na flash'u smartfona. Jeśli teraz mamy zdjętą blokadę bootloader'a, bo chcieliśmy sobie ukorzenić system, to dostęp do tych kluczy i ustawień pozostaje niechroniony i można zresetować blokadę ekranu przez tryb recovery. Więcej informacji na temat resetowania ustawień blokady ekranu można znaleźć w osobnym wątku (ostatni nagłówek). Odszyfrowanie zawartości karty SD sformatowanej jako pamięć wewnętrzna Nowsze wersje Androidów (6.0+) są w stanie rozbudować pamięć flash w smartfonach przy wykorzystaniu Adoptable Storage. Ten mechanizm zakłada sformatowanie karty SD system plików, który daje możliwość wykorzystania uprawnień do plików w celu poprawienia bezpieczeństwa systemu i poufności danych przechowywanych na samej karcie SD. Domyślnie dane na tej karcie SD są szyfrowane i nie da rady do tych informacji uzyskać dostępu z poziomu innego urządzenia. Możemy w zasadzie korzystać z tej karty na smartfonie, gdzie została ona sformatowana jako pamięć wewnętrzna i nic poza tym. Do szyfrowania zawartości karty jest wykorzystywany losowy klucz szyfrujący, który jest tworzony w procesie formatowania karty SD. Ten klucz nie jest zabezpieczony żadnym hasłem (np. tym od blokady ekranu) i leży sobie jak gdyby nigdy nic na flash'u smartfona. Mając przeprowadzony proces root, ten klucz jest dostępny praktycznie dla każdego, przez co jakiekolwiek szyfrowanie danych na karcie SD jest tylko złudzeniem bezpieczeństwa i niepotrzebnie obciąża procesor telefonu. Więcej informacji na temat odszyfrowania zawartości karty SD sformatowanej jako pamięć można znaleźć w osobnym wątku. Inne problemy Oczywiście, te powyżej wypisane niedogodności nie są jedynymi. Prawdopodobnie jest ich jeszcze cała masa ale, jako, że mam ciągle niewielkie doświadczenie z Androidem, to jeszcze nie wszystkie rzeczy udało mi się wyłapać. Niemniej jednak, jak tylko coś ciekawego znajdę, to naturalnie opiszę i dodam stosowny nagłówek w tym wątku, tak by ta lista była możliwie rozbudowana, co może przyczyni się do większej świadomości osób korzystających z Androida i zaowocuje zastanowieniem się na tym, czy faktycznie dany użytkownik potrzebuje ukorzenionego Androida w swoim smartfonie.
  15. 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.
  16. Jest możliwość -- skonfiguruj sobie roaming na klientach. Póki co w Androidach jest problem i trzeba się posiłkować aplikacjami. Z kolei na kompach/laptopach, to już w ustawieniach systemu operacyjnego trzeba skonfigurować. Ja nie używam windowsa to ci nie powiem, gdzie są te ustawienia, które trzeba przestawić, a jeśli przez przypadek korzystasz z linux, to instrukcje są tutaj
  17. Problem z roamingiem jest i przełącza/przełączasz do drugiego AP dopiero jak sygnał całkowicie zaniknie.
  18. Niżej znajdują się linki do recenzji ciekawych aplikacji, które napotkam w drodze bawienia się swoim smartfonem spod znaku Neffos. Jeśli ktoś natknął się na inne ciekawe i użyteczne programiki, to może ich nazwy i linki dopisać w tym wątku. Jeśli będą naprawdę przyzwoite, to na pewno je przetestuje, a ich opis wrzucę na forum i podlinkuję w tym poście. Ważne jest by aplikacja była bez reklam i najlepiej OpenSource. Jeśli chodzi o ten drugi typ aplikacji, to F-Droid wyśmienicie się nadaje na rozpoczęcie poszukiwań. Aplikacje już opisane: Źródło darmowych aplikacji OpenSource: F-Droid www/source/F-droid Źródło aplikacji i modułów Xposed: XDA Labs www/source Alternatywny launcher aplikacji: Nova Launcher www/GooglePlay Oprogramowanie do aparatu/kamery: OpenCamera www/source/GooglePlay/F-droid Przeglądarka YT: NewPipe www/source/F-droid Szyfrowanie zapytań DNS: dnscrypt-proxy (root) www/source Adblock: AdAway (root) www/source/F-droid Roaming: Wifi Roaming Fix i SWIFI GooglePlay/GooglePlay VPN: OpenVPN for Android www/source/GooglePlay/F-droid Aplikacja TP-LINK do kamer: tpCamera GooglePlay Aplikacja TP-LINK do zarządzania siecią: Tether GooglePlay Aplikacja TP-LINK do routerów MiFi: tpMiFi GooglePlay Aplikacje do opisania: Skaner sieci WiFi: WiFi Analyzer www/source/GooglePlay/F-Droid Klient sieci TOR: Orbot www/source/GooglePlay/F-Droid Klient sieci jabber: Xabber www/source/GooglePlay/F-droid Taktowanie procesora: Kernel Adiutor XDA/source/GooglePlay/F-droid Weryfikacja dwuetapowa: Authenticator www/source/GooglePlay/F-droid Wykorzystanie flash/SD: DIsk Usage www/source/GooglePlay/F-droid Bateria: Amplify Battery Extender (root) XDA/www/source/GooglePlay Przeglądarka dokumentów: Document Viewer www/source/F-Droid/GooglePlay Aplikacja TPLINK do urządzeń mobilnych: KASA GooglePlay Aplikacja TPLINK do transmiterów sieciowych (powerline): tpPLC GooglePlay
  19. Trochę to dziwne. U mnie przed rozbudową stacji, ten nadajnik co był, to był strasznie zapchany. Jak ograniczali prędkość przesyłu w szczycie (godziny 18-22), to dawali lejek max 2 mbit/s ale ping był nieduży i nie skakał, no chyba, że zapychałem łącze, np. pobierałem coś, itp, wtedy potrafił polecieć na 60.000 ms.
  20. I don't know. How's that related to the rooting process?
  21. 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
  22. 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.