[HN Gopher] USB Sniffer Lite for RP2040
___________________________________________________________________
USB Sniffer Lite for RP2040
Author : mdp2021
Score : 112 points
Date : 2024-08-04 06:24 UTC (16 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| actionfromafar wrote:
| Can this be used to capture the packets of another computer?
| stavros wrote:
| The USB packets? Yes.
| westurner wrote:
| So it should be possible to bridge wired USB wirelessly over
| 802.11n (2.4 GHz) and Bluetooth BLE 5.2 with two RP2040w, or
| one and software on a larger computer on the other side with
| e.g. google/bumble
| stavros wrote:
| Why go through all this trouble if you already have
| physical access to the computer?
| westurner wrote:
| To connect a USB device over WiFi or Bluetooth with or
| without an adapter plugged into the computer:
| USB device <-> RP2040w ))) wifi/bluetooth (((
| RP2040w.usb0 <-> computer USB device <-> RP2040w
| ))) wifi/bluetooth ((( computer.software_xyz
| tssva wrote:
| An example of a use I have deployed via another solution
| for my wife. She often works from home. She often has to
| markup up documents and finds it much easier to do so
| from paper copies. When connected to her work VPN she
| isn't allowed access to the local network. We have two
| offices and the printer is in mine because I frequently
| need to use it for printing invoices. She used to have to
| bring her laptop into my office and connect it via usb to
| print or disconnect from the work VPN. I deployed a usb
| over network extender. Now she can print from her office
| without disconnecting from the VPN.
| treflop wrote:
| I too have this problem but I just straight up drop the
| routing table entries that block me from my printer.
| tssva wrote:
| Unfortunately my wife's IT department locks things down
| enough that isn't possible. To setup the printer she had
| to have the IT department remote in, whitelist the usb
| printer and install the drivers. Even to get that to
| happen required several levels of approval.
| astromaniak wrote:
| -> pc: to have wireless tablet, touchpad, joystick, etc.
|
| pc ->: to have wireless robot control, printer, other
| devices which have drivers, but aren't easily
| programmable.
| sylware wrote:
| I know this is a bit off-topic, but does the RP2040 contain an
| ARM core, namely the ARM royalties must be paid?
|
| If yes, is there a derivative or version of this chip without the
| ARM core?
|
| That said, this is the same issue if there are MPEG codecs, or
| HDMI related blocks. That's why AV1 codec and DisplayPort should
| be at least there, and actively prefered.
| danhor wrote:
| > namely the ARM royalties must be paid?
|
| Yes, and it also contains other IP block (for example the USB
| from Synopsys) for which fees will be paid by the manufacturer.
| The Cortex-M0+ cores in the rp2040 are probably pretty cheap,
| so they don't impact the final price much.
|
| > is there a derivative or version of this chip without the ARM
| core?
|
| No. There might be future versions (they are, in general,
| looking at Risc-V stuff), but there isn't too much benefit.
|
| > That said, this is the same issue if there are MPEG codecs
| [..]
|
| No it isn't. The issue with those is that not only does the
| creator of the IP block itself need to get paid, but also the
| patent pool behind it, which is usually much more expensive.
| For most products from a smaller company (and even many larger
| ones), an AV1 hardware codec or a DisplayPort output will also
| be an IP block bought from someone else.
| askvictor wrote:
| Yes, it has an arm core. The manufacturer pays the royalty to
| arm. Very different ball game in my opinion to proprietary
| codecs. There are no non-arm derivatives. The closest non-arm
| MCU you'll find is the esp32 but that's completely different,
| and lacking probably the most useful thing about the rp2040:
| the PIO.
| sylware wrote:
| I guess I will avoid that chip and favor those without an ARM
| block then. Luckily there are many.
|
| But indeed, would be good if those ARM free SOC would also be
| free-ed from HDMI and MPEG blocks.
|
| Getting rid of ARM cores is only the middle of the journey
| for better hardware freedom, HDMI and MPEG codecs must be a
| target too.
| tssva wrote:
| Why do you think ARM shouldn't get paid for the work they
| did?
| sylware wrote:
| I said to favor chips without ARM ISA cores, for instance
| with RISC-V ISA cores instead.
| ta988 wrote:
| there is unfortunately absolutely nothing that get nearly
| close to the rp2040 price/performance/features...
| sylware wrote:
| Fortunately, we have many RISC-V SOC alternative without
| ARM cores able to do a more than good enough job?
| inhumantsar wrote:
| I suspect it's not that ARM shouldn't get paid, it's that
| companies producing open source hardware should get paid
| instead.
| sylware wrote:
| If you do all the real work of implementing ARM ISA, you
| will have to pay royalties anyway (where those are legal
| though).
|
| That's why it is critical to favor worldwide royalty free
| ISA like RISC-V. This is not a silver bullet but does a
| good enough job.
| numpad0 wrote:
| Everyone knows what GP is getting at, those opposing GP
| knows it leads to fragmentation and vendor lock-in, not
| standardization and open sourcing.
| sylware wrote:
| That was my assumption, indeed.
| tenebrisalietum wrote:
| Work once, get paid once is the model that most drives
| efficiency and innovation. If an entity is getting paid
| without working or innovating (work once, get paid
| forever), they have no reason to further work or
| innovate. This hampers the progress of science and the
| useful arts instead of furthering it.
| auxym wrote:
| Can you expand on why you are so much against ARM?
| sylware wrote:
| If I am a chip designer, I don't want to implement an ISA
| which requires to pay royalties (where those are legal),
| I would prefer to be free and go RISC-V which does a more
| than good enough job.
| Ecco wrote:
| How would this compare to a software-based USB sniffer?
| galangalalgol wrote:
| That is my question as well. I've always been interested on the
| binary blobs that go to HID moce and keyboards. I wonder if
| this would make cracking those any easier?
| nvllsvm wrote:
| I've had a lot of luck capturing USB packets using a Windows
| virtual machine and Wireshark on a Linux host. Most recently
| I've used this to reverse engineer the configuration protocol
| of the Pulsar X2 v2 Mini gaming mouse.
|
| I've also used this to capture the firmware update flow for
| the gamepad on a GPD Win 2. A physical sniffer wouldn't be
| ideal here since the gamepad - while USB - is embedded within
| the device.
| dougg3 wrote:
| It lets you see the raw underlying packets like IN, OUT, SETUP,
| DATA0/1, etc. That capability would be most useful for USB
| device firmware developers who might want to see these packets
| to track down an issue with the DATA0/1 toggling or something
| like that which wouldn't be visible in a higher-level software
| trace like USBpcap or usbmon.
|
| Also, it lets you sniff USB traffic of a different host
| machine, e.g. USB communication between a game console and a
| USB controller.
| ruined wrote:
| it works on macos without disabling SIP
| Tepix wrote:
| Can i use this to detect a badusb cable/charger?
| jdhdnxjxie wrote:
| Software from taradov is always joy
| Hackbraten wrote:
| A commercial off-the-shelf alternative for the impatient:
|
| https://greatscottgadgets.com/cynthion
| peterburkimsher wrote:
| I use this USB sniffer on a daily basis!
|
| At work, we're somewhat limited in what we can install on the
| office PCs. Therefore I listen to music on an iPod, rather than
| streaming.
|
| To control the music on the iPod, I have a USB sniffer that picks
| up the media keys on my keyboard, and sends serial packets to the
| iPod.
|
| I should rewrite taradov's code using RTOS threads to allow
| capture and sending at the same time, but what have now works
| well enough for my use case. If I press a key during the parse
| phase then it doesn't pick up, but I can always just press it
| again and usually it gets through.
|
| For newer devices I've got an Arduino that take iPod remote
| commands and converts them to a TRRS headphone jack remote. So I
| could use the media keys on the keyboard to control a phone, for
| example.
|
| Soon I plan to use Arduino Audio Tools to build an iPod remote ->
| Bluetooth A2DP remote using an ESP32 (note that -C and -S don't
| support A2DP, just ESP32).
|
| Every time I change the volume or track on my iPod during a work
| day, I'm using this USB Sniffer, and it's been very reliable.
___________________________________________________________________
(page generated 2024-08-04 23:01 UTC)