Proses mengubah ThinkPad menjadi perangkat USB yang dapat diprogram

 (xairy.io)
1 poin oleh GN⁺ 2024-02-24 | 1 komentar | Bagikan ke WhatsApp
  • Setelah mengaktifkan pengontrol xDCI tersembunyi pada ThinkPad X1 Carbon Gen 6, laptop itu sendiri bisa meniru perangkat USB arbitrer seperti keyboard atau perangkat penyimpanan
  • Petunjuknya adalah /sys/class/usb_role/intel_xhci_usb_sw-role-switch, tetapi pergantian peran xHCI saja tidak cukup; UDC xDCI berbasis DWC3 yang terpisah juga harus diekspos sebagai perangkat PCIe
  • Di dalam image BIOS ada pengaturan xDCI Support, tetapi tersembunyi dari UI Setup bawaan; setelah diaktifkan, lspci menampilkan xDCI 8086:9d30 dan driver dwc3-pci
  • Metode yang berhasil adalah membuka kunci halaman Advanced BIOS dan patch NVRAM; rekonfigurasi register PCH hanya sempat mengubah sebagian PMC dan gagal karena penguncian PSF
  • Setelah xDCI diaktifkan, g_mass_storage, Raw Gadget, reproducer syzkaller, dan backend Facedancer dapat berjalan tanpa perangkat keras eksternal, tetapi membutuhkan kabel USB dengan VBUS terputus dan pergantian peran ke device

Petunjuk mode perangkat USB yang ditemukan di ThinkPad

  • Raw Gadget adalah modul kernel yang menyediakan API ruang pengguna untuk subsistem USB Gadget kernel Linux, dan dapat dimanfaatkan untuk fuzzing serta eksploit host USB dengan memberikan deskriptor USB yang tidak valid
  • PC biasa umumnya tidak memiliki USB Device Controller, yaitu UDC, dan komponen ini lebih sering tertanam pada komputer papan tunggal seperti Raspberry Pi
    • Pekerjaan sebelumnya memerlukan perangkat keras eksternal seperti Raspberry Pi atau EC3380-AB berbasis USB 3380
  • Pada ThinkPad X1 Carbon Gen 6 ditemukan intel_xhci_usb_sw-role-switch di bawah /sys/class/usb_role
    • /sys/class/usb_role adalah antarmuka untuk mengalihkan komponen USB perangkat keras antara mode host dan mode device
    • Bahkan setelah menulis device ke berkas role, awalnya tidak muncul pesan dmesg maupun entri /sys/class/udc/
  • xHCI adalah HCD yang membuat sistem x86 bekerja sebagai host USB, sedangkan xDCI adalah nama yang digunakan Intel untuk antarmuka sisi perangkat USB

Struktur yang dipastikan lewat kode kernel dan mailing list

  • Di kernel Linux, intel_xhci_usb_sw ditemukan di dua lokasi
    • drivers/usb/roles/intel-xhci-usb-role-switch.c mengimplementasikan driver USB Role Switch yang memanipulasi register xHCI saat device atau host ditulis
    • drivers/usb/host/xhci-ext-caps.c membuat perangkat platform virtual intel_xhci_usb_sw bila driver xHCI menetapkan quirk XHCI_INTEL_USB_ROLE_SW
  • ID perangkat PCIe xHCI pada ThinkPad adalah 0x9d2f, cocok dengan PCI_DEVICE_ID_INTEL_SUNRISEPOINT_LP_XHCI di kernel
  • Dari diskusi di mailing list kernel Linux dipastikan bahwa xHCI dan DWC3 UDC adalah perangkat terpisah, dengan mux di antaranya
    • Role switch bertugas mengganti mux tersebut
    • Jika DWC3 UDC sendiri tidak terlihat sebagai perangkat PCI, maka tidak ada UDC yang bisa dipakai untuk mode device
  • DWC3 adalah IP Synopsys DesignWare Core SuperSpeed USB 3.0 Controller, yang dipakai berbagai vendor termasuk Intel
  • Saat memeriksa lspci di ThinkPad, awalnya hanya terlihat xHCI 8086:9d2f, dan ID perangkat xDCI Sunrise Point-LP 0x9d30 menurut dwc3-pci.c tidak muncul

Jejak xDCI yang tersisa di ACPI dan BIOS

  • Di ACPI DSDT terdapat Device (XDCI) dan metode _STA
    • /sys/bus/acpi/devices/device:33/path adalah \\_SB_.PCI0.XDCI
    • /sys/bus/acpi/devices/device:33/status bernilai 15, yang berarti perangkat dalam keadaan enabled and functioning
    • Namun karena lspci tidak menampilkan xDCI, dari sudut pandang ACPI perangkat itu tampak normal saja
  • Pada layar BIOS Setup bawaan tidak terlihat pengaturan terkait xDCI atau OTG
  • Image pembaruan Lenovo BIOS Bootable CD diunduh, lalu biner BIOS /mnt/bios/FLASH/N23ET86W/$0AN2300.FL1 diekstrak dan diperiksa dengan UEFITool
  • Saat mencari string di PE32 image section modul Setup, muncul item berikut
    • xDCI Support
    • Enable/Disable xDCI (USB OTG Device).
  • Jadi, di dalam BIOS memang ada pengaturan xDCI Support, tetapi tersembunyi dari UI bawaan

Mengaktifkan xDCI lewat halaman Advanced BIOS

  • Mengikuti dokumentasi proyek x1c6-hackintosh, dicoba metode untuk membuka halaman Advanced BIOS yang tersembunyi
  • Metode ini mengharuskan chip SPI tempat BIOS disimpan untuk di-flash ulang
    • Alih-alih memakai klip SPI, chip SPI diganti dengan soket agar eksperimen bongkar-pasang chip bisa dilakukan berulang kali
    • Isi chip SPI di-dump dan ditulis ulang memakai FTDI FT2232H Mini Module serta flashrom
  • Patch BIOS terdiri dari dua tahap
    • Dengan UEFIPatch, referensi GUID halaman BIOS Date/Time dialihkan ke halaman Advanced
    • Patch byte terpisah memaksa TPM ke MFG Mode agar Boot Guard tidak mendeteksi modifikasi BIOS
  • Pada BIOS 1.37, jika hanya patch pertama yang diterapkan laptop akan berbunyi bip dan gagal boot; setelah patch kedua juga diterapkan, halaman Advanced muncul
  • Saat xDCI Support di bawah Intel Advanced Menu → PCI-IO Configuration → USB Configuration diubah menjadi Enabled, xDCI muncul setelah boot
    • lspci menampilkan 00:14.1 USB controller [8086:9d30]
    • Kernel otomatis memuat driver dwc3-pci
    • /sys/class/udc/ berisi dwc3.1.auto

Kondisi port dan kabel untuk xDCI

  • Untuk mencari port USB eksternal yang terhubung ke xDCI, role dibiarkan pada device lalu USB flash drive dipasang ke tiap port satu per satu
    • Pada port tertentu, OS tidak mendeteksi flash drive, tetapi kembali berfungsi setelah role dikembalikan ke host
    • Port itu dianggap sebagai port yang terhubung ke xDCI
  • Karena port xDCI pada ThinkPad bertipe USB Type-A, dibutuhkan kabel Type-A ke Type-A male-to-male untuk menghubungkannya ke komputer host
  • Karena role switching tidak mematikan catu daya port VBUS, digunakan kabel dengan VBUS terputus agar VBUS dari dua perangkat tidak tersambung langsung
    • Awalnya dibuat sendiri kabel male-to-male dari dua kabel USB 2.0 yang dipotong dengan VBUS diputus
    • Setelah itu dipakai PortaPow USB Power Blocker dan kabel USB 2.0 male-to-male
  • Ketika driver gadget g_zero dimuat, perangkat USB uji berhasil diemulasikan dengan normal di laptop lain
  • Menurut pembaruan per 11 Juni 2024, DataPro USB 3.0 Super-Speed A/A Debugging Cable juga memutus jalur USB 2.0 D- dan D+, sehingga koneksi High-Speed yang dibutuhkan untuk membangun koneksi SuperSpeed gagal
    • Kabel LogiLink CU0038 yang VBUS-nya diputus secara manual bekerja untuk emulasi perangkat SuperSpeed

Mencoba aktivasi perangkat lunak lewat register PCH

  • Untuk memahami bagaimana BIOS mengaktifkan xDCI, diperiksa Pch/Library/Private/PeiPchInitLib/PchXdci.c dari kode sumber BIOS Kaby Lake
  • Jalur penonaktifan xDCI di BIOS tersusun dengan menonaktifkan xDCI di PMC dan PSF

  • Perubahan PMC

    • Diperkirakan bahwa membersihkan bit #24 XDCI Function Disable pada register NST_PG_FDIS_1 PMC offset 0x628 akan melepaskan pemutusan daya xDCI
    • Dibuat modul kernel yang memanfaatkan kembali pemetaan pmc_core_device dan pmc->regbase dari kernel Linux
    • Tepat setelah boot, bit ST_FDIS_LK #31 pada ST_PG_FDIS1 sudah tersetel sehingga nilai NST_PG_FDIS_1 tidak bisa diubah
    • Setelah laptop disuspend lalu dibangunkan kembali, lock bit tidak lagi tersetel, dan bit XDCI Function Disable berhasil dibersihkan

  • Perubahan PSF

    • BIOS menonaktifkan xDCI dengan menyetel bit USB Dual Role (OTG) Function Disable pada PSF2 PCR milik PID_PSF2 Port ID 0xBB
    • Alamat PCR dihitung dari kombinasi PCH_PCR_BASE_ADDRESS 0xFD000000, Port ID, dan offset
    • Di modul kernel, PSF2 PCR dipetakan dengan ioremap, tetapi hasil baca tetap 0xffffffff dan tidak berubah
    • Hasilnya tetap sama meski P2SB di-unhide
    • RemoveSidebandAccess di BIOS memisahkan PID_PSF2 dari IOSF-SB lewat EPMASK5 dan menguncinya dengan MASKLOCK, sehingga OS tidak bisa mengonfigurasi ulang PSF
    • Akses PCH hanya berhasil untuk sebagian pengaturan PMC, tetapi gagal sebagai metode aktivasi xDCI karena rekonfigurasi PSF tidak berhasil

Mengaktifkan lewat patch NVRAM tanpa bypass Boot Guard

  • Karena nilai konfigurasi BIOS disimpan di area NVRAM chip SPI, dicoba metode untuk hanya mengubah nilai xDCI Support tanpa membuka halaman Advanced yang tersembunyi
  • Informasi UEFI IFR dari modul Setup diekstrak dengan IFRExtractor-RS
  • Pengaturan xDCI Support tersimpan di variabel UEFI PchSetup
    • VarStore GUID: 4570B7F1-ADE8-4943-8DC3-406472842384
    • VarStoreId: 0x5
    • VarOffset: 0x40
    • Rentang nilai: 0x0 atau 0x1
  • Di efivarfs Linux diperiksa /sys/firmware/efi/efivars/PchSetup-4570b7f1-ade8-4943-8dc3-406472842384
    • Karena 4 byte pertama berkas efivarfs adalah header, nilai xDCI Support yang sebenarnya berada pada offset berkas 0x44
    • Saat xDCI nonaktif nilainya 00, dan setelah diaktifkan dari halaman Advanced BIOS nilainya berubah menjadi 01
  • Saat mencoba menulis variabel itu langsung dari ruang pengguna atau EFI Shell, muncul galat EFI_WRITE_PROTECTED
    • Bahkan setelah atribut immutable di efivarfs dihapus, tetap muncul galat Read-only file system
    • Mengubahnya dari EFI Shell dengan chipsec juga menghasilkan galat yang sama
  • Setelah urutan byte di sekitar PchSetup ditemukan pada image BIOS asli yang dibaca dengan programmer SPI, hanya bit xDCI Support yang di-patch menjadi 01 lalu BIOS di-flash ulang, xDCI pun aktif
  • Metode ini masih memerlukan reflashing chip SPI, tetapi tidak membutuhkan patch halaman Advanced maupun bypass Boot Guard, dan TPM juga tidak rusak
  • Pada BIOS 1.37, setelah NVRAM di-patch lalu diperbarui ke 1.61, nilai konfigurasi BIOS tetap dipertahankan sehingga patch tidak perlu diterapkan ulang

Mengemulasikan perangkat USB dengan xDCI

  • Semua contoh mengasumsikan xDCI sudah diaktifkan di BIOS, intel_xhci_usb_sw-role-switch sudah dialihkan ke device, dan port xDCI terhubung ke host USB dengan kabel yang VBUS-nya terputus

  • Legacy gadget drivers

    • Legacy gadget drivers dari subsistem Linux USB Gadget akan mengemulasikan perangkat kelas USB tertentu saat modul dimuat
    • g_mass_storage mengekspos image filesystem sebagai perangkat USB mass storage
    • Setelah membuat image FAT disk.img dan memasukkan Hi from xDCI ke file.txt, modul dimuat dengan sudo modprobe g_mass_storage file=./disk.img stall=0
    • Di host USB, drive ter-mount otomatis dan isi berkas dapat dilihat

  • Raw Gadget

    • Raw Gadget dijalankan bersama xDCI untuk mencoba contoh keyboard USB
    • Awalnya proses berhenti saat menangani SET_CONFIGURATION
    • Penyebabnya adalah dwc3 dan beberapa driver UDC mengasumsikan bahwa control request panjang 0 dapat langsung di-acknowledge tanpa memeriksa driver gadget
    • Setelah menerapkan patch workaround pada Raw Gadget dan juga memperbaiki GadgetFS, emulasi keyboard berhasil
    • Perilaku terkait dirangkum dalam patch dokumentasi commit

Memanfaatkan syzkaller dan Facedancer

  • syzkaller dapat menggunakan Raw Gadget untuk melakukan fuzzing eksternal pada stack USB kernel Linux
  • Fuzzing USB bawaan syzkaller biasanya memakai Dummy HCD/UDC yang menghubungkan perangkat USB virtual dan host controller di dalam kernel
  • Untuk memakai xDCI, kode penentuan UDC di syzkaller diubah dari dummy_udc menjadi dwc3-gadget, dwc3.1.auto
  • Reproducer untuk bug WARNING in smsusb_start_streaming/usb_submit_urb yang ditemukan syzkaller dijalankan dengan syz-execprog -enable=usb
    • Pada laptop yang memakai kernel host Ubuntu 5.15.0-91-generic, warning usb_submit_urb berhasil direproduksi
    • Bug tersebut hanyalah WARNING akibat driver smsusb tidak memvalidasi tipe endpoint USB, dan bukan perilaku yang berbahaya
  • Facedancer adalah framework emulasi perangkat USB berbasis Python
    • Backend Facedancer berbasis Raw Gadget masih berupa prototype dan bergantung pada patch Raw Gadget out-of-tree
    • Setelah menyetel BACKEND=rawgadget, RG_UDC_DRIVER=dwc3-gadget, RG_UDC_DEVICE=dwc3.1.auto, contoh rubber-ducky.py berjalan dengan baik
  • USB Proxy berbasis Raw Gadget juga berjalan bersama xDCI, sehingga xDCI memungkinkan laptop dipakai sebagai USB sniffer atau alat USB Man-in-the-Middle

Kemungkinan pada perangkat lain dan pendekatan berbasis perangkat lunak

  • Selain ThinkPad X1 Carbon Gen 6, PC lain juga mungkin dapat mengaktifkan xDCI
    • Dalam kasus paling sederhana, cukup dengan menyalakan xDCI dari pengaturan BIOS
    • Sistem juga harus mendukung ACPI dan role switching, serta port xDCI harus benar-benar terhubung ke port eksternal
  • ThinkPad lain juga mungkin menyembunyikan dan melindungi pengaturan BIOS xDCI sehingga reflashing chip SPI bisa diperlukan
    • Metode NVRAM dapat diterapkan tanpa bypass Boot Guard
    • Pada beberapa sistem yang lebih baru, chip SPI mungkin dilindungi dari reflashing oleh RPMC; chip seperti ini bisa memiliki huruf R pada namanya, misalnya W25R128FW
  • Menurut pembaruan, Shiny Quagsire pernah mengaktifkan xDCI pada XPS 13 dan Surface Go 1 dengan grub-mod-setup_var untuk mengubah variabel PchSetup
    • Pada perangkat tersebut, variabel PchSetup tidak diproteksi sehingga pendekatan murni perangkat lunak dimungkinkan
  • Pendekatan perangkat lunak lain yang mungkin adalah memanfaatkan kerentanan BIOS untuk mengubah variabel NVRAM terkait xDCI, atau menyerang BIOS lewat DMA saat boot untuk mengeksekusi kode arbitrer
  • Kata “secret” pada judul lebih dekat ke makna fitur yang tidak terdokumentasi, bukan penyembunyian yang disengaja

Bacaan terkait

1 komentar

 
GN⁺ 2024-02-24
Komentar Hacker News

  • Saya selalu penasaran kenapa kemampuan memakai laptop sebagai keyboard dan monitor serbaguna untuk komputer lain tidak umum
    Terasa aneh harus membeli keyboard dan monitor baru hanya untuk merawat mesin headless, padahal laptop yang sudah ada sebenarnya bisa menjalankan peran itu

    • GPD Pocket 3 punya modul KVM yang melakukan persis ini: menerima input HDMI dan USB-C, lalu bertindak seperti display, keyboard, dan mouse untuk mesin yang terhubung: https://gpd.hk/gpdpocket3
      Tablet Minisforum V3 yang akan segera rilis juga punya input video sehingga bisa dipakai seperti monitor eksternal, tetapi sepertinya tidak sampai berbagi keyboard dan mouse
      Akan sangat bagus jika fitur seperti ini menjadi lebih umum
    • Betul. Teman saya bahkan membuat cyberdeck khusus untuk ini
      Mouse dan keyboard bisa dialihkan ke port eksternal lalu dihubungkan ke mesin lain dengan kabel, dan di sisi samping ada dua port HDMI, satu untuk output dan satu untuk input
      Dengan sakelar internal, dia bisa memilih apakah monitor memakai sumber dari mesin deck itu sendiri atau dari input eksternal
    • Sebagai orang yang sering menangani mesin headless, solusi terbaik yang saya temukan untuk memakai laptop sebagai monitor adalah produk ini: https://www.amazon.com/dp/B0BJ2YDV7Q
      Pada dasarnya ini adalah chip yang menangkap sinyal HDMI dari mesin headless lalu menampilkannya ke laptop sebagai webcam emulasi lewat USB, dan komponennya cukup kecil sampai bisa dimasukkan ke dalam kabel
      Untuk keyboard, selain memakai keyboard nirkabel standar dan membeli yang punya trackpad bawaan untuk berjaga-jaga kalau sesekali butuh mouse, saya belum menemukan solusi yang bagus
    • Saya selalu merasa merepotkan bahwa satu komputer tidak bisa begitu saja dihubungkan ke komputer lain
      Katanya USB 4 punya mode yang memungkinkan hal ini
    • Dengan hidclient, laptop bisa berpura-pura menjadi keyboard dan mouse Bluetooth
      https://web.archive.org/web/20180610141436/http://anselm.hoffmeister.be/computer/hidclient/index.html.en
      https://github.com/benizi/hidclient

  • Ini mengingatkan saya pada sesuatu yang dilakukan Travis Goodspeed beberapa tahun lalu
    Smart TV menerima pembaruan firmware dari file di USB flash drive biasa, dan TV itu membaca file dari awal sampai akhir untuk memeriksa tanda tangan digital, lalu membacanya lagi untuk melakukan pembaruan
    Jika ada perangkat yang berpura-pura menjadi media penyimpanan USB, perangkat itu bisa mengirim file firmware pabrikan pada pembacaan pertama lalu firmware tidak resmi pada pembacaan kedua

  • Sangat menarik. Saya juga sudah meneliti opsi serupa yang bisa diwujudkan
    Saya punya server NAS yang kuat dan terus mencari alasan untuk memakainya, plus koneksi 40G dan 10G di berbagai sudut rumah
    PS5 dan XBox memakai hard disk USB sebagai ruang penyimpanan tambahan
    Saya mencari tahu apakah penyimpanan NAS bisa diekspos ke PS5 dan XBox, dan ternyata bisa. Anda cukup me-mount share NAS lewat iSCSI atau NFS, lalu memakai modul g_mass_storage untuk mengemulasikan perangkat penyimpanan USB dan mengekspos penyimpanan tersebut ke host USB
    Hambatan besar saat ini, selain waktu dan biaya, adalah bandwidth yang bisa diberikan sistem seperti ini. Peningkatannya tidak terlalu besar
    Raspberry Pi terkenal mendukung USB-OTG, tetapi mentok di kecepatan USB 2.0, dan SBC lain di kelas yang sama yang saya cari sebagian besar juga begitu. Pengecualiannya adalah RockPi4, dan RockPi punya port Ethernet gigabit, jadi jika Ethernet dipakai penuh, itu bisa memberi kecepatan setara HDD yang stabil ke PS5 maupun Xbox
    Kalau ada solusi dengan kartu jaringan PCIe kustom atau express card yang bisa melampaui 1GbE, itu akan cukup menarik karena bisa benar-benar memenuhi antarmuka USB 3.0

    • Saya punya setup homelab yang mirip dan sedang bereksperimen dengan USB over IP menggunakan https://www.virtualhere.com
      Memang butuh klien yang akan berkomunikasi dengan server, tetapi sejauh ini tampaknya bekerja cukup baik
      Saya sedang membayangkan konfigurasi dengan “thin USB client” di meja, tempat perangkat USB dicolokkan, lalu bisa dihubungkan atau dialihkan ke host fisik atau host VM mana pun yang diinginkan di lab
    • Saya penasaran bagaimana PS5 dihubungkan secara fisik ke NAS
      Dugaan saya NAS → SBC → PS5, atau apakah NAS dihubungkan langsung ke PS5 dengan kabel USB?
      Saya juga penasaran bagaimana pemutaran konten bekerja di PS5. Setahu saya NVMe internal harus memenuhi kecepatan tertentu, apakah itu tidak berlaku untuk drive eksternal?
    • Raspberry Pi 5 punya port Ethernet gigabit, dan SBC lain seperti lini NanoPi dari FriendlyElec juga begitu
      Bahkan NanoPi R6S punya dua port Ethernet 2.5G selain port 1 gigabit

  • Terima kasih untuk tulisan yang sangat detail ini. Kualitasnya bagus
    Fakta bahwa ini bisa dilakukan memberi harapan bahwa mungkin konfigurasi mirip Synergy / Mouse Without Borders tanpa jaringan bisa dibuat hanya dengan kabel USB yang dimodifikasi
    Ini arah yang sangat baik bagi orang-orang yang harus mengoperasikan beberapa komputer sekaligus

    • Memang sudah ada KVM switch, dan ada juga perangkat yang hanya mengalihkan keyboard dan mouse USB tanpa video
      Meski begitu, pendekatan yang diusulkan terdengar menarik

  • Baru-baru ini saya mencari tahu hal yang mirip: saya ingin menghubungkan dua mesin USB-C hanya dengan satu kabel USB-C untuk komunikasi 10Gbps
    Sayangnya, sebagian besar motherboard Ryzen masih belum punya Thunderbolt, padahal dengan Thunderbolt ini didukung secara native dengan mudah
    Pengontrol USB “dual-role” juga cukup jarang sebelum USB 3.2/4.0, dan seperti yang dibahas tulisan ini, bahkan kalaupun memungkinkan sering kali tetap tidak didukung
    Rasanya benar-benar aneh bahwa tanpa Thunderbolt, menghubungkan dua mesin menjadi jaringan lewat kabel USB-C bisa sesulit ini
    Bagian tentang bit pengunci yang terlepas setelah suspend juga menarik. Masalah seperti ini memang sangat umum. Misalnya, ini juga cara yang sangat umum saat membuat perangkat SATA keluar dari kondisi yang memblokir secure erase

  • Kedalamannya sangat mengesankan
    Kalau PC bisa dipakai sebagai perangkat USB, banyak kemungkinan menarik yang terbuka
    Agak disayangkan bahwa opsi xDCI yang dibutuhkan ada di hardware perangkat ini tetapi tidak diekspos, dan untuk mengaksesnya perlu peretasan firmware
    Hardwarenya sebenarnya mampu, tetapi pabrikan hanya mematikannya dan mengunci kendalinya

  • Saya penasaran apakah Lenovo memakai ini sebagai jalur untuk men-debug ThinkPad lain dengan satu ThinkPad
    https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/secure-coding/intel-debug-technology.html
    Pembaruan: sepertinya iya
    https://www.youtube.com/watch?v=ExUvQa_jB7c
    Ini video tentang men-debug Intel Firmware dengan DCI dan USB 3.0

  • Bagian “tetapi menangani Raspberry Pi itu merepotkan: menyambung kabel, mem-boot board, mengakses shell, dan sebagainya” mungkin bisa diatasi dengan mengatur USB OTG
    Sepertinya bisa dibuat menerima daya dari perangkat yang dicolokkan, lalu menyalakan shell dan memprosesnya lewat skrip
    Dengan begitu, kita bisa mengatur mount atau menjalankan perintah lewat SSH, dan mungkin bahkan bisa melakukan mount perangkat
    Meski begitu, upaya memahami perangkat sendiri dan membaca kernel tetap layak didorong. Ini memang sesuatu yang ingin terus kita lakukan lebih baik, dan rasanya seperti peralatan kita seharusnya bisa kita perbaiki sendiri

    • Inti eksperimen ini sendiri adalah menangani USB OTG, dan Pi hanya punya satu port OTG, jadi perlu cara lain untuk terhubung
      Saya sudah mencobanya sendiri

  • Ini sangat mengingatkan pada budaya hacker internet awal sampai terasa nostalgis. Tulisan yang benar-benar luar biasa
    Saat ESR berbicara tentang menjadi hacker, tentang hacker dalam arti Hacker News, orang yang ia maksud memang tipe seperti ini
    Perpaduan rasa ingin tahu, ketekunan, dan kemampuan teknis seperti ini sangat langka dan sangat mengesankan

  • Saya punya sistem berbasis Celeron N3350/Pentium N4200/Atom E3900, dan di BIOS ada sakelar xDCI yang diekspos
    Kalau diaktifkan, beberapa opsi lain juga muncul, dan saat boot ke Linux terlihat perangkat PCI USB controller: Intel Corporation Device 5aaa (rev 0b)
    Tetapi node perangkat UDC tidak muncul. Sepertinya saya perlu menggali lebih jauh dengan petunjuk dari tulisan asli ini