Il existe des commandes de bas (er) niveau qui peuvent être utilisées dans un shell pour crypter votre partition de données utilisateur. Avertissement / Avertissement: les instructions suivantes effaceront vos données , assurez-vous de faire une sauvegarde si nécessaire.
En suivant ces étapes, vous devriez pouvoir effacer votre partition de données et la chiffrer ensuite (comme pour une réinitialisation d'usine):
- Démarrez votre téléphone normalement (soit la récupération ne fonctionne plus, soit j'ai rencontré un problème différent).
- Assurez-vous que le mode de débogage USB (adb) et l' accès root pour ADB sont activés.
- Entrez un shell racine avec
adb root
suivi de adb shell
.
- Facultatif: surveillez les journaux en appelant
adb logcat
dans un autre shell.
Entrez cette commande, saisissez votre mot de passe et appuyez sur Entrée. Cela définira en fait votre mot de passe. Cette commande lit une ligne d'entrée ( head -1
), supprime la nouvelle ligne de fin de Enter ( tr -d '\n'
) et la convertit en une représentation hexadécimale ( hexdump ...
). Si cela semble effrayant ou si vous n'êtes pas sûr de ce que fait cette commande, voir ci-dessous.
vdc cryptfs enablecrypto wipe password $(head -1 | tr -d '\n' | hexdump -ve '1/1 "%.2x"')
- Si tout se passe bien, votre appareil définira les clés et redémarrera pour terminer le cryptage.
La vdc
commande ci-dessus ("Volume Daemon Client") communiquée avec vold
(Volume Daemon) a quelques sous-commandes comme cryptfs
pour le chiffrement. La enablecrypto
sous-commande a deux modes: wipe
(effacer /data
complètement) et inplace
(soi-disant appliquer le cryptage tout en copiant votre original /data
à l'intérieur du conteneur).
Ensuite, quatre options sont disponibles à partir d'Android 5.0, l'une d'elles est celle password
qui accepte une seule séquence hexadécimale comme clé. Ainsi, si votre mot de passe est foo
, alors la représentation hexadécimale est 666f6f
( f
est 66
en hexadécimal, o
est 6f
, voir http://www.asciitable.com/ ). La commande pour cela est:
vdc cryptfs enablecrypto wipe password 666f6f
Cela a été testé sur un Nexus 5 (nom de code hammerhead, exécutant cm-12.1-20150814) qui a une partition séparée pour stocker les métadonnées. Il est important que la partition userdata ait l' encryptable
indicateur défini suivi du chemin d'accès à une partition ou de la chaîne spéciale footer
. Une ligne (abrégée) de mon /fstab.hammerhead
fichier:
/dev/block/platform/msm_sdcc.1/by-name/userdata / data ext4 ..., check, encryptable = /dev/block/platform/msm_sdcc.1/by-name/metadata
Lorsque la chaîne spéciale footer
( encryptable=footer
) est présente, 16 Ko à la fin de la partition de données sont utilisés pour stocker les métadonnées de chiffrement.
Pour plus de lecture, voir:
Annexe: extrait de logcat à partir du moment où j'ai exécuté la commande de chiffrement jusqu'à ce qu'elle se termine et redémarre (en omettant les messages graphiques non liés à la fin). Notez que ce Nexus 5 dispose d'une cryptographie accélérée par le matériel (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
Pour moi, la réponse originale n'a pas fonctionné comme prévu. Il semblait avoir été chiffré avec succès, mais l'interface utilisateur est revenue très rapidement et le paramètre "Chiffrement" n'a pas montré que les appareils étaient chiffrés. J'ai ensuite appliqué les commandes données dans la mise à jour , mais cela n'a toujours pas fonctionné. J'ai ensuite réduit la taille de la partition de données et elle a été chiffrée avec succès. C'est à dire
mount | grep data
pour trouver le périphérique de bloc réel de la partition de données. Supposons que ce soit le cas/dev/block/mmcblk0p26
.umount /data
pour que les outils ext fonctionnent.e2fsck -f -p /dev/block/mmcblk0p26
pour ne pas rencontrer d'ennuis lors du prochain redimensionnement.tune2fs -l /dev/block/mmcblk0p26
pour obtenir le nombre de blocs. Supposons que ce soit le cas3057395
.resize2fs /dev/block/mmcblk0p26 3057375
, c'est-à-dire soustraire une quantité suffisante comme 20 du nombre de blocs d'origine.e2fsck -f -p /dev/block/mmcblk0p26
trouvé un inode mal placé pour moi.J'avais également besoin de monter la
/system
partition pour pouvoir me la procurerresize2fs
. Sur mon système, ce binaire était lié à une version 64 bits de libc, mais le TWRP que j'ai utilisé ne semblait pas le fournir. J'ai donc dû préfixer les commandes avecenv LD_LIBRARY_PATH=/system/lib64
.la source
Depuis le CM12.1 2015-10-15, la réponse de Lekensteyn ne fonctionne plus.
Apparemment, le fichier mkfs.f2fs nécessaire pour créer le système de fichiers a été déplacé de
/system/bin/
vers/sbin/
Nous devons également faire face à SELINUX. Cela signifie que nous devons effectuer plusieurs étapes supplémentaires:
la source
Une autre mise à jour - version CM13 du 9 janvier 2016 , utilisant le téléphone Nubia Z7 Max, NX505J
Cette commande (
ln -s /sbin/mkfs.f2fs /system/bin/mkfs.f2fs
) n'est plus nécessaire car le fichier vit à nouveau ici. Il n'est pas nécessaire de créer un lien symbolique.Cette commande n'a plus besoin d'être en HEX et si vous entrez hex, votre PW sera hex.
cryptfs enablecrypto wipe password 666f6f
- Cela m'a littéralement créé un mot de passe de666f6f
nonfoo
Je fais toujours des recherches sur ce problème car j'ai dépassé les blocs supplémentaires nécessaires pour les métadonnées. J'ai maintenant besoin de dépasser le fait que l'interface graphique et les commandes manuelles pour crypter entraînent toutes les deux un cryptage qui n'est viable qu'à travers un cycle de démarrage. Je ferai rapport lorsque j'aurai réussi le chiffrement.
En ce moment, je crypte et cela fonctionne bien et je démarre la première fois et il dit que le téléphone est crypté. En utilisant TWRP, je peux confirmer que les données sont cryptées, mais les mots de passe HEX et ASCI que j'essaie dans TWRP ne fonctionnent pas. Au prochain redémarrage, le système d'exploitation Android ne peut pas démarrer complètement CM13. Il confirme que j'ai le bon mot de passe de cryptage et que je ne reçois qu'un seul démarrage crypté. Après le premier démarrage chiffré réussi, il se verrouille ensuite sur l'étape d'animation du cycle de démarrage. Les meilleures pratiques de sécurité recommandent désormais le cryptage du téléphone AES256.
la source
Ayant un Moto X 2013 exécutant Cyanogenmod 12.1, je n'ai pas non plus pu le chiffrer. Enfin, j'ai réussi avec ces étapes:
su
et confirmez l'accès rootsetenforce 0
Je suis arrivé à cette solution en combinant la réponse d'Art et ce fil de discussion .
la source
Après 6 heures de douleur mentale et de sueur, j'aurais peut-être trouvé une solution qui a fonctionné pour moi. Et c'était aussi un accident. J'ai fait cela pour le Samsung S4 Mini avec CyanogenMod 13.0 et Android 6.0.1. Le facteur clé important ici est que je l'ai démarré à partir d'un téléphone propre (micrologiciel frais et non rooté), car lorsque le téléphone était précédemment enraciné, le téléphone ne voulait pas du tout fonctionner.
J'ai utilisé la solution de Firelord et Lekensteyn au problème, mais j'ai réussi à oublier une ligne des commandes.
Voici comment je l'ai fait:
J'ai activé le débogage Android et l' accès root à ADB uniquement dans les options du développeur .
Dans l'invite de commandes ADB, j'ai utilisé la commande
adb root
etadb shell
. Après cela, j'ai ouvert une autre invite de commande ADB et utilisé laadb logcat
commande.Dans le premier obus ADB, j'ai avancé avec
setenforce 0
et aprèsvdc cryptfs enablecrypto wipe password YOUR-PASSWORD
.AVIS IMPORTANT: La commande de mot de passe peut varier de la version Android que vous utilisez. Si vous utilisez Android 5.X , vous devez utiliser le système hexadécimal (dans la ligne Chr est le symbole dans votre mot de passe la valeur hexadécimale est sur la ligne Hx). Si vous utilisez Android 6.X , alors VOTRE MOT DE PASSE sera le mot de passe que vous y avez entré.
Comme vous l'avez remarqué, j'ai oublié d'utiliser la
mount -oremount,rw /system
commande. Après cela, l'écran deviendra noir. Quand j'ai vu que le shell ADB avec le journal s'est arrêté et terminé, j'ai redémarré le téléphone. Mais comme pour tout le monde, le problème est que CyanogenMod ne se charge pas. Et j'ai réussi à le réparer assez facilement:Voilà, ça devrait marcher. Au début, lorsque le téléphone est configuré, laissez-le reposer une minute. Il peut y avoir un petit plantage pour l'assistant de configuration si vous le précipitez trop rapidement, mais il redémarrera automatiquement lorsqu'il se bloque.
Dans ma très petite connaissance du fonctionnement du CyanogenMod et du cryptage Android, je pense qu'au cours du format, il supprime certains fichiers Cyanogen ou Android importants, ce qui l'empêche de démarrer.
la source
Le cryptage n'a pas fonctionné sur mon téléphone (SGS5; CM13, TWRP 3.0.2-2) - J'ai toujours un écran noir.
Je ne voulais pas utiliser de commandes shell, j'ai donc trouvé une autre façon:
J'ai installé SuperSU, je l'ai désinstallé dans l'application, puis j'ai flashé le SU-Remover .
Après cela, j'ai pu utiliser le cryptage à partir du menu.
Attention:
la source