INF-Datei o.ä. für Hameg/R&S HM8142 für Windows 11

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

Hallo allerseits,

auf einem Netzteil des Typs Hameg bzw. Rohde&Schwarz HM8142 befindet 
sich eine ältere Version eines USB/UART-Wandlers von FTDI, für den es 
auf Grund der eigenen VID/PID keine Unterstützung für Windows 11 gibt.

Hat hier schon jemand eine passende INF-Datei gebastelt, mit der sich 
das HM8142 korrekt einbinden lässt? Irgendwann habe ich so etwas 
ähnliches schon einmal selbst durchgeführt, aber das ist schon ewig 
her...

[Harald K. (kirnbichler)]

Andreas S. schrieb:
> für den es
> auf Grund der eigenen VID/PID keine Unterstützung für Windows 11 gibt.

Du könntest mit "ftprog" von FTDI den Chip auf die Standardwerte 
umprogrammieren. Das ist vielleicht die nachhaltigere Lösung.

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

Harald K. schrieb:
> Andreas S. schrieb:
>> für den es
>> auf Grund der eigenen VID/PID keine Unterstützung für Windows 11 gibt.
>
> Du könntest mit "ftprog" von FTDI den Chip auf die Standardwerte
> umprogrammieren. Das ist vielleicht die nachhaltigere Lösung.

Hmm, interessante Idee, aber dann ist das Teil nicht mehr so einfach von 
den Unmengen anderer Schniepel und Geräte zu unterscheiden, die 
ebenfalls einen FT-irgendwas einsetzen. Ich setze das Netzteil auch für 
etliche Prüfprogramme (teilweise unter Windows und teilweise unter 
Linux) ein und müsste diese dann für die neue Kennung anpassen.

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

Oh, mir ist ein grober Fehler unterlaufen: es geht um das HM8143, nicht 
HM8142.

[Harald K. (kirnbichler)]

Andreas S. schrieb:
> aber dann ist das Teil nicht mehr so einfach von
> den Unmengen anderer Schniepel und Geräte zu unterscheiden

Doch, Du kannst die "Product Description" unabhängig von VID/PID 
anpassen.

Da kann im Klartext dann "Hameg HM8142" drinstehen.

[Hmmm (hmmm)]

Andreas S. schrieb:
> Hat hier schon jemand eine passende INF-Datei gebastelt

FTDI hat einen Support-Artikel dazu:

https://www.ftdichip.com/Support/Knowledgebase/index.html?changingtheftd2xx_inffile.htm

Neuere Windows-Versionen erwarten allerdings, dass auch die INF-Datei 
signiert ist, was die Sache kompliziert macht.

Harald K. schrieb:
> Doch, Du kannst die "Product Description" unabhängig von VID/PID
> anpassen.

Je nachdem, wo man nachsieht, wird allerdings nur der String aus der INI 
angezeigt.

Wenn das kein Hindernis ist, würde ich es auch so machen.

[Niklas G. (erlkoenig)]

Harald K. schrieb:
> Doch, Du kannst die "Product Description" unabhängig von VID/PID
> anpassen.

Was wenn die Prüfprogramme explizit die spezifische VID+PID erwarten?

Im Gerätemanager oder eventuell über dpinst.exe kann man manuell einen 
spezifischen Treiber einen USB-Gerät zuweisen. Leider ziemlich nervig 
und Windows vergisst die Zuordnung regelmäßig

Aber: Gibt's auch keine INF-Datei für ältere Windows Versionen? 
Referenziert die eine alte Version vom FTDI Treiber? Vielleicht kann man 
die anpassen, dann ist leider die Signatur futsch

[Harald K. (kirnbichler)]

Niklas G. schrieb:
> Was wenn die Prüfprogramme explizit die spezifische VID+PID erwarten?

Dann kommunizieren die nicht einfach mit einer seriellen Schnittstelle. 
Und dann muss man halt entweder die Signaturprüfung von Windows 
abschalten, oder eine alte Windows-Version verwenden.

Die angebliche "Sicherheit", die das Signieren von Treibern mit sich 
bringt, ist eh' nur vorgegaukelt, wie praktisch alles, was Microsoft 
veranstaltet, was "Sicherheit" bringen soll. Das sind alles nur neue 
Geschmacksmuster von Agar-Agar für Schadsoftware.

[Niklas G. (erlkoenig)]

Harald K. schrieb:
> Dann kommunizieren die nicht einfach mit einer seriellen Schnittstelle.

Doch schon möglich, man kann tatsächlich unter Windows die VID+PID von 
USB-Serial-Adaptern per SetupAPI abfragen und die dann ganz klassisch 
als COMx öffnen. Unter Linux kann man das indirekt über udev Rules und 
spezifische Symlinks auf die Gerätedatei bewerkstelligen, das ließe sich 
immerhin simpel anpassen.

Harald K. schrieb:
> Und dann muss man halt entweder die Signaturprüfung von Windows
> abschalten, oder eine alte Windows-Version verwenden.

Beides nicht wirklich praktikabel...

Harald K. schrieb:
> Die angebliche "Sicherheit", die das Signieren von Treibern mit sich
> bringt, ist eh' nur vorgegaukelt

Früher waren mies implementierte Treiber eine der Hauptursachen von 
Bluescreens, durch die rabiate Signaturprüfung wurde das schon besser.

Man könnte argumentieren dass Windows das bloße Laden von bereits 
signierten Treibern nicht auch so einschränken sollte; wenn man aber 
einfach so z.B. WinUSB für jedes beliebige Gerät laden könnte, könnte 
man auch eine Menge Schaden anrichten.

[Εrnst B. (ernst)]

Niklas G. schrieb:
> Man könnte argumentieren dass Windows das bloße Laden von bereits
> signierten Treibern nicht auch so einschränken sollte;

Beliebtes Vorgehen bei Malware: Alten Treiber für Irgendwas mitbringen, 
der über einen Bug eine Rechteausweitung erlaubt. Windows installiert 
den anstandslos, ist ja signiert. Dass es eine neue Version vom Treiber 
mit Bugfix gibt, interessiert nicht.
Dass das Zertifikat vom Signierer abgelaufen ist, auch nicht, solange es 
zum Zeitpunkt der Signatur gültig war.

Und zack, ist das rootkit installiert.

Nennt sich "BYOVD" (Bring your own vulnerable driver).
Ließe sich nur durch lange Revocation-Lists verhindern. Aber: Wer soll 
die Pflegen, vor allem wenn die Firma, die den Treiber ursprünglich hat 
signieren lassen, nicht mehr existiert?
Und wie verhindern, dass das als Kill-Switch für geplante 
Hardware-Obsoleszenz genutzt wird?

[Niklas G. (erlkoenig)]

Εrnst B. schrieb:
> Aber: Wer soll die Pflegen, vor allem wenn die Firma, die den Treiber
> ursprünglich hat signieren lassen, nicht mehr existiert?

Microsoft - wenn bekannt wird dass der Treiber so exploited wird, setzt 
MS ihn auf die Liste.

Εrnst B. schrieb:
> Und wie verhindern, dass das als Kill-Switch für geplante
> Hardware-Obsoleszenz genutzt wird?

Indem MS Treiber nur revoked wenn eine Schwachstelle bekannt wird.

Der Treiber kann den Kill Switch auch einfach im Code enthalten, das 
lässt sich sowieso nicht verhindern...

Εrnst B. schrieb:
> . Windows installiert den anstandslos, ist ja signiert.

Wird er denn auch gestartet wenn die zugehörige Hardware nicht 
existiert?