I managed to get around to playing with the Ennio wifi doorbell a little more, trying to figure out how all of it works. It seems I have to learn a few things about UDP, however with a quick and dirty tcpdump on my openwrt router (which I was hacking in other ways earlier) to an NFS share on my RAID I managed to collect a chunk of worthwhile data while my phone interacted with the camera.
As far as I can tell without capturing all of the data of all of the interactions it goes something like this:
- Phone sends a broadcast request of some kind and the doorbell responds with a packet with it’s name to the UDP port specified by the initial contact.
- The phone logs into the device using the username and password provided by doing by sending a hex encoded ASCII string, with some preamble bytes:
The response is then similarly hex encoded ascii of
Understanding the mess
var this = that; etc… You can even send multiple commands separated by some bytes and you’ll get multiple responses back.
I’ve learned a few things since playing around like this, first of all, the password is always supplied twice in the command string and livestream.cgi initiates the UDP stream to the phone, meanwhile talking back to the device actually uses asterisk which makes me think that asterisk is more heavily involved in this? More investigation is required.
I’m going to spend some time sanitising and decoding the packets, and learning more about the interactions which go along with doorbell push notifications and device online registration etc… These are the types of data I want to highjack and use in alternative ways.
There are of course some minor impediments to my journey, not being able to hack the binary of the “encoder” I think it’s called, to change the root password, remove the google 184.108.40.206 DNS server as a primary and get the push notifications to do something else… But it looks like it’s fairly safe in so far as it’s not running a upnp service with DDNS registration and a loophole in the web UI, this has been a common security problem on many IP Cams. The worrying thing is that when I disable wifi and use 3G I can still connect to it, my guess is that it registers itself with a service somewhere most likely the amazon cloud and the video is bounced from there somehow.
I haven’t even began to try and understand how the video is being broadcast other than, it’s a blast of UDP packets at the phone…
A real fix?
There are lots of security considerations with this device, I think it might actually be best to start rewriting the binary from scratch. Life would be easier if the source code for the ipcam sdk was just made available, there are so many dodgy white box ip cams out there which could be fixed if the firmware was managed in github or at least somewhere instead of rotting between the engineers of Shenzen.