8 votes

Comment récupérer des données d'un téléphone Android complètement mort?

Le téléphone fonctionnait parfaitement. Puis un jour, complètement mort, plus rien du tout. Il se peut que ce "un jour" ait été après un certain temps d'inactivité, je ne peux pas me rappeler.

Modèle : Samsung Galaxy S3 Android AT&T (SGH-i747 SKU S9255)

Essais déjà effectués :

  • Charger le téléphone : aucune sortie visuelle, pas de voyants
  • Retirer la batterie pendant la charge : aucune sortie visuelle, pas de voyants
  • Retirer la carte SIM et la carte SD : aucune sortie visuelle, pas de voyants
  • Tenter d'allumer : aucune sortie visuelle, pas de voyants

J'ai besoin de récupérer les photos de famille de ce téléphone (stockées sur la mémoire interne). Je me préoccupe moins du matériel/téléphone lui-même.

Merci pour toute aide que vous pouvez apporter !

2 votes

Essayez ceci : Retirez l'arrière du téléphone, puis cherchez la puce qui contient toutes vos données. Si cela ne fonctionne pas, je ne sais pas ce qui le fera.

0 votes

Si vous parlez de la carte SD, elle a déjà été retirée et ne contient pas les données.

1 votes

Je suppose que Jeffrey parlait de dessouder la puce de mémoire flash. En détail, le Samsung KMVTU000LM dans le démontage du S3. Une fois que vous avez la puce, elle peut théoriquement être connectée à un lecteur de mémoire flash capable de gérer de telles puces pour lire le contenu.

7voto

Irfan Latif Points 16863

Il semble qu'il s'agisse d'un problème matériel (pas directement lié au stockage), il vaut mieux essayer de le faire réparer. À moins que l'appareil ne démarre au moins jusqu'à une étape de démarrage comme fastboot ou odin ou edl, vous ne pouvez pas accéder à sa mémoire. Ou si les données sont extrêmement importantes, contactez un service professionnel de récupération de données qui fait généralement l'une des deux choses :

  • Accès direct à la eMMC en utilisant un protocole de bas niveau comme JTAG. Un équipement spécial - généralement appelé une sorte de box par exemple EasyJtag - est utilisé pour communiquer avec la eMMC.
  • Ou en utilisant une méthode de chip-off, c'est-à-dire en retirant la puce eMMC de la carte.

    La plupart des appareils construits ces dernières années utilisent des dispositifs flash eMMC comme leur stockage persistant. Généralement, eMMC et RAM sont regroupés dans un seul package ; eMCP. Ainsi, un lecteur eMMC/eMCP compatible peut être utilisé pour récupérer des données en le connectant à un PC. Une gamme de tels lecteurs/sockets est disponible sur les magasins en ligne de plusieurs fabricants chinois - par exemple Allsocket et KZT - pour correspondre avec différentes tailles et formes de packages BGA.

Veuillez noter qu'il y a d'autres facteurs également qui peuvent définir le destin de la récupération de données via JTAG ou une méthode de chip-off. La récupération de données est très improbable ou impossible si :

  • eMMC est mort c'est-à-dire qu'il a atteint la limite des cycles E/P pour lesquels il a été conçu.
  • Vous utilisiez chiffrement (FDE/FBE) sur votre appareil. À partir d'Android 5.0, le chiffrement est pris en charge par le matériel. Cité de ici :

    Par défaut, la clé de déchiffrement est stockée dans le stockage pris en charge par le matériel
    ...
    gardez à l'esprit qu'extraire la clé de déchiffrement via une méthode de chip-off ou toute autre méthode de bas niveau n'est pas possible. Donc, si vous faites un chip-off, vous n'obtiendrez pas la clé de déchiffrement et ne pourrez pas déchiffrer les données.

LIÉ :

2 votes

Hypothétique : cela vaudrait-il la peine pour une personne de trouver un moyen de récupérer des données de l'emmc (cryptées), d'attendre quelques années voire probablement une décennie pour voir des progrès sérieux dans le matériel de traitement parallèle abordable (comme les GPU), puis de forcer le passage à travers ces données cryptées ? Je vois le brute force comme la seule méthode (à moins que l'ingénierie sociale ne nous donne le résultat) si la clé de décryptage ne peut pas être retirée.

2 votes

@Firelord intéressant. Pour déchiffrer toute la partition (FDE) ou tout le système de fichiers (FBE), une clé principale est requise, qui est chiffrée avec une autre clé intermédiaire, et stockée dans le pied de crypto ou dans /data/misc/vold/user_keys/[ce|de]//. Une clé RSA privée chiffrée est également stockée avec la clé principale, qui est fournie à KeyMaster, qui déchiffre la clé RSA et l'utilise pour signer la clé intermédiaire. La clé intermédiaire est à son tour dérivée des informations d'identification de l'utilisateur et d'un sel aléatoire également stocké avec la clé principale. Nous avons donc besoin de deux choses : les informations d'identification de l'utilisateur et la clé RSA non chiffrée, cette dernière étant uniquement connue de KeyMaster.

2 votes

Le module KeyMaster s'exécute dans un environnement sécurisé, par exemple TEE, qui utilise le processeur principal mais qui est complètement isolé du système d'exploitation principal. TZ d'ARM est une implémentation de TEE. L'implémentation de TZ de Qcomm est QSEE dans lequel KeyMaster s'exécute. Idéalement, KeyMaster ne devrait pas divulguer d'informations cryptographiques, mais il a été piraté, même si cela n'est utile que si l'appareil fonctionne. Pour les attaques hors de l'appareil, le mot de passe de l'utilisateur ainsi que la clé RSA doivent être forcés. Et le dernier semble impossible. Donc, cette approche ne semble pas être une question de temps. C'est ce que je comprends.

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