Facedancer + usb_proxy.py(example code) fails to forward Wireless Mouse (12Mbps) to Target #144
Comments
|
Also tried with, still fails, but for some reason I see Google Chrome having some fingers there Added some dmesg-s 4811907_thumb1_chrome_closed.txt |
|
Thank you for the report, it sounds like the Cynthion SoC firmware is losing the connection to the proxied device. Will follow up with more questions if I can't reproduce it on my side! |
|
same issue with multiple devices. LIBUSB_ERROR_NOT_FOUND as user |
|
This change appears to fix the issue: diff --git a/facedancer/proxy.py b/facedancer/proxy.py
index 6f053d9..26bca33 100644
--- a/facedancer/proxy.py
+++ b/facedancer/proxy.py
@@ -354,7 +354,10 @@ class LibUSB1Device:
for interface in active_configuration:
number = interface[0].getNumber()
cls.device_handle.releaseInterface(number)
- cls.device_handle.attachKernelDriver(number)
+ try:
+ cls.device_handle.attachKernelDriver(number)
+ except:
+ pass
cls.device_handle.close()
cls.device_handle = None
@@ -374,7 +377,10 @@ class LibUSB1Device:
if active_configuration:
for interface in active_configuration:
number = interface[0].getNumber()
- cls.device_handle.detachKernelDriver(number)
+ try:
+ cls.device_handle.detachKernelDriver(number)
+ except:
+ pass
cls.device_handle.claimInterface(number)
return cls.device_handleI'm guessing the problem is that an interface might currently have an altsetting that does not have a kernel driver attached and thus detaching the driver fails. |
|
I've implemented a similar solution in greatscottgadgets/facedancer#104 which has a couple advantages over the above patch. |
|
If someone else is struggling still with this issue, following worked for me (in ARM macOS and Intel Debian)
If all above works, this will work now: Exactly the same happens for me in macOS and Debian. With this approach everything works until Cynthion is reseted (or rebooted). If this happens, you just need to rerun flashing part: Once again, good way to test it before use: |
|
One more finding; if I do a cynthion/firmware/moondancer/src/bin/moondancer.rs Lines 358 to 360 in 0f63526 causes it to happen. This was found by monitoring UART. |
That's correct. The FPGA shares the USB port with the microcontroller running Apollo. This makes it possible to handover control from the FPGA to Apollo but the microcontroller has no corresponding mechanism to return control to the FPGA. If you do a |
|
I'm not sure whether the underlying problem is a related one but I'm having similar issues with usbproxy.py, no matter the type of USB device I'm trying to proxy (tried multiple USB mass storage devices, mice, keyboards with no success). For some reason, libusb is unable to open the device (I've triple checked device and vendor IDs). uname -a
Linux xyz 6.6.47+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.6.47-1+rpt1 (2024-09-02) aarch64 GNU/Linux
cynthion info
Cynthion version: 0.1.7
Apollo version: 1.1.0
Python version: 3.11.2 (main, Aug 26 2024, 07:20:54) [GCC 12.2.0]
Found Apollo stub interface!
Bitstream: Facedancer (Cynthion Project)
Vendor ID: 1d50
Product ID: 615b
bcdDevice: 0104
Bitstream serial number: xxxxxxxxxxxxxxxx ./Facedancer/examples/usbproxy.py
Traceback (most recent call last):
File ".venv/cynthion/./Facedancer/examples/usbproxy.py", line 21, in <module>
proxy = USBProxyDevice(idVendor=ID_VENDOR, idProduct=ID_PRODUCT)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File ".venv/cynthion/lib/python3.11/site-packages/facedancer/proxy.py", line 53, in __init__
device_handle = self.proxied_device.open(device, detach=True)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File ".venv/cynthion/lib/python3.11/site-packages/facedancer/proxy.py", line 374, in open
cls.device_handle = device.open()
^^^^^^^^^^^^^
File ".venv/cynthion/lib/python3.11/site-packages/usb1/__init__.py", line 2055, in open
mayRaiseUSBError(libusb1.libusb_open(self.device_p, byref(handle)))
File ".venv/cynthion/lib/python3.11/site-packages/usb1/__init__.py", line 127, in mayRaiseUSBError
__raiseUSBError(value)
File ".venv/cynthion/lib/python3.11/site-packages/usb1/__init__.py", line 119, in raiseUSBError
raise __STATUS_TO_EXCEPTION_DICT.get(value, __USBError)(value)
usb1.USBErrorAccess: LIBUSB_ERROR_ACCESS [-3]
any help is greatly appreciated! |
|
If you're on Linux the issue may be that the device you are trying to proxy has not been set up for access by a non-root account. You can test this quickly by trying to run the USB Proxy script as root:
If this solves it you can set the proxied device up for non-root access by adding a rule to your system's You can use the custom rules we install for Cynthion as a reference: 54-cynthion.rules Basically you'll want to add a line such as: More info: https://wiki.debian.org/udev As far as I know macOS doesn't have a similar mechanism so you will probably need to run USB Proxy as root if you're on a Mac. |
Thank you very much, that fixes my issue indeed (had to become root and activate my Python venv first). Yet, forwarding USB thumb drives or a keyboard to a Windows host all failed (Windows would not recognize any of them properly). fyi: When proxying a keyboard, facedancer outputs the following warning:
|
|
That could be the problem, we've got some issues with Low Speed support that should be fixed in the next Facedancer release. What are your experiences with Full and High speed devices? |
The USB drives I have been testing with are properly being detected by Facedancer as HIGH speed devices but proxying them from a Raspberry Pi 3b+ to a Windows 11 machine still does not work in that they won't be properly recognized/mounted on the target system. There are no obvious errors shown by Facedancer, its logs look clean. May I ask your results of proxying a USB High speed mass storage device from a Linux machine to a Windows target please? |
I'm guessing it might be the HUB (see dmesg from below), I'll see if I can find some USB C device, that doesn't need the HUB
throws exception
I can visually see, that the python script is able to do something to the mouse connection
Screen.Recording.2024-07-16.at.00.13.46.mov
And also from the dmesg, I see some activity
The text was updated successfully, but these errors were encountered: