Back to Projects Page

The Sign Project - Cracking the Checksum

This page describes my struggle with determining a checksum being used in an old digital sign I wish to use in some projects of mine. Once the checksum is figured out, I hope to add more information about the project as it becomes available.
Let me warn you up front: This may be a long and boring read!

UPDATE!  (4/20/09)

Hello! Although this page is quite old, I am still around and people still occasionally ask me about these signs. I still hope to someday redo this page and add some additional information and details, but until that ever happens, please feel free to contact me at the email below.

UPDATE!  (8/8/03)

Wow....It's been over a year since I've updated this page yet I've had a pretty steady interest in this over the past year. It's amazing how many people seem to have these signs. I've had some working code that I'm currently using with my sign. It's not ideal, but it works and is better(for me) than the DOS based program. I figured I should finally get off my ass and make it available to anyone interested. It's available HERE.

UPDATE!  (7/24/02)

Thanks to the help of several Slashdot readers, the checksum has been cracked and I've been able to write code to control the sign on my FreeBSD machine! I will put up the code and more information soon. The first new feature I've implemented is web based messaging.

Background:

I have a large LED digital sign and am trying to write software to control it. This "SilentRadio" sign, approximately 15 years old was manufactured by Cybernetic Data Products, who don't seem to be in existance today. The sign gets its data from a computer using a standard serial interface (2400 8N1 for what it's worth). This is a one way communication path and the sign sends nothing back to the computer.

The DOS based software (available below) that came with it does work, but doesn't do exactly what I want. I'm attempting to write custom software for my FreeBSD box to allow automatic news, weather, and stock updates and to display various system statistics. The sign is on top of the entertainment center in my apartment, and gets viewed by alot of people, therefore I'd also like to include a web or e-mail interface so people can send messages to us via the sign. I also have a barcode scanner which I would like to incorporate so I can display information about certain scanned items. If I ever figure out the checksum to the sign, I'll be able to fully implement all of these functions and then some.

Currently I am accomplishing some of this by using macros on a Windows box to cut and paste data into the DOS program every hour or so. Unfortunately, its rather unreliable and the computer can't be used for too much else when the macros are active.

Details:

I have intercepted the data that is sent from the DOS program and have figured out how to recreate most of the serial packet in my own program. A command is sent to the sign containing the format of the message and the "slot" to place the message in. A message can contain multiple sets of text in different format. Currently I've only been concentrating on packets which conatin a single set of text. Each packet is exclusive of one another and doesn't depend on any other packets sent previously. I hope that once I figure out this simple case, the more advanced modes will be trivial. Below is an example of one of the packets and what I believe to be the meaning behind some of these bytes.

00 00 00 00 00 00 00 FF 35 35 00 0E DA BC 01 00 00 08 00 19 02 54 45 53 54 1F 8C 52

The 3 main things that can be changed by the user via the program are the following: the message slot number, the text style, and the message itself. The first 11 bytes seem to always be the same and are some sort of packet header. Bytes 12 and 18 represent how much longer the packet is from that byte. Byte 14 changes, but for an unknown reason at this time. Byte 15 is the slot number, 21 is the style. Byte 22 signals the beginning of the message, and then the message, followed by 1F, then the elusive 2 byte checksum. The above example sends "TEST" to slot 1.

I've collected some additional packets of data and have the data available further down this page. These probably aren't the best choices for testing, but its all I collected at the time when I was working on it.

The biggest problem I am having is figuring out the 2 byte checksum at the end of the serial packet. I have not had much luck figuring this out, although my experience with this sort of thing is rather limited.

I can't imagine it being too complex, as the processor on the sign is only an 8 bit 6502 and probably doesn't spend too much time computing it. I am unsure whether these bytes are 2 seperate 8 bit checksums or a single 16 bit checksum.

What I've Tried:

I've done some simple math on these bytes to try to recreate the mysterious checksum but have yet to be successful. These include a combination of XORing, adding, negating, and inverting the bytes. I've also experimented with a few CRC algorithms. I've also tried using only certain parts of the packet, such as the text itself, every other byte, and reversing the packet order before calculating anything. I've also tried using only certain parts of the message in calculating the checksum. Eventually I'm hoping that a combination of one or more of these techniques may yield the solution.

Although an unlikely way to solve the problem, I've played around with the idea of disassembling the 6502 code embedded into the sign. I've dumped the sign's ROM as a binary file available further down the page. Unfortuantely this requires knowledege of the 6502 assembly language and a decent knowledege of the memory map of the system, which I have had little luck decoding as of yet. If able to disassemble and understand the correct portion of code, I was hoping I could find the algorithm being used for the checksum or either disable the checksum check altogether. The other idea would be to do a similar disassemble of the DOS program, but this seems like an even harder task to take on.

Files:

Some files to play with if you are interested:

Spreadsheet containing data I collected: sign.xls sign.htm

The DOS based sign software: sign.zip

Binary ROM image of sign's firmware: sign.bin

Conclusion:

Although I'm not too optimistic about anyone figuring this out, I've put this page here for anyone wanting a challenge. Who knows, maybe I'm just missing something simple and someone will see the pattern immediately. If you have any clues or think you've found the solution, please let me know. I appreciate any help you may have to offer with this project. If you need clarification, additional information, or just have a question, I'm more than willing to help.

Last Updated: 8/8/03

Contact me: projects@dickwick.com