Can you enable ECHONET lite only with official Mitsubishi AU/NZ Wifi App?
Closed this issue · 5 comments
Can you enable ECHONET lite only with the official Mitsubishi AU/NZ Wifi App?
I have a MAC-577IF2-e adapter in my MSZ-AP42VGK AC, but I don't see the enable ECHONET lite option in the MELCloud iOS application. I'm in the EU.
Am I using the wrong app or does MAC-577IF2-e not support it? Where can I download the official Mitsubishi AU/NZ Wifi App if the former is the case?
This is the AU/NZ app. I have no idea if you can download or access via EU App Store.
For what’s it’s worth, I am not able to download the MELCLOUD app here in the Antipodes…
According to the NZ website, only the "568" model WiFi adapter has the feature
https://www.mitsubishi-electric.co.nz/wifi/learn_echonet.aspx
I expect too that the region you buy the unit in dictates which regional cloud service it connects to, so you wouldn't be able to onboard the adapter in the NZ cloud service even if you could get the app.
In README.md, it says the project also supports MAC-578IF2-E. I have MAC-577IF2-e.
It's strange that ECHONET lite is dependent on the cloud service to enable it, but it is for local control.
To late add to this. Digging through the firmware, it became pretty apparent that all newer models of the adapter support echonet. Even those in Europe. Rule of thumb that should work fine is whether it communicates via HTTPS or not. Also all the newer Mitsubishi devices with embedded wifi adapter should be included in this group.
I've actually worked out the local protocol that you can use to communicate with the device via port 80 and the /smart endpoint. Which pretty much supports the full Mitsubishi featureset. In a tragic twist of fate, the payload data is now encrypted, specifically on models that started support for echonet. You need an AES key that is stored on device flash memory to perform encryption/decryption. This key is sent/leaked to the server on boot so the server can use it for encryption which is used on the AU/NZ app, but with SSL and cert pinning no luck reading that out for now.
Now the interesting thing is that even adapters in Europe that use MelCloud can theoretically enable echonet. There exists several exposed admin interfaces on the device, presumably for technicians. These are all running on the port 80 webserver.
The 2 most interesting endpoints would be /service which offers exactly one config adjustment - enable/disable echonet. And /server which allows you to actually change the URL of the cloud provider the device will try to connect to as well as switch between SSL certificates. Since it is free type for the URL you could probably downgrade the connection to HTTP from here which would give you the AES key for complete local control.
Now these endpoints are user:password protected. The usernames are in the firmware and the 2 highest privileged ones to access both these pages are admin and suser. The user name root can't access the /server endpoint, but can at least access /service. The passwords however are stored in either flash memory or some kind of eFuse.
So that's how far I got. The device uses strcmp to compare the provided base64 string to the one on record to grant/refuse auth, so it is probably vulnerable to a timing side channel, but over WiFi it might not be feasible to crack the password that way. Apart from that I'm not sure if that is debug mode only or not, but the passwords are written to log on boot. So it's probable they could be read out one way or another if someone were to dump the flash memory. And by nature these passwords are not device specific, at least those of the same model. So having those would help quite a few people to enable echonet on their device and/or obtain their personal AES key to achieve complete local control.