Alors, la question qui tue : comment ces clés sont-elles passées en mode lecture seule ?
Qu’est-ce que ces clés ont de particulier ? A quoi servaient-elles ? Que contiennent-elles ?
Ce ne seraient pas des clés U3 ? Tu as essayé u3-tool ?
Marchera pas. Ça ne fait que tromper la couche block device du noyau, pas la clé elle-même. D’autre part, utiliser hdparm pour ça est excessif (comme formater ou lister les partitions avec gparted), on peut le faire aussi bien avec blockdev qui est inclus dans le paquet de base util-linux.
Ce que l’auteur de ces lignes n’a pas compris, c’est que les paramètres appliqués à sdb ne sont pas appliqués à sdb1. Pour la couche block device, ce sont deux périphériques indépendants. Oui, je sais, c’est un peu particulier.
Pas besoin de décharger le module, on peut ajouter des quirks quand il est chargé avec
echo -n "0123:abcd:w" > /sys/module/usb_storage/parameters/quirks
Mais à mon avis ça ne marchera pas non plus. Ça trompera seulement le pilote et ça ne marchera que si l’information de protection en écriture fournie par la clé est bidon.
Mauvais outil, changer d’outil.
@euchcat, @grandtoubab, @DarkGagan : qu’est-ce que vous ne comprenez pas dans « protégée en écriture » ?
Un disque protégé en écriture n’existe physiquement pas, il a bien fallu écrire des données à l’intérieur pour pouvoir au moins la relire, soit le disque est crypté, soit des données ont été mise à l’intérieure avant de modifier le disque pour empêcher de nouvelles écritures. Dans le premier cas, un reformatage complet va tout effacer et remettre la clé dans un état R/W, dans le deuxième cas, il faut intervenir sur le hardware pour enlever le blocage en écriture. What else ?
Bonjour
Plutôt que de formater la clef USB,
il vaut mieux d’abord créer une table des partitions (si elle n’existe pas déjà) sur la clef,
puis créer une partition (ou en choisir une déjà créée),
et enfin formater cette partition .
ce sont des clefs de recovery directement fabriquées en lecture seule.
Sur google:
2 J'aime
Bien sûr que si. Essaie d’écrire dans un CD-ROM (pas un CD-R), tu m’en diras des nouvelles.
C’est pareil avec des clés USB quand elles tombent en panne : le contrôleur intégré se verrouille en lecture seule et bloque l’écriture.
J’ai aussi l’exemple d’une clé USB contenant la documentation de l’appareil avec lequel elle est fournie, qui est accessible en lecture seule.
Un contenu crypté n’a jamais empêché d’écrire par dessus et n’a jamais fait apparaître le support comme étant en lecture seule.
Ce n’est pas forcément possible. Cf. les mémoires programmables une seule fois (PROM) et non effaçables, ou protégées par un fusible interne claqué après l’écriture initiale.
Je parlais bien d’un disque, non d’une ROM.
La différence avec un « disque » (usb ou autre ) et une ROM (IC ou CD) est que les premiers sont dépendant d’un firmware.
La preuve de ce que j’explique est donné juste au dessus par la réponse de Zargos.
CQFD…
What else ?
Moi je pensais à une clé usb gravée avec une iso type cdrom donc accessible en lecture seule et pour faire sauter ça on refait une table de partoches et c’est bon. Pour la clé si c’est matériellement bloqué en lecture seule ça se complique. Un soft spécial? Pire encore: ouvrir la clé et voir si en reliant 2 points du circuit on récupère l’accès mais on va loin là.
Il faudrait savoir comment Dell s’y est pris pour passer ces clés en lecture seule.
Alors c’est gentil de vouloir aider, mais c’est pas comme si j’avais expressément écrit « ni fdisk, ni mkfs ni gparted ne marchent » dans le message d’origine…
Oui, j’ai oublié de le préciser dans le message originel.
Refusé car la clé est en lecture seule.
Bonjour,
Il y a aussi dans le cas des cartes sd un bit write protect qui peut être modifié, c’est peut être aussi le cas dans le cas des clés usb.
/sys/block/mmcblk0/force_ro et /sys/block/mmcblk0/ro_lock_until_next_power_on sont les fichiers utiles, tu peux regarder https://01.org/linuxgraphics/gfx-docs/drm/driver-api/mmc/mmc-dev-parts.html
Merci.
Mais hdparm j’ai déjà expliqué que ça ne marchait pas (et PascalHambourg a expliqué pourquoi).
Pour le deuxième, oui je pensais à une solution de ce genre (sauf s’il y a plus simple évidemment), mais je n’ai aucune idée de comment faire.
C’est différent de ce que propose Zargos ?
Désolé, j’ai vu après avoir posté pour hdparm. Je pense que c’est différent de ce que propose Zargos, mais pas totalement sûr.
Tu peux regarder https://01.org/linuxgraphics/gfx-docs/drm/driver-api/mmc/mmc-dev-parts.html pour voir si le fichier force_ro existe
Merci, le Canard ne me proposait pas ce lien.
Ce sont des exécutables windows, apparemment récupérés sur un site russe ?
Pas trop risqué comme démarche ?
Ma clé est noire avec logo bleu (et couvre-clé argenté) mais c’est marqué Mentor Media, pas Silicon Media comme sur ton lien. Cela change quelque chose ?
Merci, mais sur quelle partition sachant que ma clé s’affiche en /dev/sdx ?
/dev/sdxboot1 ?
C’est pas super clair… et j’ai pas envie de faire ça sur la mauvaise !
Je viens de tester avec une clé usb mais visiblement contrairement aux cartes sd il n’y a pas le fichier force_ro, donc ce que je propose n’est visiblement pas transposable aux clés usb 
En gros ça aurait donné
echo 0 | sudo tee /sys/block/mmcblk0/force_ro
mais à la place de mmcblk0 mettre sdx.
Pour info, j’avais utilisé cela sur une carte sd bloquée via le petit loquet (dont la position est déterminée par le port sd, donc côté pc et non côté carte sd) et si j’ai bien compris ça modifie le bit de protection temporaire en écriture du contrôleur de la carte sd. Donc j’avais pu écrire sur une carte sd sensée être bloquée.
Désolé, j’aurais dû tester avant de poster…
Ça ne fonctionne pas souvent le loquet, sur un pc portable (asus) le loquet des cartes sd ne sert à rien: j’ai pu écrire à loisir sur les cartes avec loquet côté ‹ ‹ lock › ›… Je l’ai découvert pas hasard en oubliant de le retirer
Pour avoir démonté des tas de trucs, je vois souvent des points de contacts sur des circuits. C’est en général des pins de connexion usine pour tester le matos ou faire des manips comme la 1re écriture d’un bios ou similaire. J’en ai vu aussi sur des cartes de disques durs ou des ssd, donc c’est selon moi probable sur clé usb aussi. Parfois c’est juste un shunt donc un petit point d’étain et c’est reparti. La difficulté est dans l’expectative par manque d’infos là et c’est pas les constructeurs qui les donneront je pense. Si tu as plusieurs clés identiques, ça vaudrait le coup d’en ‹ ‹ sacrifier › › une pour pouvoir utiliser les autres, à @lutech de décider c’est son matos. Mais une telle info dans un joli tuto sur le net ferait l’effet d’une petite bombe pour tout un tas de geek hardware 
2 J'aime
Pour info mon chef de service a réussi sous Windows, avec des exécutables qui fonctionnent sur un modèle de clé particulier (comme on en a plusieurs, il faut choisir le bon en fonction de la clé).
Il ne m’en a pas dit plus, malheureusement.
Dommage de ne pas arriver à gérer ça mieux sous Linux…