Help with reverse engineering (HTTP/MQTT) for connecting new device

Hi folks,

I hope someone can help here. I’ve installed a new device at home for mechanical ventilation, it has an iPhone app that can communicate with a ESP dongle wifi connected via rj11 to the device.

Before trying to understand the app, I see the response from Internet to my dongle is in MQTT ( eg. to set ventilation to 2, I see the publish message to units/{mydevicemac}/app/fan) … so I was wondering if via MQTT I need to subscribe to the remote server to send this message to my unit, or I can directly send this publish to the unit (like man in the middle attack).

The app is quite difficult for me to understand … it seems it reads the values via JSON from one server (based on the serial number of the device I put in the app), then when I change a value it asks the remote server to send it via MQTT.

In facts at the beginning the ESP is pinging a remote MQTT server (it will be configured internally to do so), and via app the MQTT server knows mac address of the ESP (and serial number) and maybe in this way he knows the remote client can be a subscriber.

Any suggestion?

Thank you all!!!

Andrea

maybe you can spoof the MQTT broker address? in this case your device will connect to YOUR mqtt server and you can check all the messages it sends. alternatively you can try to connect to the standard mqtt server and subscribe to topic “#” ,but I assume you will need authentication credentials to connect.

I already see all messages between client and broker, as in the Switch I monitor the port connected to the wifi so I see all traffic going through this

Update.

I can connect to the standard mqtt server, so as subscriber I can see for example the speed of the fans.

The problem is: as publisher, I can modify the speed of the fans, and when eg. I change from 3 to 2, the app is updated, but the device is actually not changing the speed :frowning:

Mmm … any suggestion?

Andrea

FYI I see in my sniffer, all traffic directed to this devices is MQTT only. So I need to understand the behavior above … mmm

this is weird, the genuine app shows that the speed has changed (via your MQTT publish command), but the device is unchanged. maybe you are missing some “committ” command? something that tells your device to apply the current configuration?

the behavior is like this:

  1. if I change the fans speed via app, I see usual MQTT messages to the device and to my MQTTBox (the app I use to emulate a MQTT client)

  2. if I change the fans speed via MQTTBox, I see the “official” app is updated, the MQTTBox is updated as well, but I don’t see any MQTT publish message from the broker to the device, only messages to MQTTBox

I suspect 2 is because I’m not using user/pass, maybe as “guest” I can see but I can’t publish … but why I can change my MQTTBox? mmm …

Another piece.

If I publish “retained”, the app is updated. If not, the genuine app is not updated. But the usual messages are not “retained”.

Try sniffing the traffic from startup of the app. There might be some messages registering or authenticating the app at startup that you have to replicate to fully simulate the app. If these messages are not passed, it defaults to read only.

I’m afraid I have no advice to provide to solve you specific problem but based on what you’ve described I have some very significant security concerns.

The fact that you can intercept and see the message traffic indicates that there is no encryption between your device and the MQTT broker running somewhere out there on the Internet.

This strongly implies that there is no authentication between your device and that broker either. So literally anyway from anywhere can access the messages passing back and forth between your device and this third party hosted MQTT broker.

The fact that you can publish messages to this broker makes this even more of a concern. Now not only can anyone from anywhere monitor this system, they can modify the settings.

If this company is that sloppy with the security around this part of the system, I certainly wouldn’t trust them with my email address or any other account information. It’s frankly shocking and scary how little attention this company is paying towards security.

On the bright side this means that you stand a chance at reverse engineering the message traffic so you can make it work.

1 Like