Reverse Engineering of a Graphics Format?

Jimbo God of Unix asks: "I recently purchased a color laser (Samsung CLP-500) because it claimed to have Linux compatibility. It does, mostly. However, I was irritated to find that the drivers are proprietary (splc, Samsung Printer Language - Color) and somewhat cranky to get working. I was hoping to find some good resources on reverse engineering the graphics format used to drive the printer. I've managed to mostly dissect the file format, so I think I can get the graphics data out, but I don't really know how to proceed to the next step. Are there any good resources for figuring out how to reverse engineer the graphics format? Are there any tools out there that will help me analyze the format (other than hexdump) or tell me if it's close to something else so I don't have to do as much work?" "I have something of an advantage since I can compare the output from the Windows driver to the Linux driver, and I was able to dissect the Windows output file from the info gleaned by dissecting the Linux output file. But I'm kind of stuck at the moment and there don't seem to be too many documents or tools out there for dissecting graphics data.

I thought this might be useful for reverse engineering some of the proprietary image compression formats for web cams as well, but that's a project for another day."

Comments

A few general hints?

[Myself]

If there's a chance it's a plain bitmap, simple visualization can reveal lots of patterns not evident in a hex dump.

I believe the old wardialing tool Toneloc had a mode, or a companion program, to display logs this way. It was easy to see things like "numbers ending in -0100 never get answered" as a vertical red line, for instance.

The important things would be an adjustable margin, to "wrap" the pixels at varying widths, and adjustable bit depth, so you can discover odd packings that might not otherwise be apparent.

If the data might be compressed, have a look at the article Hacking Data Compression for a great, if slightly dated, conceptual overview.

ERANAI (I am not a reverse engineer), but I hope this helps. Let us know if you have any luck!

Check linuxprinting.org first

[Scarblac]

I can't help you with your question, I have no experience with reverse engineering.

But for others who don't want to have the same problem: you should have checked www.linuxprinting.org, which says of the Samsung CLP-500:

Samsung supports this printer with proprietary drivers which come with the printer on its driver CD or can be downloaded on the web sites of Samsung. Unfortunately, these drivers do not work necessarily with all Linux distributions and there are no free drivers available. As it is also not sure whether Samsung will update their drivers for future Linux versions, this printer cannot be recommended.

I would try to get the proprietary driver to work, basically by getting the distro it was made for, or at least finding out why it works there but not on your distro - probably it needs some specific kernel image that it was compiled with, which would suck...

This isn't really helpful, but...

[xenephon]

You should have bought the CLP-550. I avoided the CLP-500 for just this reason (and the fact that I heard bad things about its OS X support, as well). The CLP-550 supports Postscript, and works fine from my Mac, my Linux box, and my Windows box. Another advantage to the CLP-550 over the 500 is that the 550 comes with full toner cartridges; the cartridges which ship with the 500 are only half full.

I don't understand how companies can sell printers that don't support Postscript. On the other hand, this seems to be a case where a company heard complaints from its customers, and corrected thier bad practices (the toner issue, and Postscript support).

Be Methodical

[maeglin]

If it's a head control language or something you might in trouble, but if it's simply an image being sent you should be able to figure it out eventually.

The best way to reverse engineer a graphics format is to use a collection of sample images to get a high level idea of what is going on. Choose the images in a way that will give you the most information.

Make sure the printouts always the same size, layout, color depth, margins, etc. It does no good to compare an A4 grayscale image to a color letter sized one.

If you're operating under the assumption that it's a simple bitmap, the following may work.

1. Is it compressed?

Print out a page with some dots on a colored background.

Print out a page with more dots on it.

Are they the same size?

If so, most it's most likely a bitmap.

If not, it's probably compressed.

What type of compression is it?

Print out a page which is half white, half another color.

Print out another page which is checkered (with *very* small squares) half white, half the other color.

Is one smaller than the other, if so it may be compressed. If it is, it *could* be Jim-Bobs compression algorithm, but programmers are lazy so it's most likely something off-the-shelf.

If it's the half-and-half print that is smaller, it's either RLE or something like JPG (most likely RLE as JPG is lossy -- compare a gradient print to find out if it's RLE or not).

If it's the checkered print then it's probably LZW.

If neither is smaller, re-evaluate your compression assessment.

2. Create a decompresser to test your decompression theory.

Print a colored page.

Print a second colored page a couple of changes.

If you can't create two data dumps of (relatively) equal size from the input data, you're probably wrong about the compression algorithm.

If they are the same size you may be going in the right direction. (If they're exactly the same size be very happy).

3. Guestimate packing.

Print a cyan* page, a yellow page, a magenta page and a white page. Take a look at the first four bytes or 16 bit words. If you've got clearly observable patterns (ff 0 0 0; 0 ff 0 0; 0 0 ff 0; etc.) you're in luck. If not try to work out the packing order. Just keep in mind, if it's a bitmap, and you've got the decompression down, and the page is one color *eventually* you will find a repeating pattern that represents that color.

4. Visualize the decompressed data.

The best way from this point is to find a way to visualize what you've got. In the past I had stock BMP code that I would use to generate a new displayable image, but I've also created custom apps to display it.

If the resulting image looks right but is a funky color, it's packing.

If the resulting image looks like it *could* be close but has a lot of shear, play with your assumed width and height.

If it looks like static and you've previously determined that you're dealing with 16 bit values, try changing the byte order and try again.

5. Lather, rinse and repeat.

Despite what the nay-sayers want you to do. Don't give up. Figuring out someone's attempt to hide data from you is a reward you give yourself. Even if it takes days or weeks, when the light goes on and you think, "Ah ha! I've got you now you bastard!", it makes the time worth it -- at least for me it always did.

Besides, if you do get it working, you can release it and make Open Source better by your efforts.

* Remember, it's cmyk, not rgb.