Author
Topic: Lexmark Printer Hacking (Read 12577 times)

This is something I wanted to do for a while. I claimed this printer when it stopped working and upon opening it realizing the thing was flooded with ink and beyond economical repair. However the motherboard and scanner module was okay.

The victim in question. A Lexmark Pro 805 printer, the last picture of it before I cracked the thing open.

I chose it for a few reasons:1. It was firmware upgradable2. The firmware was easy to open and disassemble3. The cpu architecture was ARM4. If I could repurpose it, its basically a free computer.5. I am a beginner to hardware.

You can download the firmware upgrade from here, they do not have any protection or anything on it so you can just dump it into a disassembler.

Well I started like anybody would on the motherboard. You can see in this image I have it almost fully working (asking for the freaking "duplex module") outside of its case.

I do not have an oscilloscope, but I wanted to probe around for a serial port. My solution to this was to wire up a speaker and use it as a probe while the thing boots up. Theory behind it would be if I hear varying tones I could be looking at a serial data pad. And wouldn't you know it after a bit of probing around near a port that was labeled "JTAG" (no JTAG hardware folks, sorry) I found some pads near a chip "25l6405dmi-12G". After asking around on the help forum earlier this week (here) I found it was a chip with an SPI bus on it.

I hooked up my logic analyzer and took a look at what was going on.Yeah I had no clue.

When I started I did not know what SPI was. A bit of Google magic and a few read articles and I sort of knew what to do so I just went for it. I have two microcontroller boards, MSP430 and an Arduino. The Arduino was my choice because I found this. I went through the code and the datasheet and started typing away some code to attempt to do something simple, just read the manufacturing id.

After some tinkering, accidentally causing the printer to fail to boot (just a short, no worries) I had something coming out of the serial out on the Arduino serial monitor.

40 00 03Well.... That is not what the datasheet says. Okay well maybe I just have a slightly different chip. Lets just go for dumping a sector of the chips memory and see what I get.

Well crap, every dump is different. And dumping is sooooo sloooow. Lets come back at this later....

*one day later*

I thought I should check to see if the printer still boots. I unwired everything and it boots fine, I didn't bust the chip. So I rewire it and I open the serial monitor to find this

C2 20 17

Well what the hell its working? I did one of two things, either when I shorted the chip I caused it to go into some mode where I could not read from it, or my wiring was dodgy and when I rewired the thing I fixed whatever what was wrong. I was ready to write my own SPI library too. So lets try to make a dump of the chip.....

Ladies and gentlemen I give you the printers bootloader. 4096 Bytes of it at least, like I said it takes forever to dump so I did a small portion. Even better, I did a few dumps and it is consistent!

Well where am I going from here?I have some reverse engineering to do. I want to bypass the message that tells me to insert the "duplex unit" first off, the printer wont let me use it until I do that. I had tried to block the sensors that detect it but I had forgotten to take note of which was the right one so finding it has been a pain. If all goes well I could either just continue to use it just as a scanner or I could repurpose the board to do something fun with the motors. Its got a fully working wifi and bluetooth module in it so we will see what I can do provided I don't brick the thing. First things first though, I need to figure out how to speed up the dumping process because its an 8mb chip and I became impatient after a 3 hour dump try.

Well, good luck with that. You'd be better off getting a dev board for something similar, though.

On dumping: First off, you're running the serial port at 9600 baud. You need to get it as fast as possible, because that is your main bottleneck.

Also, you should dump it as binary, not hex - that alone will double your speeds. Note that you'll need a client on the PC to dump it to file; a lot of terminal clients don't do super well with binary.

Well, good luck with that. You'd be better off getting a dev board for something similar, though.

On dumping: First off, you're running the serial port at 9600 baud. You need to get it as fast as possible, because that is your main bottleneck.

Also, you should dump it as binary, not hex - that alone will double your speeds. Note that you'll need a client on the PC to dump it to file; a lot of terminal clients don't do super well with binary.

I would be better off with a dev board, but then there is no fun for me. And I swapped the baud rate to 115200 and its much faster (had no idea that such a thing would be a major bottleneck), I think I will just pop open visual studio and make a quick application to receive the data and output a file.

Well duh, 9600 bauds is just about 1 KB/s ... set it to 10 times that.

If you don't want to transfer binary data, get chunks of 32 bytes, add an extra padding byte and then do a base64 encoding of this sequence, converting it into 44 bytes. Stupid simple to do that in a microcontroller. You can then convert the output from the serial port to binary with a few lines in a php script or whatever flavor of programming language you prefer.

In addition to what it was already said to speed up the uart baudrate to 115200+ (230400 is easy to get on Arduino, some tries may be neccessary at 460800 and 921600) and transfer data in binary rather than ASCII, you may speed up the SPI clock from 4MHz to 8MHz (according to the eeprom datasheet, you can set the spi clock up to 50MHz) by using SPI.setClockDivider to 2 :http://arduino.cc/en/Reference/SPISetClockDividerIf you have a more powerful board than the Arduino, you may speed up the process, but hey, what's the fun in that!

You could save the dump of the memory with a serial client like Teraterm, but you may already have the necessary tools to do that.

I just get a quick look at your post, so excuse me if I had made any mistake. Good luck in you reverse engineering.

The 'mainboard' looks just like the one on the pic above, but without the NIC and connector.

What bugged me for a while, and still surprises me, is that they used USB as a data link between the boards.

So of course I traced the USB TX/RX lanes through the boards and concluded the mainboard's processor hosts the WiFi module and the card reader controller. That controller then hosts the PictBridge USB port and also the USB-Mini that links to the LCD/UI board.

Once the printer booted, I quickly swapped the miniA cable for one that was plugged to my Linux desktop (PC to LCD/UI board), and got a RNDIS link!

Gave it an IP, pinged fine at .6ms average, port scanned with SSH and Telnet active but filtered, one open port that I have to check again, and another open port which is UPNP 1900 which replied 404 to an http request.

A bit confusing, but this is how far I think I am now. Will get some sleep and eagerly wait to hear from you guys!