กระบวนการเปลี่ยน ThinkPad ให้เป็นอุปกรณ์ USB ที่ตั้งโปรแกรมได้

 (xairy.io)
1 คะแนน โดย GN⁺ 2024-02-24 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เมื่อเปิดใช้งาน คอนโทรลเลอร์ xDCI ที่ซ่อนอยู่ใน ThinkPad X1 Carbon 6th Gen ตัวแล็ปท็อปเองก็สามารถจำลองอุปกรณ์ USB ใดก็ได้ เช่น คีย์บอร์ดหรืออุปกรณ์เก็บข้อมูล
  • เบาะแสคือ /sys/class/usb_role/intel_xhci_usb_sw-role-switch แต่การสลับบทบาทของ xHCI เพียงอย่างเดียวยังไม่พอ และต้องมี xDCI UDC ที่อิงกับ DWC3 ถูกเปิดเผยออกมาเป็นอุปกรณ์ PCIe แยกต่างหาก
  • ในอิมเมจ BIOS มีการตั้งค่า xDCI Support อยู่ แต่ถูกซ่อนไว้จากหน้าจอ Setup UI ปกติ และหลังเปิดใช้งานแล้ว lspci จะแสดง xDCI 8086:9d30 กับไดรเวอร์ dwc3-pci
  • วิธีที่สำเร็จคือ ปลดล็อกหน้า Advanced BIOS และ แพตช์ NVRAM ส่วนการพยายามตั้งค่ารีจิสเตอร์ PCH ใหม่ทำได้แค่แก้บางส่วนของ PMC และล้มเหลวเพราะการล็อกของ PSF
  • หลังเปิด xDCI แล้ว g_mass_storage, Raw Gadget, ตัวทำซ้ำของ syzkaller และแบ็กเอนด์ Facedancer ทำงานได้โดยไม่ต้องใช้อุปกรณ์ภายนอก แต่ต้องใช้สาย USB ที่ตัด VBUS และสลับบทบาทเป็น device

เบาะแสโหมดอุปกรณ์ USB ที่พบบน ThinkPad

  • Raw Gadget เป็นโมดูลเคอร์เนลที่ให้ API ฝั่ง userspace สำหรับซับซิสเต็ม USB Gadget ของเคอร์เนล Linux และสามารถใช้ให้ descriptor USB ที่ไม่ถูกต้องเพื่อทำ fuzzing และ exploit กับ USB host ได้
  • โดยทั่วไปพีซีจะไม่มี USB Device Controller หรือ UDC ซึ่งมักฝังมาในคอมพิวเตอร์บอร์ดเดี่ยวอย่าง Raspberry Pi มากกว่า
    • งานลักษณะนี้ก่อนหน้านี้ต้องใช้อุปกรณ์ภายนอกอย่าง Raspberry Pi หรือ EC3380-AB ที่อิง USB 3380
  • บน ThinkPad X1 Carbon 6th Gen พบ intel_xhci_usb_sw-role-switch ใต้ /sys/class/usb_role
    • /sys/class/usb_role เป็นอินเทอร์เฟซสำหรับสลับองค์ประกอบ USB ฝั่งฮาร์ดแวร์ระหว่างโหมด host กับโหมด device
    • แม้จะเขียน device ลงในไฟล์ role ตอนแรกก็ยังไม่มีข้อความใน dmesg และไม่มีรายการใน /sys/class/udc/
  • xHCI คือ HCD ที่ทำให้ระบบ x86 ทำงานเป็น USB host ส่วน xDCI คือชื่อที่ Intel ใช้เรียกอินเทอร์เฟซฝั่ง USB device

โครงสร้างที่ยืนยันได้จากโค้ดเคอร์เนลและเมลลิงลิสต์

  • ในเคอร์เนล Linux พบ intel_xhci_usb_sw ได้จากสองตำแหน่ง
    • drivers/usb/roles/intel-xhci-usb-role-switch.c ใช้เป็นไดรเวอร์ USB Role Switch ที่จัดการรีจิสเตอร์ xHCI เมื่อมีการเขียน device หรือ host
    • drivers/usb/host/xhci-ext-caps.c จะสร้างอุปกรณ์ virtual platform intel_xhci_usb_sw เมื่อไดรเวอร์ xHCI ตั้ง quirk XHCI_INTEL_USB_ROLE_SW
  • PCIe device ID ของ xHCI บน ThinkPad คือ 0x9d2f ซึ่งตรงกับ PCI_DEVICE_ID_INTEL_SUNRISEPOINT_LP_XHCI ในเคอร์เนล
  • จากการพูดคุยใน Linux kernel mailing list ยืนยันว่า xHCI และ DWC3 UDC เป็นอุปกรณ์คนละตัว และมี mux คั่นอยู่ระหว่างกัน
    • role switch มีหน้าที่สลับ mux ตัวนี้
    • หาก DWC3 UDC เองไม่ปรากฏเป็นอุปกรณ์ PCI ก็แปลว่ายังไม่มี UDC ให้ใช้ในโหมด device
  • DWC3 คือ IP คอนโทรลเลอร์ Synopsys DesignWare Core SuperSpeed USB 3.0 ซึ่งผู้ผลิตหลายรายรวมถึง Intel นำไปใช้ในระบบของตน
  • เมื่อดู lspci บน ThinkPad ตอนแรกพบเพียง xHCI 8086:9d2f เท่านั้น และยังไม่เห็น device ID 0x9d30 ของ xDCI สำหรับ Sunrise Point-LP ตาม dwc3-pci.c

ร่องรอยของ xDCI ที่ยังหลงเหลือใน ACPI และ BIOS

  • ใน ACPI DSDT มี Device (XDCI) และเมธอด _STA
    • /sys/bus/acpi/devices/device:33/path คือ \\_SB_.PCI0.XDCI
    • /sys/bus/acpi/devices/device:33/status มีค่า 15 ซึ่งหมายถึงอุปกรณ์ถูกเปิดใช้งานและทำงานได้
    • แต่เพราะ lspci ไม่เห็น xDCI จึงเป็นสถานะที่ดูปกติเฉพาะจากมุมมองของ ACPI เท่านั้น
  • ในหน้าจอ BIOS Setup ปกติไม่เห็นการตั้งค่าที่เกี่ยวกับ xDCI หรือ OTG
  • ดาวน์โหลดอิมเมจอัปเดต Lenovo BIOS Bootable CD แล้วแตกไบนารี BIOS /mnt/bios/FLASH/N23ET86W/$0AN2300.FL1 จากนั้นตรวจดูด้วย UEFITool
  • เมื่อค้นหาสตริงใน PE32 image section ของโมดูล Setup พบรายการต่อไปนี้
    • xDCI Support
    • Enable/Disable xDCI (USB OTG Device).
  • หมายความว่าใน BIOS มี การตั้งค่า xDCI Support อยู่ แต่ถูกซ่อนไว้จาก UI ปกติ

เปิด xDCI ผ่านหน้า Advanced BIOS

  • ผู้เขียนลองทำตามเอกสารของโปรเจกต์ x1c6-hackintosh เพื่อเปิด หน้า Advanced BIOS ที่ถูกซ่อนอยู่
  • วิธีนี้ต้องแฟลชชิป SPI ที่เก็บ BIOS ใหม่
    • แทนที่จะใช้ SPI clip ก็เปลี่ยนชิป SPI เป็นแบบซ็อกเก็ตเพื่อถอดเสียบทดลองหลายรอบ
    • ใช้ FTDI FT2232H Mini Module และ flashrom เพื่อดัมพ์และเขียนข้อมูลกลับลงชิป SPI
  • การแพตช์ BIOS มีสองขั้นตอน
    • ใช้ UEFIPatch เปลี่ยนการอ้างอิง GUID ของหน้า BIOS Date/Time ให้ชี้ไปที่หน้า Advanced
    • ใช้ไบต์แพตช์อีกตัวเพื่อบังคับ TPM ให้เป็น MFG Mode เพื่อไม่ให้ Boot Guard ตรวจจับการแก้ไข BIOS
  • บน BIOS 1.37 หากใช้เฉพาะแพตช์แรก โน้ตบุ๊กจะร้องบี๊บและบูตไม่ขึ้น แต่หลังใช้แพตช์ที่สองด้วย หน้า Advanced ก็ปรากฏขึ้น
  • เมื่อเปลี่ยน xDCI Support ใต้ Intel Advanced Menu → PCI-IO Configuration → USB Configuration เป็น Enabled หลังบูต xDCI ก็ปรากฏขึ้น
    • lspci แสดง 00:14.1 USB controller [8086:9d30]
    • เคอร์เนลโหลดไดรเวอร์ dwc3-pci อัตโนมัติ
    • /sys/class/udc/ มี dwc3.1.auto ปรากฏขึ้น

พอร์ต xDCI และเงื่อนไขของสายเคเบิล

  • เพื่อหาพอร์ต USB ภายนอกที่ต่อกับ xDCI จึงตั้ง role เป็น device แล้วเสียบแฟลชไดรฟ์ USB เข้าทีละพอร์ตเพื่อตรวจสอบ
    • ในบางพอร์ต OS ไม่ตรวจพบแฟลชไดรฟ์ และเมื่อสลับ role กลับเป็น host ก็ใช้งานได้อีกครั้ง
    • จึงสรุปว่าพอร์ตนั้นคือพอร์ตที่เชื่อมกับ xDCI
  • เนื่องจากพอร์ต xDCI ของ ThinkPad เป็น USB Type-A การเชื่อมต่อกับคอมพิวเตอร์ host จึงต้องใช้สาย Type-A to Type-A แบบ male-to-male
  • เพราะ role switching ไม่ได้ตัดไฟ VBUS ของพอร์ต จึงต้องใช้ สายที่ตัด VBUS เพื่อไม่ให้ VBUS ของอุปกรณ์ทั้งสองต่อถึงกันโดยตรง
    • ตอนแรกทำสาย male-to-male เองโดยตัดสาย USB 2.0 สองเส้นแล้วตัด VBUS
    • ต่อมาจึงใช้ PortaPow USB Power Blocker ร่วมกับสาย USB 2.0 male-to-male
  • เมื่อโหลดไดรเวอร์ gadget g_zero อุปกรณ์ USB ทดสอบก็ถูกจำลองบนโน้ตบุ๊กอีกเครื่องได้ตามปกติ
  • ตามอัปเดตวันที่ 11 มิถุนายน 2024 สาย DataPro USB 3.0 Super-Speed A/A Debugging Cable ตัดทั้ง D- และ D+ ของ USB 2.0 ด้วย ทำให้การเชื่อมต่อ High-Speed ที่จำเป็นต่อการตั้งลิงก์ SuperSpeed ล้มเหลว
    • ส่วนสาย LogiLink CU0038 ที่ตัด VBUS เองด้วยมือ ใช้จำลองอุปกรณ์ SuperSpeed ได้

ความพยายามเปิดใช้งานด้วยซอฟต์แวร์ผ่านรีจิสเตอร์ PCH

  • เพื่อดูว่า BIOS เปิด xDCI อย่างไร ผู้เขียนตรวจดู Pch/Library/Private/PeiPchInitLib/PchXdci.c ในซอร์ส BIOS ของ Kaby Lake
  • เส้นทางปิดใช้งาน xDCI ใน BIOS มีโครงสร้างเป็นการปิด xDCI ทั้งใน PMC และ PSF

  • การแก้ไข PMC

    • คาดว่าการล้างบิต #24 XDCI Function Disable ของรีจิสเตอร์ NST_PG_FDIS_1 ที่ offset 0x628 ใน PMC จะยกเลิกการตัดไฟของ xDCI ได้
    • จึงเขียนโมดูลเคอร์เนลที่นำ mapping ของ pmc_core_device และ pmc->regbase จากเคอร์เนล Linux มาใช้ซ้ำ
    • ทันทีหลังบูต บิต #31 ST_FDIS_LK ของ ST_PG_FDIS1 ถูกตั้งไว้ ทำให้ไม่สามารถเปลี่ยนค่า NST_PG_FDIS_1 ได้
    • แต่หลังสั่ง suspend แล้วปลุกเครื่อง บิตล็อกไม่ถูกตั้งไว้ และสามารถล้างบิต XDCI Function Disable ได้สำเร็จ

  • การแก้ไข PSF

    • BIOS ปิด xDCI โดยตั้งบิต USB Dual Role (OTG) Function Disable ใน PSF2 PCR ของ PID_PSF2 Port ID 0xBB
    • ที่อยู่ PCR คำนวณจาก PCH_PCR_BASE_ADDRESS 0xFD000000 ร่วมกับ Port ID และ offset
    • แม้จะ map PSF2 PCR ในโมดูลเคอร์เนลด้วย ioremap แต่ค่าที่อ่านได้เป็น 0xffffffff และไม่เปลี่ยนแปลง
    • แม้ unhide P2SB แล้วก็ได้ผลเหมือนเดิม
    • เนื่องจาก RemoveSidebandAccess ใน BIOS ใช้ EPMASK5 ตัด PID_PSF2 ออกจาก IOSF-SB และล็อกด้วย MASKLOCK ทำให้ OS ไม่สามารถตั้งค่า PSF ใหม่ได้
    • สรุปคือการเข้าถึง PCH แม้จะแก้บางส่วนของ PMC ได้ แต่ล้มเหลวในการตั้งค่า PSF ใหม่ จึงไม่ใช่วิธีเปิด xDCI ที่ใช้ได้จริง

เปิดใช้งานผ่านการแพตช์ NVRAM โดยไม่ต้องเลี่ยง Boot Guard

  • เนื่องจากค่าการตั้งค่า BIOS ถูกเก็บใน พื้นที่ NVRAM ของชิป SPI ผู้เขียนจึงลองเปลี่ยนเฉพาะค่า xDCI Support โดยไม่ต้องเปิดหน้า Advanced ที่ซ่อนอยู่
  • ใช้ IFRExtractor-RS ดึงข้อมูล UEFI IFR ของโมดูล Setup
  • พบว่าการตั้งค่า xDCI Support ถูกเก็บอยู่ในตัวแปร UEFI PchSetup
    • VarStore GUID: 4570B7F1-ADE8-4943-8DC3-406472842384
    • VarStoreId: 0x5
    • VarOffset: 0x40
    • ช่วงค่า: 0x0 หรือ 0x1
  • ตรวจสอบ /sys/firmware/efi/efivars/PchSetup-4570b7f1-ade8-4943-8dc3-406472842384 ใน efivarfs ของ Linux
    • 4 ไบต์แรกของไฟล์ efivarfs เป็นเฮดเดอร์ ดังนั้นค่าจริงของ xDCI Support จึงอยู่ที่ offset 0x44
    • เมื่อ xDCI ถูกปิด ค่าเป็น 00 และหลังเปิดผ่านหน้า BIOS Advanced แล้วจะเปลี่ยนเป็น 01
  • แต่เมื่อพยายามเขียนค่าลงตัวแปรนี้โดยตรงจาก userspace หรือ EFI Shell กลับเจอข้อผิดพลาด EFI_WRITE_PROTECTED
    • แม้ลบคุณสมบัติ immutable ของ efivarfs แล้วก็ยังเจอ Read-only file system
    • การแก้จาก EFI Shell ด้วย chipsec ก็เจอข้อผิดพลาดเดียวกัน
  • เมื่อตามหาลำดับไบต์รอบ PchSetup ในอิมเมจ BIOS ต้นฉบับที่อ่านด้วย SPI programmer แล้วแพตช์เฉพาะบิต xDCI Support เป็น 01 จากนั้นแฟลชกลับ xDCI ก็ถูกเปิดใช้งานสำเร็จ
  • วิธีนี้ยังต้องแฟลชชิป SPI ใหม่อยู่ แต่ไม่ต้องแพตช์หน้า Advanced หรือเลี่ยง Boot Guard และไม่ทำให้ TPM พัง
  • บน BIOS 1.37 หลังแพตช์ NVRAM แล้วอัปเดตเป็น 1.61 ค่าการตั้งค่า BIOS ยังคงอยู่ จึงไม่ต้องแพตช์ซ้ำ

การจำลองอุปกรณ์ USB ด้วย xDCI

  • ตัวอย่างทั้งหมดตั้งอยู่บนสมมติฐานว่าเปิด xDCI จาก BIOS แล้ว, intel_xhci_usb_sw-role-switch ถูกสลับเป็น device แล้ว และเชื่อมต่อพอร์ต xDCI กับ USB host ด้วยสายที่ตัด VBUS

  • Legacy gadget drivers

    • legacy gadget drivers ของซับซิสเต็ม Linux USB Gadget จะจำลองอุปกรณ์ USB ตามคลาสที่กำหนดทันทีเมื่อโหลดโมดูล
    • g_mass_storage จะเปิดเผยอิมเมจไฟล์ระบบเป็นอุปกรณ์ USB mass storage
    • สร้างอิมเมจ FAT disk.img ใส่ Hi from xDCI ลงใน file.txt แล้วโหลดด้วย sudo modprobe g_mass_storage file=./disk.img stall=0
    • ฝั่ง USB host จะเมานต์ไดรฟ์โดยอัตโนมัติและอ่านเนื้อหาไฟล์ได้

  • Raw Gadget

    • ทดลองใช้ Raw Gadget ร่วมกับ xDCI เพื่อรันตัวอย่างคีย์บอร์ด USB
    • ตอนแรกการทำงานค้างอยู่ระหว่างจัดการ SET_CONFIGURATION
    • สาเหตุคือ dwc3 และไดรเวอร์ UDC บางตัวสมมติว่าสามารถตอบรับ control request แบบความยาว 0 ได้ทันทีโดยไม่ต้องรอให้ gadget driver ตรวจสอบ
    • หลังใช้ workaround patch กับ Raw Gadget และ แก้ไข GadgetFS ด้วย การจำลองคีย์บอร์ดก็สำเร็จ
    • พฤติกรรมที่เกี่ยวข้องถูกสรุปไว้ในเอกสารแพตช์ commit

การใช้งานร่วมกับ syzkaller และ Facedancer

  • syzkaller สามารถใช้ Raw Gadget เพื่อทำ fuzzing ภายนอกกับ USB stack ของเคอร์เนล Linux ได้
  • การ fuzzing USB แบบปกติของ syzkaller ใช้ Dummy HCD/UDC ที่เชื่อม virtual USB Device กับ Host controller ภายในเคอร์เนล
  • เพื่อใช้ xDCI ผู้เขียนแก้โค้ดระบุ UDC ของ syzkaller จาก dummy_udc เป็น dwc3-gadget, dwc3.1.auto
  • จากนั้นรัน reproducer ของบั๊ก WARNING in smsusb_start_streaming/usb_submit_urb ที่ syzkaller พบด้วย syz-execprog -enable=usb
    • บนโน้ตบุ๊กที่ใช้เคอร์เนล Ubuntu 5.15.0-91-generic เป็น host สามารถทำให้คำเตือน usb_submit_urb เกิดซ้ำได้
    • บั๊กนี้เป็น WARNING ที่เกิดจากไดรเวอร์ smsusb ไม่ตรวจสอบชนิดของ USB endpoint และไม่ได้ก่อให้เกิดพฤติกรรมอันตราย
  • Facedancer เป็นเฟรมเวิร์กจำลองอุปกรณ์ USB ที่เขียนด้วย Python
    • Facedancer backend ที่อิง Raw Gadget ยังอยู่ในระดับ prototype และพึ่งพาแพตช์ Raw Gadget ที่อยู่นอก tree หลัก
    • เมื่อตั้งค่า BACKEND=rawgadget, RG_UDC_DRIVER=dwc3-gadget, RG_UDC_DEVICE=dwc3.1.auto แล้วรันตัวอย่าง rubber-ducky.py ก็ทำงานได้ปกติ
  • USB Proxy ที่อิง Raw Gadget ก็ทำงานร่วมกับ xDCI ได้เช่นกัน และทำให้สามารถใช้โน้ตบุ๊กเป็น USB sniffer หรือเครื่องมือ USB Man-in-the-Middle ได้

ความเป็นไปได้กับอุปกรณ์อื่นและแนวทางแบบซอฟต์แวร์

  • นอกจาก ThinkPad X1 Carbon 6th Gen แล้ว พีซีรุ่นอื่นก็อาจเปิดใช้งาน xDCI ได้เช่นกัน
    • กรณีที่ง่ายที่สุดคือ BIOS มีตัวเลือกให้เปิด xDCI อยู่แล้ว
    • แต่ต้องมีทั้งการรองรับ ACPI และ role switching และพอร์ต xDCI ต้องถูกเดินสายไปยังพอร์ตภายนอก
  • ThinkPad รุ่นอื่นก็อาจซ่อนและป้องกันการตั้งค่า xDCI ใน BIOS เช่นกัน จึงอาจยังต้องแฟลชชิป SPI ใหม่
    • วิธีแบบ NVRAM สามารถใช้ได้โดยไม่ต้องเลี่ยง Boot Guard
    • ชิป SPI ของบางระบบรุ่นใหม่อาจป้องกันการแฟลชใหม่ด้วย RPMC โดยชิปเหล่านี้อาจมีตัวอักษร R ในชื่อ เช่น W25R128FW
  • ตามข้อมูลอัปเดต Shiny Quagsire เคยเปิดใช้งาน xDCI บน XPS 13 และ Surface Go 1 โดยแก้ตัวแปร PchSetup ผ่าน grub-mod-setup_var
    • บนอุปกรณ์เหล่านั้นตัวแปร PchSetup ไม่ได้ถูกป้องกัน จึงทำได้ด้วยซอฟต์แวร์ล้วน
  • แนวทางซอฟต์แวร์อื่น ๆ อาจรวมถึงการใช้ช่องโหว่ BIOS เพื่อเปลี่ยนตัวแปร NVRAM ที่เกี่ยวกับ xDCI หรือโจมตี BIOS ผ่าน DMA ระหว่างบูตเพื่อรันโค้ดตามต้องการ
  • คำว่า “secret” ในชื่อเรื่องใกล้เคียงกับการสื่อถึงความสามารถที่ไม่ได้มีเอกสารอธิบาย มากกว่าจะหมายถึงการซ่อนโดยตั้งใจ

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-02-24
ความคิดเห็นจาก Hacker News

  • สงสัยมาตลอดว่าทำไมฟีเจอร์ที่ใช้แล็ปท็อปเป็น คีย์บอร์ดและจอมอนิเตอร์อเนกประสงค์ สำหรับคอมพิวเตอร์เครื่องอื่นถึงไม่ค่อยมีให้เห็น
    การซื้อคีย์บอร์ดกับจอใหม่เพื่อดูแลเครื่องแบบ headless มันดูแปลก เพราะแล็ปท็อปที่มีอยู่แล้วก็ทำหน้าที่นั้นได้

    • GPD Pocket 3 มีโมดูล KVM ที่ทำสิ่งนี้ได้ตรงตัว: รับอินพุต HDMI และ USB-C แล้วทำงานเหมือนจอแสดงผล·คีย์บอร์ด·เมาส์ของเครื่องที่เชื่อมต่ออยู่: https://gpd.hk/gpdpocket3
      แท็บเล็ต Minisforum V3 ที่กำลังจะออกมาก็มีอินพุตวิดีโอ จึงใช้เป็นจอภายนอกได้ แต่ดูเหมือนว่าจะไม่แชร์คีย์บอร์ดกับเมาส์ด้วย
      ถ้าฟีเจอร์แบบนี้แพร่หลายกว่านี้คงดีมาก
    • ใช่เลย เพื่อนผมสร้าง ไซเบอร์เด็ก ขึ้นมาเพื่อสิ่งนี้โดยเฉพาะ
      สามารถสลับเมาส์และคีย์บอร์ดไปยังพอร์ตภายนอกเพื่อเชื่อมต่อกับเครื่องอื่นด้วยสายได้ และด้านข้างมีพอร์ต HDMI สองพอร์ต พอร์ตหนึ่งเป็นเอาต์พุต อีกพอร์ตเป็นอินพุต
      ใช้สวิตช์ภายในเลือกได้ว่าจะใช้เครื่องของเด็คนั้นเองหรืออินพุตภายนอกเป็นแหล่งสัญญาณของจอ
    • ในฐานะคนที่ต้องจัดการเครื่อง headless บ่อย ๆ ทางออกที่ดีที่สุดสำหรับใช้แล็ปท็อปเป็นจอมอนิเตอร์คือผลิตภัณฑ์นี้: https://www.amazon.com/dp/B0BJ2YDV7Q
      โดยพื้นฐานคือชิปที่ แคปเจอร์สัญญาณ HDMI ของเครื่อง headless แล้วเผยแพร่ผ่าน USB ให้แล็ปท็อปเห็นเป็นเว็บแคมที่จำลองขึ้นมา และชิ้นส่วนอิเล็กทรอนิกส์ก็เล็กพอจะใส่อยู่ในสายได้
      ส่วนคีย์บอร์ด ผมยังไม่เจอทางออกที่ดีนอกจากซื้อคีย์บอร์ดไร้สายมาตรฐาน และแบบมีแทร็กแพดในตัวเผื่อเวลาที่ต้องใช้เมาส์บ้างเป็นครั้งคราว
    • รู้สึกไม่สะดวกมาตลอดที่เราไม่สามารถต่อคอมพิวเตอร์เครื่องหนึ่งเข้ากับอีกเครื่องได้แบบตรง ๆ
      ได้ยินมาว่า USB 4 มีโหมดที่ทำให้ทำแบบนี้ได้
    • ใช้ hidclient แล้วแล็ปท็อปสามารถแกล้งทำตัวเป็นคีย์บอร์ดและเมาส์บลูทูธได้
      https://web.archive.org/web/20180610141436/http://anselm.hoffmeister.be/computer/hidclient/index.html.en
      https://github.com/benizi/hidclient

  • นึกถึงกรณีหนึ่งที่จำได้ว่า Travis Goodspeed เคยทำไว้เมื่อหลายปีก่อน
    สมาร์ตทีวีรับอัปเดตเฟิร์มแวร์จากไฟล์ในแฟลชไดรฟ์ USB ทั่วไป และทีวีจะอ่านไฟล์ตั้งแต่ต้นจนจบเพื่อตรวจสอบลายเซ็นดิจิทัล จากนั้นอ่านอีกครั้งเพื่อทำการอัปเดต
    ถ้าเป็นอุปกรณ์ที่แกล้งทำตัวเป็นสตอเรจ USB ก็สามารถส่งไฟล์เฟิร์มแวร์ของผู้ผลิตในการอ่านครั้งแรก แล้วส่งเฟิร์มแวร์ไม่เป็นทางการในการอ่านครั้งที่สองได้

    • เยี่ยม ข้อผิดพลาดประเภทนี้มีตัวย่อเท่ ๆ ว่า TOCTOU (Time of Check to Time of Use) และพบได้ในหลายที่จนน่าประหลาดใจ
      https://en.m.wikipedia.org/wiki/Time-of-check_to_time-of-use

  • น่าสนใจมาก ผมเคยสำรวจตัวเลือกที่ทำได้จริงในแนวคล้ายกันมาแล้ว
    ผมมี เซิร์ฟเวอร์ NAS ทรงพลังที่พยายามหาเหตุผลมาใช้งานอยู่เรื่อย ๆ และในบ้านก็ต่อเครือข่าย 40G กับ 10G ไว้หลายจุด
    PS5 กับ XBox ใช้ฮาร์ดดิสก์ USB เป็นพื้นที่เก็บข้อมูลเพิ่มเติม
    พอลองดูว่าสามารถเปิดพื้นที่เก็บข้อมูลของ NAS ให้ PS5 กับ XBox เห็นได้ไหม ก็พบว่าทำได้ โดยเมานต์แชร์ของ NAS ผ่าน iSCSI หรือ NFS แล้วใช้โมดูล g_mass_storage จำลองอุปกรณ์เก็บข้อมูล USB เพื่อเผยแพร่พื้นที่นั้นให้ USB host เห็น
    ตอนนี้อุปสรรคใหญ่ นอกจากเวลาและค่าใช้จ่ายแล้ว คือแบนด์วิดท์ที่ระบบแบบนี้จะให้ได้ การอัปเกรดไม่ได้เพิ่มขึ้นมากนัก
    Raspberry Pi ขึ้นชื่อว่ารองรับ USB-OTG แต่ก็หยุดอยู่ที่ความเร็ว USB 2.0 และ SBC รุ่นใกล้เคียงที่ค้นดูก็ส่วนใหญ่เป็นแบบเดียวกัน ข้อยกเว้นคือ RockPi4 และ RockPi มีพอร์ตอีเทอร์เน็ตกิกะบิต ดังนั้นถ้าใช้อีเทอร์เน็ตได้เต็ม ก็จะให้ความเร็วระดับ HDD ที่เสถียรกับทั้ง PS5 และ Xbox ได้
    ถ้าสร้าง โซลูชันที่เกิน 1GbE ได้ ด้วยการเสียบการ์ดเครือข่าย PCIe แบบคัสตอมหรือการ์ด Express ก็น่าจะน่าสนใจทีเดียว เพราะจะทำให้อินเทอร์เฟซ USB 3.0 อิ่มตัวได้จริง

    • ผมมีโฮมแล็บคล้าย ๆ กัน และกำลังทดลอง USB over IP ด้วย https://www.virtualhere.com อยู่
      ถึงจะต้องมีไคลเอนต์ที่สื่อสารกับเซิร์ฟเวอร์ แต่ดูเหมือนจะทำงานได้ค่อนข้างดี
      กำลังคิดถึงการวาง “USB client แบบบาง” ไว้บนโต๊ะ แล้วต่ออุปกรณ์ USB เข้ากับมัน จากนั้นเชื่อมหรือสลับไปยังโฮสต์จริงหรือโฮสต์ VM ที่ต้องการในแล็บ
    • สงสัยว่า PS5 กับ NAS เชื่อมต่อกันทางกายภาพอย่างไร
      เดาว่า NAS → SBC → PS5 หรือไม่ก็เอา NAS ต่อเข้ากับ PS5 โดยตรงด้วยสาย USB?
      ยังสงสัยด้วยว่าการเล่นคอนเทนต์บน PS5 เป็นอย่างไร เห็นว่า NVMe ภายในต้องผ่านความเร็วระดับหนึ่ง แล้วข้อกำหนดนี้ไม่ใช้กับไดรฟ์ภายนอกหรือ?
    • Raspberry Pi 5 มีพอร์ตอีเทอร์เน็ตกิกะบิต และ SBC อื่น ๆ อย่างตระกูล NanoPi ของ FriendlyElec ก็เช่นกัน
      ที่จริง NanoPi R6S มี พอร์ตอีเทอร์เน็ต 2.5G สองพอร์ต นอกเหนือจากพอร์ต 1 กิกะบิตด้วย

  • ขอบคุณสำหรับบทความที่ละเอียดมาก คุณภาพดี
    การที่สิ่งนี้ทำได้จริงทำให้มีความหวังว่า อาจทำชุดคล้าย Synergy / Mouse Without Borders แบบไม่ต้องใช้เครือข่ายได้ด้วยสาย USB ที่ดัดแปลงเท่านั้น
    สำหรับคนที่ต้องควบคุมคอมพิวเตอร์หลายเครื่องพร้อมกัน นี่เป็นทิศทางที่ดีมาก

    • มี KVM switch อยู่แล้ว และก็มีอุปกรณ์ที่สลับเฉพาะคีย์บอร์ด·เมาส์ USB โดยไม่มีวิดีโอด้วย
      ถึงอย่างนั้น วิธีที่เสนอมาก็ฟังดูน่าสนใจ

  • เมื่อเร็ว ๆ นี้ผมลองหาข้อมูลเรื่องคล้าย ๆ กัน เพราะอยากเชื่อมต่อเครื่อง USB-C สองเครื่องด้วยสาย USB-C เส้นเดียวเพื่อสื่อสารกันที่ 10Gbps
    น่าเสียดายที่บอร์ด Ryzen ส่วนใหญ่ยังไม่มี Thunderbolt และถ้าเป็น Thunderbolt ก็จะรองรับสิ่งนี้แบบเนทีฟได้ง่าย ๆ
    คอนโทรลเลอร์ USB แบบ “dual-role” ก็ยังค่อนข้างหายากจนก่อน USB 3.2/4.0 และแม้จะทำได้อย่างที่บทความนี้พูดถึง ก็มักไม่ได้รับการรองรับ
    รู้สึกแปลกมากที่การเอาเครื่องสองเครื่องมาต่อเป็นเครือข่ายกันผ่านสาย USB-C โดยไม่มี Thunderbolt นั้นยากขนาดนี้
    ส่วนที่บิตล็อกถูกปลดหลังจาก suspend ก็ชอบเหมือนกัน ปัญหาแบบนี้พบได้บ่อยจริง ๆ เช่น เป็นวิธีที่เจอบ่อยมากเวลาทำให้อุปกรณ์ SATA หลุดจากสถานะที่ขัดขวางการ secure erase

  • ระดับความลึกน่าประทับใจมาก
    ถ้าใช้พีซีเป็น อุปกรณ์ USB ได้ ก็จะเปิดความเป็นไปได้น่าสนุกขึ้นมาอีกมาก
    น่าเสียดายนิดหน่อยที่ตัวเลือก xDCI ที่จำเป็นมีอยู่ในฮาร์ดแวร์ของอุปกรณ์นี้ แต่ไม่ได้ถูกเปิดให้เห็น และถ้าจะเข้าถึงก็ต้องแฮ็กเฟิร์มแวร์
    สรุปคือฮาร์ดแวร์ทำได้ แต่ผู้ผลิตแค่ปิดไว้และล็อกฟังก์ชันควบคุมเอาไว้

  • สงสัยว่า Lenovo ใช้ช่องทางนี้เพื่อดีบัก ThinkPad อีกเครื่องด้วย ThinkPad เครื่องหนึ่งหรือเปล่า
    https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/secure-coding/intel-debug-technology.html
    อัปเดต: น่าจะใช่
    https://www.youtube.com/watch?v=ExUvQa_jB7c
    เป็นวิดีโอเกี่ยวกับการดีบัก Intel Firmware ด้วย DCI และ USB 3.0

  • ส่วนที่ว่า “แต่การจัดการ Raspberry Pi นั้นยุ่งยาก: ต่อสาย, บูตบอร์ด, เข้าเชลล์ ฯลฯ” น่าจะตั้งค่า USB OTG ก็พอแล้ว
    น่าจะทำให้รับไฟจากอุปกรณ์ที่เสียบอยู่ เปิดเชลล์ แล้วจัดการด้วยสคริปต์ได้
    จากนั้นก็น่าจะตั้งค่าเมานต์หรือรันคำสั่งผ่าน SSH และอาจถึงขั้นเมานต์อุปกรณ์ได้ด้วย
    ถึงอย่างนั้นก็ยังสนับสนุนความพยายามที่จะทำความเข้าใจอุปกรณ์ของตัวเองและลองอ่านเคอร์เนลอยู่ดี เป็นสิ่งที่อยากทำให้ดีขึ้นเรื่อย ๆ และให้ความรู้สึกว่าอุปกรณ์ของเรา เราก็ควรซ่อมเอง

    • แก่นของการทดลองนี้เองคือการจัดการ USB OTG และ Pi มีพอร์ต OTG แค่พอร์ตเดียว ถ้าจะเชื่อมต่อจึงต้องใช้วิธีอื่น
      ลองทำเองแล้ว

  • ทำให้นึกถึง วัฒนธรรมแฮ็กเกอร์ ยุคอินเทอร์เน็ตตอนต้นอย่างแรง จนชวนให้คิดถึงอดีต เป็นบทความที่ยอดเยี่ยมจริง ๆ
    คนแบบนี้แหละคือสิ่งที่ ESR พูดถึงเวลาเขาพูดเรื่องการเป็นแฮ็กเกอร์ หรือแฮ็กเกอร์ในความหมายของ Hacker News
    การผสมผสานระหว่างความอยากรู้อยากเห็น ความพากเพียร และทักษะทางเทคนิคแบบนี้พบได้ยากมาก และน่าประทับใจอย่างยิ่ง

  • ผมมีระบบที่ใช้ Celeron N3350/Pentium N4200/Atom E3900 อยู่ และใน BIOS มี สวิตช์ xDCI โผล่มาให้เห็น
    พอเปิดใช้ ก็มีตัวเลือกอื่น ๆ เพิ่มขึ้นมาอีกสองสามอย่าง และเมื่อบูตเข้า Linux จะเห็นอุปกรณ์ PCI USB controller: Intel Corporation Device 5aaa (rev 0b)
    แต่โหนดอุปกรณ์ UDC ไม่ปรากฏขึ้นมา คงต้องลองขุดต่อโดยอาศัยเบาะแสจากต้นฉบับดู