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

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.

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.

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

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.

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.

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

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.

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.

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?

Ε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?

Harald K. schrieb:

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.

Was mich zu der Frage bringt, wie lese ich die Product Description in meiner Software ?

Gibt es da schon ein Beispiel - vorzugsweise in C# ?

Wenn ich einen ManagementObjectSearcher("SELECT * FROM WIN32_SerialPort") anlege und die "Caption" abfrage, bekomme ich den String aus der .inf Datei.