Danfoss living connect, new proprietary z-wave binding

I just got the Danfoss living conect thermostat working using Synology NAS and Aeo zwave dongle and the zwave binding by Chris Jackson working - little bit tricky for a newbie like me, but, got it working after some advice…

How did you get it working? I can connect it with my openHAB2 and it is being recognized immediately. I cannot set the temperature though.
Thanx for any advise.

The main problem I had was that the diescovery phase wasn’t fully completed. I was able to verify this by noticing that the node.xml files weren’t created under the zwave directory (which they should be when successfully discovered). To get it working I did the following:

  1. Triggered the discovery mode again and during this process I pressed the discovery button on the danfoss device MULTIPLE times. This resulted in successfull discovery and the creation of the node.xml files.

  2. When fully discovered, I navigated to: Configuration=>things - now I was able to see the channels.

  3. I checked the channels and created items for each channel - this made them appear under: Control - and from here you simply press the temprature number which makes the increase/decrease button appear and you can set your temperature.

hope this helps

BR

Good to find others struggling with the same challenge as me :).

I have spent a lot of time on this. MitM attacks on the Danfoss controller and Danfoss App. I have tried to decompile the Android Danfoss App. I have downloaded the controller firmware and tried to take it apart. The controller communicates with an API hosted by Trifork, the same goes for the Danfoss App. The api is served on port 443 and uses ssl. However I am unable to even connect with it with openssl. Some strange ec curve issue. When I took the Android app apart, I found a file called brainpoolP320r1-curve.pem which contains EC PARAMETERS - probably needed to connect.
I have tried to get the app and controller to communicate with my fake API which also is served with a fake Trifork CA. However nginx is unable to use the brainpool curves, even though openssl supports them. Apache can serve using some brainpool-curves, but not the P320r1 - in my first try. Right now I have given up on the API.
So trying z-wave. I bought this z-wave sniffer https://www.suphammer.net/product/suphacap and am now able to see the traffic to/from my thermostats and the controller. I have reversed part of the protocol and can now see temperature per thermostat and if it’s heating or not.
I am now not certain if I really want to take over control of my thermostats, as I am sure Danfoss does a much better job at this than I can. So maybe monitoring the state is enough?

z-wave example - my thermostat 2 says to the controller, that it is at 19,97 degrees:
0x00021028120C054720202021030020102011030F031703280318032F0330057F0800049D013700004901C06599DA
and my controller says to the thermostat, go to 24,22 degrees:
0x0002100A0D0D0001000409761C9A655E

Has anyone made better progress on this than me?

1 Like

Hi Søren,

It could be nice if you could share how you get this information. I am a big newbie on this, but I have in some time tried to get my B&O gateway to connect to Danfoss. B&O had an earlier version semi working with Danfoss, where they connected to this site https://linkdeviceapi.azurewebsites.net/, but I think they have partly closed that website now.

All I want of information is the actual temperature and maybe the set point. If you could assist me with your findings, it would be really nice.

Hi Søren,

I have been through the exact same process as you trying to get into the Danfoss CC protocol.

As you found out, the communication is hosted by trifork and they use a proprietary version of this library: Trifork - Secure Device Grid (I can only post 2 links as a new user, so just search github)

I managed to decompile the android app and extract the certificates. The general library (which is LUA based) for both the CC Controller and the iOS and Android apps are in files/mdg-c.zip directories. Everything needed for generating certificates and pairings are in there. The API calls themselves are in the android source code.
The communication to and from the endpoint is based on googles protobuf library and sent over https which is why you cant MITM attack it. However the only thing needed is to decipher the protobuf models and use the endpoints from the app, then you can talk to the controller either directly or through the endpoint.

I’ve managed to succesfully connect to the Trifork endpoint via the following commands:

openssl s_client -tls1 -connect mdg-danfoss.hosted.trifork.com:443 -servername mdg-danfoss.hosted.trifork.com -showcerts -cert app_cert.pem -key app_key.pem -CAfile trusted-CAs.pem -state -debug

Furthermore you can scan the endpoint with Nmap to see which ssl version they accept:

nmap --script ssl-enum-ciphers 77.66.11.92

So what is needed is to write a short program that connects via the openssl commands above and communicates via protobuf to the API endpoint. However i have never worked with protobuf and as such have not have success with it yet.

Would it be possible for you to share the decompiled code, with the API calls from the Android app?

I’d be happy to give deciphering them a shot, I just don’t have an android device right now.

Hi Christian.

Awesome work, I must say!

In stead of trying to figure out the protocol ourselves, wouldn’t it be an idea if we could get the controller to connect to our webserver and see what it actually posts? I bet we need some sort of authentication string, api-key/token anyway.

I havn’t got any Android device either, but I am using an emulator called Bluestacks - it’s working quite nice.

I will post the code later this week when i’m home. Unfortunately it wouldnt be possible to get the controller to connect to our webserver since it would reject the certificate. The file “trusted-CAs.pem” is the trust certificate for the self-signed trifor SSL certificate and since we dont have the private key, we cant impersonate it.
However the MDG-C lua files found in the android (and i guess iOS) app seems to contain the CC controller files too. The android code is just a wrapper around the lua files. This basiclly means we have the entire source code (without CC specific config files which are found in the controller and binary images themselves). I been trying to run it on windows x86 but there are some linux specific calls that means i cant runt it. Somebody with knowledge of lua and with a unix machine would proably be able to impersonate a client. Another way is to reverse analyse the binary images for the CC controller. I’ve tried using binwalk but i’m not knowledgeable enough to do a complete reverse analysis. - I suspect it’s encrypted in one way or another.

Actually, it should be possible to create a fake server but you would need to self-sign a certificate for the server and recompile the android app with the new trusted CA file. Then you would need to redirect both the hostname and ip to your own controller. The source code has hardcoded ip’s with fallback to hostnames which is why a normal DNS redirect wouldn’t work.

Can you make such a recompile? I’m not sure I can figure it out. Yes all my DNS “attacks” failed, so that makes sense. Did redirect with iptables on my gateway, but then obviously only got SSL-handshake errors.

I think it is worth pursuing, since we probably need to grab some sort of authentication string. Maybe you could put Let’s Encrypt’s root CA cert in the app? Then we could all easily get a trusted certificate and try it out.

Here are the files: https://1drv.ms/f/s!AkXrs_ZhDKe9spRUh_LuLC9tRz_Sbw

These are the commands if you want to redirect the traffic (With DD-WRT):
iptables -t nat -I PREROUTING -d 77.66.11.90 -p tcp --dport 443 -j DNAT --to IPOfPCRunningWireshark:PortToListenTo

iptables -t nat -I PREROUTING -d 77.66.11.92 -p tcp --dport 443 -j DNAT --to IPOFPCRUNNINGWIRESHARK:PORTOLISTENTO

iptables -t nat -I PREROUTING -d 5.179.92.180 -p tcp --dport 443 -j DNAT --to IPOFPCRUNNINGWIRESHARK:PORTOLISTENTO

iptables -t nat -I PREROUTING -d 5.179.92.182 -p tcp --dport 443 -j DNAT --to IPOFPCRUNNINGWIRESHARK:PORTOLISTENTO

iptables -t nat -I PREROUTING -d 77.66.11.94 -p tcp --dport 443 -j DNAT --to IPOFPCRUNNINGWIRESHARK:PORTOLISTENTO

These are the identified api calls from the android app:
/api/modes/
/api/alarms/
/api/rooms
/api/zones/living
/api/onoffdevices
/api/modes
/api/system/apiversions
/api/system/status
/api/system/info
/api/settings/temperature
/api/system/updatesoftware

I’ve excluded all call to TPA, which is “The Perfect App” and used for analytics

@ChristianHC @scaarup I can see that you’ve come quite far. Do you have any updates? It’s been almost two months since last reply here.

Do you think it would be possible to simulate the API server and have the Danfoss Link CC connecting to simulated API server? If so, I suggest we’ll make an open source project on GitHub, where we’ll be creating the API server.

It would be awesome. However we need a selfcompiled apk with our own CA-cert before this can happen.

Hi Jogge,

I’ve decided not to pursue emulating the SecureDeviceGrid API for now, since its rather complex First step is to get a Proof of Concept going. However! - I’ve almost got the sourcecode for the Link, Devi, Icon, Eco and TPOne App reverse engineered. Link and Devi are both using Trifork’s SecureDeviceGrid implementation, but different versions. The Devi app has binaries for Arm and Windows while the danfoss only has binaries for Arm. First step is to get a POC running on an android device and next step is to run the binary on e.g. a RaspberryPi.
I cannot publicly share the sourcecode yet, but when i have the POC i will share the code and instructions for getting the binaries from the original apps.

4 Likes

@ChristianHC have you had any time looking more at this ?

Hi Donnib,
I saw you wrote on Triforks and MITMProxy’s github repositories and wanted to chime in on the lasted updates i’ve made.
The Communication to and from the Danfoss applications and the MdgLib (Including the communication to the cloud) is made through Google Protobuf (Version 2.6). I have reverse engineered the .proto files for the Danfoss Link app and have a complete apk running, though there still is a few minor bugs i need to solve. I can share the code in a private repository if you’re interested in helping out squashing the remaining bugs.

1 Like