Project Logs

Collapse

• Dumping the SPI EEPROM

  Retroplayer • 05/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

  Retroplayer • 05/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!

  Retroplayer • 05/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

  Retroplayer • 05/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