L'impostazione "Crittografa telefono" di CyanogenMod 12 e 12.1 è stata interrotta ed è stata per un bel po '. C'è un modo per crittografare il telefono in qualche altro modo? CM può essere trasferito su un telefono con una directory crittografata / dati? Esistono altri modi per mantenere i tuoi dati sani e salvi? Il dispositivo su cui sto lavorando è un LG G3 Verizon.
Risposte:
Esistono comandi a basso (er) livello che possono essere utilizzati in una shell per crittografare la partizione dati dell'utente. Disclaimer / Avviso: le seguenti istruzioni cancelleranno i tuoi dati , assicurandoti di fare un backup se necessario.
Seguendo questi passaggi, dovresti essere in grado di cancellare la tua partizione dati e di averla successivamente crittografata (simile a un ripristino di fabbrica):
adb rootseguito da adb shell.adb logcatin un'altra shell.Immettere questo comando, digitare la password e premere Invio. Questo effettivamente imposterà la tua password. Questo comando legge una riga di input ( head -1), rimuove la nuova riga finale da Enter ( tr -d '\n') e la converte in una rappresentazione esadecimale ( hexdump ...). Se sembra spaventoso o non sei sicuro di cosa faccia questo comando, vedi sotto.
vdc cryptfs enablecrypto wipe password $(head -1 | tr -d '\n' | hexdump -ve '1/1 "%.2x"')
Il vdccomando sopra ("Volume Daemon Client") comunicato con vold(Volume Daemon) ha alcuni sottocomandi come cryptfsper la crittografia. Il enablecryptosottocomando ha due modalità: wipe(cancella /datacompletamente) e inplace(presumibilmente applicando la crittografia durante la copia dell'originale /dataall'interno del contenitore).
Quindi, sono disponibili quattro opzioni a partire da Android 5.0, una delle passwordquali accetta una singola sequenza esadecimale come chiave. Quindi se la tua password è foo, allora la rappresentazione esadecimale è 666f6f( fè 66in esadecimale, oè 6f, vedi http://www.asciitable.com/ ). Il comando per questo è:
vdc cryptfs enablecrypto wipe password 666f6f
Questo è stato testato su un Nexus 5 (nome in codice hammerhead, in esecuzione cm-12.1-20150814) che ha una partizione separata per la memorizzazione dei metadati. È importante che la partizione userdata abbia il encryptableflag impostato seguito dal percorso di una partizione o dalla stringa speciale footer. Una riga (abbreviata) dal mio /fstab.hammerheadfile:
/dev/block/platform/msm_sdcc.1/by-name/userdata / data ext4 ..., controllo, crittografabile = /dev/block/platform/msm_sdcc.1/by-name/metadata
Quando è presente la stringa speciale footer( encryptable=footer), quindi 16 KiB alla fine della partizione dati vengono utilizzati per archiviare i metadati di crittografia.
Per ulteriori letture, vedere:
Appendice: estratto di logcat dal momento in cui ho eseguito il comando di crittografia fino al termine e al riavvio (omettendo alla fine i messaggi grafici non correlati). Nota che questo Nexus 5 ha crittografia con accelerazione hardware (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
Per me, la risposta originale non ha funzionato come previsto. Sembrava crittografato correttamente, ma l'interfaccia utente è tornata molto rapidamente e l'impostazione "Crittografia" non ha mostrato che i dispositivi erano crittografati. Ho quindi applicato i comandi forniti nell'aggiornamento , ma non ha ancora funzionato. Ho quindi ridotto le dimensioni della partizione dati e crittografato correttamente. ie
mount | grep dataper trovare l'attuale dispositivo a blocchi della partizione dati. Supponiamo che lo sia /dev/block/mmcblk0p26.
umount /data per far funzionare gli ext-tools.
e2fsck -f -p /dev/block/mmcblk0p26 di non incorrere in guai per il ridimensionamento imminente.
tune2fs -l /dev/block/mmcblk0p26 per ottenere il conteggio dei blocchi. Supponiamo che lo sia 3057395.
resize2fs /dev/block/mmcblk0p26 3057375, cioè sottrae un importo sufficiente come 20 dal conteggio dei blocchi originale.
e2fsck -f -p /dev/block/mmcblk0p26 ho trovato un inode inserito erroneamente per me.
Avevo anche bisogno di montare la /systempartizione per ottenere resize2fs. Sul mio sistema, quel binario era collegato a una versione a 64 bit di libc, ma il TWRP che usavo non sembrava fornirlo. Quindi avevo bisogno di aggiungere un prefisso ai comandi env LD_LIBRARY_PATH=/system/lib64.
A partire da CM12.1 2015-10-15 la risposta di Lekensteyn non funziona più.
Apparentemente il file mkfs.f2fs necessario per creare il file system è stato spostato da /system/bin/a/sbin/
Inoltre dobbiamo fare i conti con SELINUX. Ciò significa che dobbiamo fare diversi passaggi aggiuntivi:
radice adb
shell adb
setenforce 0
mount -oremount, rw / system
ln -s /sbin/mkfs.f2fs /system/bin/mkfs.f2fs
vdc cryptfs abilitato per cancellare la password 666f6f
Un altro aggiornamento - CM13 build del 9 gennaio 2016 , utilizzando Nubia Z7 Max, telefono NX505J
Questo comando ( ln -s /sbin/mkfs.f2fs /system/bin/mkfs.f2fs) non è più necessario poiché il file vive di nuovo qui. Non è necessario creare un collegamento simbolico.
Questo comando non deve più essere in esadecimale e se si inserisce hex il PW sarà esadecimale.
cryptfs enablecrypto wipe password 666f6f- Questo ha letteralmente creato una password per me 666f6fnofoo
Sto ancora cercando questo problema perché ho superato i blocchi extra necessari per i metadati. Ora ho bisogno di superare il fatto che la GUI e i comandi manuali per crittografare entrambi comportano una crittografia che è praticabile solo attraverso un ciclo di avvio. Riporterò una risposta quando avrò una crittografia riuscita.
In questo momento crittografo e funziona bene e avvio la prima volta e dice che il telefono è crittografato. Utilizzando TWRP posso confermare / i dati sono crittografati ma le password HEX e ASCI che provo in TWRP non funzionano entrambe. Al successivo riavvio il sistema operativo Android non può avviare completamente CM13. Conferma che ho la password di crittografia corretta e quindi ottengo solo 1 avvio crittografato. Dopo il primo avvio crittografato con esito positivo, si blocca successivamente nella fase di animazione del ciclo di avvio. Le migliori pratiche di sicurezza ora raccomandano la crittografia del telefono AES256.
Avere una Moto X 2013 con Cyanogenmod 12.1 non è stato in grado di farlo crittografare. Finalmente sono riuscito con questi passaggi:
sue confermare l'accesso come rootsetenforce 0Sono arrivato a questa soluzione combinando la risposta di Art e questo thread del forum .
Dopo 6 ore di dolore mentale e sudore potrei essere incappato in una soluzione che ha funzionato per me. Ed è stato anche un incidente. L'ho fatto per il Samsung S4 Mini con CyanogenMod 13.0 e Android 6.0.1. Il fattore chiave qui è che l'ho avviato da un telefono pulito (firmware aggiornato e non rootato), perché quando il telefono era precedentemente rootato, allora il telefono non voleva affatto funzionare.
Ho usato la soluzione di Firelord e Lekensteyn al problema, ma sono riuscito a dimenticare una riga dai comandi.
Ecco come l'ho fatto:
Ho attivato il debug Android e l' accesso root ad ADB solo nelle Opzioni sviluppatore .
Nel prompt dei comandi di ADB ho usato il comando adb roote adb shell. Successivamente ho aperto un altro prompt dei comandi ADB e ho usato il adb logcatcomando.
Nella prima shell ADB, sono andato avanti setenforce 0e dopo vdc cryptfs enablecrypto wipe password YOUR-PASSWORD.
AVVISO IMPORTANTE: il comando password potrebbe variare dalla versione di Android in uso. Se si utilizza Android 5.X , è necessario utilizzare il sistema esadecimale (nella riga Chr è il simbolo nella password il valore esadecimale è nella riga Hx). Se stai utilizzando Android 6.X , YOUR-PASSWORD sarà la password che cosa hai inserito lì.
Come noterai, ho dimenticato di usare il mount -oremount,rw /systemcomando. Dopodiché, lo schermo diventerà nero. Quando ho visto che la shell ADB con il registro si è fermata e terminata, ho riavviato il telefono. Ma come per tutti, il problema è che CyanogenMod non si carica. E sono riuscito a risolverlo abbastanza facilmente:
Ecco qua, dovrebbe funzionare. All'inizio, quando viene installato il telefono, lascialo agire per un minuto. Potrebbe esserci un piccolo arresto anomalo per l'Installazione guidata se lo avvii troppo velocemente, ma si riavvierà automaticamente quando si arresta in modo anomalo.
Nella mia piccolissima conoscenza di come funzionano CyanogenMod e Android Encryption, penso che durante il formato elimini alcuni importanti file Cyanogen o Android, ciò che impedisce l'avvio.
La crittografia non ha funzionato sul mio telefono (SGS5; CM13, TWRP 3.0.2-2) - Ho sempre uno schermo nero.
Non volevo usare i comandi di shell, quindi ho trovato un altro modo:
Avevo installato SuperSU, l'ho disinstallato nell'app e quindi ho eseguito il flashing del SU-Remover .
Successivamente, sono stato in grado di utilizzare la crittografia dal menu.
Avvertimento: