Support gadget api

[shlomow]

Hi!
I saw in the readme and on youtube that this library can be ported to any embedded linux devices that has gadget api as well as usb device and host controller. I wonder if you are working on that, and if not how can I do this and contribute :)

[chadrockey]

@dominicgs Do you have a starting place for what would make the Beaglebone black work with this repository? I have an application where I'd like to MITM or sidechannel USB data to the ethernet network while not disturbing the original application. I don't see any of the newer devices having ethernet.

Alternatively, if they support the "two USB" in one connection thing I've heard about that would work as well. Example: Adding a usb-to-serial interface beside the original interface without changing the vendor or product for the original.

[ktemkin]

I have a rough outline for making this work with gadgetfs, but using gadgetfs has a couple of issues -- it's soft-deprecated in favor of functionfs, and requires some kernel patches.

In general, umap2 is a good resource for studying a (very relevant) backend implementation:

• https://github.com/nccgroup/umap2/blob/master/umap2/phy/gadgetfs/gadgetfs_phy.py
• https://github.com/nccgroup/umap2/tree/master/gadget

This is still something I want to do, but there are a lot of things in my queue before I can get around to it. Note that even after merging this, the result will still be limited compared to a proper FaceDancer board-- mostly due to the fact that Linux UDC/Gadget drivers don't give us fine-grained control over every piece of hardware.

Alternatively, if they support the "two USB" in one connection thing I've heard about that would work as well. Example: Adding a usb-to-serial interface beside the original interface without changing the vendor or product for the original.

What's the class/subclass of the 'victim' USB device? If it's a Composite device (all zeroes) and has unused endpoints, you can easily add an additional interface that provides another type of USB functionality via FaceDancer::USBProxy.

If the victim isn't a Composite device, you can possibly use FD::USBProxy to change it to composite while maintaining its original function -- but this depends on how the relevant drivers describe which devices they handle, and what assumptions the drivers make about the device.

[huntergregal]

Building around Raw Gadget https://github.com/xairy/raw-gadget (mainline since 5.7) seems like the best move for this ticket.

GadgetFS provides limitations - notably by sanity checking descriptors. Gross.

See https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/usb/raw-gadget.rst

[xairy]

There's now a prototype of a Facedancer backend based on Raw Gadget. It relies on a couple out-of-tree Raw Gadget patches, so I'll hold off sending it as a PR until I finalize the approach.

On a related note, resolving #48 would help with figuring out whether the backend implementation follows the right approach.

[huntergregal]

this is awesome! thanks for your work on this xairy. I'm also interested in these out-of-tree raw gadget patches. More then once i have found myself editing raw gadget. I see you removed the semaphore in the dev branch. +1

[antoinevg]

This is really cool work!

I'm currently prepping to merge #78 over the next couple weeks:

• Some imports have changed but, fundamentally, the backend interface remains the same.
• I hope to get a chance to write some docs on backend implementation but, failing that, I'm here to help get a PR merged.

🥳

[antoinevg]

I've pushed some initial documentation on writing new Facedancer backends:

https://github.com/greatscottgadgets/facedancer/blob/main/docs/source/howto_facedancer_backend.rst