[MàJ] Copies de puce FT232 : Microsoft supprime les pilotes fautifs

[MàJ] Copies de puce FT232 : Microsoft supprime les pilotes fautifs

Another brique in the wall

Avatar de l'auteur
Vincent Hermann

Publié dans

Sciences et espace

24/10/2014 5 minutes
214

[MàJ] Copies de puce FT232 : Microsoft supprime les pilotes fautifs

Un pilote distribué plus tôt dans le mois par Windows Update cause des ravages avec les anciens circuits Arduino (ou les modèles « compatibles ») et de nombreux équipements possédant un clone de puce FT232 du constructeur écossais FTDI. En cause, un pilote émis par ce dernier et rendant les copies de sa puce totalement inopérantes. Explications.

Un pilote qui reprogramme une puce  

La puce FT232 de FTDI est relativement connue dans le monde des bidouilleurs. Elle est dédiée à une tâche : convertir le signal provenant d’un port USB vers un port série. Elle était présente notamment sur les circuits Arduino jusqu'en 2010 mais fait l’objet de très nombreuses copies. On distingue alors deux cas : il s’agit soit de puces génériques calquant son fonctionnement, soit de copies étant vendues comme des puces légitimes. Il s’agit donc de contrefaçons.

 

Chaque périphérique USB est identifié par deux références. La première, nommée VID (Vendor ID), est fournie par le groupe USB au constructeur, de manière unique. L’autre est le PID (Product ID) et dépend du constructeur pour la propre identification de ses produits. Windows se sert du duo d’identifiants pour reconnaître le matériel présent dans la machine, et ainsi installer un nouveau pilote quand il se présente dans Windows Update.

 

Le problème est qu’un nouveau pilote fourni par FTDI est venu mettre une sacrée pagaille dans le petit monde des bidouilleurs. Les fausses puces ont été reconnues comme des vraies, mais le pilote, lui, semble faire la différence. En cas de puce non officielle, il reprogramme le Product ID pour le fixer à 0000. Résultat : une fois l’opération effectuée, la puce ne fonctionne plus, que le périphérique soit branché à un PC sous Windows ou Linux, ou même sur un Mac. Aucune machine n’est plus à même de reconnaître un tel PID.

Un CLUF caché dans les fichiers d'installation 

C’est le site Hack A Day qui a révélé l’ampleur du problème hier. Il indique que les copies de la puce FT232 sont très nombreuses et qu’il est particulièrement difficile de détecter les différences par un simple coup d’œil à la puce. Seul un examen particulièrement attentif du silicium permet de séparer la vraie puce de sa copie.

 

La question du pourquoi n’est pas claire. Actuellement, ni FTDI, ni Microsoft n’ont réagi aux questions sur le sujet. Les regards se dirigent surtout vers le constructeur écossais que beaucoup accusent d’avoir sciemment voulu se débarrasser des copies de la manière forte. Comme le pointe Ars Technica, le pilote est accompagné d’un CLUF mais il faut spécifiquement le chercher pour prendre connaissance d’un passage où FTDI annonce clairement qu’en cas de fausse puce, le composant pourrait « être endommagé irrémédiablement ».

Il faudra reprogrammer manuellement le PID de la puce 

Le problème est qu’il est difficile de savoir s’il s’agit d’une réelle volonté de FTDI de se débarrasser d’une seule traite des copies de sa puce. Le constructeur pourra en tout cas difficilement arguer que le CLUF était là pour prévenir. En effet, l’installation via Windows Update réalise toutes les étapes de manière automatique. Dans le cas d'un pilote, le contrat de licence n’est jamais affiché, et l’utilisateur n’a aucun moyen de lire le texte… avant que le pilote ne soit déjà installé. Difficile pourtant d’imaginer qu’un constructeur se lancerait dans une méthode aussi brutale pour se débarrasser des copies, au risque d’en garder une très mauvaise réputation.

 

L'autre explication est que FTDI a pu fournir un pilote qui devait effectivement réaliser certaines tâches au niveau de la puce. Une FT232 authentique aurait accepté les instructions sans ciller, tandis que les copies, présentant de très légères différences, les auraient mal interprêtées.

 

Mais si le pilote a déjà été installé et que la puce semble effectivement endommagée, que peut-on faire pour remédier au programme ? Hack A Day indique qu’il faut se rendre sur la page des utilitaires fournis par FTDI et récupérer celui dédié aux puces FT232 (une recherche dans la page permet de tomber rapidement sur le lien). Il faut ensuite l’exécuter depuis un PC sous Windows XP ou Linux et changer le PID de la puce. Une fois la procédure réalisée, il faudra faire attention à ne plus rebrancher l’appareil USB sur Windows récent équipé du nouveau pilote.

214

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Un pilote qui reprogramme une puce  

Un CLUF caché dans les fichiers d'installation 

Il faudra reprogrammer manuellement le PID de la puce 

Le brief de ce matin n'est pas encore là

Partez acheter vos croissants
Et faites chauffer votre bouilloire,
Le brief arrive dans un instant,
Tout frais du matin, gardez espoir.

Commentaires (214)


Article intéressant.


<img data-src=" /><img data-src=" />&nbsp;Je note


Ce n’est pas un bug, c’est une fonctionnalité !

La folie de la logique DRM à de beau jours devant-elle .


C’est une obsolescence vraiment programmé pour le coup&nbsp; !

<img data-src=" />




En effet, l’installation via Windows Update réalise toutes les étapes de

manière automatique. Dans le cas de pilote, le contrat de licence n’est

jamais affiché





C’est Crosoft qui l’a dans l’OS dans ce cas ?

&nbsp;


Le problème est différent. Là il veulent surtout se débarrasser de copie de leurs puces maison. Ces dernières usurpent les VID:PID pour utilisent les drives de FTDI à leur insu.


J’ai pas compris pourquoi un vrai pilote s’installait sur une fausse puce.



Ensuite j'ai pas non plus compris pourquoi FTDI devait prévenir qu'utiliser un vrai pilote sur une contrefaçon pouvait s'avérer fatal pour la puce... Ca me semble logique.

Windows 7&8 je suppose ?



&nbsp;


Parce que les controlleurs contrefaits usurpent le VID de FTDI.



Le problème n’est pas simplement que le pilote n’est pas compatible ou “fatal” pour la puce, mais que le pilote que FTDI à diffusé est spécifiquement développé pour détecter les puces contrefaites et volontairement les reprogrammer de sorte qu’elle soient inopérantes quel que soit le driver utilisé.



C’est une démarche volontaire du constructeur pour détruire des périphériques.





A savoir qu’ici on parle de contrefaçon de puce, mais cela peut toucher de nombreux produits légitimes (non-contrefaits) car les sous-traitant n’hésitent pas à substituer les puces par des équivalences moins chères sans en informer les clients. De même certains sous-traitants sont parfois aussi trompés par leur fournisseurs et achètent des puces contrefaites sans le savoir.


Déjà cloner le hardware, c’est discutable.

Mais en plus utiliser le “Vendor ID” de FTDI pour profiter des drivers officiels de FTDI, et s’épargner la peine de coder le software (driver)… c’est vraiment petit.



On ne peut même pas utiliser l’excuse de vouloir créer un équivalent “open hard/source” low-cost.

C’est clairement de la contrefacon de hardware a but lucratif.



Pas de bol pour les consommateurs. Pour eux c’est un coup dur.

Mais le fautif c’est en premier lieu le constructeur du clone qui ne fournit pas son propre VID + driver.


Je suis très content de ne ni utiliser de produits FTDI, ni Windows.

&nbsp;Se baser sur le VID:PID pour détecter une contrefaçon ça dépasse l’entendement (si c’est une contrefaçon il faudrait s’attendre à un VID « contrefaçon de FTDI ?), permettre de reprogrammer ce genre de chose depuis l’USB l’est encore plus (ça devrait être en PROM).

Il y a des techniques plus élaborées et plus respectueuses des utilisateurs que de faire un patch débile non testé et distribué de façon automatique sans qu’il n’y ait eu aucune vérification en particulier de la part de Microsoft.



C’est peut être un cas de figure où la nouvelle loi sur la consommation pourrait être invoquée (obsolescence programmée !).


Non le fautif est FTDI qui diffuse un drivers qui a été explicitement programmé pour désactiver des puces non officielles !



Le drivers possède un gros &gt; IF puce_officielle THEN flash(bon_firmware) ELSE destroy_hardware() END !


Très bon le sous-titre :)



&nbsp; &nbsp;







francois-battail a écrit :



C’est peut être un cas de figure où la nouvelle loi sur la consommation pourrait être invoquée (obsolescence programmée !).



L’obsolescence n’a rien à voir avec la reprogrammation de contrefaçon comme ici, donc non je ne vois pas en quoi cette loi pourrait être évoquée ici.



Il-y-a un sacré problème quand même. Vous présentez les choses d’une telle façon qu’à l’énoncé du titre, on a l’impression que Microsoft en tant qu’acteur systématiquement responsable/coupable/condamnable est venu avec ses milliards emmerder des petits programmeurs gentils comme tout qui veulent le bien (à définir) et aiment les bisounours.

Windows update dans le cas des MAJ matériel, n’est que le vecteur de MAJ. Microsoft les valide certes, donc connaissait l’effet de ce driver, mais de là à les charger comme ça.








francois-battail a écrit :



Je suis très content de ne ni utiliser de produits FTDI, ni Windows.

&nbsp;Se baser sur le VID:PID pour détecter une contrefaçon ça dépasse l’entendement (si c’est une contrefaçon il faudrait s’attendre à un VID « contrefaçon de FTDI ?), permettre de reprogrammer ce genre de chose depuis l’USB l’est encore plus (ça devrait être en PROM).

Il y a des techniques plus élaborées et plus respectueuses des utilisateurs que de faire un patch débile non testé et distribué de façon automatique sans qu’il n’y ait eu aucune vérification en particulier de la part de Microsoft.



C’est peut être un cas de figure où la nouvelle loi sur la consommation pourrait être invoquée (obsolescence programmée !).









La diffusion de pilotes via Windows Update est soumise à une certification WHQL. Donc Microsoft a bien testé les drivers du fabriquant avec le hardware fourni par le fabriquant.



En gros tu reproches à MS de ne pas avoir testé le driver du fabriquant avec des puces de contrefaçon avant d’accorder la certification WHQL.



Par quel miracle MS aurait pu deviner qu’il existait un marché parallèle pour ces puces, et que le nouveau driver ferait la distinction entre les puces du fabriquant et les puces contrefaites, et qu’il aurait un comportement différent sur les puces contrefaites?



beau titre à clic, mais complètement faux du coup, non? “Un pilote distribué par Windows Update « brique » une puce aimée des bidouilleurs” “une puce aimée” … les copies de la puce aimée oui … &nbsp;et bon MS ‘y est en effet pas pour grand chose ici, sauf pour le côté “install quasi automatique”



pareil pour “des ravages avec les circuits Arduino et de nombreux équipements possédant une puce FT232 du constructeur écossais FTDI.” Aucune puce FTDI n’est touchée, si? On frôle le nawak là ..



&nbsp;Bref, ils auraient du la faire exploser, plutôt .. (humour lol haha :p)


C’est donc pas les contrefacteurs qui pleurent mais plutôt les utilisateurs finaux.

Je plussoie hurd, c’est beau la mentalité DRM.


Autant s’attaquer aux contrefacteurs c’est légitime, autant détruire sciemment du matériel, même s’il viole une propriété intellectuelle c’est plus que limite quand même.

Après la plupart des bidouilleurs d’arduino ne sont pas sous windows je pense mais bon…


Ah ? Voyons, n’est-ce pas sciemment que cette mise à jour a été poussée ? Pour l’aspect « programmée » le jeu de mot était facile mais permettre de reprogrammer le VID:PID depuis l’USB je le répète c’est stupide (d’habitude c’est une série spéciale commandée au constructeur puisque ces informations font partie du masque).

Plutôt que de s’attaquer au contrefacteurs, on préfère s’attaquer à distance avec une rustine foireuse qui a pour effet de planter les utilisateurs légitimes.

C’est un peu facile et surtout très inquiétant si ça se généralisait.


Ça sent bon les actions de groupes à venir.


Moralité, utilisez Linux pour programmer votre Arduino.<img data-src=" />


“Au secours, ma puce contrefaite ne marche plus, vous l’avez cassé !”

“Ah, comme ça on contrefait ma puce et on arrive à se plaindre ?”



Aucune pitié pour les contrefacteurs. Si les consommateurs ont un problème avec leur puce, ils peuvent se retourner contre le vendeur. Ensuite si le vendeur a un problème, il se retourne contre son fournisseur. Si le fournisseur a un problème, il se retourne contre le fabriquant. Si le fabriquant a un problème, il n’avait qu’à pas contrefaire des puces.



Et c’est ainsi que ça fonctionne partout dans le monde !

Oui, des utilisateurs seront embêtés, mais c’est pas dramatique, si le produit leur plait, ils auront qu’à prendre un officiel de la marque ou s’orienter vers un concurrent.



Quant à l’usurpation de VID:PID, c’est grave. Si tu fais une puce compatible, tu changes le VID:PID et à la limite tu peux hacker le driver officiel pour qu’il accepte ta version (souvent juste un fichier ini), mais jamais tu n’utilises l’officiel !


Ce que je reproche à Microsoft, qui lui a pu lire les CGU, c’est de ne pas procéder à des vérifications plus poussées eu égard aux implications potentielles, en particulier juridiques.

L’utilisateur final peut difficilement être taxé de complicité de contrefaçon, c’est plutôt une victime.

Et si au lieu d’une Arduino c’était un équipement critique (industrie, embarqué, médical, transport…) ?


Je voudrais rien dire, mais y’a pas que les bidouilleurs que ça touche. Ca risque de toucher aussi pas mal de techs réseaux qui passent par des adaptateurs USB pour relier des switchs aux PC portables.



Franchement, c’est vraiment pas malin de la part de FTDI car à priori, on n’a aucun moyen de savoir si le produit final contient une puce originale d’une puce contrefaite.

Et puis, pour ce genre d’adaptateur, sincèrement, quand on achète, on se fiche royalement de la puce à l’intérieur, et généralement, c’est pas indiqué en plus.



En tout cas, j’espère que ça va pas me planter mon cable USB-Nullmodem perso qui est branché sur mon petit routeur Alix…


Mais elle sert à quoi cette puce au bout du compte ?


Juste un truc, combien de bidouilleurs travaillent sous windows ? Et par mis ceux ci, combien laissent le processus winupdate courir tout seul ou quand bien même laisse les MAJ se faire automatiquement ?

Après, à qui la faute, il me semble pas que ce soit le plus important car c’est comme d’habitude avec tous ces système de DRM, c’est l’utilisateur final qui trinque. La contrefaçon en électronique est quelque chose de courant. La cause racine reste la contrefaçon qui reste un fléau dans le milieu de l’industrie. Imaginez les impacts que cela peut avoir dans le médical ou l’aéronautique.








francois-battail a écrit :



Ce que je reproche à Microsoft, qui lui a pu lire les CGU, c’est de ne pas procéder à des vérifications plus poussées eu égard aux implications potentielles, en particulier juridiques.

L’utilisateur final peut difficilement être taxé de complicité de contrefaçon, c’est plutôt une victime.

Et si au lieu d’une Arduino c’était un équipement critique (industrie, embarqué, médical, transport…) ?





Je ne pense pas qu’on puisse reprocher à MS de ne pas communiquer les CGU des produits Arduino, c’est la société Arduino qui aurait du rendre ces CGU visible ou en préciser la nature à MS.



Déjà que l’installation de pilotes, c’est dans les MAJ facultatives qui ne sont pas automatiques par défaut.



Pour megadub :



&nbsp;Deuxième phrase de l’article : “Elle est dédiée à une tâche&nbsp;: convertir le signal provenant d’un port USB vers un port série.”



Dans le cas d’un Arduino, elle sert de liaison entre l’ordinateur et la mémoire programmable.


Le problème ne concerne pas Arduino. Mais le driver FTDI homologué par MS à travers un circuit supposé strict pour éviter de telles possibles déconvenues aux utilisateurs de systèmes Microsoft.








Orphis a écrit :



“Au secours, ma puce contrefaite ne marche plus, vous l’avez cassé !”

“Ah, comme ça on contrefait ma puce et on arrive à se plaindre ?”



Aucune pitié pour les contrefacteurs. Si les consommateurs ont un problème avec leur puce, ils peuvent se retourner contre le vendeur. Ensuite si le vendeur a un problème, il se retourne contre son fournisseur. Si le fournisseur a un problème, il se retourne contre le fabriquant. Si le fabriquant a un problème, il n’avait qu’à pas contrefaire des puces.



Et c’est ainsi que ça fonctionne partout dans le monde !

Oui, des utilisateurs seront embêtés, mais c’est pas dramatique, si le produit leur plait, ils auront qu’à prendre un officiel de la marque ou s’orienter vers un concurrent..





Oui mais si l’utilisateur ignore que son produit est contrefait ?





Jaskier a écrit :



Je voudrais rien dire, mais y’a pas que les bidouilleurs que ça touche…







  • 1



Perso, moi dans mon boulot j’ai un câble qui utilise cette puce, et le logiciel nécessaire pour exploiter ce que j’y branche n’est dispo que sous Windows. Du coup si une bonne âme avait l’amabilité de me communiquer la référence de la MAJ foireuse ça serait sympa. J’utilise ce truc tous les jours et j’aimerais pas être emmerdé. D’autant plus que je n’ai aucun moyen de savoir si la puce est legit ou non…


et qui fonctionne parfaitement sur tout le matériel auquel il est destiné. CQFD, en cas de problème, merci de contacter le fabricant du produit, qui verra avec son fournisseur.


Donc une société fournit un pilote qui rend inutilisables des produits contrefaits, mais également un utilitaire afin de résoudre le problème, et on trouve quand même des gens pour parler “d’obsolescence programmée” (sic), d’action de groupe ou de “DRM” (sic), ie de “Système de gestion des droits numériques”. Sinon, vous ne voulez pas arrêter de raconter n’importe quoi ?


Afficher une popup avec “puce non officielle” ou simplement faire planter le driver, ou autre aurai été bien plus que suffisant. De la part de FTDI, proposer un software permettant de reconnaitre la vrai puce aurai été plus que logique.

Mais créer un driver avec une fonction de destruction sciemment, c’est quand même grave. Surtout avec l’information sur le cluf. On ne parle pas d’un bug attaquant que les puces contrefaites.



Après, que MS valide le pilote, c’est autre chose. Il n’est là que pour valider son fonctionnement, et n’est pas responsable des dommages causés, et ce n’est pas a MS de décider à la place des constructeurs. (Heureusement!) ils s’arrêtent au bon fonctionnement du drivers pour la partie Windows afin d’éviter des BSOD.



Pour moi, c’est une très mauvaise pub pour FTDI, et un futur manque de confiance dans leur professionnalisme si l’affaire est avérée.


C’est facile. Depuis pas mal de temps des pièces aéronautiques, des médicaments et d’autres produits critiques sont contrefaits. Si au lieu de se faire justice en condamnant des utilisateurs de bonne foi ce genre de boîtes tapait vraiment à la source de la contrefaçon et légalement ce serait mieux pour tout le monde.

Bonjour les dérives possibles.


Ouais c’est FTDI donc.



Quoiqu’il en soit c’est avec FTDI qu’il faut discuter du problème.


J’adore les donneurs de leçon sur les produits contrefaits…



J’ai plusieurs produits arduino et dérivés, certains d’entre eux utilisent probablement ces fameux chips copiés/contrefaits et je n’en sait fichtrement rien, on parle d’un microcontrôleur, pas d’un putain de sac à main de grande marque acheté 20€ sous le manteau dont on peut être que certain qu’il s’agit d’une contrefaçon.



Vous vous amusez souvent à démonter votre matos et à vérifier si chaque composant électronique qui le compose n’est pas contrefait ou copié? sérieusement <img data-src=" />



Qu’un constructeur s’en prenne aux contrefacteurs directement, OK, au moins c’est à la source, mais de faire chier payer les personnes qui ont acheté un produit contenant le fameux chip SANS en être conscient, c’est TRÈS petit, pour moi une ligne à été franchie.


La puce n’est pas du tout “briquée”, c’est juste le système de drivers USB de l’OS et/ou le driver ftdi qui refuse alors de l’utiliser…


Bah non, ça s’appelle une chaîne de responsabilité.


J’utilise couramment des convertisseurs FTDI pour le boulot, j’en suis très content : les drivers tiennent la route, pas comme les ms chinoises qu’on a utilisé un temps.



Deux observations toutefois :




  1. personne n’utilise des systèmes windows en aéro (sauf équipement périphériques style test, outil de prog), et c’est heureux. Les procédures de programmation sont blindées de chez blindées, chaque ligne de code embarquée doit être validée. Inutile de dire qu’on ne peut absolument pas changer de driver à la volée en plein vol.

  2. FTDI ne détruit rien, la fausse puce est reprogrammée, on peut la récupérer. Rien ne dit d’ailleurs qu’elle est réellement compatible avec le driver FTDI et que l’ensemble fonctionne vraiment correctement.



    Au final, je trouve l’attitude de FTDI plutôt saine : ils ne garantissent le bon fonctionnement que des produits qu’ils produisent, pas celui des produits dont personne ne sait d’où ils viennent.


Pour revenir sur l’ usurpation du VID/PID (et des champs textes qui vont avec), c’est tout à fait “légal”,&nbsp; peut-être pas très fair-play. Néanmois c’est grandement encouragé par les système de drivers (tel celui de Windows) qui bloquent les appareils qui ne montrent pas patte-blanche via le VID/PID. Un device usb déclare ses fonctionalités indépendamment du VID/PID…



&nbsp;Essayez donc de faire reconnaître un device usb comme une clé-usb sous windows (sans manip administrateur) sans “usurper” de VID/PID alors que le driver est inclus dans windows (et que la spec est librement accessible sur le site de l’USB)…

&nbsp;


J’aime beaucoup ce François-Battail qui tappe sur MS pour… ben tapper sur MS.



Ici il &nbsp;n’est question que d’un constructeur qui a employé la manière forte pour attaquer ses contrefaçons. Que le drivers soit installé à la main ou par Windows Update ne change strictement rien.&nbsp;Windows Update n’installe jamas un driver “tout seul”, faut forcément accepter l’update d’un façon ou d’une autre. Ce qui revient à accepter un popup que le driver, munie d’un mécanisme d’auto-update, aurait montré.



MS est totalement étrangé à cette affaire, ils ont parfaitement remplit leur contrat en diffusant correctement un driver tout à fait fonctionnel et innoffensif, pour du matériel correcte. Après, les contrefaites sont mortent, ouais, ben elles sont contrefaites en même temps hein. Tu voudrais quoi mon chèr François, qu’on pleure pour le sort des personnes coupables de recelle de contrefaçon ?



Compte pas sur moi pour ça. Et si ils sont de bonne fois, c’est contre leur revendeur quils doivent se retourner. Pas contre le constructeur original ou le canal de distribution du patch. Faut arreter d’être idiot et d’inverser coupable et victime des fois.








aureus a écrit :



J’ai pas compris pourquoi un vrai pilote s’installait sur une fausse puce.



 Ensuite j'ai pas non plus compris pourquoi FTDI devait prévenir qu'utiliser un vrai pilote sur une contrefaçon pouvait s'avérer fatal pour la puce... Ca me semble logique.







simple,



windows se base sur le couple VID / PID pour “designer” un pilote compatible, de fait les puces usurpant le VID / PID de la puce FTDI, windos ne vois rien et applique le pilote (logique, c’est prevu pour)



de la, les puces non-officielles sont “détectées”, volontairement ou non, peut importe, et dans un tel cas, le pilote update la puce et passe le VID a 0000



apres, honnetement, meme si cela fait chier des clients qui n’avaient probablement pas la moindre idée de la provenance illegale de la puce, je trouve la demarche legitime de la part de FTDI, apres tout leurs propres puces continuent de fonctionner, et les contrefacon n’ont, au final, que ce qu’elle meritent









Bejarid a écrit :



J’aime beaucoup de François-Battail qui tappe sur MS pour… ben tapper sur MS.



Ici il &nbsp;n’est question que d’un constructeur qui a employé la manière forte pour attaquer ses contrefaçons. Que le drivers soit installé à la main ou par Windows Update ne change strictement rien.&nbsp;Windows Update n’installe jamas un driver “tout seul”, faut forcément accepter l’update d’un façon ou d’une autre. Ce qui revient à accepter un popup que le driver, munie d’un mécanisme d’auto-update, aurait montré.



MS est totalement étrangé à cette affaire, ils ont parfaitement remplit leur contrat en diffusant correctement un driver tout à fait fonctionnel et innoffensif, pour du matériel correcte. Après, les contrefaites sont mortent, ouais, ben elles sont contrefaites en même temps hein. Tu voudrais quoi mon chèr François, qu’on pleure pour le sort des personnes coupables de recelle de contrefaçon ?



Compte pas sur moi pour ça. Et si ils sont de bonne fois, c’est contre leur revendeur quils doivent se retourner. Pas contre le constructeur original ou le canal de distribution du patch. Faut arreter d’être idiot et d’inverser coupable et victime des fois.





pas forcement, un pilote WHQL&nbsp; distrbué par windows update s’installeras / s’updateras sans la moindre confirmation de la part du user.



cela est dependant de la config de win update certes, mais il n’y a pas de confirmation necessaire dans ce cas



D’après certains, Arduino devait se procurait toutes les puces contrefaites pour tester que l’update ne posait pas problème et Microsoft devait, pour valider cet update, se procurer toutes les contrefaçons pour valider que le driver ne posait pas de problème. Vu le nombre de périph qui ont besoin d’un driver, ils vont pouvoir embaucher un pays entier pour faire les tests.








dam1605 a écrit :



Pour revenir sur l’ usurpation du VID/PID (et des champs textes qui vont avec), c’est tout à fait “légal”,&nbsp; peut-être pas très fair-play. Néanmois c’est grandement encouragé par les système de drivers (tel celui de Windows) qui bloquent les appareils qui ne montrent pas patte-blanche via le VID/PID. Un device usb déclare ses fonctionalités indépendamment du VID/PID…



&nbsp;Essayez donc de faire reconnaître un device usb comme une clé-usb sous windows (sans manip administrateur) sans “usurper” de VID/PID alors que le driver est inclus dans windows (et que la spec est librement accessible sur le site de l’USB)…

&nbsp;





non, ca ne l’est pas, c’est de la contrefacon, l’USBif te choppe a faire ca tu vas etre servi



Comme tu le dis bien, ça dépend de la config. Si tu choisis la config “ne me pose jamais de question et install TOUT ce qui traine”, Windows le fera. Mais tu lui auras demander expressément, ce n’est PAS le comportement par défaut.



Et cocher la dites case à cocher (cad considérer les recommandés comme des critiques) quand on est un “bidouilleur”, comment dire… C’est pas bien malin. Même moi qui ne suis pas un bidouilleur, je temporise et me renseigne sur les drivers avant de les accepter, surtout pour mes composants sensibles (carte graphiques, chipset wifi…).



  1. LOL : personne n’utilise des systèmes windows dans l’aéro même pas dans l’armée, oui DO178 ce qui n’empêche nullement des erreurs de conception de plus haut niveau (cf. Qantas A380), en médical c’est une catastrophe, en industriel aussi (les banques raquent pour maintenir XP à cause de leurs distributeurs de billets).



    &nbsp;2) Sauf que l’utilisateur n’est pas prévenu et que ça marchait avant, juste un petit détail.



    La conclusion est moyennement terrible, j’ai environ 80000 composants électroniques chez moi et bien qu’utilisant les services de fournisseurs sérieux je ne suis pas en mesure de garantir la provenance exacte.


D’après la version officielle le Quantas A380 a été victime d’un défaut de production chez RollRoys (tube d’alimentation d’huile trop fin à un endroit) pas de conception.




 Contredits-tu cette version ?      






De même, si les banque raquent pour leurs ditributeurs sous XP, c'est principalement car elles ont fait n'importe quoi avec le projet Lugdunum (celui qui devait leur fournir des bornes sous Win7 embedded, à durée de support trèèèèès longue). Elles ne peuvent s'en prendre qu'a elles-mêmes si elles font tout pour se mettre dans la merde malgré les conseils qu'elles ont pu avoir (je le sais, je l'ai fait).   





J’attend toujours la moindre phrase qui ne contredit pas les faits mon chèr François… Tu va finir en IL à ce train.



  1. Un lien vers le JDN pour appuyer ton propos, non mais LOL, effectivement !



    1. L’utilisateur qui ne sait pas qu’il a affaire à une contre-façon est potentiellement à la merci de sérieux dysfonctionnements. Donc il n’est pas prévenu ? Mieux vaut tard que jamais.









jb07 a écrit :





  1. L’utilisateur qui ne sait pas qu’il a affaire à une contre-façon est potentiellement à la merci de sérieux dysfonctionnements. Donc il n’est pas prévenu ? Mieux vaut tard que jamais.





    Effectivement, je préfère un plantage juste après une mise à jour qu’en pleine utilisation… Ca porte nettement moins à concéquence.



Absolument pas, c’est la cause initiale mais il y a une suite : le copi qui se prend 200 fenêtres d’erreurs (modales) et qui doit normalement lire le manuel d’exploitation, faire les actions supposées correctives avant d’acquitter chaque erreur, pourtant les queues avec priorités ça existe en embarqué.








nikon56 a écrit :



non, ca ne l’est pas, c’est de la contrefacon, l’USBif te choppe a faire ca tu vas etre servi





De la contrefaçon de quoi ? Je ne parles de vendre une copie d’un produit existant, juste d’implanter une interface

L’USBif gère ses marques/dessins, tant qu’on ne les utilises pas sans son accord, elle ne peut rien faire.

&nbsp;



Je suis désolé pour la source effectivement, je voulais un lien rapide,&nbsp; mais deux rafales sont restés planté au sol parce que le système de transmission des informations de la mission (sous Windows) avait été vérolé, c’est pas glorieux pour la grande muette.



Donc il n’a pas été prévenu, c’est là qu’est l’essentiel du problème, d’autre part on parle de contrefaçon, probablement de la marque déposée FTDI, les ID USB éventuellement, pour le reste (brevets, etc) c’est peut-être moins évident…








nikon56 a écrit :



non, ca ne l’est pas, c’est de la contrefacon, l’USBif te choppe a faire ca tu vas etre servi





&nbsp;Pour le VID/PID tant qu’on n’a pas signé la charte/contrat/règle de l’usbif, on est engagé à rien.



PS: Désolé pour le doublon.



Mouais, sur le fond je comprends qu’une boite qui a été spoilé par des gens peu scrupuleux veuille faire un grand coup de ménage.

Mais sur la forme, ils ont été sans pitié (même si le matos n’est pas vraiment hs dans le fond). Le pilote étant apparemment capable de détecter la légitimité d’une puce sans avoir recours au pid/vid, ils auraient pu faire plus pédagogique : dégradation des perfs, affichage d’avertissements, voir impossibilité de l’installer sur une puce contrefaite…


Exactement. Et là ils pourraient faire passer le message à l’utilisateur de contacter son fournisseur pour demander des explications, et en parallèle d’intenter une action ou des actions en justice contre le ou les contrefacteurs. Je crois que c’est un peu raté.








dam1605 a écrit :



La puce n’est pas du tout “briquée”, c’est juste le système de drivers USB de l’OS et/ou le driver ftdi qui refuse alors de l’utiliser…



le pilote change le PID par 0000. c’est un PID qui n’est jaamis utilisé. et qui n’est donc jamais reconnu… et la puce est bien briquée.









francois-battail a écrit :



Absolument pas, c’est la cause initiale mais il y a une suite : le copi qui se prend 200 fenêtres d’erreurs (modales) et qui doit normalement lire le manuel d’exploitation, faire les actions supposées correctives avant d’acquitter chaque erreur, pourtant les queues avec priorités ça existe en embarqué.



Elles étaient triés par ordre de priorité, à fure et à mesure qu’elles se déclenchaient, hein. &nbsp;Mais le fait est qu’ils se sont mangées 51 critiques… Et ça, ce n’était pas prévu.



Critiquer le manque de conception d’Airbus, et plus particulièrement sur cet incident, c’est du troll. L’avion a survécu, sans jamais être danger, a une explosion de réacteur. C’est le premier avion civil a survivre a ce genre de dégats (destruction total de l’avant de l’aile gauche, trouage tous les 10 cm du reste de sa surface), entre autre grace a une très bonne conception (informatique central capable de reste cohérente malgré le très grand nombre de mesures incohérentes, fonctionnement autonome intelligent du réacteur 1 malgré qu’il n’avait plus aucun moyen de savoir quoi faire…).



Si il a un avion qui a fait ses preuves en matière de conception de sécurité, c’est bien l’A380. La plus grosse modif faite suite à cet incident, c’est l’ajout d’une vue global des incidents, pour permettre aux pilotes d’avoir une vue global en cas d’erreurs, car effectivement, ils n’avaient pas prévu qu’ils puissent y avoir plusieurs dizaine d’erreurs critiques simultanées (la réflexion logique si on en arrive là était qu’on a plus qu’a prier car l’avion serait condamné, preuve a été faite que non :p).



Ah mince j’ai que des contrefaçons :s



Bon ben je vais remplacer les puces au moins je serais pas emmerdé.








francois-battail a écrit :



Exactement. Et là ils pourraient faire passer le message à l’utilisateur de contacter son fournisseur pour demander des explications, et en parallèle d’intenter une action ou des actions en justice contre le ou les contrefacteurs. Je crois que c’est un peu raté.



Ca, je pense qu’ils l’ont déjà fait. Et puis si ils avaient été salaud, ils auraient reprogrammer la puce qu’elle crame, elle et le reste de le carte. Non, ils n’ont fait que jouer avec ID contrefait qui lui permettait d’usurper un driver…



Pour le coup la marque officiel des puce a décidé d’y allez clairement au bazooka pour empêcher les contre-façon mais il y a fort a parier que la “parade” sera rapidement découverte seul les personne ayant eu la negligeance de faire confiance a W10 en subiront les conséquence de plus je ne pense pas que la réputation d’un vendeur de contrefaçon puisse être impacté par ce genre de stratégie le prix bas étant leur principal argument (pour le SAV vaut mieux acheter ailleur)

Un coup dans l’eau a mon avis








francois-battail a écrit :



Ah

? Voyons, n’est-ce pas sciemment que cette mise à jour a été poussée ?

Pour l’aspect « programmée » le jeu de mot était facile mais permettre

de reprogrammer le VID:PID depuis l’USB je le répète c’est stupide

(d’habitude c’est une série spéciale commandée au constructeur puisque

ces informations font partie du masque).

Plutôt que de s’attaquer

au contrefacteurs, on préfère s’attaquer à distance avec une rustine

foireuse qui a pour effet de planter les utilisateurs légitimes.

C’est un peu facile et surtout très inquiétant si ça se généralisait.





Pour la reprogrammation je ne sais pas, mais pour le reste je suis plus ou moins d’accord, à la seule expectation que je ne pense que Microsoft soit en faute là-dessus. C’est bien le constructeur qui a décidé de répondre de cette manière aux produits contrefaits…



C’est sympa ce côté roulette russe et les frais que ça entraîne chez tous les clients finaux.

Autant, je comprends que le fabricant soit saoulé de devoir assurer le support de puces qu’il n’a pas produites, par contre, le CLUF invisible, j’aime moyen. Des mises à jours de pilote interactives existent sous Windows. Ça coûtait si cher que ça d’afficher une foutue boîte de dialogue pour dire “votre puce est une copie, veuillez contacter votre revendeur ?” sérieusement, les gars de FTDI sont particulièrement indélicats.

Maintenant j’ai peur de brancher mon Arduino que j’ai pas encore testé…


“Briquer” c’est quand même non-réversible à l’origine… là il suffit de reconfigurer le PID, comme le dit l’article. La contrefaçon est parfaitement fonctionnelle.


Si l’avion a survécu c’est surtout que le copi a fait du click-click au mépris des règlements pour en revenir aux fondamentaux : avoir une vue claire sur la situation réelle. A priori selon les témoignages du documentaire de la BBC les erreurs étaient empilées au lieu d’être recalculées / réévaluées après chaque acquittement.

Pour le reste heureusement qu’il y a des systèmes&nbsp; indépendants bien conçus et très bien testés capables de résister en mode dégradé.

Pour ta gouverne ce n’est pas le premier avion à s’être retrouvé dans une situation ultra-critique avec atteinte structurelle (il faut voir du côté de DHL qui a quand même encaissé un missile peu après le décollage), mais là il n’y avait pas trop d’informatique (de mémoire un A310).


J’avoue, j’ai tendance à taper un peu sur Microsoft. Mais malgré tout si je fais une analogie (promis pas de de voitures ni de boulangeries) il y a une chaîne de responsabilité créée par la LCEN entre l’hébergeur (le diffuseur) et l’éditeur.

Si chaque fabriquant met en place ce genre de mécanisme avec l’assentiment du diffuseur, voire même en cas de différend avec un sous-traitant, qui prend les utilisateurs en otage en arguant qu’il y a contrefaçon alors qu’a priori aucune action en justice n’a été intentée, c’est extrêmement grave.








adarion29 a écrit :



Pour le coup la marque officiel des puce a décidé d’y allez clairement au bazooka pour empêcher les contre-façon mais il y a fort a parier que la “parade” sera rapidement découverte seul les personne ayant eu la negligeance de faire confiance a W10 en subiront les conséquence de plus je ne pense pas que la réputation d’un vendeur de contrefaçon puisse être impacté par ce genre de stratégie le prix bas étant leur principal argument (pour le SAV vaut mieux acheter ailleur)

Un coup dans l’eau a mon avis



&nbsp;“négligence de faire confiance à w10” : Le bon gros troll&nbsp;poilu qui mélange tout&nbsp;… <img data-src=" />









Bejarid a écrit :



Comme tu le dis bien, ça dépend de la config. Si tu choisis la config “ne me pose jamais de question et install TOUT ce qui traine”, Windows le fera. Mais tu lui auras demander expressément, ce n’est PAS le comportement par défaut.



Et cocher la dites case à cocher (cad considérer les recommandés comme des critiques) quand on est un “bidouilleur”, comment dire… C’est pas bien malin. Même moi qui ne suis pas un bidouilleur, je temporise et me renseigne sur les drivers avant de les accepter, surtout pour mes composants sensibles (carte graphiques, chipset wifi…).





et bien, tu te trompe



lorsque tu install windows, les options par defaut installent egalement les drivers WHQL et vas meme chercher sur les serverus de MS la derniere version en date / verifier la dispo d’un driver lorsque tu plug un nouveau device



note que je parle bien des drivers WHQL, donc certifiés.



dans le cas d’un pilote non signé, effectivement il y a demande de confirmation



Le DHL qui s’est fait shooter en Irak n’a été touché qu’au bout de l’aile (les vidéos des dégats ne sont pas dur à trouver, y avait X hélicoptères de combat autour qui filmaient), il avait gardé tous ses moteurs, ainsi que la quasi totalité de ses ailes. Malgré ça, il s’est craché (contrairement au A380). Entre autre car il n’était pas tout numérique (et l’hydraulique, c’est tout sauf resistant aux pannes sur les gros n’avions).



Rien à voir, donc.








dam1605 a écrit :



“Briquer” c’est quand même non-réversible à l’origine…



pas forcément.

“briquer” c’est juste rendre un appareil inutilisable par voie logicielle, pas plus.









dam1605 a écrit :



De la contrefaçon de quoi ? Je ne parles de vendre une copie d’un produit existant, juste d’implanter une interface

L’USBif gère ses marques/dessins, tant qu’on ne les utilises pas sans son accord, elle ne peut rien faire.

&nbsp;





tu fait passer un composant / materiel sous le nom d’un concurent, c’est donc une contrefacon de marqu, attendu que des que ton materiel vas etre “reconnu”, il le serat come un materiel de la société X ou Y alors, que ce n’est pas le cas.



si ce n’est pas de la contrefacon, alors RIEN ne l’est!



Les drivers WHQL sont “Recommandé” pas “Critique”.



Ils sont effectivement classé en “Important” et non “facultatif” comme les non signés, (qui sont forcément décochés), mais ils ne sont pas installé par défaut. Sauf si tu suis les recommandations de MS à l’installation, mais si tu fais “suivant suivant” tu n’a que les critiques qui sont installés en full auto, pas les recommandées.



Du moins c’est comme jusqu’a Win7, sur Win8 je n’y mettrais pas ma main à coupé, je ne l’install pas assez souvent pour y risquer ma main, mais ça m’étonnerait qu’ils aient changé ce comportement…








McKay a écrit :



J’adore les donneurs de leçon sur les produits contrefaits…



J’ai plusieurs produits arduino et dérivés, certains d’entre eux utilisent probablement ces fameux chips copiés/contrefaits et je n’en sait fichtrement rien, on parle d’un microcontrôleur, pas d’un putain de sac à main de grande marque acheté 20€ sous le manteau dont on peut être que certain qu’il s’agit d’une contrefaçon.



Vous vous amusez souvent à démonter votre matos et à vérifier si chaque composant électronique qui le compose n’est pas contrefait ou copié? sérieusement <img data-src=" />



Qu’un constructeur s’en prenne aux contrefacteurs directement, OK, au moins c’est à la source, mais de faire chier payer les personnes qui ont acheté un produit contenant le fameux chip SANS en être conscient, c’est TRÈS petit, pour moi une ligne à été franchie.





a mais on est completement d’accord, c’est tres moche pour les utililsateurs, qui n’ont pour ainsi dire aucun moyen de verifier que leur puce soit ou non une contrefacon, mais de la a taper sur MS ou FTDI, non.



ils ne font que defedre leur business, on ne peut pas vraiment leur en vouloir pour le coup



Bah voyons. Zéro blessé, plus d’hydraulique, un missile à détection thermique qui se dirige vers quoi déjà ? Un incendie qui dévore l’aile pleine de carburant… Quant à parler de crash, franchement c’est peut être oublier : « un bon atterrissage c’est quand tout le monde est en vie après, un très bon atterrissage c’est quand on peut réutiliser l’avion. ».



Mais bon c’est bien d’occulter de cette façon le vrai problème que je souligne en matière de fiabilité de logiciel quelque soit le niveau dit de qualité, je te recommande de visionner, si ce n’est pas déjà fait, le documentaire de la BBC pour entendre la version du copi.








Patch a écrit :



pas forcément.

“briquer” c’est juste rendre un appareil inutilisable par voie logicielle, pas plus.





Si on regarde les diverses lois sur le hacking et le cyberterrorisme,&nbsp; ça pourrait tout de même revenir dans la gueule de ftdi car cela reste ni plus ni moins qu’un sabotage… le pilote se serait contenté de dire “non, désolé, matos non supporté”, ça serait passé, reflasher la puce pour qu’elle ne marche plus, c’est une autre paire de manche.



Protéger son buisness, oui, se lancer dans de la guérilla dont la première victime sera le consommateur, non. C’est quoi l’étape suivante, cramer la chaine hi-fi des gens qui auraient acheté un mp3 sur un site d’offre légale qui aurait oublié de reverser les droits d’auteur?









127.0.0.1 a écrit :



Déjà cloner le hardware, c’est discutable.

Mais en plus utiliser le “Vendor ID” de FTDI pour profiter des drivers officiels de FTDI, et s’épargner la peine de coder le software (driver)… c’est vraiment petit.



On ne peut même pas utiliser l’excuse de vouloir créer un équivalent “open hard/source” low-cost.

C’est clairement de la contrefacon de hardware a but lucratif.



Pas de bol pour les consommateurs. Pour eux c’est un coup dur.

Mais le fautif c’est en premier lieu le constructeur du clone qui ne fournit pas son propre VID + driver.





Pas de bol pour les consommateurs… Ya pas qu’eux. Ce genre de puce contrefaite doit se retrouver dans de nombreux systèmes professionnels. Quand on voit que, pour reconnaître si une pue est une originale, ou une contrefaçon, il est obligatoire de la démonter (la casser)… Il faut détruire le circuit intégré pour connaître sa provenance. Avec une telle “impossibilité” d’avoir une idée de la chose, ça doit innonder le marché professionnel, distributeurs (RS, farnell, etc.) sans même qu’ils le sachent.



Et là, c’est plus grave. De mémoire ya ce genre de puce dans nos transpondeurs 100G optiques que tout le monde utilise sans le savoir… je te laisse imaginer les conséquences d’un tel acte…



Je peux comprendre que ce soit particulièrement désagréable, mais de là à parler d’utilisateurs légitimes, il y a malheureusement un gros contresens légal:

Aux yeux de la loi, les possesseurs de ces cartes incluant des puces contrefaites sont coupables de recel de contrefaçon.

Pour vous donner un exemple assez connu, c’est comme si les gens se faisant attraper par la douane après être allés acheter des articles un peu louches au marché de Vintimille se plaignaient de la destruction desdites contrefaçons et de l’amende…

Maintenant FTDI est plutôt bon joueur car il ne détruit rien et semble même laisser en libre téléchargement l’outil permettant de reprogrammer le chip contrefait.

Il parait que c’est une carte destinée à des gens aimant bidouiller … c’est plutôt didactique quant aux rouages de l’USB, non?

Évidemment, c’est assez radical comme méthode, mais pour ceux dont le métier est de coder par exemple, pensez-vous que vous assureriez le SAV si une boite venue de nulle part vendait des copies de votre soft pour le revendre 4 fois moins cher en se faisant passer pour un revendeur, ou bien essaieriez-vous de bloquer ces copies?








ragoutoutou a écrit :



Si on regarde les diverses lois sur le hacking et le cyberterrorisme,  ça pourrait tout de même revenir dans la gueule de ftdi car cela reste ni plus ni moins qu’un sabotage… le pilote se serait contenté de dire “non, désolé, matos non supporté”, ça serait passé, reflasher la puce pour qu’elle ne marche plus, c’est une autre paire de manche.



Protéger son buisness, oui, se lancer dans de la guérilla dont la première victime sera le consommateur, non. C’est quoi l’étape suivante, cramer la chaine hi-fi des gens qui auraient acheté un mp3 sur un site d’offre légale qui aurait oublié de reverser les droits d’auteur?



<img data-src=" />

les consommateurs (particuliers comme entreprises!) sont les premières victimes… surtout que la plupart ne doivent pas être au courant d’avoir des copies d’une puce électronique dans leur appareil. et pour moi aussi un simple refus du support par le pilote aurait été amplement suffisant.









UnYx a écrit :



Évidemment, c’est assez radical comme méthode, mais pour ceux dont le métier est de coder par exemple, pensez-vous que vous assureriez le SAV si une boite venue de nulle part vendait des copies de votre soft pour le revendre 4 fois moins cher en se faisant passer pour un revendeur, ou bien essaieriez-vous de bloquer ces copies?







Réponse C : tu portes plainte et tu laisses les flics et la justice faire leur boulot (en apportant une expertise technique au besoin).









127.0.0.1 a écrit :



Déjà cloner le hardware, c’est discutable.

Mais en plus utiliser le “Vendor ID” de FTDI pour profiter des drivers officiels de FTDI, et s’épargner la peine de coder le software (driver)… c’est vraiment petit.



On ne peut même pas utiliser l’excuse de vouloir créer un équivalent “open hard/source” low-cost.

C’est clairement de la contrefacon de hardware a but lucratif.



Pas de bol pour les consommateurs. Pour eux c’est un coup dur.

Mais le fautif c’est en premier lieu le constructeur du clone qui ne fournit pas son propre VID + driver.





Non seulement, mais ça foire, périphérique en code erreur 10, échec du démarrage. CM_PROB_FAILED_START.



Excusez-moi mais quand il s’agit de composants en production de masse au moment de l’achat, il est trivial de savoir si on achète qqch de propre pour un OEM : il suffit de regarder la liste des distributeurs autorisés et éventuellement de demander la traçabilité des lots voir de demander au fabricant la confirmation de cette traçabilité (quand il s’agit de quelques milliers ou dizaines de milliers de pièces ils ne rechignent pas à le faire, voire ils sont même très demandeurs car les contrefaçons sont un marché de plus en plus dévastateur en électronique).



Au fait, dites-vous que les contrefaçons sont plus courantes en électronique que vous ne le pensez et la sortie de l’Iphone 6 va par exemple en faire prospérer bon nombre bien moins évidentes encore:

Apple absorbe parfois des dizaines de % de la totalité du marché de certains des composants qui entrent dans le nomenclature de ses produits phare et cela implique que le marché est très tendu et que le contrefacteurs se ruent pour écouler leurs camelote.

&nbsp;

Imaginez que le fabricant de votre ABS se fasse berner ou se retrouve tellement aux abois que l’acheteur n’osera même pas demander la traçabilité de l’unique lot de composant qu’il trouvera pour produire…



Crierez-vous toujours que celui qui mettra HS la contrefaçon dans votre voiture devrait avoir honte?



Dernier détail : les FT232 sont des composants USB … mais à votre avis qu’arrivera-t-il le jour où le contrefacteur ajoutera du code malicieux qui infectera vos machines après avoir été injecté dans le trafic du beau transpondeur 100G dans lequel il aura été intégré?


Tu aura beau dire ce que tu veux, c’est dans la même lignée que les DRM niveau pratique.

C’est bien dans l’idée de vérification des droits :&nbsp; t’est un périphérique de contrefaçon, tu n’a pas droit au driver.

Et ça va même plus loin en brickant volontairement la puce.



L’utilitaire de débrickage ne vaut pas bien lourd pour toutes les personnes qui vont être confrontés au problème et qui ne trouverons pas facilement voir pas du tout la cause du dysfonctionnement.

&nbsp;

Donc oui, c’est bien une sorte d’ obsolescence programmée , pas irréversible , certes , mais il y à une réelle volonté de rendre certaines puces inopérantes afin de pousser au rachat d’équipement.

Pense-tu sérieusement que toutes les personnes affectés auront la chance et les compétences pour régler ce problème rapidement et simplement ?


C’est peut-être un petit peu complexe, il faut prouver le côté intentionnel dans la mesure ou le recel est un délit. J’ai un composant électronique LPC812 en boîtier TSSOP, déjà sans loupe il est impossible de lire les références, ensuite de bonne foi, acheté chez Farnell, comment puis-je être sûr que cela provient bien des usines NXP, comment Farnell peut-il en être en sûr ?

&nbsp;

Si j’achète (hypothèse de travail) un truc de luxe renommé du côté de la frontière italienne pour 15 € qui normalement coûte 2000 € il y a probablement un faisceau de présomption de recel de contrefaçon, OK.

&nbsp;

Avec des composants électroniques c’est beaucoup plus compliqué, il y a une nomenclature extrêmement complexe ; pour un même circuit électronique : x fabricants en y boîtiers et sous-versions. Les fournisseurs vont me proposer un circuit à 2,5\( en telle version, ou un autre à 2,05\) avec quelques nuances sur les caractéristiques. À ce stade il n’y aucune suspicion de contrefaçon, par exemple un LM358 est décliné avec plein de variantes chez plein de fabricants et des déclarations de conformité RoHS et compagnie.



Je ne peux que constater que mon application qui s’appuie dessus semble fonctionner correctement, sans toutefois être en mesure de vérifier les caractéristiques exactes de ce composant.



Dès lors s’il y a du ménage à faire (et à mon avis il y en a), qu’il soit fait à la source. Ce sera bien bien pour tout le monde, mais ces méthodes (FTDI) sont irresponsables et contre-productives.








megadub a écrit :



Mais elle sert à quoi cette puce au bout du compte ?






Elle sert à faire un port série RS232 branché sur de l'USB pour les ordinateurs dépourvus de port série.     



Au passage, la plupart des cartes mères ont de quoi s’en passer, la prise nécessaire est déjà présente.

Reste juste à la relier avec ça : motherboard rs232 connector. (le lien google images est nok sur NXI <img data-src=" />)



La question du code malicieux se pose aussi dans la même mesure sur les produits officiels.

&nbsp;


Les douanes qui sont en charge de ces “problèmes” ont déjà du mal à traiter tous les cas dans lesquels ils ont les compétences à disposition tant les contrefaçons sont massives; quand il s’agit de ce type de contrefaçons ils sont malheureusement désarmés car les moyens nécessaires sont colossaux ou très chers en prestation&nbsp; (pour le pendant électronique de la chose)



Pour vous donner un ordre d’idée, une contrefaçon grossière de circuit intégré requiert plus de 5000€ de matériel pour être détectée, une moyenne fait appel à 500000€ de matériel, et la totalité de celui devant être employé pour des contrefaçons évoluées peut atteindre plusieurs millions et demander des semaines de travail à des experts ou éventuellement certaines vérifications ne peut être faites qu’avec l’aide du fabricant normal.



Pour les composants passifs montés en surface, la traçabilité sur le composant étant quasi-nulle, il faut au minimum faire un reverse engineering poussé de tous les produits de toutes les usines (ils en ont parfois plusieurs possibles pour le même composant) de chacun des fabricants chez qui on s’approvisionne si on veut être certain de ce qui est dans une bande de composants potentiellement contrefaits…

&nbsp;

Rappelez-moi combien de composants il y a dans votre téléphone par exemple??








kypd a écrit :



Non le fautif est FTDI qui diffuse un drivers qui a été explicitement programmé pour désactiver des puces non officielles !



Le drivers possède un gros &gt; IF puce_officielle THEN flash(bon_firmware) ELSE destroy_hardware() END !





Le fautif est le contrefacteur.



francois-battail a écrit :



Ah ? Voyons, n’est-ce pas sciemment que cette mise à jour a été poussée ? Pour l’aspect « programmée » le jeu de mot était facile mais permettre de reprogrammer le VID:PID depuis l’USB je le répète c’est stupide (d’habitude c’est une série spéciale commandée au constructeur puisque ces informations font partie du masque).

Plutôt que de s’attaquer au contrefacteurs, on préfère s’attaquer à distance avec une rustine foireuse qui a pour effet de planter les utilisateurs légitimes.

C’est un peu facile et surtout très inquiétant si ça se généralisait.





Un utilisateur légitime d’une contrefaçon ? <img data-src=" /> Et puis quoi encore ?



Oui, mais je parlais d’une action sur un élément spécifique après une plainte. Pas du travail régulier de la douane (qui a déjà fort à faire) <img data-src=" />


OK, on remplace légitime par « qui a acheté en toute bonne foi » et sans aucun moyen de pouvoir suspecter une quelconque contrefaçon, c’est plus clair exprimé comme cela ?








jb07 a écrit :



J’utilise couramment des convertisseurs FTDI pour le boulot, j’en suis très content : les drivers tiennent la route, pas comme les ms chinoises qu’on a utilisé un temps.



Deux observations toutefois :




  1. personne n’utilise des systèmes windows en aéro (sauf équipement périphériques style test, outil de prog), et c’est heureux. Les procédures de programmation sont blindées de chez blindées, chaque ligne de code embarquée doit être validée. Inutile de dire qu’on ne peut absolument pas changer de driver à la volée en plein vol.

  2. FTDI ne détruit rien, la fausse puce est reprogrammée, on peut la récupérer. Rien ne dit d’ailleurs qu’elle est réellement compatible avec le driver FTDI et que l’ensemble fonctionne vraiment correctement.



    Au final, je trouve l’attitude de FTDI plutôt saine : ils ne garantissent le bon fonctionnement que des produits qu’ils produisent, pas celui des produits dont personne ne sait d’où ils viennent.





    +1000. Voyez avec votre contrefacteur constructeur. <img data-src=" />









psn00ps a écrit :



Un utilisateur légitime d’une contrefaçon ? <img data-src=" /> Et puis quoi encore ?







Par opposition au type qui achète un iPhoone à 50$ dans des lieux interlopes.



Surtout que là on parle d’un composant parmi plusieurs, sur lequel l’utilisateur ne sait peut-être pas qu’il y a du © (on lui a filé des CLUF ?) et qui de surcroit est extrêmement difficile à détecter



Tu te trompe complètement et tu raconte des bêtises.

C’est un driver, pas un firmware pour commencer.



Là, le check est simple et bien différent :




  • puce genuine -&gt; On fait rien

  • puce contrefaite -&gt; Reset du Vendor ID usurpé.



    C’est là que windows/mac/linux entrent en jeu. Pas de Vendor ID, donc pas d’association automatique avec le driver FTDI puisque c’est pas du matos FTDI. Tu peux forcer le fonctionnement du driver sur la puce, mais ce n’est plus automatique.



    La puce n’est absolument pas détruite.


ça fait un moment que j’ai bloqué windows update dans mon pare-feu car il me faisait limite plus peur que les pirates et virus improbables à deux balles, surtout depuis que j’ai appris que microsoft faisait passer des maj silencieuses et sans consentement, et cela même s’il est paramétré en mode “prévenir avant d’installer”



voir ce sujet

http://answers.microsoft.com/en-us/windows/forum/windows_7-windows_update/window…



cette news n’est pas faite pour me rassurer


Nous sommes d’accord que la théorie va dans ce sens là, mais en pratique, les contrefacteurs ne sont jamais implantés en France et si par miracle il en apparaissait un ici, le temps que la machine judiciaire (qui elle aussi fait ce qu’elle peut dans la limite de ses moyens) traite le dossier, la puce concernée serait déjà en fin de vie ou largement obsolète.



Le seul espoir est donc dans la prise de conscience des OEM et cela n’arrivera que si leur image de marque en souffre après un cas pratique aussi bénin que possible…



Pour exemple il y a des études (américaines) qui indiquent que le marché de l’armement US commençait il y a quelques années à être gangréné par les composants contrefaits (quelques %, mais vu le nombre de composants dans chaque produit), ce qui a fini par faire réagir les acteurs de ce marché (qui galèrent comme les autres dans un cas comme ça, même si ils ont plus de moyens)… Une arme qui fonctionne est faite pour être dangereuse, mais que dire quand son comportement peut être imprévisible?








Patch a écrit :



le pilote change le PID par 0000. c’est un PID qui n’est jaamis utilisé. et qui n’est donc jamais reconnu… et la puce est bien briquée.





Relis le dernier paragraphe et la définition de “briqué”. <img data-src=" />









John Shaft a écrit :



Par opposition au type qui achète un iPhoone à 50$ dans des lieux interlopes.



Surtout que là on parle d’un composant parmi plusieurs, sur lequel l’utilisateur ne sait peut-être pas qu’il y a du © (on lui a filé des CLUF ?) et qui de surcroit est extrêmement difficile à détecter





Oui, cf l’article.









psn00ps a écrit :



Relis le dernier paragraphe et la définition de “briqué”. <img data-src=" />





Disons que suivant les compétences du maçon, la qualité de la brique est perçue différemment <img data-src=" />&nbsp;



Un détail rigolo, j’ai l’impression à vous lire qu’il ne peut y avoir qu’un seul et unique fautif, pas plus.

C’est pratique. <img data-src=" />








kypd a écrit :



Non le fautif est FTDI qui diffuse un drivers qui a été explicitement programmé pour désactiver des puces non officielles !



Le drivers possède un gros &gt; IF puce_officielle THEN flash(bon_firmware) ELSE destroy_hardware() END !







La faute c’est que la puce clonée ne passe pas le test “puce_officielle”, alors qu’elle utilise le VID/PID d’une puce officielle. En gros, la contrefaçon n’est pas assez bonne pour tromper le “IF puce_officielle THEN …”.





Est-ce illégal ? Est-ce immoral ? Est-ce génial ?



Mon sentiment en 3 lettres: Pwn !












ilyon a écrit :



Il-y-a un sacré problème quand même. Vous présentez les choses d’une telle façon qu’à l’énoncé du titre, on a l’impression que Microsoft en tant qu’acteur systématiquement responsable/coupable/condamnable est venu avec ses milliards emmerder des petits programmeurs gentils comme tout qui veulent le bien (à définir) et aiment les bisounours.

Windows update dans le cas des MAJ matériel, n’est que le vecteur de MAJ. Microsoft les valide certes, donc connaissait l’effet de ce driver, mais de là à les charger comme ça.



&nbsp;<img data-src=" /><img data-src=" /> Arrêtons là toute polémique et réglons le problème à sa base.&nbsp;<img data-src=" /><img data-src=" />



J’ai eu affaire à ces contrefaçons au boulot. Ca a couté une journée et demi de recherche à ma boite parce que ça ne marchait pas. On n’a pas blamé FTDI pour ça.

EDIT: et bien avant cette màj.


Pour repondre a ceux qui approuvent le comportement de Ftdi, une analogie :

Microsoft considere que Android viole ses droits -&gt; Il serait donc normal que windows brique lors de leur connexion les terminaux android des fabricants qui ne lui ont pas payé leur obole.



Comme certains je doute beaucoup de la légalité de la chose.








Winderly a écrit :



Un détail rigolo, j’ai l’impression à vous lire qu’il ne peut y avoir qu’un seul et unique fautif, pas plus.

C’est pratique. <img data-src=" />





Je ne dirais pas cela, mais le contrefacteur est rarement de bonne foi donc la repentance n’est pas à attendre de sa part; l’utilisateur final n’a que rarement la latitude de faire le tri sauf dans la sélection de son vendeur ou dans la plausibilité du prix annoncé, les seuls qui peuvent contribuer à faire le ménage sont le fabricant légitime, les distributeurs et les OEM … mais il y a du boulot.









sassa a écrit :



Pour repondre a ceux qui approuvent le comportement de Ftdi, une analogie :

Microsoft considere que Android viole ses droits -&gt; Il serait donc normal que windows brique lors de leur connexion les terminaux android des fabricants qui ne lui ont pas payé leur obole.



Comme certains je doute beaucoup de la légalité de la chose.





Il y a 2 points distincts dans votre message :

&nbsp;

Les brevets logiciels et plus largement le système de gestion des brevets outre atlantique est une vaste fumisterie car il ne s’attache presque pas à la manière de réaliser mais à la fonction réalisée : c’est comme si on brevetait la centrale à fusion nucléaire maintenant pour attaquer celui qui la rendra possible : le patent troll est un sport trop facile.



Quant à la légalité de la chose, il me semble qu’elle est raisonnable car le patch s’attaque au PID qui est grosso modo une marque déposée qui est dans ce cas contrefaite. Effacer ce PID contrefait n’est dans ce cas que faire cesser l’acte délictueux et n’altère pas la fonction intrinsèque du composant contrefait puisqu’il reste parfaitement opérant si on lui associe un PID et un driver ad hoc. Celui qui remettrait le PID contrefait serait par contre un contrefacteur actif à son tour (mais je ne sais pas si ce n’est pas toléré pour usage personnel non pécunier et/ou dans un but d’apprentissage).









choukky a écrit :



&nbsp;<img data-src=" /><img data-src=" /> Arrêtons là toute polémique et réglons le problème à sa base.&nbsp;<img data-src=" /><img data-src=" />





Miam, vite du ketchup … j’adore manger ces verdatres aux oreilles pointues grillés à la broche!



A votre avis, c’est plutôt à feu doux genre mouton ou un aller-retour genre pavé de bœuf?


C’est sûr que c’est une plaie et qu’en tant qu’utilisateur de composants électroniques ça peut m’arriver. Ce que je reproche c’est la méthode.

&nbsp;

Il y a plein de personnes qui ont des équipement comportant des composants falsifiés ce qui peut avoir de multiples conséquences et même des « gros » se font avoir. Mais la technique consistant à planter silencieusement les utilisateurs n’est pas franchement appropriée. Madame (ou Monsieur) Michu va prendre sa station de soudage à air chaud pour dessouder un QFN pour le remplacer par la version officielle ?

&nbsp;

En revanche lors de la mise à jour émettre un message comme quoi le composant semble être contrefait et que la mise à jour ne s’appliquera pas en invitant les utilisateurs à demander des comptes au vendeur du produit aurait peut-être été plus judicieux.



Il faut faire quelque chose, mais le lonesome cow boy avec dégâts collatéraux, très peu pour moi.


Comme le précise l’article, le “michu” contrefacteur actif peut remettre sa contrefaçon en fonctionnement.


Analogie complètement à côté de la plaque.

Pense d’abord à bien lire le sujet et essayer de comprendre réellement ce qu’il s’est passé.



Le driver ne détruit rien. Il s’arrange juste pour ne fonctionner que sur le matériel pour lequel il a été conçu.








francois-battail a écrit :



C’est sûr que c’est une plaie et qu’en tant qu’utilisateur de composants électroniques ça peut m’arriver. Ce que je reproche c’est la méthode.

&nbsp;

Il y a plein de personnes qui ont des équipement comportant des composants falsifiés ce qui peut avoir de multiples conséquences et même des « gros » se font avoir. Mais la technique consistant à planter silencieusement les utilisateurs n’est pas franchement appropriée. Madame (ou Monsieur) Michu va prendre sa station de soudage à air chaud pour dessouder un QFN pour le remplacer par la version officielle ?

&nbsp;

En revanche lors de la mise à jour émettre un message comme quoi le composant semble être contrefait et que la mise à jour ne s’appliquera pas en invitant les utilisateurs à demander des comptes au vendeur du produit aurait peut-être été plus judicieux.



Il faut faire quelque chose, mais le lonesome cow boy avec dégâts collatéraux, très peu pour moi.





Mouais, mais qui dit que ces copies marchent bien ou bien avec le driver normal?

Il se peut que FTDI en ait eu assez de plaintes clients (OEM) ou messages de forum disant que leurs produits plantaient alors qu’il se serait agi de copies? Ce genre de cas de figure est monnaie courante.



&nbsp;Il me revient le cas d’un fabricant (français) d’interfaces de com. pour dialogue avec véhicules (les fameux “boitiers de diagnostic”) qui avait été massivement copié (le hard) et de manière douteuse + son soft qui était “vendu” avec (et cela continue même peut-être).

Il me semble qu’ils avaient eu des tonnes de “plaintes client” relatives à des dysfonctionnements…

Sympa quand le marché est innondé de copies bas de gamme et qui ont du leur faire très mal au porte-feuille (il n’y a pas du y avoir que les particuliers qui ont acheté et à qq milliers d’euros le kit…).

Il me semble qu’ils avaient fini par faire de la plainte systématique et par lancer une version “light” plus accessible, mais semblaient avoir eu très chaud.

&nbsp;



Sauf si tu passes par Win Update où là tu l’as dans l’os (si j’ai bien suivi la discussion)


Euh, à cette heure je suis un peu fatigué, mais j’ai vraiment du mal à déceler le profil « contrefacteur actif » de Mme ou M. Michu à partir de l’article. Ça serait aimable d’être plus explicite.








francois-battail a écrit :



Euh, à cette heure je suis un peu fatigué, mais j’ai vraiment du mal à déceler le profil « contrefacteur actif » de Mme ou M. Michu à partir de l’article. Ça serait aimable d’être plus explicite.





Ben “actif” car remettre le PID de FTDI dans une puce contrefaite est un acte de contrefaçon volontaire et actif



Justement, lors d’une mise à jour cela peut-être l’occasion de faire une mise au point et d’expliquer la position de l’entreprise à l’origine du produit original. Mais taper silencieusement sur les utilisateurs, que l’on peut supposer de bonne foi, sans engager a priori (je n’ai pas l’info)&nbsp; d’actions vers la ou les sources de contrefaction, c’est un peu raide.



C’est une solution pour personne ; l’image en prend un coup, les utilisateurs (qui ne connaissaient probablement pas FTDI) sont dégoûtés, les ventes n’augmentent pas et les problèmes de contrefaçon ne sont pas résolus. Le bilan est pas terrible.








UnYx a écrit :



Miam, vite du ketchup … j’adore manger ces verdatres aux oreilles pointues grillés à la broche!









UnYx a écrit :



A votre avis, c’est plutôt à feu doux genre mouton ou un aller-retour genre pavé de bœuf?





Pavé de bœuf : une claque sur chaque oreille. <img data-src=" /><img data-src=" />









UnYx a écrit :



Ben “actif” car remettre le PID de FTDI dans une puce contrefaite est un acte de contrefaçon volontaire et actif





Pure supputation, quel pourcentage de la population est capable 1) de comprendre le problème, 2) de le contourner ? La nana ou le mec qui s’éclate avec sa carte compatible Arduino en faisant clignoter une led n’a pas été prévenu du problème. À qui elle ou il va imputer la faute ?

&nbsp;

À ce que je sache, un nombre est dans le domaine public donc la conclusion juridique est quelque peu rapide, de plus c’est FTDI qui met à disposition si j’ai bien compris le moyen de le faire… sans parler des possibilités au niveau logiciel de redéfinir le VID:PID.

Comme d’hab ce sont les utilisateurs de bonne foi qui vont en pâtir.



Des acheteurs se sont déjà fait rembourser. Le vendeur n a pas intéret a faire la sourde oreille quand on lui parle contrefacon.



Faites vous rembourser !








francois-battail a écrit :



Bah voyons. Zéro blessé, plus d’hydraulique, un missile à détection thermique qui se dirige vers quoi déjà ? Un incendie qui dévore l’aile pleine de carburant… Quant à parler de crash, franchement c’est peut être oublier : « un bon atterrissage c’est quand tout le monde est en vie après, un très bon atterrissage c’est quand on peut réutiliser l’avion. ».&nbsp;





Le missile a raté sa cible (comme la plupart des vieux missiles a guidage thermique, tout sauf précis) et a touché le bout de l’aile, mettant le feu au carburant qui en fuyait, on est bien d’accord, tu as raconté des conneries tout à l’heure. Et tu as essayé de faire comparaison erronée entre deux choses qui n’avaient rien à voir (A380 vs A300, juste 40 ans d’écart), la structure n’ayant pas été atteinte (il s’est crashé, et non posé, à cause de l’hydraulique, toi même tu semble l’avoir redécouvert).



Maintenant, tu veux me mettre ta digression vers l’aéronautique sur le dos ?



C’est toi qui est prêt à tout pour avoir raison, du mensonge grossier au hors sujet complet. Manque de peau, vu que tu ne t’y connais en rien, il est toujours aisé de voir tes tromperies et manipulations.

Bienvenue dans mon ignore list, c’est plus que mérité.



Arduino c’est pas de l’électronique ça, c’est de l’informatique bas niveau…








Winderly a écrit :



Oui mais si l’utilisateur ignore que son produit est contrefait ?



Si l’utilisateur l’ignore, quand son produit ne marche plus, il contacte le vendeur ou fabriquant pour faire jouer sa garantie, tout simplement.

Après investigation, il sera mis en avant que le produit était contrefait et l’utilisateur pourra donc se retourner contre le vendeur.









jmanici a écrit :



La diffusion de pilotes via Windows Update est soumise à une certification WHQL. Donc Microsoft a bien testé les drivers du fabriquant avec le hardware fourni par le fabriquant.



C’est en soit un gros problème de procédure,&nbsp; si Microsoft avais fait les tests sur du matériel du marché ils n’aurais jamais validés ce pilote. De plus aujourd’hui c’est un problème de contrefaçon, mais avec cette

méthodologie tu ne teste pas les éventuels problèmes d’intégration en dehors de la carte de test fournie par le fabricant ? Je m’attendais à plus de sérieux de la pars du programme WHQL !









francois-battail a écrit :



Ah ? Voyons, n’est-ce pas sciemment que cette mise à jour a été poussée ? Pour l’aspect « programmée » le jeu de mot était facile mais permettre de reprogrammer le VID:PID depuis l’USB je le répète c’est stupide (d’habitude c’est une série spéciale commandée au constructeur puisque ces informations font partie du masque).

Plutôt que de s’attaquer au contrefacteurs, on préfère s’attaquer à distance avec une rustine foireuse qui a pour effet de planter les utilisateurs légitimes.

C’est un peu facile et surtout très inquiétant si ça se généralisait.





Je sais pas pourquoi tu insistes là dessus, la plupart des config du PCI bridge sont reprogrammables (EEPROM) via un des registres qui est accessible librement. Il faut simplement pas se planter dans le protocole et le binaire que tu lui envoies.









GentooUser a écrit :



C’est en soit un gros problème de procédure,&nbsp; si Microsoft avais fait les tests sur du matériel du marché ils n’aurais jamais validés ce pilote. De plus aujourd’hui c’est un problème de contrefaçon, mais avec cette



 méthodologie tu ne teste pas les éventuels problèmes d'intégration en dehors de la carte de test fournie par le fabricant ? Je m'attendais à plus de sérieux de la pars du programme WHQL !







Non mais attends, y a plusieurs millions de cartes qui circulent en vente libre pour PC, tu voudrais que Microsoft fasse une enquête et tiennent à jour les tendances de piratages de ces cartes ? Non mais ça va pas bien …



En fait au lieu de reprogrammer les VID/PID ils auraient mieux fait de capturer l’IP et d’envoyer ça à la police avec une plainte pour recel … puisque c’est de ça dont il s’agit.









francois-battail a écrit :



Justement, lors d’une mise à jour cela peut-être l’occasion de faire une mise au point et d’expliquer la position de l’entreprise à l’origine du produit original. Mais taper silencieusement sur les utilisateurs, que l’on peut supposer de bonne foi, sans engager a priori (je n’ai pas l’info)&nbsp; d’actions vers la ou les sources de contrefaction, c’est un peu raide.



C’est une solution pour personne ; l’image en prend un coup, les utilisateurs (qui ne connaissaient probablement pas FTDI) sont dégoûtés, les ventes n’augmentent pas et les problèmes de contrefaçon ne sont pas résolus. Le bilan est pas terrible.





La bonne foi n’existe pas quand il s’agit de contre-façon ou recel, c’est immédiatement condamnable (et totalement indéfendable même avec le meilleur avocat, en passant).









catseye a écrit :



Non mais attends, y a plusieurs millions de cartes qui circulent en vente libre pour PC, tu voudrais que Microsoft fasse une enquête et tiennent à jour les tendances de piratages de ces cartes ? Non mais ça va pas bien …



Juste tester sur un échantillon de vrai matériel du marché, les défauts apparaitrons d’eux-même.









catseye a écrit :



La bonne foi n’existe pas quand il s’agit de contre-façon ou recel, c’est immédiatement condamnable (et totalement indéfendable même avec le meilleur avocat, en passant).





Pour du Vuitton acheté 5€ sur un marché en Italie oui, pour un composant à 50ct sur une carte qui coûte 45€j’ai beaucoup plus de doutes !









GentooUser a écrit :



C’est en soit un gros problème de procédure,&nbsp; si Microsoft avais fait les tests sur du matériel du marché ils n’aurais jamais validés ce pilote. De plus aujourd’hui c’est un problème de contrefaçon, mais avec cette

méthodologie tu ne teste pas les éventuels problèmes d’intégration en dehors de la carte de test fournie par le fabricant ? Je m’attendais à plus de sérieux de la pars du programme WHQL !





Sauf qu’il n’y a aucun problème avec l’intégration des cartes dans d’autres machines.



S’il y a un problème, ce sont des contrefaçons: il s’agit alors de se retourner contre le vendeur qui t’as vendu la contrefaçon et lui demander remboursement et réparation du préjudice subi.



&nbsp;









catseye a écrit :



La bonne foi n’existe pas quand il s’agit de contre-façon ou recel, c’est immédiatement condamnable (et totalement indéfendable même avec le meilleur avocat, en passant).





Non.

Dans notre cas, l’article L615-1 3e alinéa du CPI permet d’exclure la responsabilité du “contrevenant” quand il n’en avait pas connaissance.



&nbsp;



&nbsp;









GentooUser a écrit :



C’est en soit un gros problème de procédure,&nbsp; si Microsoft avais fait les tests sur du matériel du marché ils n’aurais jamais validés ce pilote. De plus aujourd’hui c’est un problème de contrefaçon, mais avec cette

méthodologie tu ne teste pas les éventuels problèmes d’intégration en dehors de la carte de test fournie par le fabricant ? Je m’attendais à plus de sérieux de la pars du programme WHQL !





Ils en ont rien a foutre MS de faire leur test sur du matos autre qu’officiel. Leur tests sont la pour vérifier que les drivers fonctionnent bien avec le matos pour lequel ils ont été codés. Ils ont pas a gérer le matos utilisant de la contrefaçon.



&nbsp;



GentooUser a écrit :



Juste tester sur un échantillon de vrai matériel du marché, les défauts apparaitrons d’eux-même.





C’est débile. Ni MS ni la boite qui a fourni le driver ne sont pas pour s’assurer du bon fonctionnement du driver sur autre chose que les produits officiels.









francois-battail a écrit :



Pure supputation, quel pourcentage de la population est capable 1) de comprendre le problème, 2) de le contourner ? La nana ou le mec qui s’éclate avec sa carte compatible Arduino en faisant clignoter une led n’a pas été prévenu du problème. À qui elle ou il va imputer la faute ?

&nbsp;

À ce que je sache, un nombre est dans le domaine public donc la conclusion juridique est quelque peu rapide, de plus c’est FTDI qui met à disposition si j’ai bien compris le moyen de le faire… sans parler des possibilités au niveau logiciel de redéfinir le VID:PID.

Comme d’hab ce sont les utilisateurs de bonne foi qui vont en pâtir.





Quel est le pourcentage de la population utilisant ce genre de matos ?? Faut arrêter un moment, ceux qui utilisent ce genre de matos sont a 95% des gens capable de trouver et d’utiliser le fix.









psn00ps a écrit :



Le fautif est le contrefacteur.



Un utilisateur légitime d'une contrefaçon ? <img data-src="> Et puis quoi encore ?







Le contrefacteur n’y est pour rien dans la diffusion d’un logiciel qui cause des dommages à certains hardware…

Tu est du genre chinois à abattre les opposants d’une balle puis la faire payer à la famille ?

On est en France il est interdit de faire justice soi-même !



Qui te dis que des bidouilleurs n’usurpent pas eux même le VID/PID en tant qu’utilisateurs finaux ?

Ai-je “PERSONNELLEMENT” l’obligation de répondre aux standards USB-IF quand je bidouille dans ma cave ?

Dois-je respecter des normes américaines lorsque je travail sur un projet personnel ?

&nbsp;

&nbsp;





127.0.0.1 a écrit :



La faute c’est que la puce clonée ne passe pas le test “puce_officielle”, alors qu’elle utilise le VID/PID d’une puce officielle. En gros, la contrefaçon n’est pas assez bonne pour tromper le “IF puce_officielle THEN …”.





Est-ce illégal ? Est-ce immoral ? Est-ce génial ?



Mon sentiment en 3 lettres: Pwn !





Ce que t’as pas compris c’est que le ELSE est illégal !



En plus d’être une volonté de nuire, c’est une faute professionnelle !



Lorsqu’un hardware ne répond pas aux specs attendues par un pilote on lève une exception on ne fait pas le shérif ! (surtout qu’il pourrait y avoir 1 millions de raisons pour que la vérification de leur puce échoue !)



Fournir un programme qui contient “ELSE destroy_hardware()” c’est du piratage (du vrai) une atteinte a un système automatisé de traitement de données qui n’appartient pas à l’éditeur de cette puce…



&nbsp;







Tatsu-Kan a écrit :



Tu te trompe complètement et tu raconte des bêtises.

C’est un driver, pas un firmware pour commencer.



Là, le check est simple et bien différent :




  • puce genuine -&gt; On fait rien

  • puce contrefaite -&gt; Reset du Vendor ID usurpé.





    Faut lever le pied, j’ai toujours dit que c’était un driver, la macro-description de son comportement est un peu grossière, mais la version originale est franchement pire,

    s’il y avait un flash des puces officielles au moins le logiciel pourrait se targuer d’impacter les puces contrefaites par effet de bord, mais là en effet ce logiciel n’a normalement aucune raison de toucher au firmware d’une puce, sauf quand il se fait justice lui même !



    Comme décrit plus haut je peux avoir mes raison pour ne pas souhaiter qu’un VID soit reseté !









yeagermach1 a écrit :



Quel est le pourcentage de la population utilisant ce genre de matos ?? Faut arrêter un moment, ceux qui utilisent ce genre de matos sont a 95% des gens capable de trouver et d’utiliser le fix.





Le fix, ou débriquage ne marchera que pour la personne qui effectue la manipulation, si le périphérique est ensuite branché à n’importe quel autre système à jour, le pilote USB est exécuté à nouveau et le périphérique à nouveau reset !



Non mais tu crois vraiment que Microsoft test chaque périphérique en les branchant????

Les tests des drivers ne vérifient qu’ils n’y&nbsp;a pas de gros problèmes sur le driver, c’est tout. C’est fait de manière automatique.

Tu croyais vraiment que tu avais des gars qui allaient acheter chaque périphérique pour les brancher et allait faire une qualification de chaque driver? Genre, une imprimante sort, on va demander à quelqu’un d’aller la brancher, vérifier qu’elle imprime bien en N&B, en couleur, en recto verso, qu’elle met bien les agrafes, etc…?

On parle de dizaines de milliers de pilotes pour bien plus de matériels différents…et il faudrait aller en plus&nbsp;dans chaque pays, pour chercher le matos contrefait? rassure moi, tu blagues

Le constructeur reste responsable du fonctionnement du&nbsp;pilote qu’il livre. Et dans le cas de cette news, les contrefaçons ne semblent même pas détectable car le PID et le VID sont identiques.

Donc même le constructeur n’est pas à blamer, tu ne peux pas demander au constructeur d’aller tester les contrefaçons. Déjà qu’ils perdent de l’argent avec la contrefaçon, tu voudrais qu’ils en perdent encore plus en faisant des enquêtes pour savoir quels contrefaçons ont été vendues. Et je te parle même pas du délai nécessaire (tu serais le premier à te plaindre du délai de mise à jour)



Les entreprises ayant vendu ce genre de matériel contrefait sont les seules responsables!

&nbsp;


La question n’est pas là: on ne peut pas reprocher à Microsoft, intel, apple, google&nbsp;ou autres de protéger leur business model, surtout dans la mesure où celui-ci devient assez rapidement outre atlantique un problème de sécurité nationale.

On sait ce qu’est Microsoft comme sont toutes les énormes boites US de l’IT: avec cette annonce, on est juste face à une énième charge gratuite qui ne convaincra que ceux qui sont déjà convaincus.


Pour info, les cartes arduino n’utilisent plus de puce FTDI depuis 2010.


les &nbsp;adaptateurs usb vers port series sont ils concernes ?



je me suis pas servis &nbsp;du mien depuis des lustres.

&nbsp;


Comme certains l’ont déjà répondu, le problème du code malicieux n’as pas besoin d’attendre les contrefaçons… Cela peut tout aussi bien exister dans des chips officiels. (Surtout que nombre de fondeurs se trouvent en Chine, avec un gouvernement qui pousse à la mise en place des backdoors, hardware ou software).

Dans le cas des transpondeurs, ces puces FT232 servent en partie pour la supervision. Donc aucune communication avec les traffic opérateur. (Mais critique malgré tout, car les outils de supervision ajustent & surveillent les paramètres optiques et les alarmes en permanence)



D’autre part, comme expliqué aussi, connaître l’origine réelle des lots de composants n’est pas simple. Croyez-moi, même en demandant la traçabilité, rien ne garantit qu’elle soit valide. Les contrefacteurs sont doués pour noyer leurs copies dans la masse, et après tout c’est logique : c’est leur business qui en dépend…



Et oui, dans l’exemple que tu cite, sur l’ABS de ma voiture, je crierais aux abois si une procédure de mise hors service déployée par le fabriquant d’une puce venait perturber mon ABS, élément vital. Car cette puce en question, bien que contrefaite possède probablement la même fiabilité et la même fonction opérationnelle que l’originale : Si elle est active, elle peut me sauver. Ça serait là un scandale méritant forte punition.



Je ne fais pas l’apologie de la contrefaçon, tout comme je comprends l’exaspération de FTDI qui l’a poussé à en venir à cette solution. Mais ce n’est pas une bonne solution (surtout que FTDI fournit lui-même un outil pour réactiver les puces -illégales- sur son site…)



Et là, clairement ils ne mesurent pas l’ampleur que ça pourrait avoir. Aujourd’hui, un “mini-scandale” sur un convertisseur USB/RS-232, demain un “méga-scandale” sur des DSP, FPGA, ou autre composant utilisé massivement pour des fonctions critiques dans l’électroménager, l’automobile, le biomédical, l’aviation, les télécoms, etc. Outre le problème de FTDI, ils ont ouvert la voie à de potentiels autres exemples de cette pratique !


C’est vrai que le titre fait un peu racoleur ^^’





Par rapport à l’article, je comprend la volontée de la part de FTDI qui de doit se dire comme ca pas besoin de passer devant les tribuneaux pour entendre dire “on ne peux rien faire”.



D’un autre coté,&nbsp; c’est la porte ouverte à n’importe quoi.








psn00ps a écrit :



Relis le dernier paragraphe et la définition de “briqué”. <img data-src=" />



c’est bien connu, aucun appareil “briqué” n’a jamais pu être remis en fonctionnement sans passer par la case SAV. absolument jamais. même pas un iPhone <img data-src=" />



+1 j’ai le même problème avec ma-config.com les gens sont persuadés que je teste chaque driver alors que c’est totalement impossible <img data-src=" />


Mais au moins il a le mérite d’en fournir un,donc il peut être de bonne foi.

&nbsp;


le problème est surtout que c’est le consommateurs final qui ramasse ! pas la boite qui contrefais … et c’est la le gros problème, car l’acheteur final n’a AUCUN moyen de savoir si il achète de l’officiel ou non …



mais le gros problème c’est surtout que tout les type de périph USB on cette puce FT232 y compris les clef USB ou je me trompe ?

car si les clef usb/DD externe l’on également ça va être un énorme bordel !


Salutations,&nbsp;



Je trouve que le titre est assez mal choisi : quelques personnes, qui ne liront pas l’article (ou de travers) vont simplement conserver et propager l’information contenue dans le titre…

Alors que WU n’a pas vraiment de responsabilité là dedans, c’est juste un vecteur ; si le constructeur décide de détruire des clones ou des copies illégales, c’est lui le responsable.

Après, à savoir s’il a le droit ou non de faire ça, c’est un débat où je ne me sens pas compétent et sur lequel je n’arrive pas à trancher.



Par contre GG le sous-titre ;)

&nbsp;








Nozalys a écrit :



&nbsp;des fonctions critiques dans l’électroménager





Mon aspirateur est devenu fou &nbsp;!!&nbsp;<img data-src=" />



Si le driver arrive à détecter une puce contrefaite, un logiciel devrait pouvoir y arriver aussi, sans passer par une analyse aux rayons X et au spectromètre de la plomberie interne..









sepas a écrit :



Non mais tu crois vraiment que Microsoft test chaque périphérique en les branchant????

Les tests des drivers ne vérifient qu’ils n’y&nbsp;a pas de gros problèmes sur le driver, c’est tout. C’est fait de manière automatique.

Tu croyais vraiment que tu avais des gars qui allaient acheter chaque périphérique pour les brancher et allait faire une qualification de chaque driver? Genre, une imprimante sort, on va demander à quelqu’un d’aller la brancher, vérifier qu’elle imprime bien en N&B, en couleur, en recto verso, qu’elle met bien les agrafes, etc…?

On parle de dizaines de milliers de pilotes pour bien plus de matériels différents…et il faudrait aller en plus&nbsp;dans chaque pays, pour chercher le matos contrefait? rassure moi, tu blagues

Le constructeur reste responsable du fonctionnement du&nbsp;pilote qu’il livre. Et dans le cas de cette news, les contrefaçons ne semblent même pas détectable car le PID et le VID sont identiques.

Donc même le constructeur n’est pas à blamer, tu ne peux pas demander au constructeur d’aller tester les contrefaçons. Déjà qu’ils perdent de l’argent avec la contrefaçon, tu voudrais qu’ils en perdent encore plus en faisant des enquêtes pour savoir quels contrefaçons ont été vendues. Et je te parle même pas du délai nécessaire (tu serais le premier à te plaindre du délai de mise à jour)



Les entreprises ayant vendu ce genre de matériel contrefait sont les seules responsables!

&nbsp;







C’est pas comme si j’avais parlé “d’échantillon”&nbsp; <img data-src=" />



Le programme WHQL est sensé être une protection pour l’utilisateur, avec le fonctionnement présent, autant l’arrêter tout de suite.



Le VID c’est pas dieu comme info, surtout quand c’est en mémoire réinscriptible. Le pilote WHQL aurait tout simplement dû refuser de se charger (libre au constructeur d’être plus “méchant” sur son pilote distribué directement). Que Microsoft valide en WHQL un pilote qui désactive du matériel sans avertir l’utilisateur c’est quand-même grave.



Au fait Microsoft teste ses pilotes ATA génériques sur des graveurs LG ? Parce-que ça a déjà posé problème à Linux dans le passé. Comme quoi, la contrefaçon n’est pas la seule en risque avec une mauvaise méthodologie.



Pour avoir déjà utilisé cette fameuse puce FTDI, le VID/PID est flashable car ces composants sont personnalisables. Par défaut, c’est celui de FTDI qui est dedans et on peut l’utiliser pour des séries inférieures à 10 pièces. C’est donc fait pour du prototypage ou à usage personnel.



Ensuite, il faut faire une demande pour obtenir son propre VID (le PID est au choix de l’utilisateur) et les puces FTDI doivent être flashées avec ce VID/PID. Le pilote écrit par FTDI est utilisable à condition de l’accompagner de son propre fichier .inf dans lequel il apparaîtra le nouveau VID/PID. Ce fichier .inf doit ensuite être signé par l’utilisateur ou mieux, par Microsoft en lui faisant passer la certification WHQL (ce qui se fera sans soucis vu que le pilote de FTDI est déjà lui-même WHQL).



Evidemment, un contrefacteur qui falsifie la puce ne va pas créer un pilote certifié WHQL pour l’utiliser ! Il est beaucoup plus simple de se faire passer pour le fabricant officiel, ça ne coûte rien !








francois-battail a écrit :



Si l’avion a survécu c’est surtout que le copi a fait du click-click au mépris des règlements pour en revenir aux fondamentaux : avoir une vue claire sur la situation réelle. A priori selon les témoignages du documentaire de la BBC les erreurs étaient empilées au lieu d’être recalculées / réévaluées après chaque acquittement.

Pour le reste heureusement qu’il y a des systèmes&nbsp; indépendants bien conçus et très bien testés capables de résister en mode dégradé.

Pour ta gouverne ce n’est pas le premier avion à s’être retrouvé dans une situation ultra-critique avec atteinte structurelle (il faut voir du côté de DHL qui a quand même encaissé un missile peu après le décollage), mais là il n’y avait pas trop d’informatique (de mémoire un A310).





Il faut dire quand même que ces systèmes ne sont pas conçu pour faire de la consolidation de panne critique, en théorie, jamais ces pannes n’auraient du se produire simultanément…&nbsp;



Ce n’est pas magique l’informatique aéronautique, ces calculateurs sont fait pour informer le pilote de l’ensemble des pannes de son avion, c’est au pilote de faire la consolidation de ces informations pour connaitre l’état de son avion - mais c’est vrai que airbus n’avais pas prévu la possibilité d’arrivé de tant de panne, et la difficulté pour un équipage de la gérer.&nbsp;



L’explosion non contenue d’un moteur est un incident majeur (ce n’est pas pour rien qu’il est très surveillé dans la qualification), et considéré comme fatal ( si une pièce avait endommagé la structure de l’avion, ça aurait été le cas ici)&nbsp;



Prendre ce cas extrême dans l’histoire de l’aviation moderne comme référence dans ton argumentaire est un peu gros…



Pour avoir moi même valider mes propres drivers en whql c’est une procédure totalement automatisé par Microsoft. En fait tu vas lancer une série de tests sur différentes machines clientes qui dépendent de la classe du driver. Si ces tests passent un fichier de résultats signé par un certificat est crée. Ensuite par le portail développeur dédié tu envoies ce fichier. Coté serveur il y a une série de vérifications automatiques qui se lancent et Microsoft renvoit au développeur le driver signé avec le bon fichier .cat WHQL.



Pour la reprogrammation du vid , c’est propre au matériel. C’est impossible de le détecter. Et comme Sepas l’a écrit avant ils ne peuvent pas tester les drivers sur l’ensemble des matériels compatibles. je suis plutôt bien placé pour en parler.


Défendre son business mais à quel prix?



Les utilisateurs ne peuvent être tenus pour responsable, pas dans ce cas de figure.



Reflasher la puce pour la rendre inutilisable et donc condamner le montage ou l’appareil entier c’est l’idée la plus conne que j’ai jamais vu, bravo le gâchis, bravo pour l’image que cette boite envoie.



la prochaine fois ils feront carrément exploser la puce?



Je rappelle encore une fois qu’on parle de minuscules composants électroniques, la copie est monaie courante, il est très difficile d’y échaper car il est impossible de vérifier l’authenticité de ces pièces.








GentooUser a écrit :



C’est pas comme si j’avais parlé “d’échantillon”&nbsp; <img data-src=" />



Le programme WHQL est sensé être une protection pour l’utilisateur, avec le fonctionnement présent, autant l’arrêter tout de suite.



Le VID c’est pas dieu comme info, surtout quand c’est en mémoire réinscriptible. Le pilote WHQL aurait tout simplement dû refuser de se charger (libre au constructeur d’être plus “méchant” sur son pilote distribué directement). Que Microsoft valide en WHQL un pilote qui désactive du matériel sans avertir l’utilisateur c’est quand-même grave.



Au fait Microsoft teste ses pilotes ATA génériques sur des graveurs LG ? Parce-que ça a déjà posé problème à Linux dans le passé. Comme quoi, la contrefaçon n’est pas la seule en risque avec une mauvaise méthodologie.





Est-ce que tu penses sérieusement que MS va prendre le risque d’aller au souk pour monter un échantillon en se rendant coupable de recel?



A mon avis le matériel qu’ils testent (car ils doivent certainement en tester quelques-uns quand même) provient de circuits ultra contrôlés et officiels et ils y a peu de chance pour eux de tomber sur une contre façon.



D’ailleurs le simple fait pour eux de tomber sur une contre façon doit pouvoir leur valoir quelques ennuis légaux, donc ton arguments est difficilement applicable.









charon.G a écrit :



Pour la reprogrammation du vid , c’est propre au matériel. C’est impossible de le détecter. Et comme Sepas l’a écrit avant ils ne peuvent pas tester les drivers sur l’ensemble des matériels compatibles. je suis plutôt bien placé pour en parler.





&nbsp;Impossible a détecter, mais FTDI a bien trouvé un moyen d’identifier le matériel contrefait.



La meilleure-chose que pourrait faire Microsoft, c’est d’exclure FTDI du programme WHQL.



Non il ne teste pas les matériels. Comme je l’ai expliqué au dessus la procédure de publication des drivers est automatisé


La certification WHQL ne concerne que l’implémentation technique du driver au sein de Windows. Donc juste le fait que le drivers fonctionne bien sous windows.

Ce que fait le driver avec leur periferique ne concerne pas WHQL, ni Windows ni Microsoft.

Microsoft ne test pas les drivers avec leur periferique, ne possede pas non plus les sources des drivers. ils verifient juste que l’instalation du drivers respecte les bon usage “windows”, qu’une fois installé la stabilité du système et des applications Windows est préservée.



Concernant le pb de la news, Microsoft/windows n’ont strictement rien a voir là dedans. De plus ce que fait ce drivers, il le fait tout autant si il est installé manuellement. Et d’ailleur il y a fort a parier que si le constructeur publi aussi un drivers officiel sous Linux, celui-ci fasse de même.

Bref il ne faut pas tout melanger

&nbsp;








charon.G a écrit :



Non il ne teste pas les matériels. Comme je l’ai expliqué au dessus la procédure de publication des drivers est automatisé





Ok, je pensais que pour certains cas il y avait des tests matériels.



Tu fait bien de parler du pilote distribué, car le pilote du noyau (ftdi_sio)&nbsp; ne fera jamais une chose pareille, ou Linus gueulerai très fort.



En plus sous Linux on a une vraie période de test sur du matériel variés grâces aux phases de Release Candidate.


Il doit envoyer une commande USB personnalisé qui permet de modifier cette information sur leur matériel. Seul FTDI sait le faire. Comme je l’ai expliqué au dessus c’est propre au matériel.



Ils ne vont pas exclure un contructeur sur Windows Update. Après les gens gueuleraient car il n’auraient plus de drivers. Légalement ils risquent surement d’avoir des problèmes.



Pour la publication sur Windows Update, j’apporte une précision. Les soumissions de driver HCK (WHQL) ou WLK (Windows Logo) sont nécessaires pour pouvoir publier son driver sur Windows Update. A ma connaissance il n’est pas possible de publier un driver non certifié par Windows Update.


Je sais pas si c’est déjà passé dans un des commentaires mais je le met au cas où:

https://lkml.org/lkml/2014/10/23/151

FTDI a essayé de patcher le kernel linux avec sa bidouille ^^








GentooUser a écrit :



La meilleure-chose que pourrait faire Microsoft, c’est d’exclure FTDI du programme WHQL.





Mais pourquoi Microsoft devrait excluse FTDI du programme WHQL ???

A ce que je sache, le pilote FT232R fonctionne parfaitement sur le matériel pour lequel il est sensé fonctionner.



Le blocage de son fonctionnement sur les puces contrefaites ne DETRUIT rien. Il retire seulement l’usurpation du VID par la puce contrefaite. La détection par Windows n’est alors plus automatique, il faut forcer le driver en manuel.



Si on devait faire une analogie avec le monde automobile, c’est comme l’homologation des véhicules. Tu ne va pas aller te plaindre que ta voiture n’est pas homologué pour rouler avec des roues de voiturette de golf et que le constructeur et l’autorité de certification ne l’ont pas testé.



Qui te dit qu’ils n’étaient pas jusqu’à présent obligé de prendre en compte les puces contrefaites dans le développement de leur driver et que cette prise en charge provoquait une baisse de la qualité de fonctionnement du driver impactant les puces genuines ?



Maintenant, c’est au consommateur de se retourner contre le vendeur qui lui se retournera contre l’industriel qui a osé vouloir faire 2 centimes d’économies en utilisant des contrefaçons.





Note : Au départ, en lisant simplement l’article de Nxi, j’avais le même avis global que FTDI avait fait de la merde et que c’était une honte. Et en allant creuser, c’est bien plus complexe et bien moins incriminant pour FTDI. L’article Nxi est trompeur. Sans parler du titre qui est une honte pour Nxi.









charon.G a écrit :



Pour la publication sur Windows Update, j’apporte une précision. Les soumissions de driver HCK (WHQL) ou WLK (Windows Logo) sont nécessaires pour pouvoir publier son driver sur Windows Update. A ma connaissance il n’est pas possible de publier un driver non certifié par Windows Update.





tout a fait, mais cette certification ne concerne que l’interaction du driver avec Windows. ce que fais le driver avec le periferique n’est pas validé/testé/certifié par le WHQL.



Cette histoire de contrefaçon est une chaîne de responsabilité. Salut les maillons. Nous avons donc :




  • l’acheteur de l’OEM qui fait son boulot d’acheteur, à savoir tirer les prix vers le bas ; en même temps il n’est pas électronicien, l’acheteur…

  • le fabricant de la puce originale qui y va un peu fort, en effet un refus de fonctionnement et/ou un avertissement sur la contrefaçon aurait été suffisant.

  • le grossiste / distributeur qui met la pression sur l’OEM pour réduire les coûts.

  • l’éditeur de l’OS qui n’a pas un processus de validation suffisant, on parle quand même de mettre sciemment en panne un produit

  • l’utilisateur final qui est coupable du délit de recel de contrefaçon, même s’il a acheté son produit de bonne foi chez un distributeur reconnu

    Autrement, je me souviens d’une carte mère particulièrement ratée, la MSI 6330. Les condos d’alimentation contrefaits pétaient au bout de 3 ans et le chip qui gérait le port parallèle n’avait pas toutes les fonctions du Intel 8255 original qu’il était sensé émuler.


Hé bien moi, du jour au lendemain, sans réels causes, j’ai perdu les options ( avancées ) de mon bios Lenovo B570e qui permettent par exemple de contrôler convenablement les ventilateurs de mon pc Intel ! Depuis j’ai téléchargé de nouveau mon bios et essayé d’installer plusieurs fois par la suite depuis un fichier ( .exe ) et au redémarrage de mon pc puis en allant dans mon bios, toujours rien, les options manquante d’Intel n’apparaissent point ! … Du coup mon les ventilateurs font un bruit pas possible lorsque je lis une vidéo Youtube, Dailymotion etc … sa rame pas mal et c’est bien chiant !








yeagermach1 a écrit :



&nbsp;

C’est débile. Ni MS ni la boite qui a fourni le driver ne sont pas pour s’assurer du bon fonctionnement du driver sur autre chose que les produits officiels.





Je ne suis pas d’accord avec toi. Si un utilisateur lambda peut se retrouver avec un chip contrefait, sur un arduino, un adaptateur série ou tout autre bidule qu’il possède en exemplaire unique, la probabilité que MS passe au travers sans s’apercevoir de rien lors d’un WHLQ correctement mené sur un échantillon représentatif de produits est tout de même trop faible pour être crédible, ou alors c’est le WHQL qui n’est pas crédible.



Possédant un Arduino (Mega) officiel… est-ce que je risque d’être touché par ce problème ? Parce que ça fait un moment que je ne l’ai pas rebranché sur mon PC windows 7, et maintenant ça m’inquiète…








Darken34 a écrit :



Je sais pas si c’est déjà passé dans un des commentaires mais je le met au cas où:

https://lkml.org/lkml/2014/10/23/151

FTDI a essayé de patcher le kernel linux avec sa bidouille ^^







Ah oui, à voir le message du patch, c’est revendiqué comme manip, ils voulaient casser de la puce pirate…



autant, faire un driver qui refuse de fonctionner avec un version non officielle, je peux comprendre



mais tenter de casser le matériel…

j’ai a mon boulot des sondes USB &lt;&gt; RS232, va savoir si elles vont pas aussi casser.. &nbsp;



Voir mon commentaire plus haut. C’est le constructeur qui choisit ses machines de tests pas Microsoft. Le serveur Microsoft se contente de vérifier que les tests sont bien valides. Donc si le constructeur a effectué ses tests sur son propre matériel officiel les tests whql passeront.

Ensuite au risque de me répéter aucun test ne peut être fait pour détecter ce problème.


petite question un peux con, pourquoi ne pas désinstaller simplement cette mis a jour ? quelqu’un aurait il le numéro de version de la mise a jour pour ensuite la virer (comme a une époque avec la MAJ de windows 7 qui détectait les version pirate, mais qu’il était possible de virer)







cela ne concerne que les adaptateur USB -&gt; série ou bien tout les type de matos USB (clef USB, DD etc) ?


Si le changement du vid et pid se fait au chargement du driver, le mal est déjà fait…..








dam1605 a écrit :



Pour revenir sur l’ usurpation du VID/PID (et des champs textes qui vont avec), c’est tout à fait “légal”,&nbsp; peut-être pas très fair-play. Néanmois c’est grandement encouragé par les système de drivers (tel celui de Windows) qui bloquent les appareils qui ne montrent pas patte-blanche via le VID/PID. Un device usb déclare ses fonctionalités indépendamment du VID/PID…



&nbsp;Essayez donc de faire reconnaître un device usb comme une clé-usb sous windows (sans manip administrateur) sans “usurper” de VID/PID alors que le driver est inclus dans windows (et que la spec est librement accessible sur le site de l’USB)…

&nbsp;





Évidemment que ça fonctionne hein…









CaptainDangeax a écrit :



Je ne suis pas d’accord avec toi. Si un utilisateur lambda peut se retrouver avec un chip contrefait, sur un arduino, un adaptateur série ou tout autre bidule qu’il possède en exemplaire unique, la probabilité que MS passe au travers sans s’apercevoir de rien lors d’un WHLQ correctement mené sur un échantillon représentatif de produits est tout de même trop faible pour être crédible, ou alors c’est le WHQL qui n’est pas crédible.





Même dans le cas ou MS ferais les test matériel (ce qui n’est pas le cas, je l’apprend en même temps que toi) il ne faudrait pas s’attendre à ce qu’ils testent la situation du matériel contrefais.



Soyons honnêtes 2mn…



on imagine,




  • je branche un perih avec la puce contrefaite, je me retrouve avec une brique …

    -je la branche sur un PC XP,je remet un bon VID, mon periph fonctionne de nouveau

    -je cherche a virer cette maj qui c’est installer via windows update (déjà faudrait trouver de quel maj il s’agit, pas trouver de numéro ou que ce soit …)

    -ma clef remarcheras sans soucie sur un PC qui AVAIT cette maj





    je me trompe où dans mon idée ? ^^









    et autre question importante a mes yeux,



    cette puce est elle présente sur du matos de stockage USB ? (car si ce n’est pas le cas c’est beaucoup moins “grave” )


Oui tu peux remettre le bon vid avec un utilitaire normalement.

Par contre je pense que le nom du driver dois apparaître dans les mises à jours.


je suis en train de chercher a droite a gauche si je trouve un numéro de mise a jour qui correspond … je tiendrait au courant







et sinon,cette puce est elle présente dans du matériel de stockage ou elle ne sert QUE a convertir un signal USB -&gt; série ?


Sinon, tu force simplement le driver sur ton périph dans le gestionnaire de périphérique, et on n’en parle plus.








detlef a écrit :



et autre question importante a mes yeux,



cette puce est elle présente sur du matos de stockage USB ? (car si ce n’est pas le cas c’est beaucoup moins “grave” )





Dans du stockage, non, dans des systèmes de sondes, de monitoring industriel ou médical, il y a plus de chances…









ragoutoutou a écrit :



Dans du stockage, non, dans des systèmes de sondes, de monitoring industriel ou médical, il y a plus de chances…





Imaginons un scénario improbable où le driver conduise au dysfonctionnement d’un appareil médical avec conséquences pour le patient… je serais curieux de voir la bataille juridique qui s’ensuivrait !









Darken34 a écrit :



Je sais pas si c’est déjà passé dans un des commentaires mais je le met au cas où:

https://lkml.org/lkml/2014/10/23/151

FTDI a essayé de patcher le kernel linux avec sa bidouille ^^







This is definitely not targeting end users



<img data-src=" />



Je suis peut être rouillé avec mon anglais, mais je n’ai pas compris du tout ceci de leur communiqué. J’ai compris que au contraire que c’était volontaire (ils sont désolés…)

Quelqu’un pour me confirmer / infirmer ?


Bon c’est mis à jour chez ArsTechnica et par ricochet ici.



Apparemment, FTDI va mettre à jour son driver pilote pour que les puces contrefaites ne soient plus modifiées. Mais d’après le communiqué de FTDI, il est clair que leur pilote ne fonctionnera plus qu’avec les puces FTDI… ou des contrefaçons dignes de ce nom.


&nbsp;&gt; This is definitely not targeting end users - if you’re unsure if

&gt; ICs are genuine then please don’t use the drivers.



En même temps, y’a pas de raison que ce soit toujours les mêmes qui dérouillent ! <img data-src=" />








jb07 a écrit :



Bon c’est mis à jour chez ArsTechnica et par ricochet ici.




Apparemment, FTDI va mettre à jour son driver pilote pour que les puces contrefaites ne soient plus modifiées. Mais d'après le communiqué de FTDI, il est clair que leur pilote ne fonctionnera plus qu'avec les puces FTDI... ou des contrefaçons dignes de ce nom.








Ils ont plutôt intérêt à clarifier la situation et à arrêter les conneries parceque bon les Michus qui se retrouvent avec une puce contrefaite dans un gadget Chinois à pas cher pour eux ça continuera à être la loterie mais pour les "bidouilleurs" (au sens large) c'était un coup à ce qu'ils scrutent attentivement tous les prochains produits Arduino ou équivalents qu'ils achètent pour s'assurer qu'ils ne comprennent aucune puce siglée FTDI juste au cas où.    





On ne peut pas cautionner la contrefaçon et ils ont raison de chercher à la combattre mais il est absolument inacceptable d’utiliser le sabotage comme moyen de le faire



Quelqu’un aurait t-il une solution pour mon commentaire du vendredi 24 octobre 2014 à 13:34:19 ? ^^


“des puces authentiques ont été touchées dans la manœuvre”



oh bravo

^^



&nbsp;


Bon, d’un autre côté, ceux qui ont la malchance d’avoir acheté un produit contenant la contrefaçon se rendent de fait coupables de recel de contrefaçon s’ils essayent de réparer et de continuer à utiliser leur produit…








after_burner a écrit :



Même dans le cas ou MS ferais les test matériel (ce qui n’est pas le cas, je l’apprend en même temps que toi) il ne faudrait pas s’attendre à ce qu’ils testent la situation du matériel contrefais.



Soyons honnêtes 2mn…





Je ne suis pas d’accord. Ou bien MS se fait offrir des échantillons et là, évidemment, ils n’ont pas de contrefaçon mais leur test n’est pas exhaustif, ou alors ils font comme tous les bons testeurs, ils achètent leurs produits chez des revendeurs et ils vont forcément tomber sur des contrefaçons. Donc, le WHQL c’est du pipeau. CQFD.









charon.G a écrit :



Voir mon commentaire plus haut. C’est le constructeur qui choisit ses machines de tests pas Microsoft. Le serveur Microsoft se contente de vérifier que les tests sont bien valides. Donc si le constructeur a effectué ses tests sur son propre matériel officiel les tests whql passeront.

Ensuite au risque de me répéter aucun test ne peut être fait pour détecter ce problème.





En même temps, &nbsp;FTDI a tenté de patcher le noyau linux avec la même bidouille et ça n’a pas traversé l’étape de relecture du code. Donc, tu peux répéter ce que tu veux, les faits ont prouvé le contraire.



Ah bon je ne savais pas que les constructeurs donnaient le source code de leurs drivers à Microsoft?

Ce n’est pas passé sur Linux car les gens qui intègrent les drivers au noyau Linux vérifient le code. Sans le source code tu ne peux pas empêcher ce type de problèmes.








CaptainDangeax a écrit :



Je ne suis pas d’accord. Ou bien MS se fait offrir des échantillons et là, évidemment, ils n’ont pas de contrefaçon mais leur test n’est pas exhaustif, ou alors ils font comme tous les bons testeurs, ils achètent leurs produits chez des revendeurs et ils vont forcément tomber sur des contrefaçons. Donc, le WHQL c’est du pipeau. CQFD.





&nbsp;Ou plus simplement ça ne fonctionne pas comme tu l’imaginais.

Et quand bien même, le constructeur ne&nbsp;fournirait pas&nbsp;d’autres matériel que le sien&nbsp;pour faire tester ses propres pilotes, ça n’a pas de sens.&nbsp;“Tiens, et si je vérifiais aussi que mes pilotes fonctionnent correctement avec du matériel contrefait” …



Quand je disais qu’aucun test ne pouvais être fait pour détecter le problème, je parlais de tests logiciels. Si tu as le source code c’est autre chose….








ragoutoutou a écrit :



Bon, d’un autre côté, ceux qui ont la malchance d’avoir acheté un produit contenant la contrefaçon se rendent de fait coupables de recel de contrefaçon s’ils essayent de réparer et de continuer à utiliser leur produit…





Surtout que, du coup, ils peuvent se faire rembourser et demander réparation en cas de préjudice/perte de temps.

Plus une dénonciation au fabricant, et le client malchanceux a des chances d’obtenir un geste commercial de la part du fabricant qui l’a aidé à conserver ses produits.



Des fois, il suffit de peu pour que la situation se retourne à notre avantage.









CaptainDangeax a écrit :



En même temps, &nbsp;FTDI a tenté de patcher le noyau linux avec la même bidouille et ça n’a pas traversé l’étape de relecture du code. Donc, tu peux répéter ce que tu veux, les faits ont prouvé le contraire.





Sous Linux, il n’y a&nbsp; eu aucun test de fait.

La demande a été faite après la révélation de l’affaire et le mail envoyé pour le patch explique très bien son effet.

On est très loin du patch windows dont l’explication ne donnait pas cette info qu’on ne pouvait trouver que dans les tréfonds du cluf de 50 pages.&nbsp;



Les faits ne prouvent rien, si ce n’est que sous Linux, on peut refuser un drivers sans même le contrôler.









ragoutoutou a écrit :



Bon, d’un autre côté, ceux qui ont la malchance d’avoir acheté un produit contenant la contrefaçon se rendent de fait coupables de recel de contrefaçon s’ils essayent de réparer et de continuer à utiliser leur produit…





Sauf qu’en vertu du principe de présomption d’innocence, on n’est pas coupable jusqu’à preuve du contraire.



FTDI et Microsoft ne sont pas des autorités judiciaires. Elles ne sont pas en droit d’en juger, ni d’agir directement contre les présumés coupables. Ces firmes n’ont simplement pas le droit de faire justice elles-mêmes.



D’autre part, il n’est même pas certain que les produits reconnus comme falsifiés par le logiciel le soient réellement… comme le suggèrent les informations récentes.









charon.G a écrit :



Quand je disais qu’aucun test ne pouvais être fait pour détecter le problème, je parlais de tests logiciels. Si tu as le source code c’est autre chose….







C’est pas passé sous linux parce qu’ils n’ont pas eu le code du driver et ne l’ont donc pas mis dans le noyeau ou bien parce que le comportement à été détecté après lecture du code?



Parce que dans le premier cas, ça fait juste des composants en moins supportés par la plateforme…









js2082 a écrit :



Non.

Dans notre cas, l’article L615-1 3e alinéa du CPI permet d’exclure la responsabilité du “contrevenant” quand il n’en avait pas connaissance.



&nbsp;



&nbsp;





C’est la différence entre ce qui est écrit et les faits. En premier tu reçois l’amende pour recel, ensuite tu dois contester, prendre un avocat (sinon t’es mort) et tenter de justifier pourquoi tu n’as pas directement acheté une carte officielle du fabricant mais à la place un vulgaire made in China à dix fois moins cher trouvé sur un site non-officiel, si tu arrives à te défendre, ça fera jurisprudence .. je te souhaite bonne chance, sachant qu’en face tu auras une bardée d’avocats qui sont près à tout pour te décrédibiliser …









after_burner a écrit :



C’est pas passé sous linux parce qu’ils n’ont pas eu le code du driver et ne l’ont donc pas mis dans le noyeau ou bien parce que le comportement à été détecté après lecture du code?



Parce que dans le premier cas, ça fait juste des composants en moins supportés par la plateforme…





Le pilote est bien présent sous Linux, mais le patch a été refusé.









catseye a écrit :



C’est la différence entre ce qui est écrit et les faits. En premier tu reçois l’amende pour recel, ensuite tu dois contester, prendre un avocat (sinon t’es mort) et tenter de justifier pourquoi tu n’as pas directement acheté une carte officielle du fabricant mais à la place un vulgaire made in China à dix fois moins cher trouvé sur un site non-officiel, si tu arrives à te défendre, ça fera jurisprudence .. je te souhaite bonne chance, sachant qu’en face tu auras une bardée d’avocats qui sont près à tout pour te décrédibiliser …





C’est pas une carte, mais une puce sur celle-ci qui est potentiellement contrefaite.



&nbsp;









js2082 a écrit :



Sous Linux, il n’y a&nbsp; eu aucun test de fait.





Sous Linux les tests interviennent, en effet, un peu plus tard dans le processus (phase de RC)

&nbsp;Les faits ne prouvent rien, si ce n’est que sous Linux, on peut refuser un drivers sans même le contrôler.Greg Kroah-Hartman a bien relu le patch avant de le refuser et il a, en effet, toute autorité sur ce qui rentre ou pas dans ses branches (avec Linus en arbitre final)









GentooUser a écrit :



C’est pas une carte, mais une puce sur celle-ci qui est potentiellement contrefaite.



&nbsp;





Ça ne fait strictement aucune différence du point vu de la loi … la puce tu l’achèteras jamais seule de toute façon.



Tu disais : et tenter de justifier pourquoi tu n’as pas directement acheté une carte officielle du fabricant mais à la place un vulgaire made in China à dix fois moins cher trouvé sur un site non-officiel.Là il s’agit d’une carte officielle dont un des composants est contrefait, ça m’étonnerait pas que sur toutes nos cartes-méres ont deux ou trois composants de contrefaçon elles-aussi, comme tu dit en Chine ça cours les rues et détecter le vrai du faux peut-être difficile même pour une entreprise d’assemblage électronique.



Aussi beaucoup d’entreprises chinoises ont un double chapeau, gentil contructeur pour l’europe et méchant contrefacteur pour le marché local et parfois la barrière n’est pas nette entre les deux et tu te retrouve à inonder le marché européen avec un smartphone dont la batterie est une contrefaçon de Nokia (HTC je crois) ou avec une carte sd Playboy (ZTE), collector celle-là <img data-src=" />


En tout cas bonne réaction de la pars de Microsoft, surtout que :&nbsp; FTDI vient également de communiquer sur le sujet, en indiquant qu’il s’agissait effectivement d’une volonté d’affecter le matériel non-authentique. Cependant, le constructeur ajoute que des puces authentiques ont été touchées dans la manoeuvre.

&nbsp;Fail <img data-src=" />

&nbsp;

Bon on aurait préférés que le processus WHQL bloque le problème en amont.




FTDI vient également de communiquer&nbsp;sur le sujet, en indiquant qu’il s’agissait effectivement&nbsp;d’une volonté d’affecter le matériel non-authentique





Si je ne mets pas un terme a cet enfilage, ce sera qui le prochain a me la mettre ?



Terminé, FTDI boycotte total.

IL y a d’autres craputalistes qu’ils veulent jouer ?


Qui.



Note: Pourquoi un temps limite si court pour corriger ses fautes de frappe ?


Arrêtez avec la contrefaçon caymal, au début de l’informatique, il s’est passé la même chose lorsque l’on à demandé à une équipe de recréer le BIOS d’IBM, lorsque les copies de bios sont nées, c’est grâce à cela qu’aujourd’hui le monde PC c’est considérablement développé…



&nbsp;On était pas obligé d’acheter la marque hors de prix (IBM à l’époque) pour pouvoir avoir un PC chez soit, ce n’est pas pour cela qu’aujourd’hui IBM à cessé d’exister… Car IBM ne reste pas sur ces acquis et continue d’innover sur d’autres produits.



La copie permet à tous d’avoir accès au produit, et donc, sur le long terme, profite à son développement…


Pour IBM c’est le DoD qui lui a lié les mains dans le dos, il ne voulait pas dépendre d’un seul fournisseur et à obligé IBM à laisser se développer les “Compatibles PC”.


+1000

&nbsp;

&nbsp;J’ai aussi eu entre les mains, quelques temps auparavant des clones d’Apple IIe/II+ et ce n’est pas pour autant qu’Apple a cessé d’exister.








Darken34 a écrit :



Je sais pas si c’est déjà passé dans un des commentaires mais je le met au cas où:

https://lkml.org/lkml/2014/10/23/151

FTDI a essayé de patcher le kernel linux avec sa bidouille ^^









CaptainDangeax a écrit :



En même temps,  FTDI a tenté de patcher le noyau linux avec la même bidouille et ça n’a pas traversé l’étape de relecture du code. Donc, tu peux répéter ce que tu veux, les faits ont prouvé le contraire.





C’était une blague apparemment, Russ Dill travaille chez Texas Instrument et s’est déjà pris la tête avec FTDI (cf. ici)…



Anticipating such a move, Linux kernel contributor Russ Dill – a Texas Instruments employee – submitted a patch on Thursday that purported to have Linux perform “the FTDI genuine product verification steps as contained within the new 2.12.00 official release.” He did so without so much as a wink, but the kernel community assumed he had tongue planted firmly in cheek, having previously butted heads with FTDI over its intellectual property stance.





Bref, ce n’est pas FTDI la source du patch, c’est pour ça que Greg KH en rigole.



Je lis dans la mise à jour NCI : “Cependant, le constructeur&nbsp;ajoute que des puces authentiques ont été touchées dans la manoeuvre”. Je ne vois rien de tel dans le communiqué du constructeur.


Idem, la seule chose que je vois c’est “has caused concern amongst our genuine customer base” qui veux simplement dire que ça a causé des inquiétudes chez les clients légitimes, rien de plus.


les contrefaçons hardware c’est très courant que ce soit sur les transistors, les AOP, puces en tout genre… le bidouilleur lambda peut rarement faire la différence à l’achat, sauf peut être sur le prix parfoit… La solution adoptée ici est clairement violente…



sinon ici le bout de code fautif dans les drivers :



http://hackaday.com/2014/10/24/ftdi-screws-up-backs-down/








f-heure-7 a écrit :



C’était une blague apparemment, Russ Dill travaille chez Texas Instrument et s’est déjà pris la tête avec FTDI (cf. ici)…





Bref, ce n’est pas FTDI la source du patch, c’est pour ça que Greg KH en rigole.





ça ne change rien au fait que le patch N’A PAS traversé le processus de vérification du noyau linux.



On ne sait pas ce qui se serait passé avec un vrai patch potentiellement un peu difficile à suivre. Il y a déjà eu le cas d’un pilote qui brickait une carte réseau Intel me semble-t-il. C’était involontaire, mais ça a passé le processus de vérification.



Mais je t’accorde que c’est peu probable que la modification reste si jamais elle arrive à passer.


Je suis la discussion sur le forum de l’EEVBLOG depuis que cette merde de driver est sortie. Pour ceux qui ne comprennent pas les enjeux et pourquoi FTDI est en tort, je vous invite à regarder cette fantastique vidéo doigt d’honneur de notre cher David Jones, simplement collector.