Comment ne pas déverrouiller les HDD HGST (Cross-flash vendor-locked)
L'année dernière je suis tombé dans le rabbit hole des disques durs SAS bloqués logiciellement. Cette page résume mes aventures à tenter techniquement de les déverrouiller mais sans succès à ce jour. Tout part de l'achat de quelques disques durs 2,5 pouces SAS-2 et SAS-3 pas chers sur eBay qui sont issus d'appliances de marque NetApp, EMC ou Cisco décommissionnées.
Et s'ils ne sont pas chers c'est qu'il y a une raison. 😁
J'en ai malencontreusement pris quatre sur eBay sans savoir, sans trop me méfier, qui sont étiquetés NetApp. N'ayant jamais eu de tel matos OVER 9000 propriétaire à la maison ou au travail, comme par exemple des baies de disques EMC ou NetApp, je n'avais absolument pas connaissance de tout ce qui m'attendait. Voici les deux modèles de disques avec lesquels je suis concerné :
Le disque ne fonctionne pas totalement de manière générique et correctement partout sur d'autres contrôleurs SAS d'autres marques (LSI, ServeRAID, PERC, ...). Il y donc une distinction à faire entre les firmware "custom" et les firmwares constructeur OEM, appelé "génériques" ou civils. "civilian" revenant souvent sur les forums spécialisés. On trouve de ces histoires à la pelle sur le net. Le sujet ne concerne pas un fabricant spécialement. La plupart ont pu faire fonctionner ces disques en l'état, tels quels, simplement en les reformatant avec une taille de secteur standard, en les passant de 520 à 512 octets, pour une utilisation en RAID logiciel du genre unRAID/TrueNAS sur une carte en mode HBA/IT.
Mais dans certains cas changer la taille de secteur à 512 octets en reformatant ne suffit pas à les rendre absolument compatible partout. Car dans mon cas souvient un autre problème de cold boot. Le blocage du disque se fait, selon moi, sur une séquence de démarrage après mise sous tension qui doit être absolument respectée (timing). Sinon à l'allumage les disques "buguent" et ne sont pas détectés correctement. Sur mon Dell PowerEdge T440, que la PERC soit en mode RAID ou HBA, c'est la même chose, la machine est bloquée au boot sur l'écran bleu, la seule solution étant de retirer les disques de la cage et de les remettre. Après cette manipulation ils fonctionnent correctement. Ce qui réclame d'être devant le serveur lors du boot : pas terrible. C'est comme si les disques attendaient une courte période de temps que le contrôleur (ou l'expander de la backplane) leur envoie quelque chose, juste après la mise en tension, sinon c'est trop tard, faut ré-appliquer une déconnexion électrique. Seulement comme la carte contrôleur et/ou la backplane elle aussi doit prendre le temps de démarrer, elle ne répond pas assez vite, ce temps est dépassé, les disques ne sont pas détectés. C'est assimilable à une race condition. C'est mon hypothèse. Même situation que cette personne : https://forums.servethehome.com/index.php?threads/hgst-netapp-sas-drives-most-of-the-time-dont-show-up-on-dell-r730xd-backplane.43001/.
Pour ceux qui auraient fait le rapprochement avec le problème de la broche 3.3V : que les disques reçoivent ce 3.3V ou pas c'est la même chose. Même avec des adaptateurs qui n'apportent pas cette 3ème tension c'est pareil. Le fil n'est pas présent, il n'y a que le 12V et 5V d'appliqués, donc ce n'est pas cela le problème.
Donc pour moi cela provient d'une modification du logiciel interne qui a été personnalisé pour un démarrage "spécifique". La solution est simple à première vue : remettre le firmware constructeur à la place, ce qui rendrait le disque conforme à son comportement d'origine. C'est là que les choses se gâtent. Si on essaye, et bien cela ne fonctionne pas. Même mettre le firmware originel du fabricant échoue. On pourrait penser que c'est quelque chose de légitime. Et bien non. C'est de la sécurité. C'est le début des investigations durant des nuits blanches de recherche et de casse tête cet été pour moi.
On peut les trouver sur le net, notamment sur l'espace de téléchargement du site hddguru.
Ouais c'est facile, yaka (faukon) dessouder la SPI Winbond/Macronix du PCB, la mettre dans un programmateur et hop.
Hélas c'est une autre époque ou pour des techniques de récupération de données très spéciales. Sur les HDD modernes une partie du firmware est en effet dans la puce Flash mais une autre partie est située sur les plateaux du disque. Cette zone est appelée la SA (System Area). Elle est située dans de la zone LBA négative (LBA < 0) et pas obligatoirement de manière contiguë.
Pour garder un ensemble cohérent de firmware et éviter de bricker son HDD, il est donc bon de laisser au firmware installé le soin d'écrire les bonnes sections lui-même du nouveau firmware à la fois dans la flash et sur les plateaux si besoin. Des bouts du firmware global étant répartis de part et d'autre. Donc cette méthode barbare, on oublie.
Il y en a comme moi qui ont essayés, ils ont eu des problèmes. 😂
Nous avons tenté des commandes à base de sg_write_buffer mais toutes échouent avec des Illegal Request comme réponse.
Déjà pourquoi ça ne fonctionne pas ? C'est simple : le firmware du HDD embarque un mécanisme interne de vérification du nouveau firmware à prendre en compte (lors d'une commande sg_write_buffer). C'est le disque dur (ou SSD) LUI-MÊME qui accepte ou refuse le fichier firmware .lod, .sed ou .bin proposé à l'implantation. Le nouveau firmware est accepté uniquement si sa signature condensée SHA256 correspond à une clé publique RSA-2048 déjà inscrite dans le firmware du HDD en place. Il faut donc être familier des principes de chiffrement asymétrique (clé publique / clé privée) et de condensât (checksums / digest).
Un disque qui embarque un firmware NetApp ne pourra être flashé qu'avec un autre firmware signé par NetApp.
Un disque qui embarque un firmware Dell ne pourra être flashé qu'avec un autre firmware signé par Dell.
Etc...
D'où le terme de "Vendor-locked" : les disques sont verrouillés et interdisent le cross-flashing, c'est à dire mettre le firmware d'un autre "vendor" (revendeur) à la place. D'où le fait aussi que les revendeurs (NetApp, Dell, EMC, Cisco,...) doivent repackager/recustomiser le firmware du fabricant (WD, HGST, Seagate...) à leurs clients lorsque le fabricant en sort un nouveau : exemple.
C'est une fonctionnalité proposée par les fabricants (WD, HGST, Seagate...) directement en usine, le firmware est personnalisé pour le client (Nom du fabricant, numéro de modèle, code PIN, clé publique RSA-2048...). Sur un HGST Ultrastar 10K900, il est facile reconnaître la provenance en lisant le numéro MLC. Il démarre toujours par CE pour Cobra-E (famille 10K900) suivi d'un 0 et enfin de 4 caractères alphanumériques (version du firmware).
Un disque NetApp aura donc un firmware noté CE0NAxx, CE0NA00, CE0NA01, CE0NA02, etc... Et cette information est apposée sur l'étiquette constructeur (valeur MLC en rouge), on peut donc en déduire que ces disques sont déjà personnalisés en sortie d'usine.
Un spécimen "civil", destiné à la revente au détail, aura un firmware générique, son MLC équivaut à CE0A5B0 sur l'étiquette de ce spécimen neuf illustré ci-dessous :
Remarque 1 : cette protection N'A RIEN A VOIR avec le chiffrage du disque en lui-même (SED) ou quelconque protection par mot de passe ATA.
Remarque 2 : Ne pas oublier que firmware contenu dans le binaire .lod n'est pas réellement 100% complet, des données variables sont propres au disque dans la Service Area et doivent le rester (calibration des têtes, listing des secteurs défectueux, numéro de série, etc... Ces données ne sont pas et ne doivent pas être mises à jour lors d'un upgrade firmware. Glossaire : https://blog.acelab.eu.com/glossary.
Il faut passer par la case retro-ingénierie et accessoirement se palucher une tonne de documentation. Va falloir fouiner ! Certaines commandes de la norme SCSI sont publiques (T10). D'autres sont cachées (non documentées, documentation non accessible au public) que l'on appelle des VSC (Vendor Specific Commands) ou encore des VUC (Vendor Unique Commands). Elles sont ainsi spécifiques à chaque marque de disque dur, et les constructeurs peuvent faire ce qu'ils veulent avec. J'ai passé des heures à jouer avec les commandes sg_utils que ce soit coté Windows ou Linux avec mon petit PC Lenovo de test :
C'est en envoyant des commandes bien ciblées au disque qu'on arrive à le placer dans un certain état (spacial mode) qui désactivera la vérification de la signature du firmware. Une fois cette fonction désactivée, le HDD pourra ingurgiter n'importe quel firmware: OEM, HP, Dell, EMC, NetApp, etc... Et le cross-flash est donc possible. Hélas seuls des outils professionnels hors de prix peuvent faire ce cross-flash. Du genre le ACELab PC3000 ou chez MRT Lab.
Il est surnommé tel quel par ce site (lug.mtu.edu). Son auteur est je pense assez blasé. J'en comprends la frustration.
E123 est une personne sur des forums qui propose un service de déverrouillage de ces disques à distance (via le bureau à distance de Windows). Un service monnayé contre quelques euros par disque. Ce E123 est très compétent, aucun doute là dessus. Il a dû y passer du temps, et le temps c'est de l'argent. Il ne souhaite pas partager ses secrets. Knowledge is money !
La vidéo ci-dessus est une démonstration de son service. En résumé : le disque connecté se présente comme un DKR5D, il lance un script .bat DOS "CMD" classique, qui démarre un deuxième Niagara en mode CLI (une deuxième instance de Niagara, pas celle que l'on voit à l'écran en graphique). Le script utilise Niagara pour envoyer des commandes au disque afin de le déverrouiller. C'est ici toute la magie, qui est monnayée, cachée dans ce script temporaire. Une fois ce script déroulé, dans un deuxième temps on peut injecter un autre firmware, ce qu'il va faire avec le Niagara déjà ouvert en GUI. Ce logiciel exploite derrière la commande sg_write_buffer. L'injection du nouveau firmware fonctionne. Il montre dans un troisième temps que le disque fraîchement mis à jour fonctionne bien sous le logiciel Victoria avec le nouveau firmware générique implanté. Le disque n'est plus un DKR5D mais un HITACHI générique tout en conservant le même numéro de série. Remarque : il existe une version Linux de Niagara.
E123 a laissé quelques indices dans ce post sur le forum hddguru.
Grosso modo il faut analyser le code du firmware ARM (en dumpant les modules de la SA du disque) à la recherche de la routine qui désactivera cette vérification : ce qui signifie trouver les "clés" et des VSC à jouer. Des investigations à faire en solo quoi (hard way), comme lui a dû les faire de son coté. Mais ce n'est pas à la portée de tout le monde de bien savoir lire et décortiquer du code ARM décompilé. Je n'ai pas IDA. Peut-être demander à une IA ?
Comme déjà dit, il faudra envoyer des commandes "sur mesure" au disque dur. Pour cela il est conseillé d'utiliser une carte HBA en mode IT (Initiator-Target). Certaines cartes comme la PERC H730P de mon Dell T440 peuvent basculer dans ce mode en jouant dans les paramètres. Sinon vous pouvez prendre une carte contrôleur SAS type LSI2008 déjà pré-flashée sur AliExpress pour quelques dizaines d'euros. Ce sont des cartes Dell, IBM/Lenovo ou HP recyclées dont le firmware d'origine a été re-flashé pour l'utiliser dans ce mode.
En gros, elle fonctionne comme un passe-plat. Les commandes SCSI transitent telles quelles de l'Initiator (hôte Linux/Windows/BSD) à la Target (disque dur) sans restriction/translation sur le chemin. Par opposition au mode RAID, qui comme son nom l'indique, embarque toute la couche de logique de gestion RAID (communications internes indépendantes entre la carte et ses disques, sans intervention de l'hôte/OS) et peut maquiller la communication. Vidéos de the-art-of-server sur Youtube :
Pour envoyer des commandes custom SCSI au disque SAS il faut passer par les outils sg_utils (paquet sg3_utils sur Linux). Pour les Windowsiens, il existe des versions exécutables pré-compilées qui font le travail même sous Windows 7.
J'ai eu un temps utilisé un Dell Optiplex 380 mais après j'ai pris un Lenovo Edge 72. Un truc assez vieux qui accepte Windows 7 out of the box.
En aparté, pour gruger la timebomb du logiciel Niagara sous Linux. Avec Ghidra je suis parti à la recherche de la fonction qui affiche le message dans libtcluil.so. Petite trouvaille, on remarque que le logiciel essaye de détecter si on est sur le réseau d'HGST ou pas (usage en interne à l'entreprise) "onHGSTNetwork".
Pour gruger, il suffit de supprimer le test de retour de la fonction niagaraExpired. Ainsi la fonction niagaraExpired est toujours exécutée mais son résultat n'est plus pris en compte (return non exploité). Le logiciel démarre intégralement sans jamais expirer. Il me semble que j'avais tenter de gruger l'heure du PC sans succès. Avant :
Après :
Un Niagara débloqué sous Linux. Plus besoin de Windows 7.
Des documentations téléchargées du web...
Au départ benoîtement, j'ai cru qu'il suffisait de lire la documentation constructeur. HGST implémente le protocole de sécurité "TCG Entreprise SCC". Ces fonctionnalités ne servent qu'aux disques dits "SED", chiffrés en interne. HGST propose deux modèles de disques, l'un chiffré (CSS601) et un autre non-chiffré (CSS600). Mes disques sont non-chiffrés. Mais en fait derrière le soft entre les deux modèles est peut-être identique ? Que ce soit un CSS600 ou 601 ce sont juste des paramètres qui changent dans le firmware. Pourquoi parler de ça ? Ce système de TCG embarque toute la logique de sécurisation globale du disque dur jusqu'au chiffrement des données sur les plateaux par zones (appelées bandes). Les données sur les plateaux sont découpées par bandes/zones et chaque zone à sa clé de chiffrement. C'est indiqué dans la documentation. HGST se sert du mécanisme TCG pour gérer l'aspect sécuritaire de deux autres fonctionnalités dont celle qui nous intéresse. Comme expliqué dans la documentation. Il est possible de désactiver cette vérification de signature de firmware. Ce qui ouvrirait la porte à notre "cross-flashing". Comme indiqué, ces fonctionnalités sont "un plus" qui sortent du cadre de la norme TCG.
En gros, il faut utiliser certaines fonctionnalités fournies par ce module TCG et aller modifier la table "Admin SP". SP pour Security Provider afin de désactiver la fameuse vérification de signature de firmware qui nous embête.
Les commandes TCG sont encapsulées via les commandes SCSI suivantes :
- SECURITY PROTOCOL IN (A2h) = IF-RECV
- SECURITY PROTOCOL OUT (B5h) = IF-SEND
Les fonctions liées à TCG sont lourdes à mettre en œuvre, il y a toute une négociation (aller-retour) à base de jeton (comID) à faire avec le disque dur avec une authentification et ça réclame un vrai programme dédié.
Il faudrait :
J'ai pu trouver sur GitHub un utilitaire génial fait en Go qui fait 95% du travail : https://github.com/open-source-firmware/go-tcg-storage/tree/main
Reste un peu à l'adapter... mais il y a un problème, il faut s'identifier auprès du disque avec le MSID ou un code PIN que l'on ne connaît pas. J'ai ressorti Ghibra à la recherche du mot de passe. Le code PIN TCG réclame que le longueur du mot de passe soit exactement de 32 caractères. Ni plus, ni moins. La longueur n'est pas variable. Sachant que le MSID par défaut est le numéro de série du disque établi sur 8 caractères répété 4 fois, donc 32 caractères. J'ai quand même trouvé du "Hello World!" dans le firmware. Hélas je n'ai pas les symboles pour tout comprendre.
Mais rien n'empêche le vendor d'avoir mis autre chose comme mot de passe. Mais hélas cette piste s'arrête là car les commandes TCG avec cet utilitaire en Go n'ont pas d'effets. La partie TCG semble complètement désactivée. Idem dans Niagara. Donc je pense que ce sont d'obscures commandes non-documentées qui gèrent cet aspect... et alors là pour les trouver... 😤🤯
Courant août j'ai abandonné. Trop complexe pour moi tout seul de rendre mes HGST OEM, c'est figé en l'état sur mon NAS.
J'en ai même perdu un sur les quatre durant mes essais, comme d'autres sur les forums, en bricolant partiellement les différents modules qui composent la Service Area avec sq_raw / sg_write_buffer. En octobre dernier, mr44er sur hddoracle poste de nouvelles informations issues d'une IA façon GPT, une lueur d'espoir. J'ai essayé certaines commandes qu'il a posté mais elles sont à moitié fausses. Le "special mode" je l'avais déjà tenté bien avant.
Nous sommes en février 2026 et donc je confirme que j'ai lâché l'affaire, trop de temps perdu même si j'ai appris pas mal. Comme d'autres avant moi, j'ai contacté ce fameux russe par courriel avec une petite vidéo faite en privée en anglais pour lui expliquer tout cela. Il est resté sur l'affaire des 520->512 octets et qu'après cela il n'y a pas de restrictions, que les disques fonctionnent bien en restant en firmware NetApp. Donc l'opération ne servirait à rien. Oui ça fonctionne, mais rien à propos de mon affaire de cold boot. Après une seconde demande quelques semaines plus tard, j'ai eu une réponse négative, grosso-modo ce n'est pas intéressant pour lui car je n'ai que trois disques à flasher, il en faudrait une dizaine pour que l'on parle sérieusement. Je pense qu'il traite plus en business/B2B qu'avec des simples particuliers ponctuels comme moi ça lui prendrait trop de temps. Finalement je sors la carte bleue et je me prends des SSD d'occasion Dell reconditionnés comme ça plus de problème.
Un jour peut-être on aura une solution gratuite mise en ligne publiquement. 😒
En attendant, beaucoup de ces disques iront finir leur vie en mode anticipé dans les DEEE. Merci la "sécurité".
Et s'ils ne sont pas chers c'est qu'il y a une raison. 😁
J'en ai malencontreusement pris quatre sur eBay sans savoir, sans trop me méfier, qui sont étiquetés NetApp. N'ayant jamais eu de tel matos OVER 9000 propriétaire à la maison ou au travail, comme par exemple des baies de disques EMC ou NetApp, je n'avais absolument pas connaissance de tout ce qui m'attendait. Voici les deux modèles de disques avec lesquels je suis concerné :
- 2x HGST HUC109090CSS600 (famille Cobra-E), dont un est décédé suite à mes essais
- 2x HGST HUC101890CS4204 (famille Cobra-F)
Le disque ne fonctionne pas totalement de manière générique et correctement partout sur d'autres contrôleurs SAS d'autres marques (LSI, ServeRAID, PERC, ...). Il y donc une distinction à faire entre les firmware "custom" et les firmwares constructeur OEM, appelé "génériques" ou civils. "civilian" revenant souvent sur les forums spécialisés. On trouve de ces histoires à la pelle sur le net. Le sujet ne concerne pas un fabricant spécialement. La plupart ont pu faire fonctionner ces disques en l'état, tels quels, simplement en les reformatant avec une taille de secteur standard, en les passant de 520 à 512 octets, pour une utilisation en RAID logiciel du genre unRAID/TrueNAS sur une carte en mode HBA/IT.
- https://www.reddit.com/r/homelab/comments/7qeet1/emcnetapp_branded_520b_block_size_sas_drives/
- https://www.reddit.com/r/netapp/comments/118lcol/netapp_hdd_in_a_dell_server
- https://forums.truenas.com/t/hgst-sas-drive-formatting-troubles/37160
- https://www.youtube.com/watch?v=JFOZ2YM0x04
- https://www.youtube.com/watch?v=BbtPPH3W7nU
Mais dans certains cas changer la taille de secteur à 512 octets en reformatant ne suffit pas à les rendre absolument compatible partout. Car dans mon cas souvient un autre problème de cold boot. Le blocage du disque se fait, selon moi, sur une séquence de démarrage après mise sous tension qui doit être absolument respectée (timing). Sinon à l'allumage les disques "buguent" et ne sont pas détectés correctement. Sur mon Dell PowerEdge T440, que la PERC soit en mode RAID ou HBA, c'est la même chose, la machine est bloquée au boot sur l'écran bleu, la seule solution étant de retirer les disques de la cage et de les remettre. Après cette manipulation ils fonctionnent correctement. Ce qui réclame d'être devant le serveur lors du boot : pas terrible. C'est comme si les disques attendaient une courte période de temps que le contrôleur (ou l'expander de la backplane) leur envoie quelque chose, juste après la mise en tension, sinon c'est trop tard, faut ré-appliquer une déconnexion électrique. Seulement comme la carte contrôleur et/ou la backplane elle aussi doit prendre le temps de démarrer, elle ne répond pas assez vite, ce temps est dépassé, les disques ne sont pas détectés. C'est assimilable à une race condition. C'est mon hypothèse. Même situation que cette personne : https://forums.servethehome.com/index.php?threads/hgst-netapp-sas-drives-most-of-the-time-dont-show-up-on-dell-r730xd-backplane.43001/.
Pour ceux qui auraient fait le rapprochement avec le problème de la broche 3.3V : que les disques reçoivent ce 3.3V ou pas c'est la même chose. Même avec des adaptateurs qui n'apportent pas cette 3ème tension c'est pareil. Le fil n'est pas présent, il n'y a que le 12V et 5V d'appliqués, donc ce n'est pas cela le problème.
- https://dyb.fr/pourquoi-votre-disque-dur-enterprise-ne-demarre-pas-lexplication-du-3-3-v-et-la-solution-kapton/
- https://www.instructables.com/How-to-Fix-the-33V-Pin-Issue-in-White-Label-Disks-/
- https://zackreed.me/hgst-7k6000-not-spinning-not-working/
Donc pour moi cela provient d'une modification du logiciel interne qui a été personnalisé pour un démarrage "spécifique". La solution est simple à première vue : remettre le firmware constructeur à la place, ce qui rendrait le disque conforme à son comportement d'origine. C'est là que les choses se gâtent. Si on essaye, et bien cela ne fonctionne pas. Même mettre le firmware originel du fabricant échoue. On pourrait penser que c'est quelque chose de légitime. Et bien non. C'est de la sécurité. C'est le début des investigations durant des nuits blanches de recherche et de casse tête cet été pour moi.
Les firmware d'origine
On peut les trouver sur le net, notamment sur l'espace de téléchargement du site hddguru.
La mauvaise idée : jouer avec la puce Flash
Ouais c'est facile, yaka (faukon) dessouder la SPI Winbond/Macronix du PCB, la mettre dans un programmateur et hop.
Hélas c'est une autre époque ou pour des techniques de récupération de données très spéciales. Sur les HDD modernes une partie du firmware est en effet dans la puce Flash mais une autre partie est située sur les plateaux du disque. Cette zone est appelée la SA (System Area). Elle est située dans de la zone LBA négative (LBA < 0) et pas obligatoirement de manière contiguë.
Pour garder un ensemble cohérent de firmware et éviter de bricker son HDD, il est donc bon de laisser au firmware installé le soin d'écrire les bonnes sections lui-même du nouveau firmware à la fois dans la flash et sur les plateaux si besoin. Des bouts du firmware global étant répartis de part et d'autre. Donc cette méthode barbare, on oublie.
La protection / Comprendre la logique
Il y en a comme moi qui ont essayés, ils ont eu des problèmes. 😂
Nous avons tenté des commandes à base de sg_write_buffer mais toutes échouent avec des Illegal Request comme réponse.
- https://www.reddit.com/r/DataHoarder/comments/7raoz8/firmware_for_hgst_10k_sas_huc109090css600/
- https://www.truenas.com/community/threads/hgst-hus723020als640-firmware-cross-flashing.61499/
Déjà pourquoi ça ne fonctionne pas ? C'est simple : le firmware du HDD embarque un mécanisme interne de vérification du nouveau firmware à prendre en compte (lors d'une commande sg_write_buffer). C'est le disque dur (ou SSD) LUI-MÊME qui accepte ou refuse le fichier firmware .lod, .sed ou .bin proposé à l'implantation. Le nouveau firmware est accepté uniquement si sa signature condensée SHA256 correspond à une clé publique RSA-2048 déjà inscrite dans le firmware du HDD en place. Il faut donc être familier des principes de chiffrement asymétrique (clé publique / clé privée) et de condensât (checksums / digest).
Un disque qui embarque un firmware NetApp ne pourra être flashé qu'avec un autre firmware signé par NetApp.
Un disque qui embarque un firmware Dell ne pourra être flashé qu'avec un autre firmware signé par Dell.
Etc...
D'où le terme de "Vendor-locked" : les disques sont verrouillés et interdisent le cross-flashing, c'est à dire mettre le firmware d'un autre "vendor" (revendeur) à la place. D'où le fait aussi que les revendeurs (NetApp, Dell, EMC, Cisco,...) doivent repackager/recustomiser le firmware du fabricant (WD, HGST, Seagate...) à leurs clients lorsque le fabricant en sort un nouveau : exemple.
C'est une fonctionnalité proposée par les fabricants (WD, HGST, Seagate...) directement en usine, le firmware est personnalisé pour le client (Nom du fabricant, numéro de modèle, code PIN, clé publique RSA-2048...). Sur un HGST Ultrastar 10K900, il est facile reconnaître la provenance en lisant le numéro MLC. Il démarre toujours par CE pour Cobra-E (famille 10K900) suivi d'un 0 et enfin de 4 caractères alphanumériques (version du firmware).
Un disque NetApp aura donc un firmware noté CE0NAxx, CE0NA00, CE0NA01, CE0NA02, etc... Et cette information est apposée sur l'étiquette constructeur (valeur MLC en rouge), on peut donc en déduire que ces disques sont déjà personnalisés en sortie d'usine.
Un spécimen "civil", destiné à la revente au détail, aura un firmware générique, son MLC équivaut à CE0A5B0 sur l'étiquette de ce spécimen neuf illustré ci-dessous :
Remarque 1 : cette protection N'A RIEN A VOIR avec le chiffrage du disque en lui-même (SED) ou quelconque protection par mot de passe ATA.
Remarque 2 : Ne pas oublier que firmware contenu dans le binaire .lod n'est pas réellement 100% complet, des données variables sont propres au disque dans la Service Area et doivent le rester (calibration des têtes, listing des secteurs défectueux, numéro de série, etc... Ces données ne sont pas et ne doivent pas être mises à jour lors d'un upgrade firmware. Glossaire : https://blog.acelab.eu.com/glossary.
Comment déverrouiller un disque ? RTFM frère
Il faut passer par la case retro-ingénierie et accessoirement se palucher une tonne de documentation. Va falloir fouiner ! Certaines commandes de la norme SCSI sont publiques (T10). D'autres sont cachées (non documentées, documentation non accessible au public) que l'on appelle des VSC (Vendor Specific Commands) ou encore des VUC (Vendor Unique Commands). Elles sont ainsi spécifiques à chaque marque de disque dur, et les constructeurs peuvent faire ce qu'ils veulent avec. J'ai passé des heures à jouer avec les commandes sg_utils que ce soit coté Windows ou Linux avec mon petit PC Lenovo de test :
C'est en envoyant des commandes bien ciblées au disque qu'on arrive à le placer dans un certain état (spacial mode) qui désactivera la vérification de la signature du firmware. Une fois cette fonction désactivée, le HDD pourra ingurgiter n'importe quel firmware: OEM, HP, Dell, EMC, NetApp, etc... Et le cross-flash est donc possible. Hélas seuls des outils professionnels hors de prix peuvent faire ce cross-flash. Du genre le ACELab PC3000 ou chez MRT Lab.
The "Russian dude"
Il est surnommé tel quel par ce site (lug.mtu.edu). Son auteur est je pense assez blasé. J'en comprends la frustration.
E123 est une personne sur des forums qui propose un service de déverrouillage de ces disques à distance (via le bureau à distance de Windows). Un service monnayé contre quelques euros par disque. Ce E123 est très compétent, aucun doute là dessus. Il a dû y passer du temps, et le temps c'est de l'argent. Il ne souhaite pas partager ses secrets. Knowledge is money !
La vidéo ci-dessus est une démonstration de son service. En résumé : le disque connecté se présente comme un DKR5D, il lance un script .bat DOS "CMD" classique, qui démarre un deuxième Niagara en mode CLI (une deuxième instance de Niagara, pas celle que l'on voit à l'écran en graphique). Le script utilise Niagara pour envoyer des commandes au disque afin de le déverrouiller. C'est ici toute la magie, qui est monnayée, cachée dans ce script temporaire. Une fois ce script déroulé, dans un deuxième temps on peut injecter un autre firmware, ce qu'il va faire avec le Niagara déjà ouvert en GUI. Ce logiciel exploite derrière la commande sg_write_buffer. L'injection du nouveau firmware fonctionne. Il montre dans un troisième temps que le disque fraîchement mis à jour fonctionne bien sous le logiciel Victoria avec le nouveau firmware générique implanté. Le disque n'est plus un DKR5D mais un HITACHI générique tout en conservant le même numéro de série. Remarque : il existe une version Linux de Niagara.
Pourquoi partir dans cette direction ?
E123 a laissé quelques indices dans ce post sur le forum hddguru.
E123 :
To reflash HGST disks from one vendor to another, it is necessary to deactivate checks inside the hard drive itself, as provided by the manufacturer. Dig the code, look for keys, look for vendor commands. No free utility, let alone OEM flasher, will help in this case.
Grosso modo il faut analyser le code du firmware ARM (en dumpant les modules de la SA du disque) à la recherche de la routine qui désactivera cette vérification : ce qui signifie trouver les "clés" et des VSC à jouer. Des investigations à faire en solo quoi (hard way), comme lui a dû les faire de son coté. Mais ce n'est pas à la portée de tout le monde de bien savoir lire et décortiquer du code ARM décompilé. Je n'ai pas IDA. Peut-être demander à une IA ?
Le matériel nécessaire
Comme déjà dit, il faudra envoyer des commandes "sur mesure" au disque dur. Pour cela il est conseillé d'utiliser une carte HBA en mode IT (Initiator-Target). Certaines cartes comme la PERC H730P de mon Dell T440 peuvent basculer dans ce mode en jouant dans les paramètres. Sinon vous pouvez prendre une carte contrôleur SAS type LSI2008 déjà pré-flashée sur AliExpress pour quelques dizaines d'euros. Ce sont des cartes Dell, IBM/Lenovo ou HP recyclées dont le firmware d'origine a été re-flashé pour l'utiliser dans ce mode.
En gros, elle fonctionne comme un passe-plat. Les commandes SCSI transitent telles quelles de l'Initiator (hôte Linux/Windows/BSD) à la Target (disque dur) sans restriction/translation sur le chemin. Par opposition au mode RAID, qui comme son nom l'indique, embarque toute la couche de logique de gestion RAID (communications internes indépendantes entre la carte et ses disques, sans intervention de l'hôte/OS) et peut maquiller la communication. Vidéos de the-art-of-server sur Youtube :
- Comparing HBA IT mode SAS controllers | 2020 Edition
- 6 Things you need to know about the LSI 9211-8i (9201-8i) vs Dell PERC H310
Les logiciels nécessaires
Pour envoyer des commandes custom SCSI au disque SAS il faut passer par les outils sg_utils (paquet sg3_utils sur Linux). Pour les Windowsiens, il existe des versions exécutables pré-compilées qui font le travail même sous Windows 7.
Pour investiguer sur le plan logiciel
J'ai eu un temps utilisé un Dell Optiplex 380 mais après j'ai pris un Lenovo Edge 72. Un truc assez vieux qui accepte Windows 7 out of the box.
- Dual boot Fedora 42 / Windows 7 (menu grub2 / os-prober), utilisation à distance (RDP/SSH)
- Un petit script pour dumper la ROM du disque en modules. (script boucle for)
- Des outils pour séparer les modules d'un package firmware : VOPT, CODD, CODF, ... (petit script de fzabkar)
- Un éditeur hexadécimal
- Les commandes linux de fouinage : binwalk, strings, file & vbindiff
- Ghidra (explorer/désassembler/décompiler le code ARM 32bits LE du firmware et les dumps de ROM)
En aparté, pour gruger la timebomb du logiciel Niagara sous Linux. Avec Ghidra je suis parti à la recherche de la fonction qui affiche le message dans libtcluil.so. Petite trouvaille, on remarque que le logiciel essaye de détecter si on est sur le réseau d'HGST ou pas (usage en interne à l'entreprise) "onHGSTNetwork".
Pour gruger, il suffit de supprimer le test de retour de la fonction niagaraExpired. Ainsi la fonction niagaraExpired est toujours exécutée mais son résultat n'est plus pris en compte (return non exploité). Le logiciel démarre intégralement sans jamais expirer. Il me semble que j'avais tenter de gruger l'heure du PC sans succès. Avant :
Après :
Un Niagara débloqué sous Linux. Plus besoin de Windows 7.
Des documentations téléchargées du web...
Les premières tentatives, comment déverrouiller un disque ?
Au départ benoîtement, j'ai cru qu'il suffisait de lire la documentation constructeur. HGST implémente le protocole de sécurité "TCG Entreprise SCC". Ces fonctionnalités ne servent qu'aux disques dits "SED", chiffrés en interne. HGST propose deux modèles de disques, l'un chiffré (CSS601) et un autre non-chiffré (CSS600). Mes disques sont non-chiffrés. Mais en fait derrière le soft entre les deux modèles est peut-être identique ? Que ce soit un CSS600 ou 601 ce sont juste des paramètres qui changent dans le firmware. Pourquoi parler de ça ? Ce système de TCG embarque toute la logique de sécurisation globale du disque dur jusqu'au chiffrement des données sur les plateaux par zones (appelées bandes). Les données sur les plateaux sont découpées par bandes/zones et chaque zone à sa clé de chiffrement. C'est indiqué dans la documentation. HGST se sert du mécanisme TCG pour gérer l'aspect sécuritaire de deux autres fonctionnalités dont celle qui nous intéresse. Comme expliqué dans la documentation. Il est possible de désactiver cette vérification de signature de firmware. Ce qui ouvrirait la porte à notre "cross-flashing". Comme indiqué, ces fonctionnalités sont "un plus" qui sortent du cadre de la norme TCG.
En gros, il faut utiliser certaines fonctionnalités fournies par ce module TCG et aller modifier la table "Admin SP". SP pour Security Provider afin de désactiver la fameuse vérification de signature de firmware qui nous embête.
Les commandes TCG sont encapsulées via les commandes SCSI suivantes :
- SECURITY PROTOCOL IN (A2h) = IF-RECV
- SECURITY PROTOCOL OUT (B5h) = IF-SEND
Les fonctions liées à TCG sont lourdes à mettre en œuvre, il y a toute une négociation (aller-retour) à base de jeton (comID) à faire avec le disque dur avec une authentification et ça réclame un vrai programme dédié.
Il faudrait :
- commencer par faire un "Level 0 discovery"
- débuter une session et obtenir un comID
- s'authentifier avec le MSID ou un code pin de 32 caractères
- pour enfin envoyer la commande pour changer la valeur qui nous intéresse : passer Firmware_Dload_Port.PortLocked à False
- à ce stade, le HDD est déverrouillé et ainsi prêt à accueillir n'importe quel firmware (civil ou non).
J'ai pu trouver sur GitHub un utilitaire génial fait en Go qui fait 95% du travail : https://github.com/open-source-firmware/go-tcg-storage/tree/main
Reste un peu à l'adapter... mais il y a un problème, il faut s'identifier auprès du disque avec le MSID ou un code PIN que l'on ne connaît pas. J'ai ressorti Ghibra à la recherche du mot de passe. Le code PIN TCG réclame que le longueur du mot de passe soit exactement de 32 caractères. Ni plus, ni moins. La longueur n'est pas variable. Sachant que le MSID par défaut est le numéro de série du disque établi sur 8 caractères répété 4 fois, donc 32 caractères. J'ai quand même trouvé du "Hello World!" dans le firmware. Hélas je n'ai pas les symboles pour tout comprendre.
Mais rien n'empêche le vendor d'avoir mis autre chose comme mot de passe. Mais hélas cette piste s'arrête là car les commandes TCG avec cet utilitaire en Go n'ont pas d'effets. La partie TCG semble complètement désactivée. Idem dans Niagara. Donc je pense que ce sont d'obscures commandes non-documentées qui gèrent cet aspect... et alors là pour les trouver... 😤🤯
La capitulation
Courant août j'ai abandonné. Trop complexe pour moi tout seul de rendre mes HGST OEM, c'est figé en l'état sur mon NAS.
J'en ai même perdu un sur les quatre durant mes essais, comme d'autres sur les forums, en bricolant partiellement les différents modules qui composent la Service Area avec sq_raw / sg_write_buffer. En octobre dernier, mr44er sur hddoracle poste de nouvelles informations issues d'une IA façon GPT, une lueur d'espoir. J'ai essayé certaines commandes qu'il a posté mais elles sont à moitié fausses. Le "special mode" je l'avais déjà tenté bien avant.
Nous sommes en février 2026 et donc je confirme que j'ai lâché l'affaire, trop de temps perdu même si j'ai appris pas mal. Comme d'autres avant moi, j'ai contacté ce fameux russe par courriel avec une petite vidéo faite en privée en anglais pour lui expliquer tout cela. Il est resté sur l'affaire des 520->512 octets et qu'après cela il n'y a pas de restrictions, que les disques fonctionnent bien en restant en firmware NetApp. Donc l'opération ne servirait à rien. Oui ça fonctionne, mais rien à propos de mon affaire de cold boot. Après une seconde demande quelques semaines plus tard, j'ai eu une réponse négative, grosso-modo ce n'est pas intéressant pour lui car je n'ai que trois disques à flasher, il en faudrait une dizaine pour que l'on parle sérieusement. Je pense qu'il traite plus en business/B2B qu'avec des simples particuliers ponctuels comme moi ça lui prendrait trop de temps. Finalement je sors la carte bleue et je me prends des SSD d'occasion Dell reconditionnés comme ça plus de problème.
Un jour peut-être on aura une solution gratuite mise en ligne publiquement. 😒
En attendant, beaucoup de ces disques iront finir leur vie en mode anticipé dans les DEEE. Merci la "sécurité".