|
Anzeige
|
INF-Datei o.ä. für Hameg/R&S HM8142 für Windows 11Hallo 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...
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. :
Bearbeitet durch User
Oh, mir ist ein grober Fehler unterlaufen: es geht um das HM8143, nicht HM8142.
Doch, Du kannst die "Product Description" unabhängig von VID/PID anpassen. Da kann im Klartext dann "Hameg HM8142" drinstehen. :
Bearbeitet durch User
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.
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.
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 :
Bearbeitet durch User
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.
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.
Beides nicht wirklich praktikabel...
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.
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?
Microsoft - wenn bekannt wird dass der Treiber so exploited wird, setzt MS ihn auf die Liste.
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...
Wird er denn auch gestartet wenn die zugehörige Hardware nicht existiert? :
Bearbeitet durch User
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. Hmm : Lesenswert -1. Ist die Antwort auf die Frage so simpel, dass es jeder für überflüssig hält, sie hier zu posten ? D2XX-API, z.B. FT_GetDeviceInfo().
Was hat eine Signatur mit der Softwarequalität zu tun? Richtig! Nichts.
Das Gleiche, was alle Qualitätssiegel mit den jeweiligen Produkten zu tun haben (CE usw.). Die jüngeren Generationen haben anscheinend nicht mehr miterlebt wie oft Windows früher abgestürzt ist; das lag definitiv zu einem signifikanten Anteil an miesen Treibern.
Das funktioniert doch vermutlich nur beim Treiber von FTDI. Wenn ich einen STM32 einen COM-Port mit aussagekräftigem Namen bereitstellen lasse, kann ich den nicht sehen, oder ?
Schon wieder eine "Vermengelierung". "Qualitätsgerechte" CE-Bapperl kann man in China kaufen.
Wenn man unterwegs ein schrottiges Windows (W98) einsetzte, sollte man eine
Wiederherstellungs/Recovery-CD/DVD/HD dabei gehabt haben. Ich habe das Problem gerade einfach einmal bei Google eingegeben:
Hast du das schon ausprobiert?
Ja, das ist die FTDI-API.
Ich bin mir nicht sicher, ob es unter Windows einen allgemeingültigen Weg gibt, um an die Description aus dem USB-Device (statt der generischen aus dem INF-File) zu kommen. Tante Google spuckt DEVPKEY_Device_BusReportedDeviceDesc aus, das wäre vielleicht ein Ansatz.
Kannst du bitte deinen Namen hier ändern! Das steht zwar "fop" hinter, aber das führt zu Verwirrungen.
Da wir ja jetzt Haare spalten: Jeder kann kryptografische Zertifikate nach Lust und Laune ausstellen und sogar signieren. Aber Zertifikate mit dem Microsoft-Signaturschlüssel kann nur Microsoft signieren, unter der Annahme, dass niemand insgeheim die kryptografischen Einwegfunktionen geknackt hat. Windows lädt standardmäßig nur von Microsoft signierte Treiber, und Microsoft signiert die Treiberzertifikate nur nach einer gewissen Qualitätsprüfung. Seitdem hat sich die Anzahl der Treiber-bedingten Bluescreens signifikant reduziert. Damit sollte der Zusammenhang doch recht klar sein.
Ich habe durchaus für die eigene Verwendung schon Zertifikate unterschiedlicher
Art erzeugt, und benutze sie. Einen kausalen Zusammenhang, zwischen einem Zertifikat von Mirkosoft, und der Qualität einer Software, gibt es nicht. Punkt!
Es hätte sich dann auch nur von "katastrophal" zu "(un)genügend" gebessert. Es gibt sicher Bereiche bei M$, bei denen tatsächlich auf eine gewisse Qualität geachtet wird. Wenn ich mir aber ein Softwaresystem im Ganzen ansehe, sind die wohl in der Minderheit.
Wenn man keine Argumente hat schreibt man einfach "Punkt!" ? Was glaubst du denn was die Voraussetzungen für das Microsoft-signierte Zertifikat sind, und wieso die Treiber-Qualität signifikant besser geworden ist? Wir reden ja nicht von der Qualität von Microsoft-eigener Software, sondern der von Drittherstellern! :
Bearbeitet durch User
Das ist doch schon mal was. Bei der Konkurrenz findet sich damit
Geglaubt wird in der Kirche. Belege "signifikant"! Kannst du nicht? Kein Wunder. {EOC] Ich bin doch noch nicht am Ziel. Das FTDI Geraffel legt nicht einfach nur einen Eintrag per COM-Port an. Es gibt einen für das Gerät und dann je einen für die Ports. Und man ahnt es schon, die per FT-Prog vergebene Bezeichnung steht nur beim Gerät. Wenn ich jetzt aber nur die Nummer des Ports habe, komme ich noch nicht zum Gerät. Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
