info about port 80 in device

[anxdroid]

Hi,

I own a mitsubishi AC with Wifi connectivity that already works with melcloud. I would like to further understand about its functioning and I started messing around with wireshark and nmap.

Before discovering your great page, I already managed to intercept the traffic using wireshark (on a mac) but the only useful infos I could extract were a communication between the device and the host "production.receiver.melcloud.com" on port 80 (a POST request) and a sequence of calls on port 443 that I couldn't decrypt. For that, I'll give a try to your proxy

As I can see, the workflow always starts from the device, that regularly polls the server for commands and this sucks ! I would like to call the device and send commands to be executed immediately !.. Do you think that's possibile to use port 80 for that ?

I doscovered through nmap that the port is open and responding but the webserver replies with 401 (it needs a password). Have you tried to investigate on that side ?

many thanks

[ncaunt]

Hi anxdroid,

production.receiver.melcloud.com resolves to the same IP address as leswifidata.meuk.mee.com so it should work fine with the code in this repo.

You're correct that the wifi device makes HTTP requests and sends device status, approximately every minute. Mitsubishi's server can respond with codes that the wifi device will send to the heat pump/AC, for example in response to you making changes on the MELCloud site/app. This is the only way I know to send commands using the wifi adapter and I haven't explored sending HTTP requests to it directly but maybe this was left open for an engineer to use or for debugging purposes.

To make changes immediately you will need to connect something to the serial port of the AC and send commands. Have you seen this repo https://github.com/SwiCago/HeatPump? It is more focussed on air conditioning units (hopefully like yours).

Cheers!

[veso266]

I also own Mitsubishi MAC-577IF2-E

and my also sends something to production.receiver.melcloud.com

but as its https I can not decrypt it, so now I don't know how to get my own server up then (I don't have Mitsubishi private key so I could setup my own server)

and my also has http page up on port 80 but it requires http basic auth which I don't have username/password for

Is there any firmware update for this device floating around which I could open in binwalk to see whats going on in this MAC-577IF2-E thing?

Thanks for Anwsering and Best Regards

[niobos]

Hi @veso266,

I wanted to check if you made any progress on your search? I'm in the same situation as you: looking to control a MAC-577IF2-E connected A/C unit locally via WiFi.

[veso266]

Not yet, I guess we need to find a firmware first so we can get to its http server

There is even a firmware upgrade for mine that I am suggested to install but dont want to because probably even if I capture update process using wireshark, its using https so I couldnt get to the update file anyway

[niobos]

Thanks for you reply. I have some idea's to try to intercept the traffic, but I don't know if they'll work. I'll keep you posted

On second thought; maybe this GitHub-issue isn't the ideal place to discuss this... but I don't have a better idea at the moment. Sorry ncaunt...

[ncaunt]

Hi @niobos , don't worry about discussing it here - this is an interesting conversation :) Have a look at the README where I mention the HTTP proxy mode and it might give you ideas about how to redirect the HTTP request from the wireless interface using the dsniff toolkit. You might struggle unless it accepts insecure (self-signed) TLS certificates but this is probably worth a try.

[niobos]

I already tried intercepting the traffic. The MELcloud-server uses a custom root CA (/CN=MELCloud Root Authority), with a leaf certificate for /CN=production.receiver.melcloud.com. I tried presenting my own similar chain, but I get an "Unknown CA" error from the client (MAC-577IF2-E) during the TLS handshake phase. Seems like the CA is pinned in the firmware. I'll have to come up with some more creative ideas...

For the HTTP-server: it looks like not all paths are protected by the authentication challenge: /license seems to work unauthenticated.

[ehliar]

I would also like to control the MAC-577IF2-E locally. If anyone is interested, in addition to /license, the MAC-577IF2-E accepts the following URLs and asks for a username/password:

• /
• /analyze
• /config
• /default
• /network
• /server
• /service
• /update

Found by writing a script that tried a list of common English words as URLs. (During this process the MAC-577IF2-E seemed to crash or hang repeatedly as well.)

Note: I know that /network is accepted without a password when setting up the device, perhaps the other URLs might work in that case as well? Something I might test later.

[thxer]

APP.zip

This is the firmware for MAC-577IF2-E. The HTTP server needs password for these URLs, even when the module was new. I don't found the password in it, maybe it's stored in the nvram, like MAC, Serial, etc.

[veso266]

Wow, thats great, how did you get the FW from it?

Did you try binwalk on app.bin?

[thxer]

I tried binwalk and strings. I found some URL-s, and maybe some valid usernames (root, admin, suser, user) I found that /config accepts "user" as username and the KEY on the module label for password.

[veso266]

Neat, works like a charm, although config endpoint isnt realy usefull (only some select list with yes/no that asks you about current internet) and I guess other endpoints need a diferent user/password combo

Its a nice step forward

Not sure if this fw runs some sort of linux with busybox, maybe try cracking the password with john the ripper (if you managed to find some etc/shadow or etc/passwd file)

No I have to take a look at binwalk myself (or you could maybe post content of it and strings here for easier acsess)

I am still puzled on how did you manage to get the fw? (did u open the device up and read the flash? Or did you manage to capture it somehow)?

[niobos]

From the looks of it [1], the firmware seems to be FreeRTOS, not linux. And based on a reference to C:\sdk-ameba-v4.0c\component\common\mbed\targets\hal\rtl8195a\gpio_api.c, We may have a hint to what hardware is used.

[1]: I see reference to xTaskCreate, vTaskPrioritySet

[niobos]

I've explored the firmware posted above. I found nothing useful yet, but I documented my findings on my blog. Will keep you posted.

[TRIROG]

Great progress, hope we get the ability for local control!

[kalwinskidawid]

Hey, @niobos great job! Any progress on cracking local access?

[niobos]

I've mostly given up on this. I think the easier route is to use an IR-sender to mimic the remote control signals.

[kalwinskidawid]

The sad thing is that Mitsubishi is so closed to the end customer, in fact if I had known earlier I might have made the modules myself for ESP

[kripton]

Hi @niobos , don't worry about discussing it here - this is an interesting conversation :) Have a look at the README where I mention the HTTP proxy mode and it might give you ideas about how to redirect the HTTP request from the wireless interface using the dsniff toolkit. You might struggle unless it accepts insecure (self-signed) TLS certificates but this is probably worth a try.

Is the mitm-proxy working reliably with the CA-pinning they are using? ARP spoofing works and I can see that the adapter now asks my system via DNS. DNS spoofing not tried yet. But how will the HTTPS connection NOT fail when I don't have their private key?

[niobos]

DNS and ARP can be spoofed successfully, but the TLS connection is torn down because the certificate doesn't match. I'm not sure that they actually pinned a certificate or a CA, but the device does check the certificate chain since a self-signed cert is not accepted.

[Grabauskas]

Hi @niobos! There is a certificate in the firmware. Did you try that?

MAC-577IF2-E_App_Cert.zip

[niobos]

That's the CA's certificate, probably used for pinning, so that doesn't help.

[dragonbane0]

I have been looking into this as well thanks to @niobos excellent research up to this point. I've actually worked out the local protocol that you can use to communicate with the device via the unprotected /smart endpoint. Which pretty much supports the full Mitsubishi featureset and would allow complete local control of the device in real time. Several of their official apps use this to get a faster response from the device if you are in the same network.

But ever since they switched over to HTTPS with the cert check, the payload data is now encrypted. From the firmware it seems the unencrypted data is still the same as before, so if the encryption is solved you could use the existing research and protocol details from the apps to achieve local communication with no restrictions.

It seems you need an AES key that is device specific and stored on some kind of flash memory to perform encryption/decryption. This key is apparently sent/leaked to the server on boot so the server can use it for encryption but with SSL locking everything down no luck reading that out for now.

Another option to gain local control would be via Echonet, a Japanese smart device standard the modern Mitsubishi HTTPS adapters support. But they only enable this on JP devices by default while the AU/NZ app surprisingly allows customers to enable it from the app. But no such courtesy for EU/US users, so Echonet remains disabled for us. But the firmware posted above proves it does exist in all of these adapters.

Following niobos research, I figured out two of the most interesting endpoints, one being /service. Which offers exactly one config adjustment - enable/disable echonet. The other being /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 or at least trusted CAs. Since it is free type for the URL you could probably downgrade the connection to HTTP from here which would allow you to also read out the AES key for complete local control. You can also apparently switch the CA to Amazon used by AWS IoT Core which they maybe used for debug/initial development.

So bringing this back around, figuring out the passwords for the /server endpoint would allow getting access to the AES key and achieve local control and switch over to any server you want. Getting at least access to the /service endpoint would allow any Mitsubishi owner regardless of region to turn on Echonet and use that standard for local control which is still better than nothing.

Apart from the discussed possibility to crack the passwords, I'm not sure if that is debug mode only or not, but the passwords are seemingly written to the system log on boot as well. 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 hopefully 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.

[niobos]

Hi @dragonbane0, I'm very interested in what you discovered on the /smart endpoint, and your other discoveries. Would you be willing to share these? If you prefer, I can contact you privately for this.

[dragonbane0]

@niobos Maybe not the best place in here, but at least it ensures some people might be able to find it down the line to help with the research and hopefully getting access to the device.

Here is the most useful stuff I found. My apologies for any mistakes in here, it's been a while:

NVRAM Offsets: NVRAM is accessed using offsets from the firmware code. Here are some things the device stores on it: -BA: Device WPA Key -C4: Melcloud domain name (Server URL) -E7: /smart AES key (16 bytes, 128 bit) -EB: active alternative cert or CA (only applies when use alternative is true) -FD: "use alternative" client cert or CA

The AES key is seemingly send to the Melcloud server in the HTTPC frameDataGet_fd() function (via decsec_getdata_fi DECSEC_KEYCODE NG). The key can also be remotely updated it looks like since it supports writing a new AES key to the NVRAM.

Explanation of the exposed web server routes: -Debug settings (POST to /analyze) -Function settings (POST to /config) -Factory reset (POST to /default) -Network settings (POST to /network) (user network setup) -Server settings (POST to /server) -Service settings (POST to /service) -Unit Information (GET from /unitinfo) -Firmware/Application Update (POST to /update)

Debug settings: -Analyze (debugStatus to off or on, probably enables the logger)

Function settings: -Connect internet (serverStatus to yes or no)

Factory reset: -Factory default configuration (Factory Reset or Normal Reset)

Server settings: -Server URL. Could probably downgrade to HTTP by changing this or use a mock server -Polling cycle (1 to 59 seconds secs/mins/hours/days) -SPMODE timeout (5, 10, 15 or 20 minutes) -Default client certificate "DefCliCert" (dynamically populated dropdown list) -Client certificate "CliCert" (unique or default setting)

If DefCliCert is set, it seemingly always forces CliCert to unique and sets it as the new default cert. Setting CliCert to unique without actually setting a cert does nothing. If DefCliCert is not set, nothing will happen unless CliCert was set to default and differs from the current value on storage, if so it will switch back to default cert.

Service settings: -Enable ecomode (Echonet) (Enable, Disable). Would grant local control if it could be accessed.

Unit Informations: -Adapter info (name, version, mac, thermal image timestamp etc.) -Unit info (unit type, IT version, last error) -Reload button

Firmware Update: -chkFirmFile(). Allows webpage user to drop a firmware bin file which is uploaded via multipart/form-data. So with the super user or admin password you could flash a custom firmware.

Random Notes: -The user access list to the webserver routes is as specified on the blog: Link -The adapter seemingly uses AWS IoT Core with MQTT for debug/dev for something which is why it supports Amazon Root CA issued certs.

The secret store: Certain secrets such as the access passwords seem to originate from some kind of secure store. I marked the base down at 0x30087AD4 for it in the image. These are also accessed by index and break down as follows:

secret 0 = decsec_keycode: offset 0, 32 byte length (this relates to the AES key somehow, but I got a bit confused here) secret 1-2: 65 byte length max (unknown) secret 3 = root pw: offset 0xA2, 65 byte length max secret 4 = super user pw: offset 0xE3, 65 byte length max secret 5 = admin pw: offset 0x124, 65 byte length max secret 6 = offset 0x400, 9216 byte length max (maybe root cert?) secret 7-8: 3072 byte length max (likely certs?)

So the passwords we need have a max length of 65 bytes.

The /smart endpoint: On the old MAC-559IF adapter type and similar ones this endpoint supported plain-text xml payloads they call CSV/LSV. Example data: Link

This is not data send/received from the /smart endpoint in particular, but data the device sends to the server when phoning home. It was obtained on an old adapter pre HTTPS. The /smart endpoint however uses the exact same protocol. The interesting data is in the PROFILECODE and CODE tag sections. I don't know much about the PROFILECODE section, but I did reverse a good chunk of the CODE VALUE tag format using the Japanese Mitsubishi app which assembles these strings locally. Another good resource was this very repo. Here are some unstructured mental notes on the format: https://pastebin.com/YwtscQAP

So with that you can quickly see that the device is messaging the server the following properties in the above example: 02 = power state, device mode and tempChanger 03 = room temperature 04 = abnormal state 05 = timer settings 06 = N/A 09 = auto mode

Safe to say you can control the entire device perfectly local with this protocol and even read out data using the /smart endpoint by switching between read and write requests.

An old adapter top layer payload you would POST to /smart would look like:

<?xml version="1.0" encoding="UTF-8"?>
<CSV>
    <CONNECT>ON</CONNECT>
    <CODE>
        <VALUE>{{{payload.lc}}}</VALUE>
    </CODE>
</CSV> 

payload.lc is the above mentioned CSV/LSV xml style document encoded to base64. So base64 decode the lc string and you get the xml document with the actual juicy data (xml within xml). Communication to the server via polling uses a similar method of xml within xml. LSV seems to be used for device outbound direction and CSV for inbound direction.

The modern payload: Now the MAC-568IF, MAC-577IF, MAC-578IF and other families of more modern adapters use the ESV format which is encrypted using the AES key. The modern payload you send to the /smart endpoint now looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<ESV>{{{payload.lc}}}</ESV>

This so called lc string is most likely just a regular CSV/LSV payload encrypted with the AES key, then base64 encoded. So to decrypt the lc string now you would:

1. Base 64 decode it
2. AES decrypt it
3. Resulting data should start with a CSV tag, either looking like the regular unencrypted payload or it's already the "final" xml document with the CODE tags

This info was obtained from the AU/NZ app which actually uses the /smart endpoint locally. It either sends the server generated CSV/LSV payload directly to the adapter if it's the older type, or pastes the encrypted lc string into the above ESV payload before sending it for the modern adapters (the app performs no encryption, the server sends the already pre-encrypted data). The app does this to make commands instant if you are in your home network. Apparently the other Mitsubishi regions sans Japan did not care about implementing this into their apps at all, but then again the AU/NZ app also allows you turn on echonet yourself so there is that.

Sadly I found no loophole in the firmware to simply send it an unencrypted payload like on the old adapters. It seemingly always expects an encrypted one, but maybe it can be fooled somehow into accepting the unencrypted CSV/LSV format.

So quite tragically the old adapter family can be controlled just fine locally, just the modern ones get blocked with the encryption for now.

All the other information on the CSV/LSV format can be found in this repo.

TLDR about the current local control options: -Older adapters pre TLS have full local control capability via the /smart endpoint. Someone just needs to write an implementation -Modern adapters currently can't use /smart because of the encryption. But modern adapters did implement the echonet protocol which the older adapters lacked. But unfortunately only the JP and AU/NZ market currently allows you to enable this on your adapter. The other regions have it, but you can't enable it without gaining access to the restricted web server

[KazWolfe]

@dragonbane0 Thanks for assembling a bunch of this; it's very useful for us over in air-to-air territory. Am I correct inasmuch as the JP app you were looking at was air.jp.co.MitsubishiElectric.KirigamineRemote?

As of right now, I have a bad feeling different regions have slightly different IT protocol responses, and that information for any one region may not necessarily properly apply to other regions. For example, my North American heat pumps don't seem to report the secondary vertical vane, nor the wind/windbreak values.

[dragonbane0]

@dragonbane0 Thanks for assembling a bunch of this; it's very useful for us over in air-to-air territory. Am I correct inasmuch as the JP app you were looking at was air.jp.co.MitsubishiElectric.KirigamineRemote?

As of right now, I have a bad feeling different regions have slightly different IT protocol responses, and tphat information for any one region may not necessarily properly apply to other regions. For example, my North American heat pumps don't seem to report the secondary vertical vane, nor the wind/windbreak values.

I'm very sure that was the app yeah. It contained all of the useful stuff about the format encoding. It did look slightly outdated to me but hopefully it's mostly updated in a forward thinking way where values are just ommitted or new ones added but the existing identifiers stay the same for the same data point.

I think with full access to the device and general knowledge it's hopefully easier to just figure out new data points by messing with the app and see how the data changes. But we need to get to that point first, at least with the modern WiFi adapter methods

[Pascal66]

APP.zip

This is the firmware for MAC-577IF2-E. The HTTP server needs password for these URLs, even when the module was new. I don't found the password in it, maybe it's stored in the nvram, like MAC, Serial, etc.

Is one of those password is working with your firmware ? (if it's used by your device) d9c7c1c1e8 fc03045a06 d7b8c8ffaf

[kalwinskidawid]

Anyone tried dump current firmware from EU version?

[niobos]

@Pascal66 I've tried these 3 passwords in combination with user, root, suser and admin (the usernames I found in the firmware, but neither combination works to GET /...

[Pascal66]

@Pascal66 I've tried these 3 passwords in combination with user, root, suser and admin (the usernames I found in the firmware, but neither combination works to GET /...

Have you used the same firmware ((APP.zip) or another one ? I think it's a POST request not a GET for most of endpoint But thank you for the try

[niobos]

@Pascal66 I've tried these 3 passwords in combination with user, root, suser and admin (the usernames I found in the firmware, but neither combination works to GET /...

Have you used the same firmware ((APP.zip) or another one ? I think it's a POST request not a GET for most of endpoint But thank you for the try

I have no idea how to check the firmware on the device itself, so I'm not sure.

I tried with GET on /, since I don't know the data (format) to POST. If you have any pointers to what would be a better test, please let me know.

[veso266]

I also tried /unitinfo (since according to previous post it does accept GET request)

with all the passwords and admin as username and they don't work

Not sure if I am using APP.zip firmware, but maybe I am, since I never manualy updated the device (got it when this issue started :smile: ) (even when prompted by MelCloud) in hopes that a loophole inside is one day found

PS: I also found this picture (thnx @niobos hope you are not mad that its here :smile: )

which might help in quickly figuring out what usename is for what endpoint

also discovered that if you download javascript that /javaScript.js gives u, you can get the list of all the wifi names the unit found inside function reloadSsid()

I guess for now, we can use it as a very primitive wifi scanner :smile:

@dragonbane0 do u have the AU/NZ app that (is this account specific or only app specific) allows us to enable Echonet

if this is app specific then the AU/NZ app just connects to /service endpoint (with some password of course :smile: ) to enable/disable Echonet?

I found the AU app net.melview.app.zip

I found out it always tries to connect to: http://192.168.11.1/apinfo (sadly it doesn't provide any username and password for this endpoint), also tried redirecting to my real ip using fiddler and a bit of scripting

    static function OnBeforeRequest(oSession: Session) {

        // Sample Rule: Color ASPX requests in RED
        // if (oSession.uriContains(".aspx")) { oSession["ui-color"] = "red";   }

        // Sample Rule: Flag POSTs to fiddler2.com in italics
        // if (oSession.HostnameIs("www.fiddler2.com") && oSession.HTTPMethodIs("POST")) {  oSession["ui-italic"] = "yup";  }

        // Sample Rule: Break requests for URLs containing "/sandbox/"
        // if (oSession.uriContains("/sandbox/")) {
        //     oSession.oFlags["x-breakrequest"] = "yup";   // Existence of the x-breakrequest flag creates a breakpoint; the "yup" value is unimportant.
        // }

        if ((null != gs_ReplaceToken) && (oSession.url.indexOf(gs_ReplaceToken)>-1)) {   // Case sensitive
            oSession.url = oSession.url.Replace(gs_ReplaceToken, gs_ReplaceTokenWith); 
        }
        if ((null != gs_OverridenHost) && (oSession.host.toLowerCase() == gs_OverridenHost)) {
            oSession["x-overridehost"] = gs_OverrideHostWith; 
        }

        if ((null!=bpRequestURI) && oSession.uriContains(bpRequestURI)) {
            oSession["x-breakrequest"]="uri";
        }

        if ((null!=bpMethod) && (oSession.HTTPMethodIs(bpMethod))) {
            oSession["x-breakrequest"]="method";
        }

        if ((null!=uiBoldURI) && oSession.uriContains(uiBoldURI)) {
            oSession["ui-bold"]="QuickExec";
        }

        if (m_SimulateModem) {
            // Delay sends by 300ms per KB uploaded.
            oSession["request-trickle-delay"] = "300"; 
            // Delay receives by 150ms per KB downloaded.
            oSession["response-trickle-delay"] = "150"; 
        }

        if (m_DisableCaching) {
            oSession.oRequest.headers.Remove("If-None-Match");
            oSession.oRequest.headers.Remove("If-Modified-Since");
            oSession.oRequest["Pragma"] = "no-cache";
        }

        // User-Agent Overrides
        if (null != sUA) {
            oSession.oRequest["User-Agent"] = sUA; 
        }

        if (m_Japanese) {
            oSession.oRequest["Accept-Language"] = "ja";
        }

        if (m_AutoAuth) {
            // Automatically respond to any authentication challenges using the 
            // current Fiddler user's credentials. You can change (default)
            // to a domain\\username:password string if preferred.
            //
            // WARNING: This setting poses a security risk if remote 
            // connections are permitted!
            oSession["X-AutoAuth"] = "(default)";
        }

        if (m_AlwaysFresh && (oSession.oRequest.headers.Exists("If-Modified-Since") || oSession.oRequest.headers.Exists("If-None-Match")))
        {
            oSession.utilCreateResponseAndBypassServer();
            oSession.responseCode = 304;
            oSession["ui-backcolor"] = "Lavender";
        }

        if (oSession.uriContains("/apinfo"))
        {
            oSession.oRequest["Host"] = "192.168.88.13" //my real devices IP
        }
    }

but the app (although success in connecting) when the module returns 401 Unauthorized the app does not try anymore

Also tried to add the my device to the app but, sadly it doesn't like it https://api.melview.net/api/serialscan.aspx reports {"claim":0,"noexist":1} for my device

while https://api.melview.net/api/unitadd.aspx reports {"result":"NOT FOUND","userunits":0}

So someone that has his unit on AU/NZ app would have to try this I guess

[fperk]

I have three air-air heat pumps, two of them have the MAC-577IF2-E wifi unit and one has the MB507IF-E.

I'm also interested in this to bypass the melcloud and to control the devices from local network only because I wanted to integrate them into Home Assistant or a similar software.

For me the login to /config works with these credentials:

• Username: user
• Password: Key from the sticker/WiFi Password

If I can somehow assist in this, I would be glad to help.

[dragonbane0]

All the endpoints support GET, doing that prompts the server to return the form mask that then performs a POST when you hit Submit. So the passwords can be tried that way and should work if they are correct

@Pascal66 are these passwords you posted the actual password or the base64 encoding of it? @niobos I guess just in case it was the base64 version and you tried the browser login mask, the actual password would probably be the decoded variant instead, e.g. "w;sW5{" for d9c7c1c1e8

@veso266 AU/NZ app is region specific since the adapters sold in AU/NZ ship with the server name it tries to connect to. The EU ones try to connect to MelCloud, the AU/NZ devices to MelView. These services are isolated from each other presumably, so the AU/NZ app will only allow you to add a device that the respective server knows. So without hacking the adapter you wont be able to add an EU device to MelView. As far as it works I doubt the app enables echonet. It tells the server which then issues a command to the unit to enable echonet. This command itself presumably works on every region adapter, but since we can't mock the server with the HTTPS encryption right now, we can't make use of it

[Pascal66]

d9c7c1c1e8 fc03045a06 d7b8c8ffaf

@Pascal66 are these passwords you posted the actual password or the base64 encoding of it? They are all 10 chars like all common user password (on stickers), so guess not base64 and only specific to the 'APP..zip' firmware

[kalwinskidawid]

@fperk Could you open MAC-577IF2-E? I would like to take a look at the board, would you take pictures from both sides? Currently, I do not have access to these modules, and I would like to see what's in there in general.

[fperk]

@fperk Could you open MAC-577IF2-E? I would like to take a look at the board, would you take pictures from both sides? Currently, I do not have access to these modules, and I would like to see what's in there in general.

Sure, here are the pictures from both sides:

[veso266]

hmm, maybe one of this test points, is UART RX and TX pin, which should hopefully give you the log

you just power it with 5V according to this connector pinout I found Maybe UART is already on the connector (but not sure if the log UART is)

Could you unsolder the RF Shield (the device will still work without, it will just produce more noise into RF enviroment and it will get afffected by outside noise more, meaning it will have weaker wifi signal), under it is probably an Ameba1 MCU and it does offer UART

PPS: for the courious minds, you can even reset the device to factory with a remote control (I wonder what command the AC sends over UART fo the device to make it reset)

with the remote control off, press and hold the + (temp) button for approx. 5 seconds.
a number will appear on the screen:
-1 = access poit
-2 = wps mode
select the number, click the on button on the remote control.
a led will start flashing on the split.
 (-1 )then perform the usual setup steps

[kalwinskidawid]

To me it looks like that on MXIC probably includes all config + certificates. I wonder if they set up an OTP, would it be possible to solder it out and read it. But my guess is that they prepared for it. Maybe I'm dump, but I don't see any procs here, so all the http encryption must be done on the main unit side? So ... when connected to the main unit, the unit would have to ask this dongle for the key (that is, it would be possible to eavesdrop?)

@veso266 Interesting idea with this uart on the wifi card

[veso266]

@kalwinskidawid processor is probably under RF shielding, no wonder, if it includes wifi, and in my opinion a must

as for reading MXIC, is desoldering realy nececery? Cant you just use a clamp like this: https://www.locksmithkeyless.com/products/autel-apa103-im508-and-im608-eeprom-clamp-cable to connect to it direcly

if this realy uses Ameba1 MCU like firmware analysis showed, then I don't think this is OTP (One time programable), you can also update the firmware

Maybe the chip is locked so it cannot be read, but not the NVRAM (which is where config and all the passwords are stored)

Looks like all the interesting things are under the shield

[dragonbane0]

Exciting stuff.

The NVRAM is definitely writeable at runtime since the firmware has a routine to write to it. Dumping the permanent data on it should give us all the passwords (and pray they either aren't device specific or that they are easily derivable from a known data point at least).

Not sure if the test points will give out the system log without turning on the mentioned debug mode, but if it does then you would also get the passwords during bootup.

PS: The technical specs of the 32 MB Flash chip just in case: https://www.mxic.com.tw/en-us/products/NOR-Flash/Serial-NOR-Flash/Pages/spec.aspx?p=MX25L3233F&m=Serial%20NOR%20Flash&n=PM2113 Pretty good datasheet for it

[veso266]

@dragonbane0 if passwords are leaked on debug log, then I guess they are meant to be used (and you need the password to turn on debug mode, so I guess at least the passwords, should be visible, because if they aren't how will u turn on debug log) and seen by someone that knows what he is doing (eather by using a special jig provided by the factory (meaning test points)) or even on the outside connector (unlikly but possible, since imagine if you need to change the server on 1000 devices, you probably will not solder tiny wires)

I hope they are not device specific, but if they are, they have to leak to a tool that is meant to read them

PS: Interesting that the flashchip is outside the RF shield (why not inside, it has to be connected to the MCU anyway)

[dragonbane0]

@veso266 Yeah for quick technician access I would say the passwords are either not device specific, or they are but can be obtained via log or maybe they are derived from the MAC or other info on the sticker and depending on access level Mitsubishi gives you the app that calculates the password based on device info. But this algorithm if it exists could maybe be reversed.

I just hope they are generic

[kalwinskidawid]

@veso266 Are you going to try to dump the NVRAM?

[veso266]

@kalwinskidawid sorry, I cannot acsess mine physically, its in a very hard to reach spot

[Pascal66]

Started a page with all the Ghidra reverse https://wordpress.priveyes.net/mac-577if2-e-realtek-rtl8195a-reverse-passwords/

As explained there https://blog.dest-unreach.be/2022/06/04/mitsubishi-wifi-adapter/#mitsubishi-wifi-adapter, there's some clues, but the analyze is wrong (he miss the httpd library wich must be included)

So i've decided to improve it. As it follow my every day work, it can be improved every times

[niobos]

@Pascal66 thank you for improving my analysis. I have very little experience reverse engineering, so I'm sure I've missed things.

[Pascal66]

@niobios> thank you for improving my analysis. I have very little experience reverse engineering, so I'm sure I've missed things. Dont worry, it took me 1 year to reverse my io-homecontrol heaters. So thank you for this work, it was the first real attempt to work on this firmware

[Pascal66]

What is sure is that the 'user password' is different from the others (admin, suser, root)

...
  app_flash_data_read_3000433c(flash_b9_login_user_len,&login_user_len,4);
  if (0x40 < login_user_len) {
    login_user_len = 0x40;
  }
  app_flash_data_read_3000433c(flash_ba_login_user_str,login_user_str,login_user_len);
  i_root = get_login_data_300197d8(3,&login_root);
  i_suser = get_login_data_300197d8(4,&login_suser);
  i_admin = get_login_data_300197d8(5,&login_admin);
  if ((i_root < 0 || i_suser < 0) || i_admin < 0) {
    LOG_console_30003438(s_ERROR:_decsec_getdata_fi_PW_30054fc4);
  }
...  

It's use the 10-20-50-(Production)-xxxxxx string-part (not the 60(china1))

Before the common "httd_start", all passwords are put on each endpoint_response_structure,

After that, when a call to an endpoint with POST, they are all compared with the startup_made base64