1. HS100 - Wi-Fi Smart Plug

    For my recently installed PXACB I was looking for a way to remotely power it on and off. I found the Wi-Fi Smart Plug "HS100" and a blog post that it can be controlled from the command-line.

    The referenced script uses captured results from wireshark and just re-transmits these messages from a shell script. In one of the comments someone points out that this is XOR'd JSON and how it can be decoded. Instead of a shell script I re-implemented it in Python and I am now always using XOR to encode and decode the JSON messages without needing to include the encoded commands in my script. This makes it easier to read the script and to extend the script.

    The protocol used is JSON which is XOR'd and then transmitted to the device. Same goes for the answers. The JSON string is XOR'd with the previous character of the JSON string and the value of the first XOR operation is 0xAB. Additionally each message is prefixed with '\x00\x00\x00\x23'.

    The message to turn on the power looks like this:

    {
     "system": {
      "set_relay_state": {
       "state": 1
      }
     }
    }
    

    To find more about which commands the device understands I used the information I got from: Why not root your Christmas gift?

    I downloaded the firmware for the US model of my smart plug and used binwalk to analyze the content of the firmware. The firmware contains busybox based ramdisk which includes the smart plug relevant programs /usr/bin/shd and /usr/bin/shdTester and it seems at least following commands exist:

    • system
    • reset
    • get_sysinfo
    • set_test_mode
    • set_dev_alias
    • set_relay_state
    • check_new_config
    • download_firmware
    • get_download_state
    • flash_firmware
    • set_mac_addr
    • set_device_id
    • set_hw_id
    • test_check_uboot
    • get_dev_icon
    • set_dev_icon
    • set_led_off
    • set_dev_location

    With the knowledge from the original shell script implementation and the results from binwalk I wrote the following script: https://lisas.de/~adrian/hs100.py

    Using this script I can power the device behind the smart plug easily on and off:

    $ ./hs100.py -H p-pxcab.example.com off
    $ ./hs100.py -H p-pxcab.example.com state
    Power OFF
    $ ./hs100.py -H p-pxcab.example.com on
    $ ./hs100.py -H p-pxcab.example.com state
    Power ON
    

    The only annoying thing about the smart plug is, that it tries to communicate with some cloud systems so that it could be controlled from anywhere. After starting the smart plug it makes a name lookup for devs.tplinkcloud.com and connects to port 50443. I can connect to that system with openssl s_client -connect devs.tplinkcloud.com:50443 but what the smart plug actually sends to that system I do not know. If I do not block the smart plug in the firewall I see a NTP request after that and then the communication seems to stop. Right now the smart plug is blocked and does no NTP requests but it still tries to reach devs.tplinkcloud.com:50443 once a minute.

    Tagged as : pxcab
  2. PXCAB

    A long time ago (2007 or 2008) I was developing firmware for Cell processor based systems. Most of the Slimline Open Firmware (SLOF) has been released and is also available in Fedora as firmware for QEMU: SLOF.

    One of the systems we have been developing firmware for was a PCI Express card called PXCAB. The processor on this PCI Express card was not the original Cell processor but the newer PowerXCell 8i which has a much better double precision floating point performance. A few weeks ago I was able to get one of those PCI Express cards in a 1U chassis:

    PXCAB

    This chassis was designed to hold two PXCABs: one running in root complex mode and the other in endpoint mode. That way one card was the host system and the other the PCI express connected device. This single card is now running in root complex mode.

    I can boot a kernel either via TFTP or from the flash. As writing the flash takes some time I am booting it right now via TFTP. Compiling the latest kernel from git for PPC64 is thanks to the available cross compiler (gcc-powerpc64-linux-gnu.x86_64) no problem: make CROSS_COMPILE=powerpc64-linux-gnu- ARCH=powerpc.

    The more difficult part was to compile user space tools but fortunately I was able to compile it natively on a PPC64 system. With this minimal busybox based system I can boot the system and chroot into a Fedora 24 NFS mount.

    I was trying to populate a directory with a minimal PPC64 based Fedora 24 system with following command:

    dnf --setopt arch=ppc64 --installroot $PWD/ppc64 install dnf --releasever 24

    Unfortunately that does not work as there currently seems to be no way to tell dnf to install the packages for another architecture. I was able to download a few RPMs and directly install them with rpm using the option --ignorearch. In the end I also installed the data for the chroot on my PPC64 system as that was faster and easier.

    Now I can boot the PXCAB via TFTP into the busybox based ramdisk and from there I can chroot in to the NFS mounted Fedora 24 system.

    The system has one CPU with two threads and 4GB of RAM. In addition to the actual RAM there is also 256MB of memory which can be accessed as a block device using the axonram driver. My busybox based ramdisk is copied to that ramdisk and thus freeing some more actual RAM:

    # df -h
    Filesystem         Size    Used Available Use% Mounted on
    /dev/axonram0    247.9M   15.6M    219.5M   7% /
    

    System information from the firmware:

    SYSTEM INFORMATION
     Processor  = PowerXCell DD1.0 @ 2800 MHz
     I/O Bridge = Cell BE companion chip DD3.0
     Timebase   = 14318 kHz (external)
     Config     = SMP disabled
     SMP Size   = 1 (2 threads)
     Boot-Date  = 2016-07-21 19:37
     Memory     = 4096MB (CPU0: 4096MB)
    

Page 1 / 1