Some time ago I got two iSP5 Smart Plugs for $30 each. The plugs can be controlled from dedicated iHome apps on iOS and Android. They also work with Apple HomeKit and Amazon Alexa. It’s great but I use OpenHab2 on Raspberry Pi 2 to control my smart home devices and there’s no integration/plugin for the plugs. I was wondering if it would be possible to reverse engineer the iHome API and write a small script to control the devices. The first thing I did was running nmap port scanning against one of the plugs which were connected to my WiFi.
Victory! … well not really. Two ports are open. HTTP port always returns 404 so it’s not very helpful yet.
The zeroconfig / mDNS/ Bonjour service on port 5353 tells us something interesting about the service being announced by the device. I checked mDNS packets in Wireshark and also installed Bonjour Browser on my OSX to see more details. mDNS tells us a service specification. In this case, it is HAP on TCP on port 80 on a device with IP 192.168.0.5. HomeKit Accessory Protocol (HAP) is what Apple desinged to control smart devices.
I know that the plugs can be controlled from my iPhone without the internet connection. It means that the iHome app must be able to talk to them directly. Interestingly, iHome Android app doesn’t work without the Internet. It’s a hint.
iHome iOS app uses the device HomeKit API directly when there’s no access to the internet. The Android app doesn’t support HomeKit and doesn’t work when the phone is offline but in the same WiFi with the devices.
I think the smart plug has only one API available directly over the local network and it’s the HomeKit API. HomeKit API has a very strong security and it’s close to impossible to hack. So how does the Android app work? The Android app sends the commands to iHome REST API in the cloud and they get passed to an MQTT channel. The plug, when it’s in WiFi with access to the Internet syncs its status with an iHome MQTT server. That is actually a quite good news. It is possible to sniff the API calls from the app and write a little script to replicate them.
Sniffing iHome REST API
There are many ways to sniff network traffic from a mobile phone. The simplest way is using Charles Proxy. You have to install a Chares Proxy ROOT cert on your phone in order to sniff the encrypted HTTPS traffic. More about it is on https://www.charlesproxy.com/documentation/using-charles/ssl-certificates/ The root cert can only be installed from Safari!
The downside of this method is that it only works for HTTPS traffic which goes on port 443. The mobile app may not respect the proxy settings or use cert pinning. Cert pinning is the worst case since the app will NOT respect the fake temporary cert signed with the Charles ROOT cert installed on your phone.
Another method of sniffing is a bit more complicated and involves MITM attack. MITM allows for sniffing the entire network traffic from the phone on any protocols and ports. I wanted to test this method first to make sure that there is nothing unexpected going on there like the app talking to the API on an unusual port or protocol. It will give me some certainty that the Charles Proxy method will be effective. Ettercap and Wireshark are the right tools for the job.
You can install Ettercap with Brew on Mac.
Download and install Wireshark from https://www.wireshark.org/
Start Ettercap with
Add a mobile phone IP 192.168.0.4 to TARGET GROUP 1
Add a smart plug IP 192.168.0.5 to TARGET GROUP 1
Add ROUTER IP 192.168.0.1 to TARGET GROUP 2
Go to MITM menu and select ARP Poisoning and as a parameter type remote in order to sniff all the traffic from the victims’ devices not only the direct traffic between them.
Ettercap should start ARP poisoning. The ARP protocol is used to resolve an IP address into a MAC address and the other way around. Ettercap floods the network with spoofed ARP packets which will reach both Target Groups network interfaces and tell them that a MAC address for the opposite group IPs is a MAC address of an attacker computer. In this case, it’s my Mac 192.168.0.2. It allows for sniffing all the network traffic between the victims and remote servers. Network packets in an ethernet network are sent to their destination based on a destination MAC address.
This attack works because Ettercap sends many fake ARP packets per minute and they always poison a local ARP cache on a victim machine. The phone, the router, and the smart plug still announce their IPs with ARP but it happens with a much longer interval. So even if a victim’s local ARP cache gets updated with a correct MAC->IP data, it will be immediately overwritten by the constant flood of spoofed ARP packets.
ARP poisoning on its own is not enough. Luckily, Ettercap also handles packet routing to the correct IPs/network interfaces after they arrive on the attacker network interface. That closes the loop and allows the traffic to flow to its intended destination.
I used Wireshark to make sure that the only traffic between the Andriod phone with iHome app is to and from the iHome REST API. That is the case.
Next, it’s time to sniff the iPhone traffic. I opened up the iOS iHome app and switched the plug on and off. The app did not send any packets directly to the smart plug. Instead, all the requests were sent to https://api.evrythng.com/ and https://www.ihomeaudio.com/api/v3/login/. Unfortunately, those requests go over HTTPS and we can’t see their content yet.
The theory is confirmed. The iHome app talks directly to the iHome REST API. iOS app has an ability to use the HomeKit API and directly talk to the devices in the case when there’s no access to the Internet. It’s time to sniff the HTTPS calls with Charles Proxy.
Here is a diagram presenting my network configuration.
After I installed Charles Proxy on my Mac 192.168.0.2, I changed my iPhone WiFi configuration to use the proxy.
I also activated Charles ROOT cert.
When I started the proxy on my Mac I had to enable the SSL proxy for the two API domains otherwise Charles wouldn’t be able to see the content of the requests.
Next, I opened up an iOS iHome app and logged out and tried to log in with some fake credentials just to see what is going to happen.
Success! We captured the login request. The response with the invalid creds gave me 401 Unauthorized …
but the correct creds worked
and the response I got looks like this.
Ok, so we got a token and an API key. everythng_api_key and evrythng_api_key values are the same. It’s probably a typo and the developers had to keep two keys for backward compatibility.
Let’s sniff more traffic. When the app UI loaded a few more requests were made. Notice that www.ihomeaudio.com API is only used to obtain the token and the API key. Not sure what the token is for. From now on the app talks to api.evrythng.com and always passes in the API key in the Authorization header. I played around for a while and this is what I discovered.
Get a list of all iHome products and their IDs.
Get a list of devices paired with your account.
Get a power history for a device.
And finally, this is how the plug can be turned off…
…or turned on.
At this point, I got all I needed to write a Nodejs app to control my iHome smart plugs. I’m going to write a separate post about the node app later. Those of you who want to integrate iHome smart plugs with OpenHab or Domoticz can use my API calls examples and build dedicated plugins. I hope this was interesting. Stay tuned for more.
EDIT: I got an email from Jeremy firstname.lastname@example.org who use my my tutorial to hack his iSP6 smart home plug. He sent me those two example requests to turn on/off the plug. If you have more questions about iSP6 please contact him.