Trying to access my myQ Hub's MQTTS connection

Hardware
1

Let me start by saying nothing in this post is actionable or directly helpful to anyone. I’ve been poking around and learned some stuff, and this is me sharing it.

I have one of those myq hub’s, mine is modal MYQ-G0401 according to the box, “MYQ-G0401 MC” according to the about.html page that it provides on port 80.

And I’m sure I don’t have to tell anyone here about the status of myQ and HA.

Before you ask, I don’t really want to replace it, like many folks are doing (and for good reason), I just want local control over it.

Thus far, I haven’t been able to accomplish anything useful. But I thought I would share what I have learned. Maybe someone will want to contribute and help me get somewhere.

The hub normally maintains a connection to connect.myqdevice.com port 8883.

I did some Wireshark captures of the hub talking to the cloud. It connects to TCP port 8883 using TLS 1.2. I tried to MITM it with mitmproxy, but I was not able to get anywhere.

I noticed that the mosquitto add-on in HA can also use that port. I tried running mosquitto locally and used DNS spoofing to convince the device to try to connect to it. That was also not fruitful. But perhaps not for the reason you think. It was actually mosquitto rejecting the connection.

This is because it is using TLS with a pre-shared key.

Cipher Suites (2 suites)
    Cipher Suite: TLS_PSK_WITH_AES_128_CBC_SHA (0x008c)
    Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)

More info about that: Ciphersuite Info

My understanding is that that means there is an AES 128 key inside the myQ hub itself, and that key is also known to the client.

Most likely each device has a unique shared key set in the factory, but I don’t know that. If they all had the same one, then we would only need to extract it once and could build something that everyone could use.

Because it is a pre-shared key (PSK), you can’t MITM it, even if you could get it to trust your self-signed certs, because the key is never transmitted.

But if you did obtain it, you could decrypt past sessions as well as new ones.

So, if I understand right, that would be perfect if some sort of permanent proxy, that decrypts the traffic and sends the door status to HA, and that could probably even inject commands to control the doors.

It suppose it is also possible that the PSK is transmitted to the device in some way during setup, or that the apps have access to it. If someone has decrypted the app’s traffic, if you’ve seen anything that looks like a PSK, that would be good to know.

As a part of the TLS handshake, the client does send an identity. Mine is 10 characters and is the serial number. That implies that the PSK is per serial number. (But doesn’t tell me if it’s factory set or sent to it during registration.)

The hub also has port 80 open. (I couldn’t find any other open ports with nmap).
If you go to the hub’s IP and /about.html it will list some info, including the serial number.

During the Server Hello, I saw it sent the random bytes (copied as C String in Wireshark): "\x17?\xcd>\x92\xa2\xef\xf3O\x92\x9e\x8f\x14\x98\xbb~tT\xf1\xa8DOWNGRD\x01"

That last part, DOWNGRD, doesn’t look very random.

I don’t know what the random bytes are used for with PSK mode, maybe they’re repurposed? Hopefully someone who knows TLS better than me can comment.

Once the connection is setup, the data is transmitted with “Content Type: Application Data (23)” and Wireshark adds the implied info “[Application Data Protocol: MQ Telemetry Transport Protocol]”.

Other Info:

Here they mention they can dump the firmware with JTAG. I’ve never done anything like that, but it sounds like a possible next step. Adafruit has an adapter for $60. Might not get me anywhere, but it does kind of sound like fun.

I’ve learned that if you go to a page on fcc dot gov, you can type in the FCC ID from the back of devices and learn quite a bit about them, including photos of the inside! Interestingly, the picture of the inside they show on the McAfee article seems to be from that and not from their own teardown. (There’s also some scammy pages that mirror the real fcc site.)

2 Likes
2

Check this out: GitHub - fuxxociety/MyQ-ESP-transplant: Attempt to replace the wifi module on a MyQ-equipped garage door opener with an ESP8266 and ESPHome.

Someone managed to get the FW dumped…
I’ve been trying to figure out if any of the http endpoints can get us anywhere.

1 Like
3

Also have you tried to do a full reset and wireshark all the communication from that point?

4

Thanks! I am still going through that. Looks like it’s a lightly older version of the firmware than what my own device has, and I am not sure if it’s a different model or the firmware is the same across the ones that support Homekit and those that don’t. I was able to learn a few more urls to hit on port 80 at least.

I haven’t been able to find the AES key yet, but I’ve just been running strings on it so far, and so it would only stand out if it’s hex encoded or something.

5

Also have you tried to do a full reset and wireshark all the communication from that point?

I have not done that yet, but I am considering it. It’s a little bit tricky as I don’t want to disable it for too long and annoy the rest of my family.

6

Very interesting… did you try to change the states of the door, motion, light, etc. and see if these messages on port 80 change. Makes me think it’s telling you it’s DOWN to GROUND level.

7

Well, this was port 8883, the MQTTS connection between the myQ hub and connect.myqdevice.com.

And this was just the initial connection setup, so would normally not happen very often, only when it loses its connection and has to reconnect, or was power cycled.

That is a good point though that DOWNGRN might be a garage door state. I have two doors, and both were down. I did not try opening my garage doors while making the myQ reconnect.

Another possibility is that it is sending uninitialized memory as the “random bytes”.

I was hoping a TLS expert would see this and tell me if random bytes is even meaningful in PSK (pre-shared key) mode. I think it’s normally uses by the diffie-hellman-like key exchange protocols. But PSK mode doesn’t derive a key, instead the myQ device just has a key preprogrammed into it, and also stored on the myQ server.

If I can find a way to get that key out of it, I should be able to decrypt all the TLS traffic, even past captures. It’s most likely unique to each device. It sends the serial number as a hint or sort of username that goes with the key, so that the server knows which key we’re using.

If it’s sending status info in the random bytes, I’m not sure that is useful, as I’d have to reset the connection every few minutes to “poll”. myQ might start to wonder why all of a sudden everyone’s internet is so unreliable.

If it’s uninitialized memory, that could lead to an exploit to recover the PSK or other sensitive info stored on the device. (But creating such as exploit is almost certainly beyond my abilities.)

8

I also found this on the web: Chamberlain Smart Garage Control teardown | TechThink

1 Like