Control requests, which are a type of USB request, make it easier to enumerate devices in order to retrieve and configure information about those devices.
Post-enumeration, researchers reconfigure devices or transmit commands, which are always initiated by the host and dictate data flow direction as IN (Device-to-Host) or OUT (Host-to-Device).
It falls into three categories: Device (standard requests per USB specifications), Class (specific to USB Classes like HID or Mass Storage), and Vendor (custom, non-standardized requests).
Tools like `lsusb` list USB devices, revealing internal USB connections such as webcams, while exploring vendor-specific USB requests, like those for X230 webcams, enabling fuzzing to test or manipulate device behavior.
Experimenting with OUT fuzzing caused the X230 webcam to stop responding, and after rebooting, it disappeared from the `lsusb` list, suggesting a potential firmware overwrite or hardware brick.
Attempts to recover involved sourcing X230 webcam modules from eBay, including those with different camera controllers (e.g., FRU 04W1364) and layouts but compatible firmware (FRU 63Y0248).
The SPI chip was desoldered and mounted in a detachable TSSOP8 socket for external programming, while fuzzing revealed specific `bRequest` values unlocking, overwriting, and locking SROM.
Investigation into R5U8710 pinouts used IU233N schematics but lacked direct datasheet support, confirming the camera’s code corruption and bricked state.
Efforts to modify the X230 webcam firmware revealed key findings and challenges, where the LED, connected to the R5U8710’s “GPIO B1” (per datasheet), is likely controllable via firmware, but its specific mapping to 8051 GPIOs (P0–P3) remains unclear.
Testing arbitrary GPIO manipulations failed to produce LED changes, suggesting that GPIO B1 may not link directly to 8051 GPIOs but instead involve the SoC’s internal logic but firmware modification confirmed control over enumeration behavior, as demonstrated by changing the camera name to “Pwned!” and injecting infinite loops.
Power cycling is necessary for firmware updates, as SROM changes do not reload dynamically. While enumeration code execution is achievable, streaming-specific code offers additional implant opportunities.
The next goal is to reverse engineer the Boot ROM, hypothesized to control GPIO B1, by devising a method to leak its contents, potentially via USB, as refining clean code execution during enumeration is a priority for further progress.
To hook code without breaking enumeration, a jump to a “free” memory location was implemented, and a side-effect–less implant was placed there to leak the Boot ROM over USB.
Enumeration implants surprisingly executed during UVC request handling as well, enabling incremental leaks of up to 16 KB per session, though the Boot ROM’s dense packing required avoiding streaming-related code to prevent crashes.
According to the researcher, absolute address jumping remained unresolved due to unknown SROM loading addresses, and relative jumps of the 8051 were constrained to ±127 bytes.
Efforts to map GPIO B1 relied on dumping memory spaces (XDATA, RAM, IRAM) with the LED off and on, comparing for changes at bit #2, assuming GPIOs were memory-mapped. UVC controls (e.g., Contrast at 0xafb9, Saturation at 0xafbd in XDATA) proved valuable as configurable, persistent variables, allowing offsets within 16 KB.
The process of leaking Boot ROM data at a rate of approximately one bit per second was achieved through the utilization of enumeration implants that were refined to evaluate the value of `CODE_BITS[N].
In the future, there will be an effort to map GPIO B1 for complete LED control and to improve USB packet manipulation in order to extract Boot ROM more effectively.
%20(1).webp?w=1200&resize=1200,0&ssl=1 "Ransomware Group “Medusa” Targets Rent-2-Own in Latest Cyberattack")
