Analyse d’un appareil Apple
Introduction
Il y a quelques week-ends j’ai récupéré un vieux macbook pro de 2012 en sale état d’une bonne connaissance à moi (qui n’avait pas tourné depuis 2015).
Il s’allumait, mais une fois sur l’écran de connexion, on a un magnifique message d’erreur kernel panic et j’avais une flemme ENORME de faire une installation neuve de OS X sur un vieux mac ou de chercher à “réparer” l’installation actuelle.
Puis la personne qui m’a donné cet ordinateur m’a dit que ça serait fun d’essayer de récupérer quelques données du disque s’il était pas foutu.
Donc je devais faire deux choses : récupérer des données d’un ordinateur qui ne s’allume plus et reinstaller linux sur ce mac (bah oui on crache pas sur un PC gratos ;) ).
Installation de Linux
Pour ce faire j’ai donc démonté le disque dur du Macbook, et remplacé par un vieux disque dur qui trainait (oui, j’avais pas le budget d’acheter un ssd), pour ensuite installer Linux : le classique clée usb > boot > install sans aucun soucis (sauf pour l’installation des driver wifi mais pas mal de resources sont disponibles en ligne).
Le magnifique MacBook “”charo””
Analyse du disque / Récupération des données
Préparatifs et prérequis
Comme dans toute analyse de donnés : avant tout, on clone le disque.
J’ai utilisé dd, mais il existe d’autres outils et même des docks permettant de cloner directement un disque.
Les manipulations pour récupérer les données peuvent des fois être risquées, et il est fréquent de perdre une partie des données en travaillant avec un disque directement branché. En créant une image du disque, on écarte ce risque, en plus de travailler avec un fichier qui sera plus rapide à manipuler que si on travaillait en temps réel sur le disque dur.
Je n’avais jamais travaillé avec des volumes Apple, mais il se trouve, après quelques recherches que les appareils utilisants MacOS, utilisent le système de fichier HFS+, qui est normalement supporté nativement sur Linux dans les dernières versions. Cependant, dans le cas présent, impossible de faire quoi que ce soit avec les driver de base, j’ai donc installé les packages hfsplus et hfsfuse.
Je devais également débloquer mon volume, car protégé par mot de passe, pour cela j’utilise libfvde (la version sur github et plus récente, mais le package peut également être installé via apt-get install libfvde-utils ).
On creuse !
Je connaissais le mot de passe utilisateur, ce qui va permettre de déchiffrer le volume, cependant si je n’avais pas été en possession de celui-ci, il aurait été possible de l’extraire de la mémoire vive de la machine, ou d’extraire le hash de celui ci relativement facilement.
Même si j’avais un mot de passe, ce n’est pas suffisant pour déchiffrer le volume. En effet un mot de passe sert juste à ouvrir une session d’un utilisateur sur la machine et permettre d’accéder à ses données, il ne permet pas de déchiffrer un disque entier. Cependant, grâce au travaux de chercheurs en informatique, on sait que, un fichier nommé ‘EncryptedRoot.plist.wipekey’ est présent sur le disque, ce fichier contient les informations necessaires pour dériver la ‘master key’ depuis le mot de passe d’un utilisateur. Tout est expliqué clairement ici.
Les outils suivants font partie de la librairie TheSleuthKit
Ce fichier se trouve dans la partition “Recovery HD” du disque, on identifie donc l’emplacement de cette dernière avec mmls :
$ mmls apple.raw
GUID Partition Table (EFI)
Offset Sector: 0
Units are in 512-byte sectors
Slot Start End Length Description
000: Meta 0000000000 0000000000 0000000001 Safety Table
001: ------- 0000000000 0000000039 0000000040 Unallocated
002: Meta 0000000001 0000000001 0000000001 GPT Header
003: Meta 0000000002 0000000033 0000000032 Partition Table
004: 000 0000000040 0000409639 0000409600 EFI System Partition
005: 001 0000409640 0975503591 0975093952 Sans titre
006: 002 0975503592 0976773127 0001269536 Recovery HD
007: ------- 0976773128 0976773166 0000000039 UnallocatedOn voit donc que la partion “Recovery HD” débute au secteur 975503592, pour lire les fichiers d’une image, SleuthKit propose fls, qui permet de récupérer le nom des fichiers et des répertoires d’une image disque, en nous donnants les inodes. Ainsi on fait :
$ fls -r -o 975503592 apple.raw | grep EncryptedRoot
+++++ r/r 3581: EncryptedRoot.plist.wipekey-r indique à fls d’être récursif
-o précise l’offset
| grep nous permet de trouver seulement la ligne qui nous intéresse.
Ainsi, on sait maintenant que le fichier qui nous intéresses se trouve à l’inode 3581
On utilise donc icat, qui permet de lire un fichier d’une image disque, en lui fournissant un inode.
$ icat -o 975503592 apple.raw 3581 > EncryptedRoot.plist.wipekeyOn se retrouve donc avec un magnifique fichier EncryptedRoot.plist.wipekey !
Maintenant qu’on a ce qu’il nous faut il est possible d’utiliser fvdemount pour monter la partition et pouvoir l’explorer.
Nottons qu’ici la partition qui nous intéresse est celle qui se nomme ‘Sans Titre’, on adaptera donc l’offset en conséquence.
sudo fvdemount -e EncryptedRoot.plist.wipekey -p XXXXXX -o $((409640*512)) apple.raw /media/myhfsdrive/-e : le nom du fichier .wipekey
-p : le mot de passe d’un des utilisateurs
-o : Offset de la partition à monter
apple.raw est notre image disque
/media/myhfsdrive/ est le point de montage (cela doit être un répertoire déjà existant)
Notre disque est donc monté, et sur le point de montage on constate un fichier “fvde1”. C’est l’image disque déchiffrée, il faut donc le remonter sur un autre point de montage, j’utilise pour ça hfsfuse (mount ne fonctionnais pas).
sudo hfsfuse --force /media/myhfsdrive/fvde1 /media/hfs/—force n’est pas obligatoire, mais dans mon cas le programme produisait des erreurs et ne voulais pas continuer (oui, je sais, normalement on doit corriger les erreurs plutôt que d’y aller comme un sauvage 🙂).
Le disque est maintenant accessible sur /media/hfs/ , on peut l’explorer comme bon nous semble et utiliser des outils pour récupérer des données.
Récupération et analyse
Dans mon cas, le disque d’origine a reçu beaucoup de chocs, donc les données sont corrompues et il est impossible d’ouvrir une image ou un documents, même si la structure des dossiers et fichiers est restée intacte. Il est cependant possible d’utiliser photorec (directement sur le fichier fvde1) pour récupérer un grand nombre de fichiers (doc, pdf, images etc). J’ai effectué cette récupération avec succès, mais pas grand chose à montrer ici.
D’autres outils comme Apollo permettent une analyse complète en lisant les fichiers de base de données présents sur l’ordinateur, ils peuvent donner accès à des informations comme les messages envoyés et reçus, l’historique d’utilisation de l’appareil, les appel et pleins d’autres données.
Ces données sont tirées des synchronisation entre le téléphones et l’ordinateur
Exemple de données recueillies avec Apollo. Ici des logs de SMS.
Conclusion
Au travers de cette petite experience, j’ai eu l’occasion d’en apprendre plus sur les systèmes Apple, qui ont la réputation d’êtres très “fermés”. Savoir travailler avec ce genre de systèmes est crucial, leur fonctionnement est assez différent des autres systèmes et comprendre leur fonctionnement permet d’être mieux préparé à tout type de situtations. Les appareils Apple représentant une part non négligeable du parc informatique chez les utilisateurs particuliers, il est important de savoir les maniers et connaître leurs spécificités.
Puis bon je suis l’heureux propriétaire d’un ordinateur zombie, mi-pomme, mi-pingouin :)
Resources
https://eprint.iacr.org/2012/374.pdf
http://www.cl.cam.ac.uk/~osc22/docs/slides_fv2_ifip_2013.pdf