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.
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
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
Yes i was kind of trying my luck until i noticed this post and got the last question answered. My initial need for the protocol is to make an implementation for Home Assistant which is similar to openhab so if you have an app that has code including how to communicate with the trifork SecureDeviceGrid then i would be VERY interested to see that eventually this needs to be converted into a python library which i can use further but i can look at that. Maybe you could share it on Bitbucket and send an invite for that ?
Shoot me a PM with your emails/Bitbucket Usernames and i will add you the the repository
@ChristianHC i can’t PM here, please send invite to username: mihaicph https://bitbucket.org/mihaicph/
Thank you 
I’ve given you access. You can PM by pressing the username and click on “Message” 
Thanks @ChristianHC, for some reason i don’t have rights to PM here, maybe there is some form of restriction.
I cloned and i tried in Android Studio unfortunnately i got
Caused by: org.gradle.internal.resolve.ArtifactNotFoundException: Could not find aapt2-proto.jar
Its a gradle issue, i had the *.iml file included in the .gitignore. I pushed a new commit, try that.
You need the basic badge for that. Not really sure how you get that though, guess you need to do some posts and maybe hang around for a while 
