What I'm less happy about is the fact I can only control it from my phone; and that my local network has decided to stop letting me talk to the air con.
I fired up wireshark, and here's what I know so far:
Like most devices, the Air Conditioner is running UPnP services basically. There's packets being sent via http://en.wikipedia.org/wiki/Simple_Service_Discovery_Protocol for my Android phone and the air con to discover each other.
Here's my phone asking over HTTPU (HTTP UDP) for air conditioners via multicast:
NOTIFY * HTTP/1.1
LOCATION: 192.168.1.2
HOST: 239.255.255.250:1900
CACHE-CONTROL: max-age=20
SERVER: AIR CONDITIONER
MAC_ADDR: 98:0c:82:f4:d4:5c
SPEC_VER: MSpec-1.00
SERVICE_NAME: ControlServer-MLib
MESSAGE_TYPE: CONTROLLER_START
... and the air conditioner starts to respond:
NOTIFY * HTTP/1.1
LOCATION: http://192.168.1.4
NTS: ssdp:alive
CACHE_CONTROL: max-age=60
HOST: 255.255.255.255:1900
SERVER: SSDP,SAMSUNG-AC-BORACAY
MAC_ADDR: 7825AD103D06
SERVICE_NAME: ControlServer-MLib
SPEC_VER: MSpec-1.00
MESSAGE_TYPE: DEVICEDESCRIPTION
NICKNAME: 536D61727420412F432837383235414431303344303629
MODELCODE: SAMSUNG_DEVICE
Unfortunately, my air con actually lives at 192.168.1.7, the web application isn't smart enough to respond to changing IP addresses; even if the web server and everything else is.
I'm not entirely sure why, but my phone tends to flood packets out there - I presume the people who put the phone app together wanted to avoid dodgy local wireless problems; and this now explains why my air con is always discovered quickly, but the screen keeps 'loading'.
Strangely, for the local in home network stuff, it looks like my air conditioner is talking to a samsung owned service to give it status updates, even when I'm on my local network:
211.45.27.216
HTTP/1.1 200 OK
Cache-Control: private
Content-Length: 111
Content-Type: text/xml; charset=utf-8
Server: Microsoft-IIS/7.5
X-AspNet-Version: 2.0.50727
X-Powered-By: ASP.NET
Date: Thu, 24 Jan 2013 10:38:31 GMT
<rsp stat="ok"></rsp>
<device duid="7825AD103D06" message="Off"></device>
Attempt #2: There's an online service you can use.
Now, our clever friends at Samsung have done the right thing and made communication with their services via HTTPS - at least from the android to the soap service. Weirdly, the air conditioner does not speak HTTPS; and seems to be sending packets to the samsung control service, not my phone directly.
I looked at a few packets, but at this point, I was pretty much fed up - I'm not going to do a MITM attack via my router, and redirect traffic to a HTTP proxy I control; I'm not going to reroute traffic, and sticking the app in an android emulator to sniff the packets is annoyingly hard.
So, what's really left to do but... log in to the website and look at what's going on there?
It's probably a fairly safe assumption to think those endpoints are just RESTful wrappers around the underlying webservice.
Two are of quite a lot of interest, if ... dubious quality:
http://global.samsungsmartappliance.com/Content/js/communication/commMgr.js
http://global.samsungsmartappliance.com/Content/js/communication/Device/Device.js
Looking in firebug/chrome's console, you can see that the device traffic is going back and forth, with an incrementing token continually polling my air conditioner for status.
When you actually execute a command, a fairly simple request is sent:
- Request URL:http://global.samsungsmartappliance.com/Communication/setControl
- Request Method:POST
- Status Code:200 OK
Most of the other status information has included the MAC address of the air conditioner as the "DUID" - it's stripped of colons, but otherwise identical. While we can't tell what's in the session on the samsung side, I would not be surprised if it were a simple variable named DUID, which identifies where the command should be sent.
More interestingly, the requests can be replayed; so assuming you have a valid cookie that contains the right DUID, you can just send restful requests.
I'm going to assume that there's some kind of ESB or similar taking these requests and distributing them from my phone/browser to the aircon; as the traffic to the aircon is different to the endpoint my phone / browser speaks to.
There is a delay, perhaps 3-5 seconds, which is about what I would expect if there was a Giant Messaging Queue in use here; and to be honest the site seems to go down regularly - some service faceplanting it seems likely.
The fact it's jquery + xml being used also suggests there's an Enterprise Service Beast in play - though json is more common, the transformation between formats is a bit easier if you can hit it with an XSLT.
The use of a session would normally make things more secure... but the control to manipulate that value appears to be right out in the open.
I'm going to assume that there's some kind of ESB or similar taking these requests and distributing them from my phone/browser to the aircon; as the traffic to the aircon is different to the endpoint my phone / browser speaks to.
There is a delay, perhaps 3-5 seconds, which is about what I would expect if there was a Giant Messaging Queue in use here; and to be honest the site seems to go down regularly - some service faceplanting it seems likely.
The fact it's jquery + xml being used also suggests there's an Enterprise Service Beast in play - though json is more common, the transformation between formats is a bit easier if you can hit it with an XSLT.
The use of a session would normally make things more secure... but the control to manipulate that value appears to be right out in the open.
- Request URL:http://global.samsungsmartappliance.com/Communication/selectDevice?_=1359032361539
- Request Method:GET
- Status Code:200 OK
I doubt you could hijack someone else's air con if you knew the mac address, but for devices associated with your account...
At this point I have two good avenues to explore:
- Local network - I need to fix the IP addresses, and see what's going on after the SSDP phase. I had to authorise my phone, so I suspect that Samsung provides a third party service that verifies allowed MAC addresses prior to opening all of the communication flood gates.
- Pretend to be a browser, and invoke the restful services. If I supply my credentials, I can get the session I need - then the API is just a few POST requests away.
I'm likely to do the latter, unless I can figure out how to power cycle my aircon properly, and get it understanding its IP address.
No comments:
Post a Comment