Revogi Smart Power Strip SOW323 , part two

After messing with the telnet interface for a bit, I managed to brick the device to the point it couldn't connect to the WiFi. Since I previously dumped the content of the SPI NOR, the obvious solution was to crack the device open and see what's inside.

It turns out there's no UART, no usable USB (the port is charge-only), no JTAG. But the SPI NOR is a nice SOIC8 chip, so let's pull it out. To make further experimentation possible, I wirebonded a DIP8 socket onto where the SOIC8 was and placed the SPI NOR itself onto a protoboard with DIP8 compatible footprint.

By using a SPI NOR programmer, I was able to reprogram the flash back with a working system image and the device boots again, great!

But looking at the cables coming out of the mainboard, there are two 4pin connectors on the board, white and black. You can see them between the USB port and the yellow transformer brick.

Poking at them with a scope turns, it turns out the top one is UART and the bottom one is just some power sequencing for something.

The UART is routed to a STMicro ARM chip controlling the relays and probably also the touch strip. The UART connector pinout is, top to bottom, CPU-to-STM data, STM-to-CPU data, GND, 3V3.

Using logic analyzer, it is easy to see the protocol. The CPU seems to be polling the STM all the time for what looks like the status of the sockets.

The polling protocol looks really trivial:

CPU sends:
0F 04 05 00 00 06 FF FF

STM replies (sockets off):
0F 04 05 00 00 06 FF FF
0F 04 05 00 00 06 FF FF

CPU sends:
0F 04 05 00 00 06 FF FF

STM replies (socket 1 on):
0F 04 05 00 01 07 FF FF
0F 04 05 00 01 07 FF FF

So presumably, byte 4 indicates socket status. Since byte 0, 0x0f, is in all frames, this is likely some preamble. Same for trailing byte 6 and 7, 0xff, is likely some end of frame indicator. Bytes 1, 2, 3 are likely some command field, while byte 5 might be a checksum of sorts.

Now, to make fiddling with the system easier, I figured how to stop the "switch" process which is hogging the ttyS0. Just replace /bin/switch with /bin/sh in /etc/inittab. I'm not convinced this is the right solution, but it does it's job. After a reboot, /dev/ttyS0 is available, so let's try sending the same poll command:

# /tmp/busybox stty -F /dev/ttyS0
speed 4800 baud; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ;
swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O;
min = 1; time = 0;
-brkint -icrnl -imaxbel
-opost
-isig -icanon -iexten -echo

# /tmp/busybox hexdump -vC /dev/ttyS0 &

# /tmp/busybox echo -en '\x0f\x04\x05\x00\x00\x06\xff\xff' > /dev/ttyS0
# 00000050  0f 04 05 00 00 06 ff ff  0f 04 05 00 00 06 ff ff  |................|

The reply looks sensible, great! Now we can talk to the socket without needing the proprietary application. Further protocol analysis will be needed.