8 ms·

This is an extremely poor venue for this type of question - the answers are all over the place and mostly unhelpful (printer drivers in Linux almost never invol

This is an extremely poor venue for this type of question - the answers are all over the place and mostly unhelpful (printer drivers in Linux almost never involve a custom kernel driver). You might have better luck on Arch Linux forums of all places. What you’re asking for probably won’t be low hassle compared to just running the 32 bit usermode “driver” - which should run fine on a 64 bit system with some packaging help. Ask yourself, are you trying to use the damn printer or you want a possibly educational rabbit hole to go down. Even if you sniff the USB (you can simply use pcap/wireshark) what are you expecting to see? It will likely be Canons proprietary raster and control format. Reversing that from the bus alone will be an enormous amount of work. I’ve written proprietary “WinPrinter” printer drivers with the spec in hand and it’s still not trivial.

jrockway 4y ago
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/
AshamedCaptain 4y ago
I mentioned to just use the Gutenprint mailing list, but I was downvoted. They are at least a bit more likely to minimally look at the proprietary driver (no one of the commenters here did), or even remember by heart a similar model with the exact same interface (which is rather likely to exist).
rroot 4y ago
I really don't agree with this. What we have here is an enthusiastic hacker wanting to go down the rabbit hole of writing a hardware driver. That's no easy task (like you point out), and answers like this are not helpful at all. The answer is discouraging and seem to only sow doubt in OPs mind. Let him find out how hard it is. May I remind that this website is called "Hacker News". Let the voting suggest the venue for the question - it hit the front page of hacker news.
- parker_mountain 4y ago
  While normally I would agree with your comment, printers are an especially complicated class of device. Also, the suggestion to check the arch linux forums was spot on. I think OPs answer was very helpful and polite.
  - waynesonfire 4y ago
    > especially complicated class of device. is it as complicated as calculus? or running your own e-mail server? you're perpetuating the same sentiment. Let the OP figure it out on their own.
    - pessimizer 4y ago
      And also go to the arch linux forums. I think everyone has been helpful and polite.
      - waynesonfire 4y ago
        Sad to see that on "hacker" news the top-post is essentially, go to kinkos. I am legitimately interested in the understanding the scope of the work and what it would entail to solve such a problem successfully. And, maybe I only have enough resources to solve the elementary steps but that's beside the point. Also, this is a relatively new post so maybe relevant information will eventually bubble up. I am starting to see some interesting comments.
dopamean 4y ago
I love how "Hacker"News threads has evolved to the point of actively discouraging people from hacking.
- fuckstick 4y ago
  How is pointing out 1. That the SNR of the answers here isn’t the best and there may be venues with better expertise (with a specific example) and 2. Pointing out the potential scope of work in any way actively discouraging?
  - waynesonfire 4y ago
    Because it doesn't address the OPs question. "I'm interested in writing a x86_64 Linux driver for my 15 year old photo printer." Is a very clear statement. Maybe if they had solicited, "how difficult would this be?" -- but that was not asked. Iterating how difficult the project is doesn't move the needle forward and in fact, does the opposite and is not at all helpful to the OP. Don't project your inadequacies.
    - pessimizer 4y ago
      Every single sentence in fuckstick's answer is helpful and responsive to someone who is interested in writing a driver for their printer. Including the discouragement, which communicates an expert opinion of the amount of work involved. Can't believe I'm defending a fuckstick rn, but here we are.
    - AshamedCaptain 4y ago
      > "I'm interested in writing a x86_64 Linux driver for my 15 year old photo printer." [...] is a very clear statement. The problem is, everyone who knows a thing about "Printer drivers" shivers when they read that statement, in part because it mentions Linux or x86_64, which kind of implies some level of confusion. Also, it doesn't mention whether he's doing it for the sake of an old printer (which then makes the question the wrong thing to ask -- rather you should ask "I want to make my printer work with x86_64 Linux" -- which likely has a much simpler answer) or the sake of how to learn to write Linux printer drivers (which makes the question bizarre -- there are no Linux printer drivers per se). > Iterating how difficult the project is doesn't move the needle forward and in fact, does the opposite and is not at all helpful to the OP. Don't project your inadequacies This is really the wrong take here. If someone asks "I want to learn to pave roads for 4-wheel bikes" you don't answer with "OK, tarmac is made with crushed stone, tar, ...". You answer with "WTF are you doing this for?". Because it's highly likely that the questioner is having some type of confusion, rather than explicitly wanting to make such a strange request. As Eric S. Raymond put long ago: > Often, people who need technical help have a high-level goal in mind and get stuck on what they think is one particular path towards the goal. They come for help with the step, but don't realize that the path is wrong. It can take substantial effort to get past this. By not addressing the user's exact question, and considering the user's final goal, you may be moving the needle much forward than if you just blindly answer it like some people have done here.
matheusmoreira 4y ago
> you want a possibly educational rabbit hole to go down What would your advice be if we assume that was what the author wanted? I had a lot of fun reverse engineering my laptop's keyboard LEDs and I'd love another rabbit hole to go down into...
a-dub 4y ago
wireshark/pcap/scapy last i played with this, i had to hack up scapy to handle the windows usb packet capture format. (windows and linux usb packet captures are/were in different formats, unfortunately) when you're on windows you should print a bunch of images and then try and train a transformers neural network to predict the packets from the images alone. if you got this to work, it would be cool.
- worthless-trash 4y ago
  There is hacking, then there is building skynet... cmon man dont start the singularity from a printer.

jrockway 4y ago

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/

AshamedCaptain 4y ago

I mentioned to just use the Gutenprint mailing list, but I was downvoted. They are at least a bit more likely to minimally look at the proprietary driver (no one of the commenters here did), or even remember by heart a similar model with the exact same interface (which is rather likely to exist).

rroot 4y ago

I really don't agree with this. What we have here is an enthusiastic hacker wanting to go down the rabbit hole of writing a hardware driver. That's no easy task (like you point out), and answers like this are not helpful at all. The answer is discouraging and seem to only sow doubt in OPs mind. Let him find out how hard it is. May I remind that this website is called "Hacker News". Let the voting suggest the venue for the question - it hit the front page of hacker news.

parker_mountain 4y ago
While normally I would agree with your comment, printers are an especially complicated class of device. Also, the suggestion to check the arch linux forums was spot on. I think OPs answer was very helpful and polite.
- waynesonfire 4y ago
  > especially complicated class of device. is it as complicated as calculus? or running your own e-mail server? you're perpetuating the same sentiment. Let the OP figure it out on their own.
  - pessimizer 4y ago
    And also go to the arch linux forums. I think everyone has been helpful and polite.
    - waynesonfire 4y ago
      Sad to see that on "hacker" news the top-post is essentially, go to kinkos. I am legitimately interested in the understanding the scope of the work and what it would entail to solve such a problem successfully. And, maybe I only have enough resources to solve the elementary steps but that's beside the point. Also, this is a relatively new post so maybe relevant information will eventually bubble up. I am starting to see some interesting comments.

dopamean 4y ago

I love how "Hacker"News threads has evolved to the point of actively discouraging people from hacking.

fuckstick 4y ago
How is pointing out 1. That the SNR of the answers here isn’t the best and there may be venues with better expertise (with a specific example) and 2. Pointing out the potential scope of work in any way actively discouraging?
- waynesonfire 4y ago
  Because it doesn't address the OPs question. "I'm interested in writing a x86_64 Linux driver for my 15 year old photo printer." Is a very clear statement. Maybe if they had solicited, "how difficult would this be?" -- but that was not asked. Iterating how difficult the project is doesn't move the needle forward and in fact, does the opposite and is not at all helpful to the OP. Don't project your inadequacies.
  - pessimizer 4y ago
    Every single sentence in fuckstick's answer is helpful and responsive to someone who is interested in writing a driver for their printer. Including the discouragement, which communicates an expert opinion of the amount of work involved. Can't believe I'm defending a fuckstick rn, but here we are.
  - AshamedCaptain 4y ago
    > "I'm interested in writing a x86_64 Linux driver for my 15 year old photo printer." [...] is a very clear statement. The problem is, everyone who knows a thing about "Printer drivers" shivers when they read that statement, in part because it mentions Linux or x86_64, which kind of implies some level of confusion. Also, it doesn't mention whether he's doing it for the sake of an old printer (which then makes the question the wrong thing to ask -- rather you should ask "I want to make my printer work with x86_64 Linux" -- which likely has a much simpler answer) or the sake of how to learn to write Linux printer drivers (which makes the question bizarre -- there are no Linux printer drivers per se). > Iterating how difficult the project is doesn't move the needle forward and in fact, does the opposite and is not at all helpful to the OP. Don't project your inadequacies This is really the wrong take here. If someone asks "I want to learn to pave roads for 4-wheel bikes" you don't answer with "OK, tarmac is made with crushed stone, tar, ...". You answer with "WTF are you doing this for?". Because it's highly likely that the questioner is having some type of confusion, rather than explicitly wanting to make such a strange request. As Eric S. Raymond put long ago: > Often, people who need technical help have a high-level goal in mind and get stuck on what they think is one particular path towards the goal. They come for help with the step, but don't realize that the path is wrong. It can take substantial effort to get past this. By not addressing the user's exact question, and considering the user's final goal, you may be moving the needle much forward than if you just blindly answer it like some people have done here.

matheusmoreira 4y ago

> you want a possibly educational rabbit hole to go down What would your advice be if we assume that was what the author wanted? I had a lot of fun reverse engineering my laptop's keyboard LEDs and I'd love another rabbit hole to go down into...

a-dub 4y ago

wireshark/pcap/scapy last i played with this, i had to hack up scapy to handle the windows usb packet capture format. (windows and linux usb packet captures are/were in different formats, unfortunately) when you're on windows you should print a bunch of images and then try and train a transformers neural network to predict the packets from the images alone. if you got this to work, it would be cool.

worthless-trash 4y ago
There is hacking, then there is building skynet... cmon man dont start the singularity from a printer.