[ILUG] Reverse engineering serial protocol

[Dale Dunlea]

> Without a scope, there's not much you can do to detect baud 
> rate other than "suck it and see". However, if your rx baud 
> rate is too low, you'll just see gibberish; if it's too high, 
> you'll see bits repeated in what you receive (for example, 
> you'll never get a byte that reads 01010101 in binary, but 
> you could well get one that reads 0011001 or 00001111).

Well, that means I definitely don't have it set too high as I always get
a single-bit transition on the last byte of a transaction. That's good
to know.

> To reverse engineer a protocol, you're _much_ better off 
> eavesdropping on a functional dialogue than talking 
> gibberish, particularly where you have some idea of or 
> control over what's happening at application level (in this 
> case, poke the screen in different places!). Talking 
> gibberish to an unknown piece of driver software could well 
> crash it, which would be unhelpful.

I tried placing a software spy on the windows machine but none of them
seem to get in at boot time before the driver device locks the port.
Point taken about driver not likely being shouted at with random
gibberish.

> The optimal way to do this is to make up an eavesdropping 
> cable which has two extra connectors - each of these has one 
> of the data lines in question wired to its rx pin. Plug these 
> two eavesdropping connectors into two ports on your box, and 
> the normal two as usual, and watch the two serial ports and 
> write a program to poll both ports and output what comes in 
> on them - either to separate files with (accurate) 
> timestamps, or to stdout in a format that makes it clear 
> whence each byte came.

At this point, I begin to regret buying a small form-factor box with
just one serial port. Oscilloscope it is then.

Thanks,
Dale.