Blog › Méthodes et bonnes pratiques › Fusion Drive APFS

Fusion Drive APFS : identifier un membre à l'hexadécimal (superbloc NXSB, flag Fusion, fusion UUID)

Publié le 14 septembre 2026

Un iMac arrive à l'atelier avec deux supports : le petit SSD Apple d'origine (vendu « 32 Go », 28 Go réels) et un SSD de 1 To qui a remplacé le disque dur de 2 To du Fusion Drive. Après le remplacement, macOS a été réinstallé. Le client veut retrouver des données, et une question conditionne toute la suite du travail : la réinstallation a-t-elle recréé un Fusion Drive (petit SSD + nouveau SSD) ou macOS s'est-il installé sur le seul SSD de 1 To ?

Si c'est un nouveau Fusion, les deux supports sont indispensables et doivent être imagés puis recombinés. Si ce sont deux conteneurs indépendants, le petit SSD n'a peut-être rien à voir avec les données actuelles. Se tromper, c'est soit perdre du temps sur une recombinaison inutile, soit extraire un volume à moitié vide en ignorant la moitié du conteneur.

Cet article s'adresse aux professionnels de la récupération de données. Il montre comment trancher à l'éditeur hexadécimal, à partir des seules structures documentées dans la spécification publique d'Apple (Apple File System Reference), sans dépendre d'un logiciel particulier.

Pourquoi la table de partitions ne suffit pas

Sur un Mac récent, chaque support porte un GPT classique : une partition EFI, puis une grande partition de type APFS (GUID 7C3457EF-0000-11AA-AA11-00306543ECAC). Ce type est le même que la partition soit un conteneur APFS autonome ou l'un des deux membres d'un Fusion Drive. Le GPT ne dit donc rien de l'appartenance à un Fusion.

Deux cas se distinguent tout de même dès cette étape :

• partition de type Apple Core Storage (53746F72-6167-11AA-AA11-00306543ECAC, le préfixe se lit « Storage » en ASCII) : c'est un Fusion de l'ancienne génération, sous HFS+, antérieur au passage à APFS ;
• partition APFS : il faut descendre dans le conteneur pour savoir.

La réponse se trouve dans le superbloc du conteneur, le nx_superblock_t, reconnaissable à sa signature NXSB. Sa copie de référence est le bloc 0 de la partition APFS, et chaque membre d'un Fusion en porte une.

Étape 1 : localiser la partition APFS (attention aux secteurs de 4096 octets)

Sur un support classique en secteurs de 512 octets, la partition APFS d'un Mac démarre en général au LBA 409640 (EFI de 200 Mo), soit l'offset 0xC805000 dans l'image.

Piège n° 1 de ce cas : le SSD Apple de 28 Go des iMac Fusion est en secteurs logiques de 4096 octets. Il annonce 6 835 938 secteurs, pas 54 millions. Toute la géométrie change :

Les réflexes à avoir :

• si la signature EFI PART n'est pas à 0x200 mais à 0x1000, le support est en 4K natif ;
• ne jamais « deviner » le LBA 409640 : lire l'entrée de partition dans le GPT (champ premier LBA, 8 octets little-endian, à +0x20 de chaque entrée de 128 octets) ;
• si l'image d'un support 4K est ouverte dans un éditeur réglé sur 512 octets par secteur, le LBA 76806 devient 614448 (×8). C'est l'offset en octets qui fait foi, pas le numéro de secteur affiché.

Étape 2 : lire le superbloc NXSB

Au bloc 0 de la partition APFS, le superbloc commence par un en-tête d'objet de 32 octets (checksum, identifiant d'objet, numéro de transaction, type), puis les champs du conteneur. Les offsets utiles pour notre question :

Toutes les valeurs numériques sont en little-endian.

Le flag Fusion (+0x40)

• 02 00 00 00 00 00 00 00 : conteneur simple (seul le bit 0x2, conteneur APFS de version 2, est présent) ;
• 02 01 00 00 00 00 00 00 : le bit 0x100 est levé, le conteneur est un Fusion.

Le fusion UUID (+0x500)

• 16 octets à zéro : ce support n'appartient à aucun Fusion ;
• non nul : ce support est membre d'un Fusion. Le point décisif est que les deux membres portent le même nx_fusion_uuid à un seul bit près. Ce bit distingue le support principal du support secondaire (« tier2 »).

Attention à ne pas vouloir déduire le rôle de chaque membre de la position de ce bit : la spécification et certaines implémentations ne décrivent pas la même convention. Le principal est de toute façon le support rapide (le SSD), le tier2 est le support de grande capacité.

La taille du conteneur (+0x24 × +0x28)

Multipliez nx_block_size par nx_block_count et comparez le résultat à la taille de la partition lue dans le GPT :

• conteneur simple : les deux valeurs coïncident (au bloc près) ;
• membre d'un Fusion : la taille du conteneur dépasse la partition du support lu, car le conteneur couvre les deux supports.

C'est un contrôle de cohérence précieux quand l'un des deux premiers indices est douteux.

Le numéro de transaction (+0x10)

Les copies du superbloc portées par les deux membres d'un même Fusion sont identiques au bit d'UUID et au checksum près, avec le même xid. Deux superblocs dont les UUID Fusion concordent mais dont les xid divergent fortement méritent qu'on aille lire le checkpoint le plus récent (voir plus bas) avant de conclure.

Exemples de lecture

Les extraits ci-dessous sont reconstitués sur le modèle du cas traité (valeurs d'ordre de grandeur, checksums masqués).

SSD 1 To, conteneur simple (bloc 0 à l'offset 0xC805000) :

+0x00  xx xx xx xx xx xx xx xx  01 04 00 00 00 00 00 00
+0x10  80 0A EE 00 00 00 00 00  01 00 00 80 00 00 00 00   xid ~15,6 millions
+0x20  4E 58 53 42 00 10 00 00  AC 45 8D 0E 00 00 00 00   NXSB, 4096, 244 139 436 blocs
+0x40  02 00 00 00 00 00 00 00  ...                        pas de bit 0x100
...
+0x500 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   fusion UUID nul

244 139 436 blocs × 4096 = environ 1 000 Go : exactement la taille de la partition. Conteneur autonome.

Membre d'un Fusion 28 Go + 2 To (même zone, à titre de comparaison) :

+0x20  4E 58 53 42 00 10 00 00  E3 6B 82 1D 00 00 00 00   495 086 563 blocs = ~2 To
+0x40  02 01 00 00 00 00 00 00  ...                        bit 0x100 levé
+0x500 5B 1E 9A 07 C4 22 4D 61  8F 0B 3D 72 A9 10 E6 9C   fusion UUID non nul

Sur le SSD de 28 Go, dont la partition APFS fait environ 6,76 millions de blocs, un tel superbloc annoncerait un conteneur de plus de 2 To : incohérent pour un conteneur simple, parfaitement normal pour un membre de Fusion. Le second membre porterait le même fusion UUID, un bit mis à part, et le même xid.

Étape 3 : compter et nommer les volumes avant de conclure

Piège n° 2 : un conteneur qui contient plusieurs volumes n'est pas forcément une installation de macOS.

Le tableau nx_fs_oid[] (+0xB8) liste un identifiant non nul par volume. Une installation complète de macOS en compte en général quatre ou cinq (Système, Données, Preboot, Recovery, VM). On est tenté d'en déduire « macOS était installé ici ». C'est une erreur fréquente.

Ces identifiants sont virtuels : ils se résolvent via la carte d'objets du conteneur. À l'hexadécimal, la voie pragmatique consiste à repérer les superblocs de volume, signature APSB, et à y lire :

Plusieurs versions d'un même superbloc de volume coexistent sur le support (une par transaction) : retenez celle dont le xid (+0x10) est le plus élevé, pour chaque index.

Dans notre cas, le SSD de 28 Go affichait quatre volumes. Leur lecture a tout changé : Preboot, Recovery, VM (2 Go) et un volume créé à la main de quelques centaines de kilo-octets. Aucun volume Système, aucun volume Données. Quatre identifiants de volume, mais pas de macOS et pas de données utilisateur.

Le xid n'est pas une date

Le xid du bloc 0 donne une indication d'activité : environ 15,6 millions sur le SSD de 1 To (conteneur en service depuis longtemps), 608 sur le SSD de 28 Go (conteneur à peine utilisé). Deux précautions :

• le bloc 0 peut être en retard sur le dernier checkpoint. Le superbloc le plus récent se trouve dans la zone de descripteurs de checkpoint, localisée par nx_xp_desc_base (+0x70) et nx_xp_desc_blocks (+0x68) : c'est l'exemplaire NXSB au xid le plus élevé et au checksum valide ;
• un xid ne se compare pas entre deux conteneurs différents et ne donne aucune date absolue. Il sert à comparer les copies d'un même conteneur, pas à dater une installation.

Arbre de décision

Une fois les deux supports imagés (jamais de travail sur l'original), lisez le GPT puis le bloc 0 APFS de chacun :

1. Le gros support a le bit 0x100 levé et un fusion UUID non nul

• Le petit SSD porte le même fusion UUID à un bit près, avec un xid concordant : nouveau Fusion. Les deux images sont indispensables et doivent être présentées ensemble comme un conteneur unique. Le SSD porte l'essentiel des métadonnées, le grand support l'essentiel des données froides : l'un sans l'autre ne restitue qu'une fraction du contenu.
• Aucun support ne porte l'UUID jumeau : un membre manque. Chercher le support absent avant d'aller plus loin.

2. Le gros support est un conteneur simple (bit 0x100 absent, fusion UUID nul, taille = partition)

• Le petit SSD est aussi un conteneur simple : deux conteneurs indépendants. L'installation en service est sur le gros support. Identifiez les volumes du petit SSD par leur nom et leur rôle avant de lui attribuer la moindre importance.
• Le petit SSD est un membre de Fusion avec un autre UUID, ou une partition Core Storage : il porte l'ancien Fusion, orphelin de son disque dur d'origine. La nouvelle installation n'y touche pas. Sans le disque dur d'origine, seule une partie des métadonnées et des fichiers récents peut s'y trouver.

3. Le petit SSD a été reformaté lors de la réinstallation

L'ancien Fusion y est écrasé. Sur un SSD, le reformatage s'accompagne en général d'un TRIM de l'espace libéré : les blocs de l'ancien conteneur ont très vraisemblablement été effacés par le contrôleur, et ne sont plus lisibles par l'interface. C'était la situation de ce cas : deux conteneurs simples, les données actuelles entièrement sur le SSD de 1 To, le petit SSD hors jeu.

Ce qu'il ne faut pas faire

• Brancher les supports sur un Mac en lecture-écriture. Face à un Fusion incomplet, macOS peut proposer de « réparer » le disque, et la commande de réinitialisation d'un Fusion efface les deux membres. Travaillez sur images, en lecture seule.
• Conclure sur le GPT seul, ou sur le nombre de volumes seul.
• Supposer la géométrie 512 octets sur un SSD Apple : un offset calculé au LBA 409640 tombe au milieu de la partition EFI d'un support 4K et fait conclure, à tort, à un superbloc absent.
• Déduire le rôle de chaque membre du bit qui diffère dans le fusion UUID.
• Reformater ou réinstaller « pour voir » : sur SSD, chaque effacement déclenche un TRIM qui peut rendre définitive la perte d'un ancien conteneur.

En résumé

• Le type de partition GPT ne distingue pas un conteneur APFS simple d'un membre de Fusion Drive.
• La réponse est dans le superbloc NXSB, bloc 0 de la partition APFS : +0x40 (bit 0x100 = Fusion), +0x500 (nx_fusion_uuid, zéro = simple), +0x24 × +0x28 (taille du conteneur supérieure à la partition = Fusion), +0x10 (même xid entre membres).
• Deux membres d'un même Fusion ont le même fusion UUID à un bit près.
• Le SSD Apple de 28 Go des iMac Fusion est en secteurs de 4096 octets : partition APFS au LBA 76806, pas 409640.
• Lisez les noms et rôles des volumes (APSB, +0x2C0 et +0x3C0) avant de décider qu'un conteneur contient une installation ou des données.

Sources : Apple File System Reference, spécification publique d'Apple (structures nx_superblock_t, apfs_superblock_t, constantes NX_INCOMPAT_FUSION et rôles de volume) : developer.apple.com/support/downloads/Apple-File-System-Reference.pdf ; spécification UEFI pour la structure GPT. Cas terrain : iMac Fusion 28 Go + 2 To, disque dur remplacé par un SSD de 1 To puis macOS réinstallé.

‹ Tous les articles du blog