Jak szyfrujesz swoje urządzenie z CyanogenMod 12.1?

CyanogenMod 12 i 12.1 Ustawienie „Szyfruj telefon” jest zepsute i trwa już od dłuższego czasu. Czy istnieje jakiś sposób szyfrowania telefonu w inny sposób? Czy CM można załadować bocznie na telefon z zaszyfrowanym katalogiem / danymi? Czy istnieją inne sposoby na zapewnienie bezpieczeństwa i ochrony danych? Urządzeniem, na którym pracuję, jest Verizon LG G3.

Istnieją komendy niskiego poziomu (er), których można użyć w powłoce do zaszyfrowania partycji danych użytkownika. Uwaga / ostrzeżenie: poniższe instrukcje wyczyszczą Twoje dane , w razie potrzeby wykonaj kopię zapasową.

Po wykonaniu tych kroków powinieneś być w stanie wyczyścić partycję danych, a następnie zaszyfrować ją (podobnie jak w przypadku przywracania ustawień fabrycznych):

1. Uruchom telefon normalnie (albo odzyskiwanie już nie działa, albo napotkałem inny problem).
2. Upewnij się, że tryb debugowania USB (adb) i dostęp do rootowania dla ADB jest włączony.
3. Wpisz powłokę roota, a adb rootnastępnie adb shell.
4. Opcjonalnie: oglądaj dzienniki, wywołując adb logcatinną powłokę.

5. Wpisz to polecenie, wpisz hasło i naciśnij Enter. To faktycznie ustawi twoje hasło. To polecenie odczytuje jeden wiersz input ( head -1), usuwa końcowy tr -d '\n'znak nowej linii z Enter ( ) i przekształca go w reprezentację szesnastkową ( hexdump ...). Jeśli wygląda to przerażająco lub nie masz pewności, co robi to polecenie, zobacz poniżej.

   vdc cryptfs enablecrypto wipe password $(head -1 | tr -d '\n' | hexdump -ve '1/1 "%.2x"')
   

6. Jeśli wszystko pójdzie dobrze, urządzenie ustawi klucze i uruchomi się ponownie, aby dokończyć szyfrowanie.

Powyższe vdcpolecenie („Volume Daemon Client”) komunikowane z vold(Volume Daemon) ma pewne podkomendy, takie jak cryptfsszyfrowanie. enablecryptoKomenda ma dwa tryby: wipe(wyczyść /datacałkowicie) i inplace(podobno stosując szyfrowanie podczas kopiowania oryginał /datawewnątrz pojemnika).

Następnie dostępne są cztery opcje, począwszy od Androida 5.0, jedna z nich passwordakceptuje pojedynczą sekwencję szesnastkową jako klucz. Zatem jeśli twoje hasło to foo, to reprezentacja szesnastkowa to 666f6f( fjest 66w postaci szesnastkowej, oto 6fpatrz http://www.asciitable.com/ ). Polecenie to brzmi:

vdc cryptfs enablecrypto wipe password 666f6f

Zostało to przetestowane na Nexusie 5 (nazwa kodowa hammerhead, działający cm-12.1-20150814), który ma osobną partycję do przechowywania metadanych. Jest to ważne , że partycja userdata ma encryptableustawioną flagę następującą po nich ścieżkę do partycji lub specjalnego łańcucha footer. Skrócona linia z mojego /fstab.hammerheadpliku:

/dev/block/platform/msm_sdcc.1/by-name/userdata / data ext4 ..., sprawdź, szyfrowalne = /dev/block/platform/msm_sdcc.1/by-name/metadata

Gdy występuje specjalny ciąg footer( encryptable=footer), do przechowywania metadanych szyfrowania służy 16 KiB na końcu partycji danych.

Więcej informacji można znaleźć w:

• https://source.android.com/devices/tech/security/encryption/

Dodatek: fragment logcat od momentu wykonania polecenia szyfrowania do momentu jego zakończenia i ponownego uruchomienia (pomijając niepowiązane komunikaty graficzne na końcu). Pamiętaj, że ten Nexus 5 ma akcelerację sprzętową szyfrowania (QSEECom).

--------- beginning of main
08-16 12:57:15.459 W/DrmManagerClientImpl(Native)( 2108): DrmManager server died!
08-16 12:57:15.459 I/ServiceManager(  184): service 'drm.drmManager' died
08-16 12:57:15.467 D/Cryptfs (  186): Just asked init to shut down class main
08-16 12:57:15.470 D/Cryptfs (  186): unmounting /mnt/shell/emulated succeeded
08-16 12:57:15.599 I/ServiceManager(  184): service 'media.audio_flinger' died
08-16 12:57:15.599 I/ServiceManager(  184): service 'media.player' died
08-16 12:57:15.599 I/ServiceManager(  184): service 'media.camera' died
...
08-16 12:57:16.695 D/Cryptfs (  186): unmounting /data succeeded
08-16 12:57:16.695 D/QSEECOMAPI: (  186): QSEECom_get_handle sb_length = 0x2000
08-16 12:57:16.696 D/QSEECOMAPI: (  186): App is already loaded QSEE and app id = 2
08-16 12:57:16.697 I/Cryptfs (  186): keymaster version is 3
08-16 12:57:16.697 D/QSEECOMAPI: (  186): QSEECom_dealloc_memory 
08-16 12:57:16.697 D/QSEECOMAPI: (  186): QSEECom_shutdown_app, app_id = 2
08-16 12:57:16.697 D/QSEECOMAPI: (  186): QSEECom_get_handle sb_length = 0x2000
08-16 12:57:16.697 D/QSEECOMAPI: (  186): App is already loaded QSEE and app id = 2
08-16 12:57:18.058 D/QSEECOMAPI: (  186): QSEECom_dealloc_memory 
08-16 12:57:18.058 D/QSEECOMAPI: (  186): QSEECom_shutdown_app, app_id = 2
08-16 12:57:18.058 I/Cryptfs (  186): Using scrypt with keymaster for cryptfs KDF
08-16 12:57:18.208 D/BootAnimation( 2683): Use save memory method, maybe small fps in actual.
08-16 12:57:18.208 E/QCOM PowerHAL( 2683): Failed to acquire lock.
08-16 12:57:18.691 D/QSEECOMAPI: (  186): QSEECom_get_handle sb_length = 0x2000
08-16 12:57:18.691 D/QSEECOMAPI: (  186): App is already loaded QSEE and app id = 2
08-16 12:57:18.692 I/Cryptfs (  186): Signing safely-padded object
08-16 12:57:18.797 D/QSEECOMAPI: (  186): QSEECom_dealloc_memory 
08-16 12:57:18.797 D/QSEECOMAPI: (  186): QSEECom_shutdown_app, app_id = 2
08-16 12:57:20.056 I/Cryptfs (  186): Using scrypt with keymaster for cryptfs KDF
08-16 12:57:20.690 D/QSEECOMAPI: (  186): QSEECom_get_handle sb_length = 0x2000
08-16 12:57:20.691 D/QSEECOMAPI: (  186): App is already loaded QSEE and app id = 2
08-16 12:57:20.691 I/Cryptfs (  186): Signing safely-padded object
08-16 12:57:20.796 D/QSEECOMAPI: (  186): QSEECom_dealloc_memory 
08-16 12:57:20.796 D/QSEECOMAPI: (  186): QSEECom_shutdown_app, app_id = 2
08-16 12:57:21.429 I/Cryptfs (  186): Enabling support for allow_discards in dmcrypt.
08-16 12:57:21.429 I/Cryptfs (  186): load_crypto_mapping_table: target_type = crypt
08-16 12:57:21.429 I/Cryptfs (  186): load_crypto_mapping_table: real_blk_name = /dev/block/platform/msm_sdcc.1/by-name/userdata, extra_params = 1 allow_discards
08-16 12:57:21.431 I/Cryptfs (  186): Making empty filesystem with command /system/bin/make_ext4fs -a /data -l 13725837312 /dev/block/dm-0
08-16 12:57:21.447 I/make_ext4fs(  186): SELinux: Loaded file_contexts from /file_contexts
08-16 12:57:21.447 I/make_ext4fs(  186): Creating filesystem with parameters:
08-16 12:57:21.447 I/make_ext4fs(  186):     Size: 13725835264
08-16 12:57:21.448 I/make_ext4fs(  186):     Block size: 4096
08-16 12:57:21.448 I/make_ext4fs(  186):     Blocks per group: 32768
08-16 12:57:21.448 I/make_ext4fs(  186):     Inodes per group: 8144
08-16 12:57:21.448 I/make_ext4fs(  186):     Inode size: 256
08-16 12:57:21.448 I/make_ext4fs(  186):     Journal blocks: 32768
08-16 12:57:21.449 I/make_ext4fs(  186):     Label: 
08-16 12:57:21.449 I/make_ext4fs(  186):     Transparent compression: none
08-16 12:57:21.449 I/make_ext4fs(  186):     Blocks: 3351034
08-16 12:57:21.449 I/make_ext4fs(  186):     Block groups: 103
08-16 12:57:21.459 I/make_ext4fs(  186):     Reserved block group size: 823
08-16 12:57:21.465 I/make_ext4fs(  186): Created filesystem with 11/838832 inodes and 93654/3351034 blocks
08-16 12:57:21.465 I/make_ext4fs(  186):     Total files: 0
08-16 12:57:21.465 I/make_ext4fs(  186):     Total bytes: 0
08-16 12:57:42.926 D/Cryptfs (  186): Successfully created filesystem on /dev/block/dm-0

Dla mnie oryginalna odpowiedź nie działała zgodnie z oczekiwaniami. Wyglądało na to, że zostało pomyślnie zaszyfrowane, ale interfejs użytkownika wrócił bardzo szybko, a ustawienie „Szyfrowanie” nie pokazało, że urządzenia zostały zaszyfrowane. Następnie zastosowałem polecenia podane w aktualizacji , ale nadal nie działało. Następnie zmniejszyłem rozmiar partycji danych i została ona zaszyfrowana pomyślnie. To znaczy

mount | grep dataznaleźć rzeczywiste urządzenie blokujące partycję danych. Załóżmy, że tak /dev/block/mmcblk0p26.

umount /data do działania narzędzi zewnętrznych.

e2fsck -f -p /dev/block/mmcblk0p26 aby nie wpaść w kłopoty podczas nadchodzącej zmiany rozmiaru.

tune2fs -l /dev/block/mmcblk0p26 aby uzyskać liczbę bloków. Załóżmy, że tak 3057395.

resize2fs /dev/block/mmcblk0p26 3057375, tj. odejmij wystarczającą ilość, na przykład 20, od pierwotnej liczby bloków.

e2fsck -f -p /dev/block/mmcblk0p26 znalazłem dla mnie nieprawidłowo umieszczony i-węzeł.

Musiałem także zamontować /systempartycję, żeby się dostać resize2fs. W moim systemie ten plik binarny był połączony z 64-bitową wersją libc, ale użyty TWRP, który mnie wykorzystał, nie zapewniał tego. Musiałem więc poprzedzić komendę env LD_LIBRARY_PATH=/system/lib64.

Począwszy od CM12.1 2015-10-15 odpowiedź przez Lekensteyn już nie działa.

Widocznie mkfs.f2fs które jest potrzebne do stworzenia systemu plików, został przeniesiony z /system/bin/do/sbin/

Musimy także walczyć z SELINUX. Oznacza to, że musimy wykonać kilka dodatkowych kroków:

1. root adb

2. powłoka adb

3. setenforce 0

4. mount -oremount, rw / system

5. ln -s /sbin/mkfs.f2fs /system/bin/mkfs.f2fs

6. vdc cryptfs enablecrypto wyczyść hasło 666f6f

Kolejna aktualizacja - kompilacja CM13 z 9 stycznia 2016 r. , Przy użyciu telefonu Nubia Z7 Max, NX505J

To polecenie ( ln -s /sbin/mkfs.f2fs /system/bin/mkfs.f2fs) nie jest już potrzebne, ponieważ plik ponownie znajduje się tutaj. Nie ma potrzeby tworzenia dowiązania symbolicznego.

To polecenie nie musi już być w HEX, a jeśli wprowadzisz hex, PW będzie hex.
cryptfs enablecrypto wipe password 666f6f- To dosłownie stworzyło dla mnie hasło 666f6fniefoo

Nadal badam ten problem, ponieważ przekroczyłem dodatkowe bloki potrzebne do metadanych. Teraz muszę sobie poradzić z faktem, że GUI i ręczne polecenia szyfrowania powodują, że szyfrowanie jest wykonalne tylko przez jeden cykl rozruchowy. Prześlę raport, gdy uda mi się pomyślnie zaszyfrować.

W tej chwili szyfruję i działa dobrze, a ja uruchamiam się za pierwszym razem i mówi, że telefon jest szyfrowany. Za pomocą TWRP mogę potwierdzić / dane są szyfrowane, ale hasła HEX i ASCI, które próbuję w TWRP, nie działają. Przy następnym uruchomieniu system operacyjny Android nie może w pełni uruchomić CM13. Potwierdza, że ​​mam prawidłowe hasło szyfrujące, a następnie otrzymuję tylko 1 zaszyfrowany rozruch. Po pierwszym udanym zaszyfrowanym uruchomieniu blokuje się na etapie animacji cyklu rozruchu. Najlepsze praktyki bezpieczeństwa zalecają teraz szyfrowanie telefonu AES256.

Mając Moto X 2013 z Cyanogenmod 12.1, również nie byłem w stanie go zaszyfrować. Wreszcie udało mi się wykonać następujące kroki:

1. Włącz root w Ustawieniach programisty na telefonie i otwórz powłokę (aplikację Terminal można również włączyć w Ustawieniach programisty)
2. Wprowadź sui potwierdź dostęp do konta root
3. Wchodzić setenforce 0
4. Teraz otwórz Ustawienia , przejdź do Bezpieczeństwo i wybierz Szyfruj telefon . Android uruchomi się ponownie i zacznie szyfrować telefon.

Doszedłem do tego rozwiązania, łącząc odpowiedź Art i ten wątek na forum .

Po 6 godzinach bólu psychicznego i potu mogłem natknąć się na rozwiązanie, które działało dla mnie. I to był także wypadek. Zrobiłem to dla Samsunga S4 Mini z CyanogenMod 13.0 i Android 6.0.1. Ważnym czynnikiem tutaj jest to, że zacząłem od czystego telefonu (świeżego oprogramowania układowego i bez rootowania), ponieważ kiedy telefon był wcześniej zrootowany, telefon wcale nie chciał działać.

Użyłem rozwiązania Firelorda i Lekensteyn, ale udało mi się zapomnieć o jednej linii z poleceń.

Oto jak to zrobiłem:

1. Włączyłem debugowanie Androida i dostęp root do ADB tylko w Opcjach programisty .

2. W wierszu polecenia ADB użyłem polecenia adb rooti adb shell. Następnie otworzyłem kolejny wiersz polecenia ADB i użyłem adb logcatpolecenia.

3. W pierwszej powłoce ADB poszedłem naprzód setenforce 0i potem vdc cryptfs enablecrypto wipe password YOUR-PASSWORD.

WAŻNA INFORMACJA: Polecenie hasła może różnić się od używanej wersji Androida. Jeśli używasz Androida 5.X , musisz użyć systemu szesnastkowego (w linii Chr jest symbolem w haśle wartość szesnastkowa znajduje się w linii Hx). Jeśli używasz Androida 6.X , HASŁO będzie hasłem, które tam wprowadziłeś.

Jak zauważyłeś, zapomniałem użyć mount -oremount,rw /systempolecenia. Po tym ja ekran stanie się czarny. Kiedy zobaczyłem, że powłoka ADB z logiem zatrzymała się i zakończyła, ponownie uruchomiłem telefon. Ale dla wszystkich problemem jest to, że CyanogenMod się nie ładuje. I udało mi się to dość łatwo naprawić:

1. Przytrzymaj Vol Up & Home & Power w dół, aż TWRP się uruchomi. Poprosi Cię o hasło do szyfrowania.
2. Wykonaj część instalacyjną CyanogenMod z dodatkowymi Google Apps (druga część przewodnika).
3. Po zakończeniu ponownie uruchom urządzenie. Kiedy się uruchomi, potrwa to chwilę. Najpierw uruchomi telefon, następnie poprosi o hasło szyfrujące, a następnie zajmie trochę czasu, zanim się uruchomi.

Proszę bardzo, powinno działać. Na początku, gdy pojawi się konfiguracja telefonu, pozwól mu na chwilę. Może wystąpić drobna awaria Kreatora instalacji, jeśli pospieszycie go zbyt szybko, ale automatycznie uruchomi się ponownie po awarii.

Z mojej bardzo małej wiedzy na temat działania CyanogenMod i szyfrowania Androida, myślę, że podczas formatu usuwa niektóre ważne pliki Cyanogen lub Android, co powstrzymuje go przed uruchomieniem.

Szyfrowanie nie działało na moim telefonie (SGS5; CM13, TWRP 3.0.2-2) - zawsze mam czarny ekran.

Nie chciałem używać poleceń powłoki, więc znalazłem inny sposób:

Miałem zainstalowany SuperSU, odinstalowałem go w aplikacji, a następnie sflashowałem SU-Remover .

Potem mogłem użyć szyfrowania z menu.

Ostrzeżenie:

• Szyfrowanie usunęło wszystkie moje dane i aplikacje (w tym pliki na wewnętrznej karcie SD), więc najpierw wykonaj kopię zapasową !
• Po szyfrowaniu pozostało mi tylko 2 GB wewnętrznej przestrzeni (zwykle 11 GB) - musiałem wykonać pełne czyszczenie (również usuwając sam Cyanogenmod), ponownie zainstalować Cyanogenmod i kolejną próbę szyfrowania, aby odzyskać moją przestrzeń.
• Musisz także ponownie aktywować root, użyłem do tego BETA-SuperSU-v2.68-20160228150503 (flash z twrp).