No token in miio2.db after version 5.0.29 of MiHome app...

[khalitovsv]

In versions 5.0.31+ there is empty field token in miio2.db file.
They change something in application.
An investigation is required.

Tested on Mi Robot Vacuum Cleaner (1st generation)

[rytilahti]

Could you check if there's another field which could have the token? Maybe they have done the same or similar as with the iphone app and encrypted it? Do you see is_encrypted or similar boolean field?

[khalitovsv]

There is content of miio2.db in JSON format (PRIVATE is private information, changed by me):

[
{
"bssid": "00:24:01:CF:1B:C1",
"canAuth": "1",
"canUseNotBind": "0",
"desc": "Charging：89%",
"descNew": "",
"descTimeJString": "",
"did": "55393227",
"eventInfo": "{"event.back_to_dock":"{\"timestamp\":1517070715,\"value\":[0]}","event.back_to_dock_no_power":"{\"timestamp\":1493405918,\"value\":[0]}","event.back_to_origin_fail":"{\"timestamp\":1495822059,\"value\":[0]}","event.back_to_origin_succ":"{\"timestamp\":1517000558,\"value\":[0]}","event.clean_complete":"{\"timestamp\":1517070666,\"value\":[0]}","event.error_code":"{\"timestamp\":1517070715,\"value\":[0]}","event.relocate_fail":"{\"timestamp\":1493819748,\"value\":[0]}","event.robot_timed_ended":"{\"timestamp\":1506240979,\"value\":[1506240960,0]}","event.robot_timed_started":"{\"timestamp\":1512226801,\"value\":[1512226800,0]}","event.status":"{\"timestamp\":1517071680,\"value\":[{\"battery\":89,\"clean_area\":8410000,\"clean_time\":1207,\"dnd_enabled\":0,\"error_code\":0,\"fan_power\":90,\"in_cleaning\":0,\"map_present\":1,\"msg_seq\":913,\"msg_ver\":6,\"state\":8}]}","prop.back_to_origin_fail":"0","prop.back_to_origin_succ":"0","prop.clean_complete":"0","prop.error_code":"0","prop.fan_power":"90","prop.ota_progress":"100","prop.ota_progress_ts":"1517002835","prop.ota_state":"idle","prop.ota_state_ts":"1517014037"}",
"extraInfo": "{"isSetPincode":0,"fw_version":"3.3.9_003094","needVerifyCode":0,"isPasswordEncrypt":0,"is_factory":false}",
"index": "63",
"isOnline": "1",
"latitude": "PRIVATE",
"localIP": "192.168.1.46",
"location": "1",
"longitude": "PRIVATE",
"mac": "28:6C:07:F7:3C:5C",
"methodInfo": "",
"model": "rockrobo.vacuum.v1",
"name": "R2D2",
"ownerId": "",
"ownerName": "",
"parentId": "",
"parentModel": "",
"permitLevel": "16",
"pid": "0",
"propInfo": "",
"resetFlag": "0",
"rssi": "-66",
"showMode": "1",
"ssid": "PRIVATE",
"token": "",
"userId": "PRIVATE",
"version": ""
}
]

Finding of actual token in HEX or BIN representation in /data/data/com.xiaomi.smarthome, gave the only one result: some cache files contains HEX token in /data/data/com.xiaomi.smarthome/cache/smrc4-cache folder

When downgrading to version 5.0.29, we can find actual token in miio2.db file again...

[yawor]

I've installed 5.1.0 and I can confirm that. I've analysed the decompiled code and it seems that the token is no longer being kept locally, but instead it's being downloaded from the server on app opening. This can be observed when opening app after forcefully closing it. Previously, the device would show up immediately in the UI. Now it takes a moment, probably the app waits for the server response containing a list of devices, which contain tokens amongst other information.

[yawor]

For few past days I've been playing around the communication between MiHome app and xiaomi servers. I've captured the traffic using the mitmproxy. The whole communication is using SSL so there's some setup required for the capture to work.
In addition to SSL, after the authentication most of the data in requests and responses is additionally encrypted and then encoded in base64. I already know what encryption algorithm is in use and I've been able to decrypt most of the communication (there are still some bits and pieces I'm not sure about). I can confirm that the token is being received from the server (it was even in earlier versions).
It seems that tapping into the app's communication may be the only way to retrieve the tokens with versions 5.0.31+. The issue is that setting up the mitmproxy may to too much for most miio users. I'm thinking about simulating the app in the library: a cli command that would ask a user about the email and password for mi account used in the app and the library would use them to authenticate to xiaomi servers and request the devices list associated with the account.

[rytilahti]

Interesting findings, and it's very unfortunate that it's being made more difficult to obtain those tokens. Maybe we should add a note into the README file to warn about that. I'm wondering whether this change is done in the device specific communication part or in the main app. Can one downgrade the main app and regain the access, or will it be necessary to have an old version of the vacuum plugin available?

To the cli tool with emails & password. The problem with such a cli tool would be that it needs to be updated regularly (assuming they want to block that way) depending on how they are blocking it. I'm not completely against it though.

For cloud<->vacuum communication you may want to check https://github.com/dgiese/dustcloud - they have pretty much reverse-engineered it afaik.

[yawor]

The change is at the main app level. Downgrades are possible now, but I wonder if they can somehow block it. For example they could make newer versions of plugins compatible only with newer app versions and disable access to older plugin versions for new installations.

Regarding accessing the Xiaomi servers from the library, if the request could be made indistinguishable from those made by the app, then to block it Xiaomi would need to change something in the protocol, which in turn would require a new app version and immediate cut off of all their clients until they upgrade. But I partially share your concern, that's why I haven't yet disclosed the details of the protocol.

Thanks for the link. I've been looking for some information regarding the communication between the device and the servers. I've seen that the protocol is the same but I don't know the token. But there's really nothing interesting in the payload anyway, when I look at the info on the linked page.

BTW I see that Air Purifier Pro responds to miIO.ota, miIO.get_ota_state and miIO.get_ota_progress commands. It would be nice to capture the moment Xiaomi pushes the update and get the original firmware file like they did for the vacuums.

[rytilahti]

Ok, I think it'd be fine to provide that functionality for fetching the tokens online (not just for the vacuum, but also for the other linked devices). It'd need finding out what type of requests the app is making (e.g. is there User-Agent and does it depend on version of the app or the OS behind etc.).

I think they analyzed how the token for server<->device communication is delivered, but didn't pay much attention to it. Support for those commands is being worked in #153 - the same update procedure is apparently used for at least most of the other devices too, so that's why I started to implement it as a part of the Device. Those commands are only accepted by the device when it has not been provisioned or when you have access to the device<->cloud token.

[rytilahti]

BTW I see that Air Purifier Pro responds to miIO.ota, miIO.get_ota_state and miIO.get_ota_progress commands.

Could you post and/or implement a PR for the responses from those? Looks like the vacuum responds only to miIO.ota (tested by updating the FW), but nothing on those two others. Maybe I'm missing some required parameter (didn't namely pass any)?

[syssi]

@rytilahti Do you use the mihome app and could you provide the plugin (apk) of the vacuum cleaner?

[rytilahti]

@syssi sure, let's discuss on discord.

Looks like those commands work just fine now. get_ota_progress reports [percentage], and get_ota_state has values idle, downloading, installing and failed, at least.

[crhan]

have the same issue. Does anyone have any solution?

I try to reset wifi configure and obtain the token. But it seems like after configure the wifi. The token will reset again.