Die perfekte USB-I2C-Bridge

TL;DR: Ich habe sie noch nicht gefunden und mich beschleicht das Gefühl, dass ich selbst eine (weitere, nicht perfekte) bauen muss.

Aber erst einmal auf Anfange: Mangels halbwegs flotter Alternative habe ich Libs in Python und C# (ein paar fixes stehen noch aus) um mit dem MCP2221 von Microchip zu sprechen.

Der Chip ist einfach und macht auch ungefähr, was er soll. Nur leider ist er – nicht nur aufgrund der natürlichen Beschränkung von USB HID – verdammt langsam. Speziell wenn es um Standardaufgaben wie Register lesen geht. Das ist ein richtig großer Zeit- und Performancefresser, denn: man muss es „kleinteilig“ durchführen: Register an den Controller schicken ist ein Befehl, auf den geantwortet wird, dann muss man den Lesebefehl senden (auf den auch wieder geantwortet wird) und anschließend muss man für jeden 60-Byte-Chunk der gelesenen Daten auch wieder lesen und auf die Antwort warten. Ich bin mir nicht ganz sicher, ob die Antwort im gleichen oder nächsten USB-Interrupt-Zeitschlitz kommt, aber im dümmsten Fall würde das bei einer ein Chunk großen Leseanforderung 2+2+2 ms bedeuten. Bei 20 Registern (manche Chips lassen das Lesen im Block nicht zu, durchaus aus guten Gründen) wären das 120 ms. Dann war’s das mit 10 Refreshes pro Sekunde – zugleich stottert das UI, wenn man die Kommunikation nicht in einen anderen Thread auslagert. Alles großer Mist. Im Datenblatt sind zudem Fehler u. a. in der Protokollbeschreibung und der einzige Kontakt bei Microchip (immerhin, sie haben geantwortet, was ich nicht erwartet hätte) hat sich hinter seiner NDA versteckt – obwohl die erfragten Infos teilweise schon im (von Microchip geschriebenen) Treiber für Linux stecken.

In der Hoffnung, dass es andere Hersteller besser machen, habe ich mir einen CP2112 von Silicon Labs geholt. Silabs hat einige Dinge deutlich besser gemacht – neben den deutlich höheren Bustakten (> 1 MHz) es gibt einen Befehl (und Konfiguration), der Leseanfragen deutlich verkürzt. Mit aktiviertem „Automatically send read response“ lässt sich ein Register mit n byte Länge am Chip mit Adresse a wählen und die Antwort der Länge l wird ohne weitere WriteReports an den Controller zurückgesendet. Im Schlimmsten Fall dauert der Lesen eines Chunks 2 ms. Beide Baumen Hoch!

Tja, wenn sie nicht in anderen Situationen ziemlich verkackt hätten. Hat man den auto read response an und möchte mit einer I2C-Adresse sprechen, die es auf dem Bus nicht gibt, läuft man ohne Threading in einen Deadlock, da es einfach keine Antwort vom Controller gibt und die ReadReport-Methode blocking ist (auch das Setzen des read timeout und retry count bringt nichts). Gerade beim I2C-Detect ist das ziemlich bescheiden. Richtig bescheiden ist an dieser Stelle auch, dass man keinen „Klingelstreich“ (Start, Adresse auswählen, Stop und einfach nur Auswerten, ob ein oder kein ACK kam) machen kann. Man muss immer mindestens ein Byte lesen. Das kann bei manchen Devices für Ärger sorgen. Gleichzeitig habe ich es nicht geschafft, bei Adresse 0 zu „klingeln“. Obwohl diese, gerade wenn man einen SMBus auf dem Tisch hat, wichtig ist.

Ja, das kann man alles umschiffen, aber wiederum zulasten der Performance. Dabei wäre alles super einfach in der Firmware zu implementieren. Anderes Manko des Chips: Man kann höchstens 512 Byte am Stück lesen und nur 61 (?) Byte am Stück schreiben. Warum nur?

FTDI FT232H (und andere). Kein HID, also muss man sich entweder mit einer DLL von FTDI herumschlagen oder mit LibUSB/WinUSB herumbasteln (Tolle Projekte aber da man Zadig verwenden muss, ist es kein wirkliches Plug & Play mehr. Was mir an der Sache überhaupt nicht gefällt: Obwohl man für das beste Benutzererlebnis die DLL von FTDI benutzten muss, ist es nötig, die MPSSE-Pakete selbst zusammenbasteln. Gleichzeitig gibt es beim Initialisieren anscheinend Glitches auf den Busleitungen und zwischen Start condition, Adressierung und Stop condition habe ich bei ersten Tests wahnsinnig große Zeitlücken gesehen. Ich habe mich nicht wirklich intensiv damit auseinandergesetzt, aber bis jetzt hat mich das elendige Treibergeschwurbel aktiv davon abgehalten, Code dafür zu schreiben.

WCH CH341A: Ein Kit liegt hier und ich habe aus Anwendersicht erste Tests (mit einem EEProm) durchgeführt. Sieht nicht ganz schlecht aus. Wie der FT232H ist es kein USB-HID und man darf wieder mit der bereitgestellten DLL oder anderen Libs basteln. Ein Bastelkollege hat sich der Sache schon angenommen. Großes Problem: Alles aus erster Hand ist nur auf chinesisch. Da ich auf der Website nix lesen kann, ist sie auch nicht verlinkt. Englische Dokus kommen m. W. nur aus der Community. Muss nicht schlecht sein, aber es riecht halt alles ein bisschen arg bastelig.

Von Cypress habe ich mal ein PSoc4-Devkit (so ein Stick) mit Kitprog USB bekommen, der auch sehr schnell I2C sprechen kann. Das Teil hat sich aber durch mehrere Dinge sehr schnell disqualifiziert: Den Treiber gab’s nicht einzeln, eine Doku zum Protokoll glaube ich auch nicht und das Teil hat sich extrem schnell so stark verschluckt, dass man die Hardware neu starten musste.
Es gibt noch z. B. den CY7C65211, allerdings ist mir in freier Wildbahn noch kein Devkit über den Weg gelaufen und ich hatte mit einem anderen USB-Chipsatz schon ein bisschen Probleme, was Treiberstabilität (irgendein USB-UART-Wandler, man konnte den Port öffnen, aber es gingen keine Daten durch). Ein paar haben sich auch ziemlich empfindlich gegenüber Störungen von außen gezeigt. Ob es der Chip oder die externe Beschaltung war, ließ sich nicht mehr richtig rekonstruieren, aber da haben doch ein paar Bauteile dicke Backen gemacht.

Alternativen? Da gäbe es noch den Buspirate von Dangerous Prototypes. Für den Entwickler-Tisch ok, aber für den ganzen Rest einfach zu groß. Zudem bis jetzt keine Single-Chip-Lösung eher ein USB <> UART <> irgendwas-Wandler

Ok, wenn wir schon beim Entwicklertisch sind – Aardvark von TotalPhase. Macht man da einmal den Deckel auf (zumindest den, den ich mal auf dem Tisch hatte), sieht man nix anderes als einen USB <> UART + AVR. Zugleich konnte man ihn nicht standalone verwenden, sondern braucht(e) eigentlich immer den ziemlich klobigen Levelshifter. Die Software ist fummelig und instabil, wobei ich nicht herausgefunden hab, ob es nicht vielleicht auch die Hardware war. Hab das Teil auf jeden Fall sehr schnell wieder zur Seite gelegt. Für meine Begriffe ist das Teil nicht seinen Kosten gerecht.

Was wäre da sonst noch? TI? Die hatten IIRC mal etwas im Programm aber das war entweder ziemlich lausig oder zumindest für Normalsterbliche faktisch nicht verfügbar.

Sonst fällt mir nicht mehr viel ein. Außer, dass ich schon vor längerer Zeit die Idee hatte, selbst einen USB<>irgendwas-Wandler zu bauen. Leider ist es bis jetzt in der Planungs-Featuritis hängen geblieben. Mal grob, was ich mir vorgestellt habe, was es können muss^Wsoll:

  • GPIOs + IRQs, PWM, …
  • ADCs
  • SPI
  • I2C
  • OneWire
  • SMI/MDIO (clause 22/45)
  • UART + RS485

Multiscreen unter Windows 10

Mit dem gestern erwähnten Wechsel des ausgedienten alten Bildschirms stehen nun zwei gleich große (hinsichtlich Auflösung und Panelgröße) Pixelschleudern auf dem Schreibtisch.

Was ich am alten Setup und mochte: der kleinere Bildschirm (2) vertikal mittig zum größeren (1) angeordnet. Mit dem Effekt, dass die Cursor in den Ecken des größeren gefangen (primären Bildschirm) wurden, bildlich gesprochen in etwa so:

Das Setup habe ich unter Windows 10 behalten, weil man sehr schnell per Doppelklick in der linken oben Ecke das aktuell maximierte Fenster schließen konnte und links unten war man direkt im Startmenü. Zudem kann man auf die Weise sehr einfach den Cursor „wiederfinden“ wenn er im Wimmelbild untergeht – Cursor erst nach unten, dann nach links – und man muss nur in zwei Ecken suchen (ok, die anderen Ecken gehen natürlich auch)

Mit zwei Bildschirmen mit gleicher Auflösung rutschte man unter Windows 7 beim Verschieben des Cursors auf einem Bildschirm direkt auf den anderen, was dann in etwa so aussieht:

Unter Windows 10 gibt es, neben der sich wiederholenden Taskleiste, einige kleine aber sehr schöne Funktionen für mehrere und vor allem größere Bildschirme:

Der Cursor wird in jedem Fall gefangen, wenn man ihn in die „gemeinsame Ecke“ zweier Bildschirme schiebt. Der Fangradius beträgt gefühlt nur 5 Pixel, aber die machen schon einen angenehmen Unterschied. In etwa so:

Dann wären da noch, dass die Bildschirmflächen beim „Anschnappen“ von Anwendungen als solche berücksichtigt werden. Der Cursor ist hier auf angenehme Weise am Bildschirmrand magnetisch. Bei Windows 7 muss(te) man den Workaround Win+Cursor gehen, um ein Fenster an die linke Seite des rechten Bildschirms zu kleben. Zudem können Fenster nun in den 4 Quadranten eines jeden Bildschirm packen, vielleicht ist bald (auf Umwegen auch jetzt schon mit den Powertoys) auch ein mehrspaltiges Layout möglich.

Ja, es sind kleine Dinge, aber obwohl ich Win10 sehr lange eher kritisch gegenüberstand muss ich sagen, dass viele (auch kleine) Funktionen mittlerweile sehr durchdacht sind. Vor dem nächsten Feature Upgrade werde ich aber trotzdem ein vollständiges Backup machen.

Blickwinkel

Es wurde Zeit für eine neue Schreibtischleuchte.

Mittlerweile haben ja so gut wie alle PC-Monitore nur noch sehr wenig Rand. Der alte hier hatte knapp 2 cm, der neue noch knapp 8 mm. Gleichzeitig ist aus dem TN-Panel ein AH-IPS geworden, das mit einem sehr großen Blickwinkel angegeben ist. Überspitzt tritt heutzutage eher die Totalreflexion ein als dass man auf den Displays aufgrund des Panels nix mehr sieht.

Allerdings – und das habe ich nun bei vielen neueren Bildschirmen beobachtet – reicht das Backlight nicht mehr weit genug über das Panel heraus, um bei flacheren Winkeln noch ein sauber ausgeleuchtetes Bild zu haben:

Aktueller Screenshot von stackoverflow.com

Am Rand wird’s dunkel. Der andere Bildschirm mit satter 2 cm-Kruste hat den Effekt nicht.

Ansonsten bin ich mit dem Teil recht zufrieden. Die Farbtemperatur und -wiedergabe passt auch fast perfekt zum anderen Monitor, nur gibt es einen Bug beim Asus BE27A:

Hat man ihn per Displayport am PC angeschlossen und dieser schickt die Anzeige in den Display geht er zunächst zwar wie vorgesehen in den Standby, wacht nach 20 Sekunden auf Signalsuche wieder auf. Eh?

Der Herstellersupport hat einigermaßen schnell einen Workaround angeboten: In den Einstellungen unter System-Einstellungen auf die zweite Seite blättern und die Auto-Quellerkennung ausschalten. Damit muss man bei der Verwendung von mehreren Geräten zwar manuell hin und her schalten, für meine Anwendung ist das aber nicht nötig. Ein Bugfix oder Firmwareupdate ist wohl nicht in Aussicht.

Wer hat an der Uhr gedreht

Als „Computerfritze“ erlebt man ja die verrücktesten Dinge.

Heute hat es mich selbst erwischt: PC gestartet und trotz frischem System und m.2-SSD kommt der Kübel nicht in die Gänge. Nicht einmal Strg+Alt+Entf lässt sich verwenden. Dank 8GadgetPack lässt sich zumindest eine CPU-Auslastung und RAM-Belegung sehen, die sich sehen lassen kann: dauerhaft 100 % CPU-Load und 32 GB RAM rappelvoll.

Ok, Windows 10 macht Schnellstartgedöns, also mal einen „sauberen“ Neustart geben. Nix. Der abgesicherte Modus will auch nicht fliegen. Nachdem noch ganz nette Laufwerks-Aktivität gibt, erst einmal die Sekundärdatenträger abgeklemmt, nicht dass doch Crypto/Ransomware einen Weg durchs offene Scheunentor gefunden hat.

Rien ne va plus.

Zum Glück und aufgrund eines ziemlich beschissenen Bugs der Soundkartentreiber meines Mainboards (den Gigabyte bis jetzt nicht zugeben oder zumindest nachstellen wollte/konnte) habe ich eine Windows Togo-Installation. Also externe HDD ran und den Rechner mit altbekanntem F12-Gehämmer gestartet.

Das EFI-Setup öffnet sich und über der Datenträgerauswahl steht eine Fehlermeldung: Settings reset, please check, blabla. Nanu? Ein zweiter Blick und…

…wer hat an der Uhr gedreht?

Dass sich Browser und Software, die (ablaufende) Zertifikate verwenden an falschen Systemdaten stören, ok. Aber doch nicht Windows?!

Datum korrigiert und nach dem Reboot flutscht die Kiste wieder. Kurz konnte ich im Taskmanager noch sehen, wer sich die knapp 32 geschnappt hat: Der Desktopfenster-Manager. Alles klar, danke Microsoft!

Ich habe es jetzt nicht mehr reprovoziert, aber die Uhrzeit war neben dem XMP-Profil das einzige, was ich im EFI-Setup verändert habe…

Also: Falls der PC mal langsam wird oder sich anderweitig komisch verhält: Uhrenvergleich!

Die Goobay Steckdosenleiste

Der neue Rechner steht da und funktioniert soweit, nur gibt es nun ein Problem: Die Leitungsschutzschalter in meiner Wohnung sind nach über 30 Jahren schon ziemlich ausgenudelt und nachdem mein PC samt Peripherie bei Nichtbenutzung vom Strom getrennt wird (bisweilen mit Taster + Stromstoßschalter) ist der Einschaltstrom zu viel für den LSS, auf dem die halbe Butze hängt.

Beim alten PC habe ich immer hinter das Gehäuse gefasst und das Netzteil vor dem Betätigen des Hauptschalters kurz ausgeknipst. Neue Gehäuse haben das Netzteil unten verbaut, hieße: unter den Tisch krabbeln.

eBay fördert ein Wunderwerk des China-Exports zu Tage: eine Steckdosenleiste mit Haupt- und Einzelschaltern, sogar noch genug von der Sorte um den Drucker und Verstärker getrennt zu schalten (seitdem ich einen DAC und vernünftige Kopfhörer habe, bleiben die größeren Lautsprecher öfter aus). Also bestellt und zwei Tage später von innen bewundert:

Eine Kombination aus Ultraschallschweißen und Verlöten – Einzelne Leitungen zu den Dosen hätte ich ehrlich gesagt nicht erwartet, eher dass die Federkontakte direkt an die Schalter gelötet sind…

Der Hauptschalter ist zweipolig – so wie es sein sollte. Die Einzelschalter knipsen leider nur einpolig aus. Ich hatte schon vor dem Kauf noch die Hoffnung, dass die LED anzeigt, wenn die Phase auf der richtigen Seite hängt, ein genauerer Blick verrät aber:

Nope, nix schickes drin, nur ein Kondensatornetzteil damit nicht nur die Schalter sondern die (selbstverständlich) blaue und viel zu helle LED die Netzhaut runterbrennt. Immerhin: Es gibt tatsächlich einen Überspannungsschutz. Wie gut er ist habe ich nicht weiter untersucht.

Jetzt aber noch kurz, warum ich von den einpoligen Schaltern und der nicht vorhandenen Phasenanzeige nicht so begeistert bin:

Der Schalter ist aus, der Lügenstift leuchtet aber trotzdem – nanu?

Es ist ausnahmsweise keine Fehlfunktion des „Phasenprüfers“, an der Buchse liegen tatsächlich 230 V an. Der Grund ist einfach wie fatal: unsere (sonst eigentlich gut durchdachten Schuko-Stecker) kann man in beide Richtungen stecken und es gibt m.W. auch keine Vorgaben, wo an Steckdosen die Phase hängen muss. Wenn nun ein einpoliger Schalter auf diese Unbekannte stößt, besteht eine 50:50-Chance, dass es nicht leuchtet, dafür aber brennt.

An Geräten mit Metallgehäuse kann man sich dadurch entweder lustige Elektrovibration oder einen eher unangenehmen Schlag abholen (da muss dann aber schon mehr schief gegangen sein), schön ist es trotzdem nicht.

Ich hab an beiden Enden (Stecker und Buchsen) nun einfach die dauerhaft verbundene Seite mit „N“ beschriftet und mich nochmal an der Steckdose anlügen lassen.

Bezüglich der Leitungsschutzschalter: Der Techniker ist informiert, dabei wird dann auch gleich der uralt-FI in den Ruhestand geschickt.

Fritz!Box Zugangsdaten vergessen?

Hier werkelt seit knapp 5 Jahren eine Fritz!Box 7390. Mit Loch im Deckel und sehr langsam drehendem Lüfter erlitt sie bis jetzt noch nicht den Hitzetod und braucht daher sehr wenig Aufmerksamkeit.

Leider ist das DSL hier nicht ganz so schnell, wie es mir lieb wäre. Ich klage zwar noch immer auf hohem Niveau, von den knapp 17,7 Mbit/s nutzt die Box 15,1 Mbit/s und es bleiben 12,56 Mbit/s für den tatsächlichen Download übrig. Im Upload sind es 2,8/2,3/1,95 Mbit/s:

Weil sie dann doch etwas in die Jahre gekommen ist, und die 7390 nicht unbedingt durch ihre DSL-Performance bekannt wurde, wollte ich mir mal eine zweite Meinung einholen. Ok, eine ähnlich alte 7360 – aber mal einen Versuch wert.

Nach etwas Suchen wurde allerdings klar – und nun zum eigentlichen Thema: ich habe die für die Einrichtung benötigten Logindaten verlegt. Mist.

Also mal suchen, wie man die Daten da herausbekommt. Das auf vielen Seiten beworbene Tool RouterPassView von Nir Sofer (der schnörkellose und sehr gute Tools anbietet) funktioniert nicht (mehr?) mit Fritz!Boxen.

Eine andere Lösung: Die fb_tools von Michael Engelke. Der in der Beschreibung gezeigte Befehl führte bei mir nur zu folgender Ausgabe:

Keine Konfig erhalten - Möglichlichweise ist noch die Sicherheits-Bestätigungsfunktion aktiviert? [sic!]

Also in der Anleitung der Box nachgeschaut – unter System -> FRITZ“Box-Benutzer -> Anmeldung im Heimnetz lässt sich die Option Ausführung bestimmter Einstellungen und Funktionen zusätzlich bestätigen zwar deaktivieren, nach dem Übernehmen ist die Option allerdings wieder gesetzt. Hmpf.

Wenn das Script die Daten aber entschlüsseln kann und die man in der Box die Einstellungen speichern kann – AVM wird wohl kaum mehrere Verfahren für die Crypto der Konfiguration verwendet haben. Schaut man etwas genauer in die Hilfe der fb_tools – ja, es kann verschlüsselt gesicherte Exportdateien entschlüsseln. Mit

fb_tools.bat nix@nix konfig File-DeCrypt sicherung.export dateipasswort

bekommt man die Daten direkt in der Konsole (Anm: das Tool braucht für den Aufruf immer Passwort@IP, nix@nix funktioniert auch, da kein Zugriff auf die Box erfolgt):

Ja, der Screenshot ist halbwegs witzlos, aber Beweis ist Beweis.

Jetzt muss man nur noch wissen, wie der „internet-String“ aufgebaut ist. Aus DFÜ-Zeiten weiß man noch:

Anschlusskennung#Zugangsnummer#Mitbenutzernummer@t-online.de

Das Password steht direkt hinter passwd= und war zumindest bis vor ein paar Jahren eine 8-stellige Nummer.

Auf die Test-7360-Box eingetippelt und eingestöpselt, purzeln auch hier die Bytes durchs verdrillte Kupfer. Die Ergebnisse sind etwas besser aber trotzdem ernüchternd:

Die Frage, wie sich die Performance bei einem moderneren oder etwas besseren Hardware verhält, bleibt natürlich offen. Unterm Strich: für die meisten Anwendungen reicht das. Auch wenn der Outdoor-DSLAM von m-net nur 70 m weiter steht, mit einer IPv4 wäre es dort um die 5 Euro im Monat mehr. Mehr Upload wäre gerade für VPN toll, aber die Schmerzen sind dafür nicht groß genug 😉

APDS-9960 decap

Der APDS-9960 von Avago/Broadcom ist das, was man sich unter einem vernünftigen Lichtsensor vorstellt: ALS, Proximity, RGB.

Weil ich eine Konkrete Idee für eine Anwendung hatte, landete einer für billig Geld auf dem Basteltisch. Nur leider wollte er nicht so richtig. Ich konnte ihn nicht dazu überreden, RGB-Werte auszuspucken und die ID passte auch nicht wirklich.

Im Internet gab es nichts zu finden, auch die IDs der anderen APDS-Sensoren passten nicht.

Da das Teil zu meinem Erstaunen einen Metalldeckel hat: warum nicht kurz drunterschauen? An der ersten Seite hat das leichte Hochbiegen noch ganz gut funktioniert, bei der zweiten nicht mehr:

Man erkennt es leider nicht ganz so gut, aber die IR-LED und ein paar Bonddrähte blieben im oberen Teil. Well, fuck.

Naja, jetzt brauch ich schon nicht mehr das passende Datenblatt suchen.

廉价 oder 有利

Günstig oder billig?

Ein Kollege brachte heute ein Stück Technik vorbei, das zwar funktionierte, aber nicht so richtig wertig wirkte:

Links ist das gute Stück, rechts ein zum Verwechseln ähnlicher USB-Charger von Samsung. Abgesehen von der Größe und und dem fehlenden Samsung-Logo (ok, das CE-Logo sieht auch eher nach „China Export“ aus) merkt man den Unterschied, wenn die Steckernetzteile in der Hand hält: Das Gewicht ist doch ziemlich unterschiedlich: Der Samsung-Charger wiegt mit 40 g ein bisschen mehr als doppelt so viel wie das Teil aus dem Reich der Mitte (18 g).

Mit ein bisschen Gewalt am oberen Ende offenbarte das Ladegerät seine inneren Werte, die man vorher schon an der USB-Buchse riechen konnte (heißes Hartpapier). Entsprechend meinen Erwartungen wurde ich nicht enttäuscht:

Hmmm, Crusty!

Zum Vergleich die Innereien eines anderen Samsung-Ladegerätes, das ich mal auseinandergenommen habe (IIRC ohne „adaptive fast charging“):

Auffälligster Unterschied: Eine richtige Sicherung, eine Common-Mode-Choke zur Funkentstörung, bisschen höherwertige Kondensatoren (wobei mir „Chang“ nicht als besonders hochwertig in Erinnerung ist), ein im Vergleich richtig fetter Transformator und ein halbwegs seriöser X-Kondensator zwischen Primär- und Sekundärseite. Der größte und auffälligste Unterschied: Eine Isolationsplatte, die durch den Slot zwischen Netzspannung und Schutzkleinspannung greift. In den Bildern sieht man es leider nicht so richtig: sie ragt 3,5 mm über die andere Seite der Leiterkarte heraus.

Aber auch auf der Unterseite sieht man deutliche Unterschiede. Zunächst, als Positivbeispiel Samsung:


Muss man noch etwas dazu sagen?

…und nun das, was man für 3,50 1,86 Euro mit USB-Kabel und Versand bekommt:

Der Isolationsabstand zwischen Primär- und Sekundärseite beträgt ca. 1,5 mm. Die Kriechstrecke sollte IIRC eher die vierfache Breite haben

Völlig unklar ist auch, wie gut die Wicklungen im Trafo voneinander isoliert sind. Wenn man genauer hinsieht, kann man zwar noch eine rote Folie unter der äußeren Wicklung erkennen, aber die Zweifel bleiben

Kurzgesagt: Das Teil würde ich definitiv nicht an mein Telefon oder etwas anderes anschließen.

Noch ein weiteres Leckerchen: Die Interpretation einer Sicherung (der Eingangswiderstand) oder besser sein Beinchen (unten mitte-links im Bild) ist so ungeschickt abgeschnitten, dass der Pin sehr nah in Richtung Ausgangsseite des Gleichrichters reicht.

Den Ausfall dürfte man dann ziemlich schnell merken 😉

USB 3.2 – Ist die Lösung schlimmer als das Problem?

Vor knapp zwei Wochen gab es in der c’t (4/2019) einen Artikel zu USB 3.2, das neben der doppelten Geschwindigkeit (20 GBit/s) auch ein älteres Problem des Systems beheben soll: BadUSB. Dabei kann z. B. ein USB-Stick mehr als Massenspeicher. Als beispielsweise Maus- und Tastatur-Simulator kann er Eingaben am Rechner durchführen, als RNDIS kann es ggf. sogar Netzwerkverkehr manipulieren. Hurra!

Mit USB 3.2 soll das alles besser werden. Mit Zerifikaten und Crypto. An der Stelle sei erwähnt, dass Apple mit im Gremium war. Wofür haben die nochmal Crypto in ihren Lightning-Steckern hinzugefügt? Um ihre Produkte sicherer zu machen oder um sich vor günstiger Nachbauware zu schützen? Ein Schelm, ….

So, jetzt stellt sich einer mal das hier vor: Ein USB-Device, sei es eine Maus, eine Tastatur, ein USB-Speicherstick, hat ein gültiges Zertifikat. Soweit, so gut. Was hindert die Maus oder Tastatur nun daran, böswillige Eingaben zu machen, von denen der User nix mitbekommt? Wenn man wollen würde, könnte man sogar hinter dem USB-Controller, also direkt an der Tastaturmatrix etwas böswilliges einbauen. Schützt einen das Zertifikat, das man wahrscheinlich für teuer Geld kaufen muss davor?

Andersrum: Wenn ein legitimer Chip mit diesem Angriffsvektor in einem dadurch illegitimen Produkt verbaut wird und dieses Zertifikat zurückgezogen oder für ungültig erklärt werden muss (wie läuft das überhaupt, muss man nun beim Einstecken eines USB-Geräts online sein?), sitzen dann die Nutzer des legitimen Produkts im Dunkeln? Was hält einen Hersteller davon ab, schlechte Firmware zu schreiben, dass man trotz Zertifikat Schadsoftware injizieren kann?

Oder noch viel einfacher: Wenn ein Angreifer eine Maus und Tastatur in einen USB-Stick (zusätzlich zum Speicher) unterjubeln will, dann kann er doch einfach einen legitimen USB-Hub vor den legitimen USB-Speicher hängen und nebendran noch eine legitime Tastatur anbasteln, die über einen weiteren µC (oder auf andere Wege) illegitime Befehle an den PC weitergibt. Zwar werden dadurch mehrere Geräte erkannt, aber welchen Unterschied macht’s?

Und wie schaut es mit alten USB-Geräten aus? Es ist ja schon ein riesiges Problem, bei USB-Type-C-Buchsen & -Steckern zu sagen, was sie denn überhaupt können. USB 2.0, USB 3.0, USB 3.1, USB 3.2, Tunderbolt, Display Port, Power Delivery mit 5 W, 10 W, 20 W, 100 W, Quelle, Senke oder beides. Kann sie Analog Audio, kann ich daran meinen Mixer anschließen?

Aber ich schweife ab: Wie sieht es mit Legacy-Devices aus? Sie von der Verwendung auszuschließen wäre Irrsinn, also müssen sie weiter funktionieren – und wen hält es ab, einen scheinbar modernen USB-Stick (z. B. mit USB Type C) einfach nur ein USB 2.0-Interface zu implementieren, das dann fleißig böse Dinge tut.

Ich muss zugeben, ich habe die Spec (noch) nicht gelesen, aber die die (ok, nicht exklusive) Apple’sche Zwangsneurose alles verdongeln zu müssen kotzt mich als User, Bastler und Entwickler einfach nur noch an.

Warum löst man das BadUSB-Problem nicht wie früher bei den Personal Firewalls: Ein Gerät meldet sich an, wird enumeriert, darf aber erst einmal nichts machen. Der Benutzer bekommt einen Popup mit dem neu erkannten Gerät (oder Gerätebaum) präsentiert und muss sich entscheiden, ob er die Verwendung zulassen oder verweigern möchte. Noch eine Checkbox dazu, ob man dies vorübergehend oder dauerhaft will und ob dies für alle USB-Buchsen der Fall sein soll und fertig.

Einen halbwegs eindeutigen Fingerabdruck (Vendor- & Product ID, Seriennummer, Descriptors) haben eigentlich alle Geräte und ja ich weiß, es ist nicht perfekt und hindert ein wenig die Usability. Aber es könnte jetzt sofort für alle USB-Generationen implementiert werden. Selbst bei Eingabegeräten (Maus/Tastatur), die man an einen jungfräulichen PC anschließt, dürfte die Kopplung funktionieren, indem man eine angezeigte, zufällige Tastenfolge, eingibt.

Ich befürchte nur, dass das Ganze eher wieder ein Mittel wird, um Firmeninteressen zu verfolgen und die Sicherheit der User nur eine gefühlte bleibt.