Well, that being said, it sounds like there needs to be a more rigorous way of detecting these new codes.
One way I can think of, is to record data on the CMYK pins on the inkjet head itself. IIRC, they activate between 17v and 22v, and pulse per high.
The goal here is to make the printer think its printing, while recording all the data of the pulse operations. We would get a lengthy file out.
Ideally, the pulse coding should be consistent if printing the same image. "Printing" the same thing over multiple times could show time/date codes embedded.
I should also be able to compare underlying system internals too, with multiple clones of VMs with small config details different. They should be the same data. If they aren't, we know its encoding system stuffs.
But yeah, there is a way to attack this, and that's by going lower in the stack and treating the printers as a black box. It's not the best way, but a way I've thought of that could at least detect this new technique.
Probably. But my experiences are that these chips are fabless fab chips with half a dozen things on it. Reverse engineering is of course doable. But you're getting into ARM territory, with custom ARM licenses and different opcodes. It gets "unfun", and quickly. And ARM has no concept of probing for hardware, your best chance at a memorymap is whatever you build yourself, and not fry.
But I would imagine that a simple 3d printed harness would work a lot better with allowing signals to be recorded and make the printer think its printing. Then the bypass harness could have an ARM on it and spool instructions to either a SD card, or via USB serial.
The goal here is as transparent as possible, just in case there are other security systems that try to detect this attack. But I'd guess they havent got to that point yet.
Why make the printer "think" it's printing. Why not just literally measure and record the pulses sent to the actual print heads?
The "yellow dot" method would be picked up pretty quickly by the yellow being triggered while printing entirely B&W documents.
Things like dithering, if they encode things like printer serial numbers might be catchable by printing an identical set of documents across two examples of the printer.
> Why make the printer "think" it's printing. Why not just literally measure and record the pulses sent to the actual print heads?
That's what my shim would do, is record the signals to the ink solenoids. The reason to make the printer think its printing, is primarily because of all the DRM lockout crap all manufacturers use. Ideally, I'd even let it print so that when the firmware sees ink levels going down, nothing on the firmware side would look amiss.
> The "yellow dot" method would be picked up pretty quickly by the yellow being triggered while printing entirely B&W documents.
Indeed. However, its old hat about the yellow dots. I know they've moved on to something much harder to detect, and also likely scan and reprint resilient. What is this new type? No bloody clue. I'd assume a bad actor using heavy stego on chip. And if I were designing it, I'd watch for things like test images coming through and not mark them.
My first attempt would be with a high res 100$ bill scan. I betcha that'd trigger something interesting.
> Things like dithering, if they encode things like printer serial numbers might be catchable by printing an identical set of documents across two examples of the printer.
Yeah, I figure there's a serial number, time/date, hostname, IP, logged-in username.. All sorts of data. This is also corporate espionage area as well as national security, so I'd figure they would put out all the stops to catch, if they can't prevent the print itself.
Just chalk it up to me, and my paranoid mind. Still doesnt mean they arent out to get you!
I doubt it. There's tons of tricks and things that can be done to steganographically hide data in images. And given the algo is hidden, and the data is hidden in plain sight, we have to go to a level that can't be hidden from us.
Printing in different inks also wouldn't show us a way to diff 2 printed images. Whereas, saving the pulses from the CMYK pins would do that.
When you have a datalog of lots of pulses that represent a picture, you can back-calculate it into an image. You can also diff it without relying on losing data from scanning (or paying attention to the wrong thing). And with enough samples, we can recalculate the algorithm. With the knowledge of what they're doing, we can then start scanning other images for this... But only once we know what they're doing.
One way I can think of, is to record data on the CMYK pins on the inkjet head itself. IIRC, they activate between 17v and 22v, and pulse per high.
The goal here is to make the printer think its printing, while recording all the data of the pulse operations. We would get a lengthy file out.
Ideally, the pulse coding should be consistent if printing the same image. "Printing" the same thing over multiple times could show time/date codes embedded.
I should also be able to compare underlying system internals too, with multiple clones of VMs with small config details different. They should be the same data. If they aren't, we know its encoding system stuffs.
But yeah, there is a way to attack this, and that's by going lower in the stack and treating the printers as a black box. It's not the best way, but a way I've thought of that could at least detect this new technique.