Wie ein ThinkPad in ein programmierbares USB-Gerät verwandelt wurde

 (xairy.io)
1 Punkte von GN⁺ 2024-02-24 | 1 Kommentare | Auf WhatsApp teilen
  • Nach dem Aktivieren des versteckten xDCI-Controllers im ThinkPad X1 Carbon der 6. Generation konnte der Laptop selbst beliebige USB-Geräte wie Tastaturen oder Massenspeicher emulieren
  • Der Hinweis war /sys/class/usb_role/intel_xhci_usb_sw-role-switch, aber ein xHCI-Rollenwechsel allein reichte nicht aus; zusätzlich musste ein separates DWC3-basiertes xDCI-UDC als PCIe-Gerät sichtbar werden
  • Im BIOS-Image gab es die Einstellung xDCI Support, sie war jedoch in der standardmäßigen Setup-Oberfläche verborgen; nach der Aktivierung erschienen in lspci xDCI 8086:9d30 und der Treiber dwc3-pci
  • Die erfolgreiche Methode bestand aus dem Freischalten der erweiterten BIOS-Seite und einem NVRAM-Patch; eine Rekonfiguration der PCH-Register scheiterte trotz einiger PMC-Änderungen an der PSF-Sperre
  • Nach der Aktivierung von xDCI funktionierten g_mass_storage, Raw Gadget, syzkaller-Reproducer und ein Facedancer-Backend ohne externe Hardware, erforderten aber ein USB-Kabel mit unterbrochenem VBUS und den Rollenwechsel auf device

Hinweise auf den USB-Gerätemodus im ThinkPad

  • Raw Gadget ist ein Kernel-Modul, das dem USB-Gadget-Subsystem des Linux-Kernels eine User-Space-API bereitstellt, und kann für USB-Host-Fuzzing und Exploits genutzt werden, indem es fehlerhafte USB-Deskriptoren liefert
  • Gewöhnliche PCs haben normalerweise keinen USB Device Controller, also keinen UDC; dieser ist eher in Single-Board-Computern wie dem Raspberry Pi integriert
    • Für bisherige Arbeiten war externe Hardware wie ein Raspberry Pi oder ein USB-3380-basiertes EC3380-AB nötig
  • Auf dem ThinkPad X1 Carbon der 6. Generation wurde unter /sys/class/usb_role intel_xhci_usb_sw-role-switch gefunden
    • /sys/class/usb_role ist eine Schnittstelle zum Umschalten von USB-Hardwarekomponenten zwischen Host- und Device-Modus
    • Selbst wenn device in die role-Datei geschrieben wurde, erschienen zunächst weder dmesg-Meldungen noch Einträge unter /sys/class/udc/
  • xHCI ist der HCD, der auf x86-Systemen USB-Host-Funktionalität bereitstellt; xDCI ist Intels Bezeichnung für die USB-Device-Seite

Struktur durch Kernel-Code und Mailinglisten bestätigt

  • Im Linux-Kernel taucht intel_xhci_usb_sw an zwei Stellen auf
    • drivers/usb/roles/intel-xhci-usb-role-switch.c implementiert den USB-Role-Switch-Treiber, der xHCI-Register manipuliert, wenn device oder host geschrieben wird
    • drivers/usb/host/xhci-ext-caps.c erzeugt ein virtuelles Plattformgerät intel_xhci_usb_sw, wenn der xHCI-Treiber das Quirk XHCI_INTEL_USB_ROLE_SW setzt
  • Die xHCI-PCIe-Device-ID des ThinkPad war 0x9d2f und stimmte mit PCI_DEVICE_ID_INTEL_SUNRISEPOINT_LP_XHCI im Kernel überein
  • Diskussionen auf der Linux-Kernel-Mailingliste bestätigten, dass xHCI und DWC3 UDC getrennte Geräte sind und dazwischen ein Mux sitzt
    • Der Role Switch schaltet diesen Mux um
    • Wenn der DWC3 UDC selbst nicht als PCI-Gerät sichtbar ist, gibt es keinen UDC für den Device-Modus
  • DWC3 ist die DesignWare Core SuperSpeed USB 3.0 Controller IP von Synopsys, die von mehreren Anbietern einschließlich Intel verwendet wird
  • Beim Prüfen von lspci auf dem ThinkPad war anfangs nur xHCI 8086:9d2f sichtbar; die in dwc3-pci.c für Sunrise Point-LP genannte xDCI-Device-ID 0x9d30 erschien nicht

In ACPI und BIOS verbliebene Spuren von xDCI

  • In der ACPI-DSDT existierten Device (XDCI) und eine _STA-Methode
    • /sys/bus/acpi/devices/device:33/path war \\_SB_.PCI0.XDCI
    • /sys/bus/acpi/devices/device:33/status war 15, was bedeutet, dass das Gerät aktiviert und funktionsfähig ist
    • Da xDCI jedoch nicht in lspci erschien, wirkte es nur aus ACPI-Sicht normal
  • Auf dem normalen BIOS-Setup-Bildschirm waren keine Einstellungen zu xDCI oder OTG sichtbar
  • Nach dem Herunterladen des Lenovo-BIOS-Bootable-CD-Update-Images wurde das BIOS-Binary /mnt/bios/FLASH/N23ET86W/$0AN2300.FL1 extrahiert und mit UEFITool untersucht
  • Bei der Suche nach Zeichenketten im PE32 image section des Setup-Moduls erschienen folgende Einträge
    • xDCI Support
    • Enable/Disable xDCI (USB OTG Device).
  • Die xDCI-Support-Einstellung war also im BIOS vorhanden, aber in der Standard-UI versteckt

xDCI über die erweiterte BIOS-Seite aktivieren

  • Nach der Dokumentation des Projekts x1c6-hackintosh wurde versucht, die versteckte Advanced-BIOS-Seite zu öffnen
  • Dafür musste der SPI-Chip mit dem BIOS erneut geflasht werden
    • Statt einer SPI-Klammer wurde der SPI-Chip durch einen Sockel ersetzt, um ihn für wiederholte Tests mehrfach entnehmen und einsetzen zu können
    • Mit einem FTDI FT2232H Mini Module und flashrom wurde der Inhalt des SPI-Chips ausgelesen und zurückgeschrieben
  • Der BIOS-Patch bestand aus zwei Schritten
    • Mit UEFIPatch wurde die GUID-Referenz der BIOS-Seite Date/Time auf die Seite Advanced umgebogen
    • Ein separater Byte-Patch zwang das TPM in den MFG Mode, damit Boot Guard die BIOS-Änderung nicht erkennt
  • Unter BIOS 1.37 führte nur der erste Patch dazu, dass der Laptop piepte und nicht startete; erst nach dem zweiten Patch erschien die Advanced-Seite
  • Nach dem Setzen von xDCI Support auf Enabled unter Intel Advanced Menu → PCI-IO Configuration → USB Configuration wurde xDCI nach dem Booten sichtbar
    • In lspci erschien 00:14.1 USB controller [8086:9d30]
    • Der Kernel lud automatisch den Treiber dwc3-pci
    • Unter /sys/class/udc/ erschien dwc3.1.auto

xDCI-Port und Anforderungen an das Kabel

  • Um den externen USB-Port zu finden, der mit xDCI verbunden ist, wurden bei auf device gesetzter Rolle USB-Flash-Laufwerke nacheinander an allen Ports getestet
    • An einem bestimmten Port erkannte das Betriebssystem das Flash-Laufwerk nicht; nach dem Zurückschalten der Rolle auf host funktionierte er wieder
    • Daraus wurde geschlossen, dass dies der an xDCI angeschlossene Port ist
  • Da der xDCI-Port des ThinkPad USB Type-A war, wurde für die Verbindung zu einem Host-Computer ein Type-A-zu-Type-A-Male-to-Male-Kabel benötigt
  • Weil das Umschalten der Rolle die Port-Stromversorgung VBUS nicht abschaltete, wurde ein Kabel mit unterbrochenem VBUS verwendet, damit VBUS der beiden Geräte nicht direkt verbunden wird
    • Zunächst wurde ein solches Male-to-Male-Kabel aus zwei aufgeschnittenen USB-2.0-Kabeln mit unterbrochenem VBUS selbst gebaut
    • Später wurden ein PortaPow USB Power Blocker und ein USB-2.0-Male-to-Male-Kabel verwendet
  • Nach dem Laden des Gadget-Treibers g_zero wurde auf einem anderen Laptop erfolgreich ein USB-Testgerät emuliert
  • Laut Update vom 11. Juni 2024 trennt das DataPro USB 3.0 Super-Speed A/A Debugging Cable auch USB-2.0-D- und D+, wodurch die für den SuperSpeed-Linkaufbau nötige High-Speed-Verbindung scheitert
    • Ein LogiLink-CU0038-Kabel mit manuell unterbrochenem VBUS funktionierte für die Emulation von SuperSpeed-Geräten

Versuch einer softwareseitigen Aktivierung über PCH-Register

  • Um zu verstehen, wie das BIOS xDCI aktiviert, wurde Pch/Library/Private/PeiPchInitLib/PchXdci.c aus dem BIOS-Quellcode für Kaby Lake geprüft
  • Der BIOS-Pfad zum Deaktivieren von xDCI bestand darin, xDCI in PMC und PSF abzuschalten

  • PMC-Änderungen

    • Es wurde angenommen, dass sich die Stromabschaltung von xDCI aufheben lässt, indem im PMC-Register NST_PG_FDIS_1 mit Offset 0x628 Bit #24 XDCI Function Disable gelöscht wird
    • Dafür wurde ein Kernel-Modul geschrieben, das das Mapping von pmc_core_device und pmc->regbase aus dem Linux-Kernel wiederverwendet
    • Direkt nach dem Booten war in ST_PG_FDIS1 das ST_FDIS_LK-Bit #31 gesetzt, sodass der Wert von NST_PG_FDIS_1 nicht geändert werden konnte
    • Nach Suspend und Resume war das Lock-Bit nicht gesetzt, und das Löschen des Bits XDCI Function Disable gelang

  • PSF-Änderungen

    • Das BIOS deaktiviert xDCI, indem es im PSF2-PCR von PID_PSF2 mit Port-ID 0xBB das Bit USB Dual Role (OTG) Function Disable setzt
    • Die PCR-Adresse wird aus PCH_PCR_BASE_ADDRESS 0xFD000000, Port-ID und Offset berechnet
    • Das Kernel-Modul mapte den PSF2-PCR per ioremap, aber gelesene Werte waren 0xffffffff und ließen sich nicht ändern
    • Auch nach dem Unhide von P2SB blieb das Ergebnis unverändert
    • Das BIOS trennt mit RemoveSidebandAccess über EPMASK5 den PID_PSF2 vom IOSF-SB und sperrt dies mit MASKLOCK, sodass das Betriebssystem PSF nicht neu konfigurieren kann
    • Damit gelang zwar der Zugriff auf einige PMC-Einstellungen, aber wegen der fehlgeschlagenen PSF-Rekonfiguration war dies kein praktikabler Weg zur Aktivierung von xDCI

Aktivierung per NVRAM-Patch ohne Boot-Guard-Umgehung

  • Da BIOS-Einstellungswerte im NVRAM-Bereich des SPI-Chips gespeichert werden, wurde versucht, nur den Wert von xDCI Support zu ändern, ohne die versteckte Advanced-Seite zu öffnen
  • Mit IFRExtractor-RS wurden die UEFI-IFR-Informationen aus dem Setup-Modul extrahiert
  • Die Einstellung xDCI Support war in der UEFI-Variable PchSetup gespeichert
    • VarStore GUID: 4570B7F1-ADE8-4943-8DC3-406472842384
    • VarStoreId: 0x5
    • VarOffset: 0x40
    • Wertebereich: 0x0 oder 0x1
  • Unter Linux wurde in efivarfs /sys/firmware/efi/efivars/PchSetup-4570b7f1-ade8-4943-8dc3-406472842384 geprüft
    • Die ersten 4 Bytes einer efivarfs-Datei sind Header; der eigentliche Wert von xDCI Support liegt daher bei Datei-Offset 0x44
    • Bei deaktiviertem xDCI war der Wert 00, nach Aktivierung über die Advanced-BIOS-Seite 01
  • Beim direkten Schreiben dieser Variablen aus dem User Space oder aus der EFI Shell trat der Fehler EFI_WRITE_PROTECTED auf
    • Selbst nach dem Entfernen des immutable-Attributs von efivarfs trat der Fehler Read-only file system auf
    • Auch mit chipsec in der EFI Shell trat derselbe Fehler auf
  • Nachdem in einem mit dem SPI-Programmer ausgelesenen Original-BIOS-Image die Byte-Sequenz rund um PchSetup gesucht und nur das Bit für xDCI Support auf 01 gepatcht und zurückgeflasht wurde, war xDCI aktiviert
  • Diese Methode erfordert weiterhin das Reflashing des SPI-Chips, benötigt aber weder den Advanced-Seiten-Patch noch eine Boot-Guard-Umgehung und beschädigt auch das TPM nicht
  • Nach dem Patchen des NVRAM unter BIOS 1.37 und einem späteren Update auf 1.61 blieb der BIOS-Einstellungswert erhalten, sodass der Patch nicht erneut angewendet werden musste

USB-Geräte mit xDCI emulieren

  • Alle Beispiele setzen voraus, dass xDCI im BIOS aktiviert ist, intel_xhci_usb_sw-role-switch auf device geschaltet wurde und der xDCI-Port über ein Kabel mit unterbrochenem VBUS mit einem USB-Host verbunden ist

  • Legacy-Gadget-Treiber

    • Die Legacy-Gadget-Treiber des Linux-USB-Gadget-Subsystems emulieren nach dem Laden eines Moduls ein bestimmtes USB-Class-Gerät
    • g_mass_storage stellt ein Dateisystem-Image als USB-Massenspeichergerät bereit
    • Es wurde ein FAT-Image disk.img erstellt, file.txt mit Hi from xDCI befüllt und dann mit sudo modprobe g_mass_storage file=./disk.img stall=0 geladen
    • Auf dem USB-Host wurde das Laufwerk automatisch eingehängt und der Dateiinhalt bestätigt

  • Raw Gadget

    • Raw Gadget wurde zusammen mit xDCI verwendet, um das Beispiel einer USB-Tastatur auszuprobieren
    • Zunächst blieb der Ablauf bei der Verarbeitung von SET_CONFIGURATION hängen
    • Ursache war die Annahme in dwc3 und einigen UDC-Treibern, dass eine 0-Byte-Control-Request sofort bestätigt werden könne, ohne den Gadget-Treiber zu prüfen
    • Nach Anwendung des Workaround-Patches auf Raw Gadget und einer Anpassung an GadgetFS funktionierte die Tastatur-Emulation
    • Das zugehörige Verhalten wurde in einem Dokumentations-Patch als Commit festgehalten

Einsatz mit syzkaller und Facedancer

  • syzkaller kann mit Raw Gadget externes Fuzzing des USB-Stacks des Linux-Kernels durchführen
  • Das standardmäßige USB-Fuzzing von syzkaller verwendet Dummy HCD/UDC, die im Kernel intern ein virtuelles USB-Device und einen Host-Controller verbinden
  • Um xDCI zu nutzen, wurde der UDC-Auswahlcode in syzkaller von dummy_udc auf dwc3-gadget und dwc3.1.auto geändert
  • Der von syzkaller gefundene Reproducer für den Bug WARNING in smsusb_start_streaming/usb_submit_urb wurde mit syz-execprog -enable=usb ausgeführt
    • Auf einem Laptop mit Ubuntu-Kernel 5.15.0-91-generic als Host wurde die Warnung usb_submit_urb reproduziert
    • Der Bug war eine WARNING, verursacht dadurch, dass der Treiber smsusb die Prüfung des USB-Endpoint-Typs ausließ; schädliches Verhalten trat nicht auf
  • Facedancer ist ein Python-basiertes Framework zur Emulation von USB-Geräten
    • Das auf Raw Gadget basierende Facedancer-Backend ist noch ein Prototyp und hängt von einem Out-of-Tree-Patch für Raw Gadget ab
    • Mit BACKEND=rawgadget, RG_UDC_DRIVER=dwc3-gadget, RG_UDC_DEVICE=dwc3.1.auto und dem Beispiel rubber-ducky.py funktionierte es korrekt
  • Auch der auf Raw Gadget basierende USB Proxy lief zusammen mit xDCI; damit kann ein Laptop per xDCI als USB-Sniffer oder USB-Man-in-the-Middle-Werkzeug verwendet werden

Möglichkeiten auf anderen Geräten und rein softwareseitig

  • Auch auf anderen PCs als dem ThinkPad X1 Carbon der 6. Generation könnte sich xDCI aktivieren lassen
    • Im einfachsten Fall genügt es, xDCI in den BIOS-Einstellungen zu aktivieren
    • Erforderlich sind ACPI- und Role-Switch-Unterstützung sowie eine Verdrahtung des xDCI-Ports zu einem externen Anschluss
  • Auch bei anderen ThinkPads könnten die BIOS-Einstellungen für xDCI versteckt und geschützt sein, sodass ein Reflashing des SPI-Chips nötig wird
    • Der NVRAM-Ansatz funktioniert ohne Boot-Guard-Umgehung
    • Bei manchen neueren Systemen kann das Reflashing des SPI-Chips durch RPMC geschützt sein; solche Chips können ein R im Namen tragen, etwa W25R128FW
  • Laut Update hat Shiny Quagsire auf einem XPS 13 und einem Surface Go 1 xDCI bereits durch Ändern der Variable PchSetup mit grub-mod-setup_var aktiviert
    • Auf diesen Geräten war PchSetup nicht geschützt, sodass ein rein softwarebasierter Weg möglich war
  • Weitere softwareseitige Ansätze könnten BIOS-Schwachstellen nutzen, um xDCI-bezogene NVRAM-Variablen zu ändern, oder das BIOS während des Bootvorgangs per DMA angreifen, um beliebigen Code auszuführen
  • Das „secret“ im Titel meint eher eine undokumentierte Funktion als eine absichtlich versteckte

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-02-24
Hacker-News-Kommentare

  • Ich habe mich schon immer gefragt, warum die Funktion nicht verbreiteter ist, einen Laptop als universelle Tastatur und Monitor für andere Computer zu verwenden.
    Es ist seltsam, für die Wartung einer Headless-Maschine extra eine Tastatur und einen Monitor zu kaufen, wenn ein Laptop diese Rolle bereits übernehmen könnte.

    • Das GPD Pocket 3 hat ein KVM-Modul, das genau das macht: Es nimmt HDMI- und USB-C-Eingänge entgegen und verhält sich wie Display, Tastatur und Maus der angeschlossenen Maschine: https://gpd.hk/gpdpocket3
      Das bald erscheinende Minisforum V3-Tablet hat ebenfalls einen Videoeingang und kann daher wie ein externer Monitor genutzt werden, aber Tastatur und Maus werden wohl nicht mitgeteilt.
      Es wäre wirklich schön, wenn solche Funktionen häufiger würden.
    • Genau. Ein Freund hat nur dafür ein Cyberdeck gebaut.
      Maus und Tastatur lassen sich auf externe Ports umschalten und per Kabel mit einer anderen Maschine verbinden; an der Seite gibt es zwei HDMI-Ports, einen als Ausgang und einen als Eingang.
      Über einen internen Schalter kann man wählen, ob die Maschine des Decks selbst oder der externe Eingang als Monitorquelle genutzt wird.
    • Da ich oft mit Headless-Maschinen arbeite, war dieses Produkt für mich die beste Lösung, um einen Laptop als Monitor zu verwenden: https://www.amazon.com/dp/B0BJ2YDV7Q
      Im Grunde ist es ein Chip, der das HDMI-Signal der Headless-Maschine erfasst und über USB als emulierte Webcam am Laptop bereitstellt; die Elektronik ist klein genug, um im Kabel zu stecken.
      Für die Tastatur habe ich keine gute Lösung gefunden, außer eine normale kabellose Tastatur zu kaufen, selten mit integriertem Trackpad für den Fall, dass man eine Maus braucht.
    • Ich fand es schon immer umständlich, dass man einen Computer nicht einfach an einen anderen anschließen kann.
      Soweit ich gehört habe, gibt es in USB 4 einen Modus, der das ermöglicht.
    • Mit hidclient kann sich ein Laptop als Bluetooth-Tastatur und -Maus ausgeben.
      https://web.archive.org/web/20180610141436/http://anselm.hoffmeister.be/computer/hidclient/index.html.en
      https://github.com/benizi/hidclient

  • Mir fällt ein Fall ein, an den ich mich aus einer Arbeit von Travis Goodspeed vor einigen Jahren erinnere.
    Ein Smart-TV nahm Firmware-Updates über Dateien auf einem normalen USB-Stick entgegen; der Fernseher las die Datei von Anfang bis Ende, um die digitale Signatur zu prüfen, und las sie dann für das Update erneut.
    Ein Gerät, das sich als USB-Speicher ausgibt, könnte beim ersten Lesen die Hersteller-Firmwaredatei senden und beim zweiten Lesen eine inoffizielle Firmware.

  • Wirklich interessant. Ich habe nach ähnlich realisierbaren Optionen gesucht.
    Ich habe einen leistungsstarken NAS-Server, für den ich ständig nach einem Vorwand zur Nutzung suche, und im ganzen Haus 40G- und 10G-Verbindungen verlegt.
    PS5 und XBox verwenden USB-Festplatten als zusätzlichen Speicher.
    Ich habe geprüft, ob man den NAS-Speicher PS5 und XBox bereitstellen kann, und es war möglich. Man mountet eine NAS-Freigabe per iSCSI oder NFS und emuliert dann mit dem Modul g_mass_storage ein USB-Speichergerät, um diesen Speicher dem USB-Host bereitzustellen.
    Derzeit ist neben Zeit und Kosten die Bandbreite, die so ein System liefern kann, der große Stolperstein. Das Upgrade wäre nicht besonders groß.
    Der Raspberry Pi ist zwar bekannt dafür, USB-OTG zu unterstützen, bleibt aber bei USB-2.0-Geschwindigkeit; die meisten anderen SBCs derselben Klasse, die ich gefunden habe, waren ähnlich. Die Ausnahme war der RockPi4, und der RockPi hat einen Gigabit-Ethernet-Port, sodass er bei voller Auslastung des Ethernets sowohl PS5 als auch Xbox stabile HDD-Geschwindigkeiten liefern kann.
    Wenn man mit einer eigenen PCIe-Netzwerkkarte oder Express-Karte eine Lösung jenseits von 1GbE bauen könnte, ließe sich das USB-3.0-Interface richtig auslasten; das wäre ziemlich interessant.

    • Ich habe eine ähnliche Homelab-Konfiguration und experimentiere mit USB über IP über https://www.virtualhere.com.
      Man braucht zwar einen Client, der mit dem Server kommuniziert, aber es scheint ziemlich gut zu funktionieren.
      Ich denke über eine Konfiguration nach, bei der ein „Thin USB Client“ auf dem Schreibtisch steht, USB-Geräte daran angeschlossen werden und sie dann an einen gewünschten physischen Host oder VM-Host im Labor angebunden oder dorthin umgeschaltet werden.
    • Mich würde interessieren, wie PS5 und NAS physisch verbunden werden.
      Ich vermute NAS → SBC → PS5, oder wird der NAS direkt per USB-Kabel an die PS5 angeschlossen?
      Außerdem frage ich mich, wie die Wiedergabe von Inhalten auf der PS5 funktioniert. Soweit ich weiß, muss die interne NVMe bestimmte Geschwindigkeiten erfüllen; gilt das für externe Laufwerke nicht?
    • Der Raspberry Pi 5 hat einen Gigabit-Ethernet-Port, und andere SBCs wie FriendlyElecs NanoPi-Reihe ebenfalls.
      Der NanoPi R6S hat tatsächlich zusätzlich zu einem 1-Gigabit-Port zwei 2,5G-Ethernet-Ports.

  • Danke für den sehr ausführlichen Beitrag. Die Qualität ist gut.
    Dass das möglich war, gibt mir Hoffnung, dass vielleicht eine netzwerklose Konfiguration ähnlich Synergy / Mouse Without Borders allein mit einem modifizierten USB-Kabel möglich sein könnte.
    Für Leute, die mehrere Computer gleichzeitig bedienen müssen, wäre das eine sehr gute Richtung.

    • Es gibt zwar KVM-Switches, und auch Geräte, die ohne Video nur USB-Tastatur und -Maus umschalten.
      Trotzdem klingt der vorgeschlagene Ansatz interessant.

  • Ich habe mich kürzlich mit etwas Ähnlichem beschäftigt: Ich wollte zwei USB-C-Maschinen mit einem einzigen USB-C-Kabel verbinden und darüber 10 Gbps Kommunikation erreichen.
    Leider haben die meisten Ryzen-Boards immer noch kein Thunderbolt; mit Thunderbolt ließe sich das nativ und problemlos unterstützen.
    Auch „Dual-Role“-USB-Controller waren bis USB 3.2/4.0 ziemlich selten, und selbst wenn es möglich war, wurde es, wie in diesem Artikel beschrieben, oft nicht unterstützt.
    Dass es so schwierig ist, zwei Maschinen ohne Thunderbolt per USB-C-Kabel zu vernetzen, fühlt sich völlig absurd an.
    Auch der Teil, in dem das Lock-Bit nach dem Suspend aufgehoben wird, war gut. Solche Probleme sind wirklich häufig. Zum Beispiel ist das auch ein sehr gängiger Ansatz, um SATA-Geräte aus einem Zustand zu holen, in dem sie Secure Erase verhindern.

  • Die Tiefe ist beeindruckend.
    Wenn man einen PC als USB-Gerät verwenden kann, eröffnen sich viele interessante Möglichkeiten.
    Etwas schade ist, dass die nötige xDCI-Option zwar in der Hardware dieses Geräts vorhanden ist, aber nicht offengelegt wird und man Firmware-Hacking braucht, um darauf zuzugreifen.
    Die Hardware kann es, aber der Hersteller hat es einfach deaktiviert und die Steuerungsmöglichkeiten gesperrt.

  • Ich frage mich, ob Lenovo das als Weg nutzt, um mit einem ThinkPad ein anderes ThinkPad zu debuggen.
    https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/secure-coding/intel-debug-technology.html
    Update: Vermutlich ja.
    https://www.youtube.com/watch?v=ExUvQa_jB7c
    Das ist ein Video zum Debuggen von Intel Firmware mit DCI und USB 3.0.

  • Der Abschnitt „Aber der Umgang mit dem Raspberry Pi ist umständlich: Kabel anschließen, Board booten, Shell-Verbindung herstellen usw.“ hätte sich vermutlich mit einer Einrichtung von USB OTG lösen lassen.
    Man hätte ihn vom eingesteckten Gerät mit Strom versorgen lassen, eine Shell starten und das Ganze per Skript abwickeln können.
    Dann hätte man per SSH Mounts einrichten oder Befehle ausführen können, und wahrscheinlich wäre sogar das Mounten des Geräts möglich gewesen.
    Trotzdem ist der Versuch, das eigene Gerät zu verstehen und den Kernel zu lesen, sehr zu begrüßen. Das ist etwas, worin man immer besser werden möchte – ganz im Sinne von: Unsere Geräte reparieren wir selbst.

    • Der Kern dieses Experiments ist ja gerade USB OTG, und der Pi hat nur einen OTG-Port, daher braucht man für den Zugriff einen anderen Weg.
      Ich habe es selbst ausprobiert.

  • Es erinnert stark an die frühe Hacker-Kultur des Internets und ist fast schon nostalgisch. Ein wirklich hervorragender Artikel.
    Genau solche Leute meinte ESR, wenn er darüber sprach, was es heißt, ein Hacker zu sein – ein Hacker im Sinne von Hacker News.
    Diese Kombination aus Neugier, Ausdauer und technischem Können ist äußerst selten und sehr beeindruckend.

  • Ich habe ein System auf Basis von Celeron N3350/Pentium N4200/Atom E3900, und im BIOS ist ein xDCI-Schalter sichtbar.
    Wenn man ihn aktiviert, erscheinen noch ein paar weitere Optionen, und beim Booten von Linux sieht man das PCI-Gerät USB controller: Intel Corporation Device 5aaa (rev 0b).
    Ein UDC-Device-Node taucht allerdings nicht auf. Mit den Hinweisen aus dem Originalbeitrag sollte ich da wohl noch etwas tiefer graben.