5 votes

Comment faire une réinitialisation d'usine complète, sans que personne ne puisse récupérer mes données ?

J'aurai quelques téléphones Android que je devrai laisser partir.

Je voudrais faire un nettoyage complet des données, sans que personne ne puisse les récupérer, et faire une réinitialisation d'usine.

J'ai lu à propos de la Méthode Schneier le cryptage de l'appareil avant une réinitialisation d'usine, les deux, etc.

Comme je ne suis pas un gourou d'Android/adb, j'aimerais savoir si certains d'entre vous auraient une idée sur la façon d'y parvenir avec certitude.

Je sais que "certitude" est un grand mot quand il s'agit d'effacer correctement des données sur une mémoire flash, mais quand même.

J'ai trouvé des réponses ici et ailleurs, disant qu'il suffit de crypter et de faire une réinitialisation d'usine sur votre appareil Android, mais je n'ai pas pu trouver de source fiable.

Juste quelques informations qui pourraient être utiles :

  • J'utilise Linux comme système d'exploitation et, par conséquent, je ne cherche pas de solution basée sur Windows.
  • Mes appareils sont non rootés et (presque) identiques (Samsung A510F + 1 A510FD)

0 votes

Cet appareil est crypté par défaut. Pour éviter le verrouillage FRP, activez le déverrouillage OEM dans les paramètres développeurs (s'il existe), puis procédez à une réinitialisation d'usine normale.

0 votes

@alecxs Je pourrais simplement supprimer mon compte Google avant de procéder à la réinitialisation d'usine afin d'éviter le verrouillage FRP, ou est-ce que j'ai raté quelque chose ?

0 votes

Oui, la suppression du compte Google est également possible

10voto

Irfan Latif Points 16863

COMMENT RÉCUPÉRER LES DONNÉES SUPPRIMÉES ?

La (dé)suppression des données dépend fortement de la manière dont un support de stockage ( HDD , SSD , eMMC etc.), système de fichiers ( NTFS , FAT32 , ext4 etc.) et l'OS enregistre et supprime des fichiers.

  • File carving / signature search / content-aware recovery identifie les valeurs de signatures standard dans les en-têtes des fichiers supprimés (en tant que file et les programmes antivirus le font pour identifier les virus connus qui se cachent dans les fichiers), par exemple les fichiers JPEG commencent par 0xffd8 et se terminent par 0xffd9 . Les données entre les blocs sont supposées être le fichier (en considérant que le fichier est contigu ; pas de fragmentation). D'autres vérifications peuvent également être effectuées sur l'en-tête, comme une somme de contrôle, la longueur du fichier, la date et l'heure, etc. Mais tous les types de fichiers n'ont pas une signature d'en-tête/de pied de page standard, il est donc difficile de déterminer où commence/se termine le fichier. Les métadonnées (y compris les noms de fichiers) ne sont pas récupérées avec cette méthode.

    Cette approche fonctionne pour les fichiers, systèmes de fichiers ou partitions supprimés. Photorec , scalpel , foremost et l'application populaire Android DiskDigger (en mode "creuser plus profondément") travailler sur cette approche.

  • Récupérer autant que possible les informations sur les blocs de données supprimés à l'intérieur du système de fichiers, par exemple à partir des éléments suivants directory entries , journal , inodes etc. Le système de fichiers est essentiellement le catalogue qui contient nom du fichier et emplacement du fichier et le journal est une sorte d'information de sauvegarde. Ainsi, la récupération des noms de fichiers (et d'autres métadonnées) est plus probable avec l'option journaling systèmes de fichiers.

    Cette approche ne fonctionne que si le système de fichiers et la partition sont intacts, ou s'ils sont récupérables avec la première méthode. DiskDigger (en mode "creuser") et extundelete travailler sur cette approche.


QU'EST-CE QUI REND DIFFICILE / IMPOSSIBLE LA RÉCUPÉRATION DE DONNÉES EFFACÉES ?

  • Un fichier/répertoire est simplement supprimé, par exemple à partir d'une application de l'Explorateur de fichiers ou avec rm à partir de la ligne de commande.

  • Un fichier est renommé en une chaîne aléatoire, puis supprimé.

  • Le système de fichiers sur le périphérique n'est pas journal intime Ainsi, aucune information ne peut être collectée auprès de journal . Ext4 le système de fichiers le plus couramment utilisé sur Android, est le suivant journaling .

  • Le système de fichiers sur le périphérique est un Système de fichiers Flash par exemple F2FS .

    Dans ce cas, vous ne disposez que d'un minimum d'outils (par exemple, pas d'outils de travail). debugfs à la liste supprimée inodes et de rechercher les blocs de données correspondants dans journal ) et les données sont toujours écrites dans de nouveaux blocs comme stratégie de nivellement de l'usure. Garbage Collection rend la récupération moins probable à partir du système de fichiers car les adresses de blocs logiques ( LBAs ) des blocs de données sont modifiés. Ainsi, seuls carving method est applicable, et ça marche .

  • Le système de fichiers ou la partition est supprimé(e), ce qui rend la recherche plus difficile. directory structures y journal à partir du système de fichiers. La restauration d'origine d'Android supprime le système de fichiers lors d'une réinitialisation d'usine. Voir cette réponse .

  • Tout le disque est effacé, y compris Table de partition Les limites des partitions et des systèmes de fichiers ont disparu. Ce n'est pas possible sur les appareils Android car il y a des partitions nécessaires pour démarrer l'appareil.

  • Le fichier a été fragmenté (non sauvegardé de manière contiguë comme un seul morceau), en particulier si aucune information ne peut être récupérée du système de fichiers.

    La fragmentation est plus importante sous Windows que sous Linux/Android ; Ext4 est auto-dé-fragmentant grâce à Allocation retardée y pourcentage de blocs réservés etc. Mais généralement, les gros fichiers sur un ancien système de fichiers sont toujours fragmentés.

  • Vous écrasez le fichier/système de fichiers/partition avec un autre fichier/système de fichiers/partition, ou des zéros, ou des données aléatoires ( shredding ).

    Si vous avez un accès Root, lancez un flux de /dev/urandom sur le périphérique de bloc pour écraser toutes les données, y compris le système de fichiers. Oubliez maintenant leur récupération, bien que cela n'annule pas la possibilité de récupérer les données directement à partir du stockage flash (raw NAND), en les détachant de la carte (qui le fera sauf dans un laboratoire médico-légal !). Outil officiel de l'organisation SD : Formateur de carte mémoire SD écrase également avec zeros en mode plein format. Veuillez noter que l'écrasement répété gaspille de précieux cycles E/P de la mémoire flash.

  • Le système de fichiers est TRIMmed o SECURE TRIMmed ou ERASEd o SECURE ERASEd .

    Ce sont commandes spéciales pour différents types de dispositifs de stockage flash. TRIM est émis par le système de fichiers vers le microprogramme du dispositif flash, demandant l'effacement physique réel des blocs de données ( LBAs ) qui ont été supprimés du système de fichiers. Les systèmes de fichiers montés avec discard l'option envoie toujours FITRIM ioctl chaque fois qu'un fichier est supprimé. Android fait un TRIM programmé, ou vous pouvez le faire manuellement avec fstrim commandement. Voir cette réponse .

  • La partition est BLKDISCARDed o BLKSECDISCARDed .

    blkdiscard émet une commande TRIM pour un bloc entier, c'est-à-dire une partition ou un disque (ce qui équivaut à émettre une commande TRIM sur un système de fichiers nouvellement créé).
    TRIM enregistre les données du système de fichiers superblocks / inode et la table de partition du lecteur, BLKDISCARD ne sauvegarde rien sur le dispositif de blocage.

    La récupération stock d'Android essaie de faire au moins l'un des deux pendant une réinitialisation d'usine. Voir cette réponse .
    Quelque chose de similaire se produit avec déverrouillage du bootloader y fastboot erase Bien que cela dépende de la mise en œuvre du chargeur de démarrage, c'est ce que Google attend des fournisseurs OEM/SoC.

  • Le fichier supprimé est crypté ou le fichier n'a pas d'adresse. signature unique identifiable (au début ou à la fin), de sorte qu'aucune sculpture n'est possible.

    Comme une archive ou un fichier crypté que la plupart des explorateurs de fichiers peuvent créer. Ou un fichier dont le format n'est pas commun et que les programmes de récupération ne connaissent pas.

  • Le système de fichiers ou le périphérique de bloc est crypté de sorte que les données deviennent méconnaissables (comme le FBE / FDE sur Android). La plupart des nouveaux appareils sont livrés avec forceencrypt o fileencryption les drapeaux définis dans fstab Así que vold les crypte lors de la première utilisation. S'ils ne sont pas déchiffrables (par exemple, s'ils sont formatés), il est impossible de récupérer les données sur ces appareils.

  • Le dispositif de stockage Flash est self-encrypting , commun pour SSDs mais pas pour eMMCs .

  • Le dispositif de stockage flash est effacé avec SECURITY_ERASE o ENHANCED_SECURITY_ERASE Les commandes ATA, courantes pour SSDs mais pas pour eMMCs .

  • Le périphérique de stockage n'est pas accessible, par exemple, sur un système embarqué, si le chargeur de démarrage est effacé, le périphérique est bloqué et ne peut plus être démarré. Il n'y a pas de protocole pour communiquer avec la carte eMMC, même si les données sont présentes, sauf par le biais de quelque chose de très bas niveau comme JTAG ou un chip-off.

    Voir aussi : Chargeur de démarrage/BIOS, flashage de ROM et risques associés. Pourquoi les appareils Android sont plus vulnérables que les PC ?

  • Les supports de stockage sont physiquement endommagés, mécaniquement ou électriquement.

Des solutions de rangement de grande taille comme NAS ou le plus compliqué SAN qui fait appel à LUNs avec des protocoles avancés comme iSCSI et des solutions d'intégrité des données comme RAID compliquent également le processus de récupération des données. Cependant, les disques simples comme sur les PC domestiques ou la mémoire flash comme sur les téléphones Android sont des cas plutôt simples.


Ainsi, bien qu'une réinitialisation d'usine avec récupération du stock suffise dans la plupart des cas, vous pouvez combiner l'une des étapes décrites ci-dessus, selon ce qui s'applique à votre appareil, pour vous assurer que vos données ne sont pas récupérables.

RELATION :

androidalle.com

AndroidAlle est une communauté de androiders où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X