Close
0%
0%

Vorne XL800 LED Display (32x80)

Attempting to hack this LED message Board
Help appreciated!

Similar projects worth following
While browsing around at the local electronics recycler, I stumbled on a LED display for $15, figuring it might make for a fun project.

The display is a Vorne Industries XL800 "Productivity Appliance" Model XL800-32080T.
It features a 32x80 tricolor (Amber, Red, Green) LED matrix or 4 line x 80 columns.

It turns out this particular display has a webserver built in! However, the software running in it is specifically geared toward Lean Six Sigma productivity metrics used in a factory environment.

This project is my attempt to reverse engineer the display and develop my own web interface to make it general purpose.

I am guessing that is probably running Linux.

The CPU is a Cirrus Logic EP9302 ARM9 SoC

Flash: Cypress S29GL256P 256Mb (32 or 16MB - need to check if 16 or 8 bit mode)

RAM: Micron 48LC16M16A2 256Mb DRAM

EEPROM: 25P05VP

Interfaces include:

1 Ethernet

2 serial ports, one configurable as RS422/RS485 isolated or RS232. The other is RS232 only.

8 programmable discrete inputs

1 relay output

Expansion boards available to add more inputs and outputs

ARM JTAG header

Option 1 and Option 2 headers (for the expansion boards)

2 additional DISPLAY headers, I am assuming to run additional matrix boards.

The display appears to be handled by a Xilinx FPGA with no configuration rom on the board, so it must be loaded at run time.

The SoC also has two USB host ports available, but they are not being used.

I have mapped out the JTAG header

12 pin SMD pads

1Prst2Vdd
3GND4Trst
5GND6TDI
7GND8TMS
9GND10TCK
11GND12TDO

I have scanned for all open ports on the ethernet interface and only port 80 (the webserver) and port 4001 (labeled as binary interface in the configuration screen.)

The manual states that there is a bootloader mode activated by setting DIP switch 8 to the OFF position. You then use serial port 1 and a tool supplied with the display (I didn't get a CD)

I have tried tapping in to the serial port to look for any activity in both boot-loader and normal mode. No activity present.

ep9302.ibs

ibs model for the EP9302 for JTAG

ibs - 306.04 kB - 05/22/2016 at 20:46

Download

Developer Guide.pdf

SQL and JSON details for using the built in query API

Adobe Portable Document Format - 380.51 kB - 05/22/2016 at 20:46

Preview
Download

U7 25P05 SPI EEPROM.pdf

Datasheet for the SPI EEPROM

Adobe Portable Document Format - 376.67 kB - 05/22/2016 at 20:45

Preview
Download

Flash S29GL256P.pdf

Datasheet for the main flash memory

Adobe Portable Document Format - 1009.21 kB - 05/22/2016 at 20:45

Preview
Download

SoC EP9302.pdf

Datasheet for the SoC

Adobe Portable Document Format - 534.12 kB - 05/22/2016 at 20:45

Preview
Download

View all 6 files

  • Dumping the SPI EEPROM

    Retroplayer05/29/2016 at 01:59 0 comments

    After quite a fuss, I was able to finally dump the SPI EEPROM, and... blank. I shouldn't be surprised. If there were something stored in it, I would have had some type of console access.

    I guess since it is empty (and I needed to remove it from the board to dump it), I will be replacing it with a serial NOR flash a bit larger than the 64K.

    I am in search of either source code to build U-Boot for this processor or some binary, but it seems very few have messed with the SPI boot.

  • Bootstrapping

    Retroplayer05/22/2016 at 23:54 0 comments

    So....

    BOOT0 is the pin to flip if you want to get into UART boot mode. It is indeed traced out to DIP Switch 8. However, this boot mode is the same for SPI EEPROM mode. If it is HIGH, then it will look for the UART and then the SPI EEPROM. If it is LOW, then it will load from the main flash memory.

    The boot flow is to first check the UART for 2048 characters. If it receives 2048 characters, then it loads that into a buffer and executes.

    If it does not receive anything from the UART, then it checks for SPI EEPROM with "CRUS" or "SURC" at the front of the EEPROM. If this header is present, then it continues to load 2048 bytes into a buffer and executes that code. That code could then load the rest of the contents of the EEPROM.

    The board does have the EEPROM installed, so it is possible that there is some custom boot code in there that runs when the DIPSW 8 is flipped.

    So there are two ways to bootstrap the SoC.

    I have also confirmed that the data bus width is set for 16 bit, so the the flash and RAM are 16MB.

    Since I am looking for the least intrusive attack vector (and un/soldering that 56 pin TSOP is not on my fun list) my next move, I think will be to dump the contents of the EEPROM and see if it is boot code.

    My target, of course, is to dump the flash memory. I'm going to poke around a bit to see if I can find some already spun code to save me some time and hassle.

  • Doh!

    Retroplayer05/22/2016 at 21:55 0 comments

    Reading a little further, I stumbled on the "User Guide" for the EP9302, which details the boot process.

    In section 4.1.2.2, it details how the internal boot room chooses which method to continue booting from. One of those modes is to read 2048 characters from the UART, put them in a buffer, and then execute that code.

    The boot ROM will output a "<" character when it is in this mode. I did, indeed see this character when I was poking around in the boot loader mode, but I had attributed it to garbage characters from turning power on/off.

    So, we have a possible attack vector by loading up to 2K code through UART and executing it. Since the flash memory is a 56 pin TSOP and I do not have the appropriate adapters for that yet, I am going to look into putting together a little program that can dump the memory over the UART.

    And..... it appears the EP9302 is used in the Vex Robotics platform. I'm going to bet that someone has already wrote some code I am looking for! :)

  • Next steps

    Retroplayer05/22/2016 at 21:14 0 comments

    What I have tried so far:

    Poking at the serial port looking for activity in boot loader and normal mode -Failed

    Wireshark sniffing on the ethernet interface - Nothing interesting

    Port scan on the ethernet interface - Port 80 and 4001 are open

    Lifted CS# on the EEPROM hoping it might force the display into some mode were I can talk to it over serial. No noticeable affect on operation, strangely.

    So, I have not been able to find any attack vectors so far. There is the firmware update mode that could be explored a bit, but without the software tool, no firmware images, and no activity present on the serial port, I am completely blind.

    I suspect that there are additional factory pages in the webserver, but I do not know of any way of finding hidden pages, so one would need to know the URL.

    The next step, I suppose, is to dump the flash memory and have a look. Things to look out for will be filenames, signs of Linux, etc... if it is a known filesystem, it might be possible to to patch in SSH.

    Another adventure would be to JTAG into the SoC and look at the 16K internal boot rom.

View all 4 project logs

Enjoy this project?

Share

Discussions

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates