Is indoor unit local password derivable?

[dlarrick]

The last piece of information we are missing from the Kumo v3 API in order to restore local access & control is the unit password.

Theory: This password is actually derivable via some transformation from information we already have, such as:

• User login name / password
• Unit MAC address / serial number / IP address

Given a working unit password and the above information, apply intuition, guesswork, and knowledge of common cryptographic / security procedures, reverse-engineer a way to derive the unit password.

[cmatthias]

Hi, owner of 9 Kumo-enabled units with a broken HA integration here. 😭

Am I correct in thinking that the decompiled Android app linked to in #58 would likely contain the logic to generate the indoor unit password somewhere in those thousands of JavaScript files, assuming the password is derivable?

If so, I can do some digging through the decompiled code to see what I can find. But I didn't want to start on this process without confirming my thinking above.

[dlarrick]

The decompiled Android app may or may not contain logic to generate the indoor unit password.

Evidence suggests that this new Comfort app does not use local communication, but instead does everything through the cloud. In that case, no, that app probably doesn't have the right code.

Or at least that was the situation when it was first released. It's possible the feature was added to Comfort later. There was speculation at the time that the wide public release caught the contracted Comfort developer by surprise and maybe that part was just not implemented yet. If so, a new decompilation would be in order. I myself am loathe to run Comfort since my units continue to work and I don't want that to change.

It's also possible that the cloud-based Comfort-HA integration (mentioned at the top of the README at hass-kumo ) might be usable for you at least as a stopgap.

[cmatthias]

Thanks for the info @dlarrick! I actually discovered that my units went offline locally due to an IP address change, not because of the Comfort app upgrade. I was able to update their IPs in hass_kumo's kumo_cache.json file, and I got all the units working again. This was surprising to me as so many people have said that Comfort completely broke local control.

So I decided to do a little digging around, and found a few interesting things. Apologies if any of this is old news, and sorry for the novel:

All my local unit passwords are base64 strings which decode to 30 bytes of data. This is notable only because I'm not aware of any hash algorithms that directly produce 30-byte output. Of course they could be truncated from longer values, but this doesn't really give too many clues as to which hash algorithm is used, if any, other than it needs to be one that produces hashes that are at least 30 bytes.

Second, I wrote a little script which attempts to brute force local passwords. I picked one of my mini splits, and base64 decoded the local password (which I confirmed is working using a test pykumo script) to get the raw hex string. The script tries every permutation/combination of unit serial number, MAC address with and without colons, the cryptoSerial value, my Kumo username and password, and my Wifi SSID name, all concatenated with one another. The permutations include ones with only a subset of the possible values, for example MAC+SSID, or cryptoSerial+unitSerialNumber+kumoUsername. The script tries SHA-256, SHA-384, and SHA-512 for each of the permutations, and then truncates the resulting hash to 30 bytes before comparing with the known local password. I was not able to find a match using this script for the mini split unit I chose.

Third, I threw a little bit of the decompiled code at ChatGPT and managed to get a few insights. First, the CalculateMacHash function implementation is almost exactly the token generation algorithm that exists as the _token function in pykumo. There appear to be only two differences: 1) the payload that's hashed: in CalculateMacHash, the request is wrapped in an outer {"r":{}} top-level JSON key, and only that value is hashed, not that value concatenated with a password, and 2) the hardcoded key used (what pykumo calls W_PARAM) is different: in CalculateMacHash, a value starting with 9f549f... is used instead of 44c7328... in pykumo.

I tried altering pykumo to follow this algorithm by wrapping the post_data in the outer {"r":{}} JSON object, removing the password from the payload hash, and changing the W_PARAM value to the one used by the comfort app. But I wasn't able to successfully connect this way.

I didn't think that the above was that big of a surprise, because I thought that maybe Mitsubishi just uses a similar token generation algorithm for cloud requests, and that's what this function is used for. But ChatGPT also helpfully pointed out that this algorithm is well-known as the MAC generation algorithm required to use a small crypto chip called the ATSHA204, which the Kumo Wifi adapters appear to be using. In fact, the cryptoSerial value used by Kumo matches the format of the unique serial numbers that each ATSHA204 chip has. So that might lend more weight to the theory that CalculateMacHash is in fact used for accessing devices locally.

I have some more info but this is long so I'll stop here. Let me know if you have questions or want me to provide any additional data. Thanks for this project, it's been great for me for many years and I hope it can continue to work locally too!