Bastelprojekte am USB eines Android-Handys

[Frank Buss]

On 12/19/2018 11:27 AM, Wolfgang Allinger wrote:

Bei dem FTDI FT232RL gibts Hinweise, dass deren Win Treiber die Nachbau
chips bricken

Tun sie nicht, sie setzen nur die USB Vendor-ID auf 0000.

Wo? Auf dem chip oder im Treiber?

Im EEPROM des Adapters, siehe hier fĂźr Details:

https://groups.google.com/d/msg/de.sci.electronics/jTAlW-CvZRM/0ljtkHzqCgAJ

Es gibt zwar Tools, um das dann unter Linux wieder zu reparieren, und
unter Linux mittlerweile ein Patch, um die dann immer noch verwenden zu
kĂśnnen, aber faktisch ist das fĂźr Windows User gebrickt. Siehe hier fĂźr
die Details:

https://groups.google.com/d/msg/de.sci.electronics/jTAlW-CvZRM/0ljtkHzqCgAJ

Wenn du das
dem OS und Treiber bekanntmachen kannst funktioniert der Chip wie
gehabt, bzw. so gut wie ein gefälschter Chip eben funktioniert.

Wo/wie geht das bei W7

Man mĂźsste eine eigene INF-Datei schreiben und dort die PID 0 eintragen,
sofern Windows das zulässt. Ist aber fraglich, ob das durch das nächste
Windows Update nicht wieder Ăźberschrieben wĂźrde.

CP1202
Ich hab mit Silabs bisher immer gute Erfahrungen gemacht. Ist da dann
CP1202 die bessere Wahl?

Ist das nicht nur ein speziell programmierter Microcontroller? Die haben
manchmal komische Probleme. Das Äquivalent von Microchip baut zwischen
jedes gesendete Byte eine feste Pause ein. Egal bei niedrigen Baudraten,
aber wenns schnell gehen soll bremsen so ein paar Âľs schon deutlich.

BTW: Meinst du nicht eher den CP2102?

Ich habe gute Erfahrungen mit CH340G gemacht. Gibt es viele Angebote,
z.B. hier, direkt mit RS232 TTL:

http://cgi.ebay.de/282124138631

Aber am besten einfach ein paar unterschiedliche Adapter bestellen.
Kosten ja nicht die Welt, und einer wird dann schon laufen

--
Frank Buss, http://www.frank-buss.de
electronics and more: http://www.youtube.com/user/frankbuss

 

[Gerrit Heitsch]

On 12/18/18 11:45 PM, Hanno Foest wrote:

Am 18.12.18 um 20:21 schrieb Gerrit Heitsch:

Ja. Ansonsten dĂźrfen sie gerne den Schadenersatz bezahlen, wenn
irgendwo in der Industrie eine Anlage wegen ihrer Kapriolen stillsteht.

Nein, FTDI hat keinerlei Verpflichtung die nicht von ihnen
hergestellten Chips zu unterstĂźtzen.

Sicherlich wäre es vÜllig OK, wenn die FTDI Treiber mit den Fakes den
Betrieb einstellen und das entsprechend irgendwo loggen. Fremdes Gerät
kaputtzuschreiben kann man aber nicht tolerieren. - Was wĂźrdest du denn
davon halten, wenn ein PL2303 Treiber einen (originalen) FTDI Chip
findet und den dann mit der Argumentation "den muß ich ja nicht
unterstĂźtzen" kaputtschreibt?

Mooooment... Der FTDI versucht nicht den PL2303-Treiber zu verwenden um
sich so die Entwicklung eines eigenen Treibers zu ersparen. Ausserdem
hat der FTDI eine andere VID als der PL2303, der Treiber wird ihn also
gar nicht finden.

Das Problem mit den Fakes war, daß die sich als FT232 ausgeben und
kostenlos deren Treiber benutzen wollen. Hätten sie eine eigene VID
gekauft, einen eigenen Treiber programiert und ausgeliefert hätte keiner
gemeckert.

Gerrit

 

[Gerrit Heitsch]

On 12/19/18 6:14 PM, Hanno Foest wrote:

On 19.12.18 17:57, Gerrit Heitsch wrote:

Nein, ist es nicht. Der Fake gibt sich als FTDI-Hardware aus um zu
erreichen, daß ihn der FTDI-Treiber anspricht.

Und? Der FTDI Treiber muß da ja nicht mitspielen. Er kann die Hardware
ja offenbar erkennen.

Und dann wird das Geschrei groß weil er die Arbeit einstellt und eine
wichtige Anlage steht.

Der echte FTDI hingegen gibt sich hingegen nicht als PL2303 aus und
will auch nicht vom PL2303-Treiber angesprochen werden.

Das mag sein. Aber wenn der PL2303-Treiber trotzdem Bock drauf hat,
Konkurrenzhardware plattzumachen? Ist prinzipiell die gleiche Situation.

Aber ganz und gar nicht, der Unterschied ist, daß sich der Fake-Chip die
Unterstßtzung des FTDI-Treibers erschleichen will während sich ein
bĂśswilliger PL-Treiber an einem Chip mit einer fĂźr ihn gar nicht
relevanten VID vergreifen mĂźsste.


Gerrit

 

[Gerrit Heitsch]

On 12/19/18 6:26 PM, Peter Heitzer wrote:

Gerrit Heitsch <gerrit@laosinh.s.bawue.de> wrote:
On 12/19/18 9:11 AM, Matthias Weingart wrote:
Frank Buss <fb@frank-buss.de>:

On 12/18/2018 10:09 PM, Axel Berger wrote:
Frank Buss wrote:
daß die Fake Chips (faktisch) gebrickt wurden, war
natürlich komplett unbeabsichtigt. Und morgen kommt der
Weihnachtsmann

Die richtige LÜsung von FTDI wäre gewesen, das der Treiber einfach seine
Arbeit einstellt. Alles andere (Fake-Daten senden, bricken) ist Selbstjustiz.

In diesem Fall hätte man gelesen 'Das kÜnnen die doch nicht machen, was
wenn durch ein Update auf den neuen Treiber eine teure Maschine ausfällt
oder gar ein wichtiges medizinisches Gerät!'

So gesehen wäre 'Arbeit einstellen' auch Selbstjustiz.
NACK. Die Aufgabe des Treibers ist die Kommunikation mit einem Chip mit
bestimmten Eigenschaften. Stellt der Treiber fest, daß der Chip diese Eigenschaften
nicht besitzt, darf er IMO die Arbeit verweigern.

Ich habe nur geschrieben was dann zu lesen wäre.

Gerrit

 

[Peter Heitzer]

Gerrit Heitsch <gerrit@laosinh.s.bawue.de> wrote:

On 12/19/18 9:11 AM, Matthias Weingart wrote:
Frank Buss <fb@frank-buss.de>:

On 12/18/2018 10:09 PM, Axel Berger wrote:
Frank Buss wrote:
daß die Fake Chips (faktisch) gebrickt wurden, war
natürlich komplett unbeabsichtigt. Und morgen kommt der
Weihnachtsmann

Die richtige LÜsung von FTDI wäre gewesen, das der Treiber einfach seine
Arbeit einstellt. Alles andere (Fake-Daten senden, bricken) ist Selbstjustiz.

In diesem Fall hätte man gelesen 'Das kÜnnen die doch nicht machen, was
wenn durch ein Update auf den neuen Treiber eine teure Maschine ausfällt
oder gar ein wichtiges medizinisches Gerät!'

So gesehen wäre 'Arbeit einstellen' auch Selbstjustiz.

NACK. Die Aufgabe des Treibers ist die Kommunikation mit einem Chip mit
bestimmten Eigenschaften. Stellt der Treiber fest, daß der Chip diese Eigenschaften
nicht besitzt, darf er IMO die Arbeit verweigern.
Eine Bank muss auch kein Falschgeld annehmen.

--
Dipl.-Inform(FH) Peter Heitzer, peter.heitzer@rz.uni-regensburg.de

 

[Hanno Foest]

On 19.12.18 17:59, Gerrit Heitsch wrote:

In diesem Fall hätte man gelesen 'Das kÜnnen die doch nicht machen,
was wenn durch ein Update auf den neuen Treiber eine teure Maschine
ausfällt oder gar ein wichtiges medizinisches Gerät!'

Ach Unsinn. Zu alte, neue, falsche, kaputte oder aus anderen GrĂźnden
nichtfunktionierende Treiber sind unter Windows ein Standardproblem
mit der StandardlĂśsung neuere oder richtigere Treiber runterladen.

Auch neuere FTDI-Treiber wĂźrden den Fake nicht mehr ansprechen.

Und? Es gibt aber Treiber, die es kĂśnnen. Siehe Linux. Wo man die
herbekommt ist ein anderes Problem, aber ein typischer Job des
Windows-Admins.

Hat er nicht, er hat nur dafür gesorgt, daß der Fake sich nicht mehr als
FTDI-Chip, der er ja nie war, meldet.

Und sich auch als kein anderer Chip mehr meldet (PID 0000). Das ist fĂźr
alle praktischen Belange kaputt, bricked, mithin Sachbeschädigung und
justiziabel. Daß man mit speziellem know-how unbricken kann steht dem
nicht entgegen.

Hanno

 

[Hanno Foest]

On 19.12.18 17:57, Gerrit Heitsch wrote:

Nein, ist es nicht. Der Fake gibt sich als FTDI-Hardware aus um zu
erreichen, daß ihn der FTDI-Treiber anspricht.

Und? Der FTDI Treiber muß da ja nicht mitspielen. Er kann die Hardware
ja offenbar erkennen.

Der echte FTDI hingegen gibt sich hingegen nicht als PL2303 aus und will
auch nicht vom PL2303-Treiber angesprochen werden.

Das mag sein. Aber wenn der PL2303-Treiber trotzdem Bock drauf hat,
Konkurrenzhardware plattzumachen? Ist prinzipiell die gleiche Situation.

Irgendwie vermuten, was manche Hardware gerne hätte oder nicht, kann ja
nicht die Grundlage sein, wenn es darum geht, ZerstĂśrungen anzurichten.

Hanno

 

[Gerrit Heitsch]

On 12/19/18 5:53 PM, Hanno Foest wrote:

On 19.12.18 17:45, Gerrit Heitsch wrote:

Die richtige LÜsung von FTDI wäre gewesen, das der Treiber einfach seine
Arbeit einstellt. Alles andere (Fake-Daten senden, bricken) ist
Selbstjustiz.

In diesem Fall hätte man gelesen 'Das kÜnnen die doch nicht machen,
was wenn durch ein Update auf den neuen Treiber eine teure Maschine
ausfällt oder gar ein wichtiges medizinisches Gerät!'

Ach Unsinn. Zu alte, neue, falsche, kaputte oder aus anderen GrĂźnden
nichtfunktionierende Treiber sind unter Windows ein Standardproblem mit
der StandardlĂśsung neuere oder richtigere Treiber runterladen.

Auch neuere FTDI-Treiber wĂźrden den Fake nicht mehr ansprechen.

Nur

greift die halt nicht, weil der unpassende FTDI-Treiber die Hardware
dann schon dauerhaft gebricht hat. *DAS* ist das Problem.

Hat er nicht, er hat nur dafür gesorgt, daß der Fake sich nicht mehr als
FTDI-Chip, der er ja nie war, meldet.

Gerrit

 

[Gerrit Heitsch]

On 12/19/18 5:50 PM, Hanno Foest wrote:

On 19.12.18 17:41, Gerrit Heitsch wrote:

Nein, FTDI hat keinerlei Verpflichtung die nicht von ihnen
hergestellten Chips zu unterstĂźtzen.

Sicherlich wäre es vÜllig OK, wenn die FTDI Treiber mit den Fakes den
Betrieb einstellen und das entsprechend irgendwo loggen. Fremdes
Gerät kaputtzuschreiben kann man aber nicht tolerieren. - Was wßrdest
du denn davon halten, wenn ein PL2303 Treiber einen (originalen) FTDI
Chip findet und den dann mit der Argumentation "den muß ich ja nicht
unterstĂźtzen" kaputtschreibt?

Mooooment... Der FTDI versucht nicht den PL2303-Treiber zu verwenden
um sich so die Entwicklung eines eigenen Treibers zu ersparen.
Ausserdem hat der FTDI eine andere VID als der PL2303, der Treiber
wird ihn also gar nicht finden.

Das tangiert nicht deine Argumentation "ist nicht meine Hardware, also
kann ich machen was ich will, inklusive kaputt". Wenn ein FTDI-Treiber
nicht-FTDI-Hardware kaputtmachen kann, warum dann nicht auch nicht-FTDI
Treiber FTDI Hardware? Ist das gleiche in grĂźn.

Nein, ist es nicht. Der Fake gibt sich als FTDI-Hardware aus um zu
erreichen, daß ihn der FTDI-Treiber anspricht.

Der echte FTDI hingegen gibt sich hingegen nicht als PL2303 aus und will
auch nicht vom PL2303-Treiber angesprochen werden.

Gerrit

 

[Hanno Foest]

On 19.12.18 17:45, Gerrit Heitsch wrote:

Die richtige LÜsung von FTDI wäre gewesen, das der Treiber einfach seine
Arbeit einstellt. Alles andere (Fake-Daten senden, bricken) ist
Selbstjustiz.

In diesem Fall hätte man gelesen 'Das kÜnnen die doch nicht machen, was
wenn durch ein Update auf den neuen Treiber eine teure Maschine ausfällt
oder gar ein wichtiges medizinisches Gerät!'

Ach Unsinn. Zu alte, neue, falsche, kaputte oder aus anderen GrĂźnden
nichtfunktionierende Treiber sind unter Windows ein Standardproblem mit
der StandardlĂśsung neuere oder richtigere Treiber runterladen. Nur
greift die halt nicht, weil der unpassende FTDI-Treiber die Hardware
dann schon dauerhaft gebricht hat. *DAS* ist das Problem.

Hanno

 

[Hanno Foest]

On 19.12.18 17:41, Gerrit Heitsch wrote:

Nein, FTDI hat keinerlei Verpflichtung die nicht von ihnen
hergestellten Chips zu unterstĂźtzen.

Sicherlich wäre es vÜllig OK, wenn die FTDI Treiber mit den Fakes den
Betrieb einstellen und das entsprechend irgendwo loggen. Fremdes Gerät
kaputtzuschreiben kann man aber nicht tolerieren. - Was wĂźrdest du
denn davon halten, wenn ein PL2303 Treiber einen (originalen) FTDI
Chip findet und den dann mit der Argumentation "den muß ich ja nicht
unterstĂźtzen" kaputtschreibt?

Mooooment... Der FTDI versucht nicht den PL2303-Treiber zu verwenden um
sich so die Entwicklung eines eigenen Treibers zu ersparen. Ausserdem
hat der FTDI eine andere VID als der PL2303, der Treiber wird ihn also
gar nicht finden.

Das tangiert nicht deine Argumentation "ist nicht meine Hardware, also
kann ich machen was ich will, inklusive kaputt". Wenn ein FTDI-Treiber
nicht-FTDI-Hardware kaputtmachen kann, warum dann nicht auch nicht-FTDI
Treiber FTDI Hardware? Ist das gleiche in grĂźn.

Hanno

 

[Gerrit Heitsch]

On 12/19/18 9:11 AM, Matthias Weingart wrote:

Frank Buss <fb@frank-buss.de>:

On 12/18/2018 10:09 PM, Axel Berger wrote:
Frank Buss wrote:
daß die Fake Chips (faktisch) gebrickt wurden, war
natürlich komplett unbeabsichtigt. Und morgen kommt der
Weihnachtsmann

Die richtige LÜsung von FTDI wäre gewesen, das der Treiber einfach seine
Arbeit einstellt. Alles andere (Fake-Daten senden, bricken) ist Selbstjustiz.

In diesem Fall hätte man gelesen 'Das kÜnnen die doch nicht machen, was
wenn durch ein Update auf den neuen Treiber eine teure Maschine ausfällt
oder gar ein wichtiges medizinisches Gerät!'

So gesehen wäre 'Arbeit einstellen' auch Selbstjustiz.

Gerrit

 

[Gerrit Heitsch]

On 12/19/18 6:20 PM, Hanno Foest wrote:

On 19.12.18 17:59, Gerrit Heitsch wrote:

In diesem Fall hätte man gelesen 'Das kÜnnen die doch nicht machen,
was wenn durch ein Update auf den neuen Treiber eine teure Maschine
ausfällt oder gar ein wichtiges medizinisches Gerät!'

Ach Unsinn. Zu alte, neue, falsche, kaputte oder aus anderen GrĂźnden
nichtfunktionierende Treiber sind unter Windows ein Standardproblem
mit der StandardlĂśsung neuere oder richtigere Treiber runterladen.

Auch neuere FTDI-Treiber wĂźrden den Fake nicht mehr ansprechen.

Und? Es gibt aber Treiber, die es kĂśnnen. Siehe Linux. Wo man die
herbekommt ist ein anderes Problem, aber ein typischer Job des
Windows-Admins.

Geht nur solange wie du solche Treiber fĂźr das verwendete OS noch
bekommst. Was aber wenn du ein OS-Upgrade machst, der alte Treiber nicht
dort mehr läuft und der neue die Arbeit verweigert?

Hat er nicht, er hat nur dafür gesorgt, daß der Fake sich nicht mehr
als FTDI-Chip, der er ja nie war, meldet
Und sich auch als kein anderer Chip mehr meldet (PID 0000). Das ist fĂźr
alle praktischen Belange kaputt, bricked,

Nein, denn der Linux-Treiber konnte mit dem so behandelten Chip ja reden.

Gerrit

 

[Hanno Foest]

On 19.12.18 18:35, Gerrit Heitsch wrote:

Und? Der FTDI Treiber muß da ja nicht mitspielen. Er kann die Hardware
ja offenbar erkennen.

Und dann wird das Geschrei groß weil er die Arbeit einstellt und eine
wichtige Anlage steht.

NĂś. Wer Windows einsetzt kennt dieses Risiko von Updates und
Treiberinkompatibilität.

Der echte FTDI hingegen gibt sich hingegen nicht als PL2303 aus und
will auch nicht vom PL2303-Treiber angesprochen werden.

Das mag sein. Aber wenn der PL2303-Treiber trotzdem Bock drauf hat,
Konkurrenzhardware plattzumachen? Ist prinzipiell die gleiche Situation.

Aber ganz und gar nicht, der Unterschied ist, daß sich der Fake-Chip die
UnterstĂźtzung des FTDI-Treibers erschleichen will

Und? Kann man ja mal versuchen. Wenn FTDI das nicht paßt, gibt es
Gerichte - aber ich glaub nicht, daß Kompatibilität justiziabel ist. Das
falsche Firmenlogo auf dem Gehäuse des Chips schon eher. Aber das sieht
der Treiber ja nicht. Selbstjustiz ist jedenfalls nicht so toll.

während sich ein
bĂśswilliger PL-Treiber an einem Chip mit einer fĂźr ihn gar nicht
relevanten VID vergreifen mĂźsste.

"Wenn FTDI nicht kaputtgeschrieben werden mĂśchte, kĂśnnten sie diese
Funktion ja weglassen". Ansonsten machst du halt was geht: Ist genau das
gleiche, Selbstjustiz halt.

Hanno

 

[Hanno Foest]

On 19.12.18 18:38, Gerrit Heitsch wrote:

Auch neuere FTDI-Treiber wĂźrden den Fake nicht mehr ansprechen.

Und? Es gibt aber Treiber, die es kĂśnnen. Siehe Linux. Wo man die
herbekommt ist ein anderes Problem, aber ein typischer Job des
Windows-Admins.

Geht nur solange wie du solche Treiber fĂźr das verwendete OS noch
bekommst. Was aber wenn du ein OS-Upgrade machst, der alte Treiber nicht
dort mehr läuft und der neue die Arbeit verweigert?

Backup einspielen, dafĂźr sind die Dinger da, das hat noch den alten
Treiber. Aber natĂźrlich nicht, wenn FTDIs Sabotage-Treiber bereits
permanent gebrickt hat.

Hat er nicht, er hat nur dafür gesorgt, daß der Fake sich nicht mehr
als FTDI-Chip, der er ja nie war, meldet
Und sich auch als kein anderer Chip mehr meldet (PID 0000). Das ist
fĂźr alle praktischen Belange kaputt, bricked,

Nein, denn der Linux-Treiber konnte mit dem so behandelten Chip ja reden.

Erst, nachdem der Treiber so gepatched worden ist. Wie ich bereits
sagte: "Daß man mit speziellem know-how [also so einem patch] unbricken
kann steht dem nicht entgegen."

Bei akuten Windows-Treiberproblemen mit einer Industrieanlage auf Linux
wechseln wĂźrde allerdings nicht mal ich empfehlen.

Hanno

 

[Gerrit Heitsch]

On 12/19/18 6:59 PM, Hanno Foest wrote:

On 19.12.18 18:35, Gerrit Heitsch wrote:

Und? Der FTDI Treiber muß da ja nicht mitspielen. Er kann die
Hardware ja offenbar erkennen.

Und dann wird das Geschrei groß weil er die Arbeit einstellt und eine
wichtige Anlage steht.

NĂś. Wer Windows einsetzt kennt dieses Risiko von Updates und
Treiberinkompatibilität.

Das ist inzwischen allerdings deutlich besser geworden.

Der echte FTDI hingegen gibt sich hingegen nicht als PL2303 aus und
will auch nicht vom PL2303-Treiber angesprochen werden.

Das mag sein. Aber wenn der PL2303-Treiber trotzdem Bock drauf hat,
Konkurrenzhardware plattzumachen? Ist prinzipiell die gleiche Situation.

Aber ganz und gar nicht, der Unterschied ist, daß sich der Fake-Chip
die UnterstĂźtzung des FTDI-Treibers erschleichen will

Und? Kann man ja mal versuchen. Wenn FTDI das nicht paßt, gibt es
Gerichte - aber ich glaub nicht, daß Kompatibilität justiziabel ist. Das
falsche Firmenlogo auf dem Gehäuse des Chips schon eher. Aber das sieht
der Treiber ja nicht. Selbstjustiz ist jedenfalls nicht so toll.

Die verwendete USB-Vendor-ID gibts auch nicht umsonst, dafĂźr muss man
bezahlen. Und damit du jemanden vor Gericht ziehen kannst musst du
erstmal rausfinden wer den Chip eigentlich hergestellt hat.

Ich hab damals gesucht und eine obskure chinesische Webseite gefunden
deren Angebote sehr verdächtig aussahen. Leider finde ich die nicht
mehr, wahrscheinlich offline.

während sich ein bÜswilliger PL-Treiber an einem Chip mit einer fßr
ihn gar nicht relevanten VID vergreifen mĂźsste.

"Wenn FTDI nicht kaputtgeschrieben werden mĂśchte, kĂśnnten sie diese
Funktion ja weglassen". Ansonsten machst du halt was geht: Ist genau das
gleiche, Selbstjustiz halt.

Ist immer noch nicht dasselbe, auch nicht im Prinzip. Der eine benutzt
eine geklaute USB-Vendor-ID damit sich ein bestimmter Treiber um ihn
kĂźmmert an dem er keine Rechte hat. Der andere hat eine korrekte
USB-Vendor-ID und geht davon aus, daß sich nur der zu dieser ID passende
und genau fĂźr diesen Chip geschriebene Treiber um ihn anspricht.

Oder anders... Der FTDI-Treiber spricht nur mit ICs die sich mit einer
FTDI-VID/PID melden. Das ist das erwartete Verhalten. Der hypothetische
bĂśse PL-Treiber hingegen wĂźrde nicht nur die zu ihm passende
VID/PID-Kombination ansprechen sondern auch eine die einem Konkurrenten
gehĂśrt.

Aber ich sehe schon, der Konsenz hier ist, daß es am schönsten wäre,
wenn der Fake einfach so behandelt wĂźrde wie das Original, damit der,
der sich eine Fälschung hat andrehen lassen das mÜglichst nicht merkt
und keine Unanehmlichkeiten erleiden muss. Das solche Nachbauten u.U.
andere Probleme, besonders bei edge Cases, machen wird dabei
ausgeblendet. Leider wird man so das Problem mit gefälschten Chips
garantiert nicht los sondern ermutigt die Fälscher geradezu.

Gerrit

 

[Hanno Foest]

Am 19.12.18 um 19:19 schrieb Gerrit Heitsch:

Aber ich sehe schon, der Konsenz hier ist, daß es am schönsten wäre,
wenn der Fake einfach so behandelt wĂźrde wie das Original, damit der,
der sich eine Fälschung hat andrehen lassen das mÜglichst nicht merkt
und keine Unanehmlichkeiten erleiden muss.

Ich sagte schon, daß eine entsprechende Meldung loggen oder auch den
Betrieb einstellen kein Problem wäre.

Das solche Nachbauten u.U.
andere Probleme, besonders bei edge Cases, machen wird dabei
ausgeblendet. Leider wird man so das Problem mit gefälschten Chips
garantiert nicht los sondern ermutigt die Fälscher geradezu.

Wo genau ist der Unterschied zwischen einem kompatiblem Nachbau, second
source und einer Fälschung? Insbesondere auf elektrischer Ebene.

MĂśchtest du unbedingt Verdongelung der Treibersoftware?

Hanno

 

[Gerrit Heitsch]

On 12/19/18 8:03 PM, Hanno Foest wrote:

Am 19.12.18 um 19:19 schrieb Gerrit Heitsch:

Aber ich sehe schon, der Konsenz hier ist, daß es am schönsten wäre,
wenn der Fake einfach so behandelt wĂźrde wie das Original, damit der,
der sich eine Fälschung hat andrehen lassen das mÜglichst nicht merkt
und keine Unanehmlichkeiten erleiden muss.

Ich sagte schon, daß eine entsprechende Meldung loggen oder auch den
Betrieb einstellen kein Problem wäre.

Du ja, in diversen Foren waren andere der Meinung das Einstellen des
Betriebes wäre schon zuviel.

Das solche Nachbauten u.U. andere Probleme, besonders bei edge Cases,
machen wird dabei ausgeblendet. Leider wird man so das Problem mit
gefälschten Chips garantiert nicht los sondern ermutigt die Fälscher
geradezu.

Wo genau ist der Unterschied zwischen einem kompatiblem Nachbau, second
source und einer Fälschung? Insbesondere auf elektrischer Ebene.

Bei einer Fälschung garantiert dir keiner die 100% Kompatibilität (du
findest oft nicht einmal raus wer das Teil hergestellt hat weil er eben
die Aufschrift des Originals benutzt), bei einem lizensiertem Nachbau
und Second Source schon. Auf der elektrischen Ebene kommen noch
Unterschiede im Prozess dazu und teilweise auch komplett andere
Schaltungen, siehe die Die-Shots auf Zeptobars:

https://zeptobars.com/en/read/FTDI-FT232RL-real-vs-fake-supereal

Bringt die Fälschung dieselben Treiberleistungen auf den I/O-Leitungen?
Hat er dieselben Schaltschwellen?

Siehe auch die diversen Fälschungen bei Transistoren.

Gerrit

 

[Hanno Foest]

Am 19.12.18 um 21:24 schrieb Axel Berger:

Wenn ein FTDI-Treiber
nicht-FTDI-Hardware kaputtmachen kann, warum dann nicht auch nicht-FTDI
Treiber FTDI Hardware? Ist das gleiche in grßn.

Nochmal, weil mir keiner widersprochen hat und ich es also vielleicht
nicht mißverstanden habe: Sie machen nichts kaputt sondern sie
überschreiben die offensichtlich falsche Meldung mit der sinngemäßen
Bedeutung "ich bin ein originaler FTDI".

Hä? Quatsch. Liest den Thread, zum Beispiel
<pvbdhv$h4t$1@news.bawue.net>. Oder google.

https://www.techdirt.com/articles/20141023/15502828928/microsoft-windows-update-completely-kill-devices-that-might-possibly-be-used-piracy.shtml

Die USB Vendor-ID wird auf 0000 gesetzt, wodurch das Teil fĂźr jeden
Treiber unbrauchbar wird, es sei denn, du hast einen, der spezifisch
gepatcht ist, um diese Form des Brickens zu adressieren. Keinen
Schimmer, wo du das mit "ich bin ein originaler FTDI" herhaben willst.

Hanno

 

[Axel Berger]

Hanno Foest wrote:

Und? Der FTDI Treiber muß da ja nicht mitspielen.
Er kann die Hardware ja offenbar erkennen.

Er ja. Aber alle möglichen Tools zur Hardwareanzeige vermutlich nicht.
Er behebt einen offensichtlichen Fehler und hilft damit entscheidend bei
der Problemlösung.

--
/Ż\ No | Dipl.-Ing. F. Axel Berger Tel: +49/ 221/ 7771 8067
\ / HTML | Roald-Amundsen-Straße 2a Fax: +49/ 221/ 7771 8069
 X in | D-50829 Köln-Ossendorf http://berger-odenthal.de
/ \ Mail | -- No unannounced, large, binary attachments, please! --