5 ms·
> Make it show up as a device you can write 3 bytes to I've been curious about doing something like this for a while, but don't even really know where to star
by JLCarveth 4y ago
> Make it show up as a device you can write 3 bytes to
I've been curious about doing something like this for a while, but don't even really know where to start when it comes to researching information on this topic. Do you have any good resources for accomplishing this?
- lozenge 4y agoBen Eater has some videos showing the USB protocol on an oscilloscope. https://www.youtube.com/watch?v=wdgULBpRoXk https://www.youtube.com/watch?v=wdgULBpRoXk https://www.youtube.com/watch?v=N0O5Uwc3C0o https://www.youtube.com/watch?v=N0O5Uwc3C0o And some videos on using chips and breadboards to meet protocols- https://www.youtube.com/watch?v=l7rce6IQDWs https://www.youtube.com/watch?v=l7rce6IQDWs And a digital protocol too- https://www.youtube.com/watch?v=MCi7dCBhVpQ https://www.youtube.com/watch?v=MCi7dCBhVpQ
- bri3d 4y agoWith existing USB devices you don't usually need to go nearly this low level to reverse engineer them - just enumerating the endpoints and then using Wireshark and USB packet capture is plenty sufficient. Understanding how the USB wire protocol works is definitely valuable knowledge in some arenas, but not at all important for the kind of reverse engineering task OP is trying to perform, as they can generally speaking trust the electrical layer is standard and only need to operate at a level above it. Same for the "write 3 bytes to a USB device" hypothetical from upthread - electrical understanding of USB is interesting but ultimately unimportant if you're using an existing USB stack - higher level knowledge of USB endpoint types and transport mechanisms is the name of the game there. If I were given this task and I had to produce a driver with source code (rather than just get things working), I'd start with a combination of USB sniffing and static decompilation (Ghidra/IDA) of the Canon binaries, followed by perhaps some dynamic analysis (logging shims) if things turned out very complex. If I just had to get things working, I'd just use one of the many approaches to mix 32/64-bit userland binaries in order to shim the 32 bit Canon binaries into a 64-bit CUPS driver.
- deleted 4y ago[deleted]
- jrockway 4y agoSo most Arduino-alikes have USB support these days, and often appear to the host computer as a serial port. The absolute easiest thing is to take advantage of this; on the microcontroller end read the color over the serial port and set the LED appropriately. On the host computer end, write a tiny program that opens the right serial port and sends the desired bytes. Super straightforward. From there, being a USB HID device will be a lot easier on your host machine code. You have to speak a predefined protocol, but the OS can use its own drivers to take advantage of the functionality you offer. For example, your microcontroller code can be a keyboard or a joystick. (It's still bidirectional, so you should be able to configure the color of the on-board LED. I don't know whether or not there's a standard there so you can just use a pre-written host app across platforms.) Finally, if you want to pick apart an actual product that does this, I just found: https://www.blinkstick.com/ https://www.blinkstick.com/
- floxy 4y agohttps://www.packtpub.com/product/linux-kernel-development-cookbook/9781789953435 https://www.packtpub.com/product/linux-kernel-development-co... ...is a pretty readable book.