morfikov

Zarejestrowany
  • Zawartość

    34
  • androcoin

  • Bieżący miesiąc

    9
  • Rejestracja

  • Ostatnia wizyta

Otrzymane piwa: 13

O morfikov

  • Tytuł
    Zarejestrowany +

Kontakt

  • Jabber
    morfik@chrome.pl

Informacje

  • Model Telefonu
    TP-LINK Neffos: C5, C5 MAX, Y5 i Y5L
  • Sieć
    Red Bull Mobile
  • Płeć
    Mężczyzna

Ostatnie wizyty

140 wyświetleń profilu
  1. Od jakiegoś czasu próbuję rozwiązać bardzo dziwny problem polegający na niezbyt przyzwoitym zachowaniu się trybu recovery, który zdaje się ignorować ustawienia określone podczas kompilacji samego obrazu TWRP. Generalnie to tutaj jest drzewo urządzenia pod budowę TWRP. Zbudowany obraz działa bez problemu ale tylko gdy się go odpali przez fastboot boot recovery.img . Natomiast, gdy się ten sam obraz wrzuci na smartfona via fastboot flash recovery recovery.img , to już zaczynają się problemy i np. nie można zmienić jasności ekranu, bo ta się utrzymuje ciągle na full czy po zgaśnięciu wyświetlacza nie da rady go już włączyć. Udało mi się ustalić, że problematyczny jest parametr w linii kernela, a konkretnie rr=2 .Ten parametr nie jest widoczny w /proc/cmdline gdy się załaduje obraz recovery bezpośrednio do pamięci RAM ale jest on dodawany, gdy się odpala tryb recovery z partycji /recovery/ . Można ten parametr przepisać np. rr=0 przy konfiguracji obrazu TWRP ale żadne ustawienie nie naprawia problemu. Jedyna opcja to usunięcie tego parametru. No i w zasadzie mam kilka pytań: 1. Czy ktoś wie za co odpowiada ten parametr rr,? 2. Co może dodawać ten parametr do linijki kernela? 3. Jak usunąć ten parametr? 4. Dlaczego ten parametr jest dodawany jedynie przy ładowaniu trybu recovery z partycji /recovery/ ?
  2. Jak coś to gotowe katalogi z konfiguracją dla dwóch z moich smartfonów już przygotowałem. Kod jest na githubie: Neffos Y5 i Neffos Y5L . Nadal jest jeszcze trochę roboty by pewne opcje powłączać ale grunt, że praktycznie wszystko działa jak trza. Jak coś to tutaj jest jeszcze trochę info jak takie drzewo katalogów zbudować od podstaw.
  3. Na te Neffosy, co mam, to też niedługo będzie wsparcie, jak tylko ustalę co te urządzenia mają za hardware, bo w sumie to nie mam pojęcia (poza SoC) ale raczej da radę te informacje uzyskać, tylko do TP-LINK'a będę musiał kilka zapytań skierować ale z tym nie powinno być problemu.
  4. No ja akurat mam zamiar zrobić dla swoich telefonów custom ROM'y (moje urządzenia nie są przez nic wspierane), a jak bym poległ na generowaniu samego obrazu recovery, to raczej nici by były z tych planów. Dlatego tak czy inaczej ja te wszystkie problemy, które mam, muszę rozwiązać. Grunt, że to szyfrowanie w końcu zmęczyłem.
  5. @piskorfa @maxprzemo , ok chłopaki, udało się ten mechanizm zhakować! To chyba moje największe osiągnięcie jak do tej pory w przygodach z Androidem. W zasadzie to trzeba było przekopiować trochę plików z oryginalnego firmware tego telefonu. Część plików była w /system/vendor/ , część na wydzielonej partycji /firmware/ i parę plików z oryginalnego recovery. Wszystkie te pliki trzeba wrzucić do katalogu ze źródłami Androida pod device/tp-link/tp802a/recovery/ (dostosowując producenta i model telefonu): $ tree device/tp-link/tp802a/recovery/ device/tp-link/tp802a/recovery/ └── root ├── fstab.qcom ├── init.recovery.qcom.rc ├── prebuild_file_contexts ├── sbin │ ├── libQSEEComAPI.so │ ├── libdiag.so │ ├── libdrmfs.so │ ├── libdrmtime.so │ ├── librpmb.so │ ├── libssd.so │ └── qseecomd ├── ueventd.qcom.rc └── vendor ├── firmware │ ├── cmnlib.b00 │ ├── cmnlib.b01 │ ├── cmnlib.b02 │ ├── cmnlib.b03 │ ├── cmnlib.mdt │ └── keymaster │ ├── keymaste.b00 │ ├── keymaste.b01 │ ├── keymaste.b02 │ ├── keymaste.b03 │ └── keymaste.mdt └── lib ├── hw │ └── keystore.msm8909.so ├── libQSEEComAPI.so -> ../../sbin/libQSEEComAPI.so ├── libdiag.so -> ../../sbin/libdiag.so ├── libdrmfs.so -> ../../sbin/libdrmfs.so ├── libdrmtime.so -> ../../sbin/libdrmtime.so ├── librpmb.so -> ../../sbin/librpmb.so └── libssd.so -> ../../sbin/libssd.so 7 directories, 28 files Jak tylko poczyszczę pliki konfiguracyjne i poopisuje stosowne opcje, to wrzucę konfigurację na github'a i podlinkuję tutaj, tak by treść tych plików była widoczna. Choć muszę przyznać, że jak zbudowałem ten obraz i go załadowałem, to aż się zdziwiłem, że zadziałało, a już taki zrezygnowany byłem.
  6. W zasadzie to chyba wpadłem już na trop. W logu TWRP jest coś takiego: I:Can't probe device /dev/block/mmcblk0p29 I:Unable to mount '/data' I:Actual block device: '/dev/block/mmcblk0p29', current file system: 'ext4' get_crypt_ftr_info crypto key location: 'footer' I:Using automatic handling for /data/media emulated storage device. I:Setting up '/data' as data/media emulated storage. I:Created '/sdcard' folder. I:Backup folder set to '/data/media/TWRP/BACKUPS/Neffos_Y5' I:Settings storage is '/data/media' Updating partition details... ...done Unable to mount storage I:Unmounting main partitions... .... I:Set page: 'decrypt' I:Set page: 'trydecrypt' I:operation_start: 'Decrypt' crypt_ftr->fs_size = 25421759 Using scrypt with keymaster for cryptfs KDF Invalid hex string Failed to convert passwd from hex, using passwd instead keymaster module name is Keymaster QCOM HAL keymaster version is 3 Found keymaster0 module, using keymaster0 API. could not open keymaster device in keystore (Operation not permitted) Failed to init keymaster Signing failed kdf failed failure decrypting master key Failed to decrypt master key Tu jest jakiś keymaster i przeglądając sobie różne konfiguracje, np. taką to jest podana taka sekwencja: on init # dencryption files from device mkdir /firmware mkdir /vendor/firmware mkdir /vendor/firmware/keymaster wait /dev/block/platform/msm_sdcc.1/by-name/modem mount ext4 /dev/block/platform/msm_sdcc.1/by-name/modem /firmware symlink /firmware/image/keymaster.b00 /vendor/firmware/keymaster/keymaster.b00 symlink /firmware/image/keymaster.b01 /vendor/firmware/keymaster/keymaster.b01 symlink /firmware/image/keymaster.b02 /vendor/firmware/keymaster/keymaster.b02 symlink /firmware/image/keymaster.b03 /vendor/firmware/keymaster/keymaster.b03 symlink /firmware/image/keymaster.mdt /vendor/firmware/keymaster/keymaster.mdt symlink /firmware/image/cmnlib.b00 /vendor/firmware/cmnlib.b00 symlink /firmware/image/cmnlib.b01 /vendor/firmware/cmnlib.b01 symlink /firmware/image/cmnlib.b02 /vendor/firmware/cmnlib.b02 symlink /firmware/image/cmnlib.b03 /vendor/firmware/cmnlib.b03 symlink /firmware/image/cmnlib.mdt /vendor/firmware/cmnlib.mdt symlink /sbin/libQSEEComAPI.so /vendor/lib/libQSEEComAPI.so Ten smartfon ma partycję modem , która jest montowana jako /firmware/ z systemem plików ext4, no to sobie zajrzałem na tę partycję i te pliki keymaster.* cmnlib.* również w na tej partycji siedzą i dokładnie w tych samych ścieżkach. Niemniej jednak, póki co kompletnie nie wiem co z tym zrobić ale najwyraźniej brakuje czegoś i ten mechanizm odszyfrujący ma przez to problem.
  7. @piskorfa , powoli sprawa się wyjaśnia. Ten obraz TWRP, który mam u siebie na smartfonie to jest port z innego zbliżonego hardwarem urządzenia. Ja w zasadzie nigdy nie budowałem obrazu TWRP, bo nie wiedziałem jak, przynajmniej do teraz. Przeglądając sobie konfiguracje różnych smartfonów zacząłem kolekcjonować różne opcje. Natrafiłem min. na TW_INCLUDE_CRYPTO := true Nazwa raczej mówi sama za siebie. Po paru błędnych kompilacjach, w końcu mi obraz wyszedł i nawet działa. W prawdzie jest jeszcze daleki od doskonałości i trochę jeszcze nad nim posiedzę ale co ciekawe, teraz przy odpalaniu TWRP wyrzuca mi taki obrazek: Problem w tym, że póki co jeszcze nie udało mi się odszyfrować przez wpisanie poprawnego hasła i muszę się dowiedzieć WTF. Tak czy inaczej, jeśli obraz TWRP ma wkompilowane wparcie dla szyfrowania, to można tę partycję /data/ (nawet zaszyfrowaną) bez problemu wyczyścić: Jakiś pomysł czemu nie chce prawidłowego hasła zaakecptować przy odszyfrowaniu via TWRP?
  8. No to w sumie nic nie zrobię z tym resetowaniem do ustawień fabrycznych z poziomu TWRP na zaszyfrowanym /data/ . Tak testując sobie to formatowanie, to wychodzi na to, że to fastboot coś źle formatuje i nadpisuje tą szyfrowaną stopkę . Jak sobie sprawdziłem Factory Reset z poziomu TWRP bez szyfrowania, to w dalszym ciągu mogłem zaszyfrować telefon. dodana zawartość Dało radę obejść się bez stock'owego recovery. Trzeba było tylko zmniejszyć nieco system plików partycji /data/ z poziomu TWRP. W sumie, to nic trudnego.
  9. W sumie to działa bez problemu fastboot -w i można tak zrobić Factory Reset. dodana zawartość Czytając sobie ten wątek, dochodzę do wniosku, że mam coś nie tak z wpisem od partycji /data/ w fstab dla trybu recovery (albo z czymś co się do niego odnosi). W sumie to nie wiem jak ten proces montowania zaszyfrowanej partycji /data/ powinien wyglądać ale z tego co czytam, to klucz szyfrujący dane jest ulokowany albo na końcu partycji /data/ w 16 KiB, albo na osobnej partycji. Tak czy inaczej te dane trzeba uwzględnić w fstab, by TWRP był w stanie na tej partycji poprawnie operować. Czyli mając prawidłowy wpis, TWRP powinien wyrzucić chyba jakiś monit o hasło do odszyfrowania tej partycji, po podaniu którego partycja /data/ zostanie zamontowana już bez błędów. Wtedy proces formatowania partycji powinien przebiec bez zarzutu. Przeglądając pliki fstab dla stock'owego recovery, są tam min. takie wpisy: /dev/block/bootdevice/by-name/userdata /data ext4 nosuid,nodev,barrier=1,noauto_da_alloc,discard wait,check,encryptable=footer oraz /dev/block/bootdevice/by-name/userdata /data ext4 noatime,nosuid,nodev,barrier=1,data=ordered,noauto_da_alloc wait,check,length=-16384 No to wychodzi, że te klucz szyfrujący tę partycję jest ulokowany w stopce na partycji /data/ . W sumie ja u siebie w TWRP dałem taki wpis: /data ext4 /dev/block/bootdevice/by-name/userdata flags=display="Data";backup=1;wipeingui;wipeduringfactoryreset;length=-16384;encryptable=footer Myślałem, że może te dwie ostatnie flagi coś chrzanią ale bez znaczenia czy są one zdefiniowane obie czy tylko jedna z nich. System nie chce zamontować tej partycji /data/ , bo najwyraźniej czegoś mu brakuje jeszcze. Tutaj taka ciekawa uwaga. Jak sformatowałem sobie partycję /data/ przez fastboot i/lub przez TWRP recovery, to później miałem problem z włączeniem szyfrowania. W logu można było wyczytać taki komunikat: E Cryptfs : Bad magic for real block device /dev/block/bootdevice/by-name/userdata E Cryptfs : Orig filesystem overlaps crypto footer region. Cannot encrypt in place. Czyli system źle sformatował tę partycję i nadpisał stopkę systemem plików, przez co nie dało rady już zaszyfrować tej partycji. Jeśli się ze stock'owego recovery tę partycję wyczyściło, to już dało radę zaszyfrować. Czyli coś tutaj nie gra.
  10. Ta metoda również nie działa.
  11. W sumie to chyba wszystkie opcje sprawdzałem i nie nie działa w żaden sposób. Ten TWRP ma jakiś problem z rozpoznaniem tej zaszyfrowanej partycji i poprawnym jej opisaniem. Jak się popatrzy na rozmiar tego /data/ , to zwraca 0 bajtów i pewnie dlatego system wariuje.
  12. Ani zwykły wipe, ani też Advanced wipe nie działa. Zdziwiłbym się gdyby ten drugi zadziałał.
  13. Juto zweryfikuje te informacje o obrazie partycji /boot/ ale w sumie teraz mam jedno pytanie jeszcze. Po tym jak zaszyfrowałem ten telefon, to oczywiście musiałem zapomnieć hasła jakie zostało użyte do zabezpieczenia tego urządzenia. Bez hasła to trzeba robić Factory Reset. W TWRP recovery jest opcja resetu ustawień do fabrycznych i w zasadzie ten mechanizm działa prawidłowo ale na niezaszyfrowanym telefonie. Partycje, które TWRP czyści, to /data/ i /cache/ ale po wdrożeniu szyfrowania, TWRP ma problemy z przeprowadzeniem Factory Reset. Zwyczajnie wyrzuca, że nie można zamontować tych partycji, no i nie mam jak ten procesu przeprowadzić na zaszyfrowanym smartfonie. Musiałem sobie wgrać do pamięci telefonu stock'owy obraz recovery i z niego wyczyścić te dwie partycje. Orientujecie się może jak przeprowadzić taki reset zaszyfrowanego telefonu z poziomu TWRP recovery? Może coś w fstab trzeba dopisać? Jak coś to mam póki co taki fstab dla recovery.
  14. Ja sobie jutro wypakuje zawartość obu obrazów i porównam w meld na spokojnie różnice. Grunt, że się ruszyło.
  15. Udało się. Coś w tym obrazie /boot/ jest zmieniane i bez tego SuperSU nie działa w system-mode. Później sobie porównam i może zobaczę co tam za zmiany są wprowadzane. Zaraz sprawdzę, czy da radę zaszyfrować. dodana zawartość Udało się! Czyli jednak ten system-mode rozwiązuje ten problem.