3 ms·

This is the best advice I've read so far. I think that it's good to separate "I need a hard copy of a document I have" with "I'd like to learn how to reverse e

This is the best advice I've read so far. I think that it's good to separate "I need a hard copy of a document I have" with "I'd like to learn how to reverse engineer proprietary hardware". If you need a hard copy of a document, just email the thing to Kinkos and be done. If you want to start reverse engineering stuff, I'd get the "forward engineering" down first. Get a USB-capable arduino, try making a rotary encoder attached to it into a Linux input device. Make it show up as a device you can write 3 bytes to and turn the onboard LED that color. If you really want to crawl before you walk, skip USB and attach these things to a Raspberry Pi or similar. (Linux has built in drivers for all of these things, amazingly!) Now you have the basics of the communication down, and you can consider looking at wading into the undocumented archana of a proprietary one-off printer. It's going to be a really big project even for someone who has designed a printer and written a driver for it. That said, sniffing and replaying packets might get you pretty far. You should be able to do basic things like making the windows driver eject a piece of paper, and then doing that from Linux.

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 ago
  Ben 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 ago
    With 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 ago
  So 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 ago
  https://www.packtpub.com/product/linux-kernel-development-cookbook/9781789953435 https://www.packtpub.com/product/linux-kernel-development-co... ...is a pretty readable book.

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 ago
Ben 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 ago
  With 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 ago
So 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 ago
https://www.packtpub.com/product/linux-kernel-development-cookbook/9781789953435 https://www.packtpub.com/product/linux-kernel-development-co... ...is a pretty readable book.