Comment vérifier la version du firmware Trezor ? (Informations sur l'appareil)

Récupération d'informations sur l'appareil

1. Connectez l'appareil Trezor à un ordinateur à l'aide d'un câble USB certifié. Assurez-vous que l'appareil est allumé et déverrouillé via la saisie du code PIN.

2. Ouvrez un terminal ou une interface de ligne de commande avec des privilèges administratifs. Confirmez que Python et pip sont installés, car trezorctl en dépend.

3. Exécutez trezorctl get-features pour récupérer des métadonnées complètes du micrologiciel. Cette commande renvoie une sortie au format JSON contenant les identifiants de version, les types de pièces pris en charge et les indicateurs matériels.

4. Localisez le champ « firmware_version » dans la réponse. Il apparaît sous la forme d'une chaîne numérique en trois parties (par exemple, « 2.5.2 »), où chaque segment indique les niveaux de révision majeurs.mineurs.des correctifs.

5. Comparez la version récupérée avec le journal officiel des modifications du micrologiciel Trezor hébergé sur https://github.com/trezor/trezor-firmware/releases pour identifier le comportement connu, les correctifs de sécurité et les notes de compatibilité.

Flux de travail de vérification en ligne de commande

1. Installez trezorctl s'il n'est pas déjà présent : pip install -e . à partir du répertoire racine du référentiel trezor-firmware cloné.

2. Validez l'intégrité de l'outil en exécutant trezorctl --version . La sortie doit correspondre à la dernière version CLI publiée (par exemple, « 0.17.2 ») pour garantir l'alignement du protocole avec le micrologiciel de l'appareil.

3. Répertoriez les appareils connectés avec la liste trezorctl . Une réponse saine affiche exactement une entrée au format '- Trezor T (version 2.5.2)' , confirmant la communication bidirectionnelle.

4. Évitez d'interpréter les chaînes de version uniquement à partir des interfaces basées sur un navigateur. Wallet.trezor.io peut mettre en cache une logique d'interface utilisateur obsolète ; l’interrogation directe CLI reste la source canonique de vérité.

5. Répétez l'appel get-features après toute réinitialisation physique ou entrée en mode de récupération pour vérifier qu'aucune mise à niveau silencieuse ne s'est produite lors de l'initialisation.

Implications de la version du micrologiciel pour la prise en charge des crypto-monnaies

1. Le micrologiciel v2.4.4 a introduit la prise en charge native des adresses Cardano (ADA) Shelley. Les versions antérieures renvoient le code d’erreur 1015 lorsqu’on leur demande les chemins de dérivation ADA.

2. La génération d'adresses Ethereum via la somme de contrôle EIP-55 nécessite la version 2.3.2 ou supérieure. Les versions antérieures émettent des chaînes hexadécimales minuscules incompatibles avec la plupart des interfaces dApp.

3. Bitcoin La dérivation d'adresse Taproot (P2TR) est devenue disponible à partir de la version 2.5.0. Tenter de --script-type taproot sur un ancien micrologiciel déclenche le rejet du type de script non pris en charge.

4. L'intégration de Monero (XMR) a été entièrement supprimée dans la version 2.5.1 en raison de conflits de spécifications de portefeuille déterministe. Les appareils exécutant cette version omettront les champs liés à XMR dans la sortie get-features .

5. La gestion des balises de destination Ripple (XRP) a été modifiée dans la version 2.4.0 : le micrologiciel existant échoue à la validation de la signature lorsque les balises dépassent 10 chiffres, ce qui entraîne des rejets de transactions au niveau du grand livre.

Considérations relatives à l'environnement hors ligne

1. La commande get-features fonctionne sans accès à Internet. La prise de contact du périphérique et l'énumération des fonctionnalités se produisent localement via le protocole USB HID.

2. Aucune clé privée, phrase de départ ou donnée de transaction ne traverse la machine hôte lors de l'interrogation de version. Seuls les attributs publics des appareils sont exposés.

3. Les configurations à air isolé nécessitent un transfert manuel de la sortie JSON vers un système en ligne pour la comparaison du journal des modifications. N'exécutez pas trezorctl sur des machines non fiables, même pour des requêtes en lecture seule.

4. Lorsque vous utilisez des machines virtuelles, assurez-vous que le relais USB est activé et que l'ID du fournisseur Trezor (0x1209) et l'ID du produit (0x53c1 ou 0x53c0) sont sur la liste blanche dans les paramètres de l'hyperviseur.

5. Certaines distributions Linux nécessitent des règles udev pour accorder l'accès aux utilisateurs non root. Les règles manquantes se manifestent par des erreurs d'autorisation refusée malgré une détection correcte du périphérique dans la liste trezorctl .

Foire aux questions

Q1 : Puis-je récupérer la version du micrologiciel sans installer trezorctl ? Oui. Accédez à wallet.trezor.io, connectez votre appareil et cliquez sur « Informations sur l'appareil » dans la barre latérale gauche. La version affichée correspond à ce que rapporte get-features .

Q2 : Pourquoi la liste trezorctl affiche-t-elle « Trezor Model T » mais get-features renvoie « Trezor One » ? Cela indique une incompatibilité du micrologiciel ou une corruption du chargeur de démarrage. Effectuez une réinstallation complète du micrologiciel à l'aide de l'application de bureau officielle Trezor Suite.

Q3 : La version du micrologiciel affecte-t-elle la gestion de la phrase secrète BIP-39 ? Oui. La logique de chiffrement de la phrase secrète a été modifiée entre la version 2.2.x et la version 2.3.x. Les appareils mis à niveau au-delà de cette limite peuvent générer des adresses différentes pour des combinaisons mnémoniques et phrases secrètes identiques, à moins qu'elles ne soient explicitement dérivées.

Q4 : La version du micrologiciel est-elle visible en mode de récupération ? Non. Le mode de récupération désactive tous les rapports sur les fonctionnalités. L'inspection de version nécessite un état de fonctionnement normal avec un code PIN déverrouillé.