Revised Rich Header Parser

I've revised the rich.py script. It's much better but doesn't actually do anything more than it used to. I'll be making some more additions in the very near future, but I wanted to post this before I misplaced it.

New script here: rich.py

Fujitsu Lifebook B3020D Touchscreen and Linux

(I actually did this at the tail end of 2009, then I revised the python script it in 2010. I've been thinking of attacking the problem with un-smooth lines when the cursor is dragged...)

A friend gave me one of these Fujitsu B3020D Lifebooks. It's quite beat up. No, really, the screen is cracked in the lower left corner and a failing hard drive or bad RAM requires that I reboot the thing periodically. It's currently running Windows 7 and Skype with a Zoom adapter so I can plug cordless telephone bases into it. But before that, it was running Ubuntu. It ran Ubuntu for a good week to a week and a half. The touchscreen didn't work on it, and the screen was cracked even then, but it wasn't a bad little system. The battery life was good, the wireless worked without having to fight with it, and I thought it would be fun to reverse engineer the touchscreen and write some kind of mouse driver.

It didn't take me long to see that the touchscreen is actually exposed to the system as a serial device. That's damn cool. If you just start cating out the serial ports at the console and then touching the screen, you'll eventually see it spew a bunch of numbers. That's how I figured out which serial port it was using. After that you can pretty much tell what the values mean just by trial and error. There's a byte that indicates the type of event (push/release/drag) and then a series of bytes indicating the x and y coordinates. I suggest piping the output of cat through xxd in order to see the byte values in hex. For example: cat /dev/ttyS2 | xxd -

I don't recall from memory what the different byte values were, but you can kind of tell from the python script I wrote for it. This script reads the touch screen and will tell X11 to move the mouse around the screen and click the left mouse button in pretty much the way you would expect it. However, if you run the gimp or some other paint program, you'll notice that touching and dragging results in a rather imperfect line. Instead of nice diagonal lines, you get these crazy little semi-circles. If I ever get a second system set up to run my Skype phone (or can borrow another one of these laptops,) I'll revisit the script and see if I can fix it, but otherwise it works okay.

Here's the script via pastebin: touchmy.py

SEN-08634 Magnetic Card Reader/Writer

The SEN-08634 Magnetic Card Reader/Writer is exactly what it sounds like: it reads and writes to magnetic strip cards. SparkFun has them.

This device will connect to your host as a serial device (/dev/ttyUSB0, for example) but if you try to cat it out, it will immediately return. The damn thing doesn't buffer! Well, okay, that's not true, it will buffer, but it throws the buffer away after a very short period of time. So, if you wanted to use the device with some clever bash scripting, you would have to do something like while [ "1" ] ; do echo -n `cat /dev/ttyUSB0` ; done

I didn't actually try that command while I had the device, it didn't occur to me until just now.

Anyway, I borrowed one of these and wrote a python script that can use it. It reads high coercivity cards and reads and writes low coercivity cards, but that's about the only thing that works. For some reason, all the commands that the documentation claims should work don't return anything. My script is heavily commented and I don't recommend simply running it unless you're ready to lose the data on whatever card you swipe through it. The main body of the script will attempt to write hello world to track 1 and then a couple strings of numbers to track 2 and 3. It will not backup what's on the card before writing. That didn't occur to me either. I don't have the device any more, so I'm not going to update the script.

Here's the script via pastebin: magstripe.py.
If you want to see documentation for it, you can do something like this: doxygen -g magstrip.doxy ; doxygen magstrip.doxy

Diablo 2 Cloner GUI

I threw this together just for practice, though not very good practice since it spits most of the output to the terminal... It uses GtkBuilder under python so it requires the Gtk runtime in addition to python.

This is the file to run: d2gui.py
Here's the file that does the actual work:d2functions.py
And here's the interface xml document: d2gui.glade

Rich Header

The Rich header is that bit of data in a Portable Executable (PE) File^[1] that follows the DOS Stub, but preceeds the actual PE Header. It's format is only documented in a handfull of places on the searchable net, and that documentation isn't terribly in-depth.^[2] This post tries to shed some light on the Rich Header, but I fear it poses more questions than it answers.

While looking into the format of the PE Header, I became curious about an odd collection of consistent data in PE files produced by Visual Studio. It always began with the word Rich, and it wasn't in any of the documents made public by Microsoft. After spending some quality time with google, I found a bunch of references to the Rich header, but nothing described it in depth. Most just said it wasn't used by Windows and could be safely removed to save a few bytes. So I gave up.

Later on, I was reading something about anti-disassembling that discussed some fun modifications that one could do to a PE File. I don't recall where I saw this document^[3], as it occurred quite some time ago, but it basically dealt with crashing various debuggers and disassemblers. At one point, this document talked about how the Rich header had been used in some court case to attribute a virus to its creator. That was all the document said, and THAT got my attention.

Some additional quality time with google eventually led me to the forum posting^[2] by lifewire, who I'm assuming is some russian hacker or something. It described, with a couple of confusing typos, a little bit more information about the Rich header. In fact, most of what will be described here can be ascertained by reading his rich.txt file. (I'd post that file, but I haven't figured out how to put up attachments.) Unfortunately, I couldn't get the details through my thick skull without taking his document and firing up a free copy of IDA Pro^[4] to disassemble the link.exe file provided in Microsoft Visual Studio .Net 2003.

Using IDA Pro and frequently referring to lifewire's rich.txt file, I learned that the Rich header begins with a marker, a checksum that is repeated three times, some encoded values, the word Rich in ascii, and finally ends with the checksum value, again.

The encoded values are "comp.id" fields from Visual Studio. I don't entirely understand them, and they're really key in making the Rich header forensically useful. For every library file that is linked against, for every object file that is compiled in, and for every tool in Visual Studio that touches data in the build process, there is a compid that is recorded.^[5] Some of the Visual Studio tools have an associated compid. These compids are encoded along with an occurrence count. So the format of the encoded data in the Rich header is compid XOR checksum followed by the number of times that compid is referenced XORed with the checksum. That is, the compid is XORed with the checksum and then the occurrence count is XORed with the checksum, and then these values are written to the header.

The checksum itself is computed by iterating over every byte of the DOS Header, skipping the elfanew field, copying the byte into a 32-bit field, rotating the field left by the field's offset in the PE header, and then adding that to a sum. But that's not all. Next, that sum is then added to each compid XORed with its occurrence count. That is, the 32-bit sum is added to the value resulting from compid XOR occurrence, for every compid in the list.

The last detail I have is that the marker that appears at the beginning of the Rich header is the checksum value that was computed XORed with 0x536e6144. (Note that it's DanS in ascii; another name to put with MZ and Rich.)

So what does the Rich header tell us about the executable? It can tell us how many different object files, libraries, and tools where used to create the executable. What additional information could it tell us? If one were to create a table of compids and the corresponding components in Microsoft's tools, the Rich header would tell us what tools were used to create that executable. Additionally, by verifying the checksum, one can make guesses about whether the PE file were modified. I suspect that a table of components used to build the PE might provide enough details to extrapolate whether the executable itself were modified manually by testing to see if the object files and tools that were specified by the compids actually left a mark on the rest of the PE file.

In closing, here's some python (forgive it's rough edges, I'm new to python) that parses compids from PE files: rich.py via GoogleDocs

EDIT: here's a revised one via pastebin: rich.py

Sources:
[1] PE Coff Format Spec
[2] Forum Posting of rich.txt by lifewire
[3] If anyone recognized this description, please post a comment!
[4] IDA Pro Freeware Download
[5] This was speculation incorrectly included as though it were fact -- and it's false