Notes on reverse engineering the Midea Portasplit

These are notes from one evening of checking how the Midea Portasplit communicates and how its electronics are structured.

Existing work on smart home integration

The following repositories already reverse-engineered the protocol between a Midea Portasplit and some Chinese cloud services.

• midea-msmart (that is used in midea-ac-py)
• midea_ac_lan

For some time now, Midea ACs have used version 3 of the protocol. This requires fetching a key/token pair from several Midea cloud APIs. The one used at the time of writing is “NetHome Plus”.

LAN traffic between you and the AC is AES-encrypted using the token and key.

So, to get a key and token, you:

1. Install SmartHome/MSmartHome (com.midea.ai.overseas)
2. Create an account
3. Hold the power button for 3 seconds to bring the AC into AP mode.
4. Use the app to connect to the encrypted wifi network net_ac_****
5. The app now switches the AC into client mode and connects to the home network.
6. The AC now talks to the cloud for the first time.
7. If that is successful you can use msmart to get a key and token:
8. docker run --network=host ghcr.io/mill1000/msmart-ng:latest discover --region DE <AC_IP>
9. Get the token from the response that looks like:

    1{
    2   'ip': '<ip>', 
    3   'port': 6444, 
    4   'id': <id>, 'online': True, 
    5   'supported': True, 
    6   'type': <DeviceType.AIR_CONDITIONER: 172>, 
    7   'name': 'net_ac_0085', 
    8   'sn': '<sn>', 
    9   'key': '<key>', 
   10   'token': '<token>'
   11 }
   

10. Now use those to query the state: docker run --network=host ghcr.io/mill1000/msmart-ng:latest query <ip> --token <token> --key <key> --region DE --device_type AC --id <id> -d

Looking at this flow, it seems that creating an account and registering the unit might not even be required. However, without more reverse engineering, we don’t know how to set WLAN credentials while the AC is in AP mode. We don’t even know the credentials for the AP-created WLAN network.

The APIs for getting a token/key pair are documented in the code of the repositories above.

Notes on the MSmarthome app

I started by statically analyzing the MSmarthome app. It turns out that the app uses obfuscation, namely KiwiVM.

I did not find much information about it. Searching Chinese websites would likely reveal more. It is not new, but it appears to use specialized bytecode, which makes reverse engineering with standard tools close to impossible.

The app uses Weex as a frontend framework.

Interestingly, it looks like the Weex app can be downloaded via a msmart feature. That download gives a bunch of JavaScript files, that seem to communicate with the device or either via Lua or some other APIs. There is a bridge to native parts of the app which is missing. However this shows the API structure of the cloud parts (no domain names are mentioned though). Definitely looks interesting to look into.

For the midea communication it seems to use several Midea SKDs, one being libmsmart.so that is also available on GitHub.

Looking at AndroidManifest.xml and the entry point, which is already obfuscated, shows that the app starts by loading a system library called libkadp.so/libkadp_x86.so. That’s all we can get from standard Java code. Everything else is handled in that heavily obfuscated library.

The next step would be to run it on an emulator. However, I had no luck with some Google API and Play Store images, as it crashed because of missing Java classes.

I suspect there would be runtime mitigations anyway, so it’s probably not worth it without a properly rooted Android device that still passes integrity checks.

For now, I stopped reversing the app, as it turns out the hardware path might be much simpler than anything we could do through the app.

Notes on the “smart” hardware

A Reddit user took a photo of the smart components, which are on the display board. The “mainboard” is in fact the controller and does not contain any “smart” bits. That picture is great, because I don’t have to take anything apart yet.

Check it out here or archived here.

The picture shows that there is a WLAN module called EU-SK110. However, this is no ordinary WLAN module. It is, in fact, a full SoC based on the RTL8720CMF.

The FCC database has everything you would want to understand what this module does. It even has a draft data sheet here. The internal and external pictures show that this is a WLAN <-> UART bridge.

I have two ideas here:

1. We can simply hook up an ESP32 to the UART. We can capture the messages and probably reverse-engineer the protocol in an afternoon. The UART protocol is likely documented somewhere already anyway, as Midea uses these smart keys in many of its ACs (see here).
2. It looks like the RTL can be dumped as described here. A datasheet is available for it as well. With that firmware, we can probably figure out how to talk to the AP to set up WLAN, and maybe even understand the encryption protocol.

The FCC images show the pins on the bottom side of the PCB that are used for UART. That means we don’t even need to remove anything from the board to start interacting with the AC mainboard/controller.

Thoughts

So yeah I think this would be a fun project to either dump the RTL or just sniff on the UART.

The sniffing is less intrusive and would probably not even void warranty. Dumping the RTL is a bit more risky so I would try to see if I can buy a fresh Smartkey first and start working on that one.