Hi! I maintain the python-roborock library and the Roborock integration in Home Assistant.
Roborock vacuums use a local protocol for direct commands, but they still route all map data strictly through the cloud (even though the map is stored locally). Even worse, if you try to block the vacuum from accessing the internet on your router, it will constantly reboot its Wi-Fi connection trying to re-establish a cloud connection, meaning you can't rely on just using a private local connection.
It works without having to open the device or root it, taking advantage of a couple of quirks during the onboarding process:
1) The vacuum has api-%s.roborock.com baked into its firmware. It injects the region directly into the string and this is the first exploit we take advantage of. The app will send in your region as a two letter code, e.g. 'us', 'eu', 'cn'. We send in a full URL ending with a '/' (e.g. 'example.com/'). The vacuum then treats "api-example.com" as the host and the rest as the URL path(e.g. 'api-example.com/.roborock.com'), directing its traffic to your server so long as there is a valid HTTPS certificate on that domain.
2) The second part of the handshake requires encrypting a message via a public key that is stored on Roborock's cloud where the private key pair is on the vacuum. We are able to reverse engineer the public key as the robot sends signatures with its message. Because of how RSA works, each signature is mathematically tied to the secret public key plus some extra noise. By gathering a few signatures across multiple onboarding attempts and taking their greatest common divisor, the noise cancels out and cleanly isolates the vacuum's actual public key which allows the server to encrypt its response and complete the pairing.
I wanted to share this on HN as I think this points to a very interesting thing that is happening. I have been playing with this idea for years in my head and I have not been able to get it to work (and I am not the only one who had looked into the api-%s avenue). I'm not a cryptography expert and had no idea that the signature exploit was even possible. I was stuck for long enough that I decided to throw the problem at some long-running agents, and they found the greatest common divisor exploit.
IoT companies put most of their security effort into the cloud, since that's what they actually run. The vacuum is just one device on someone's home network, so it gets less attention and corners get cut. I think LLMs that are willing to throw themselves at a problem for hours are going to make stuff like this a lot easier to pull off and a lot more common.
Roborock vacuums use a local protocol for direct commands, but they still route all map data strictly through the cloud (even though the map is stored locally). Even worse, if you try to block the vacuum from accessing the internet on your router, it will constantly reboot its Wi-Fi connection trying to re-establish a cloud connection, meaning you can't rely on just using a private local connection.
I built a self-hostable version of Roborock's cloud: https://github.com/Python-roborock/local_roborock_server
It works without having to open the device or root it, taking advantage of a couple of quirks during the onboarding process:
1) The vacuum has api-%s.roborock.com baked into its firmware. It injects the region directly into the string and this is the first exploit we take advantage of. The app will send in your region as a two letter code, e.g. 'us', 'eu', 'cn'. We send in a full URL ending with a '/' (e.g. 'example.com/'). The vacuum then treats "api-example.com" as the host and the rest as the URL path(e.g. 'api-example.com/.roborock.com'), directing its traffic to your server so long as there is a valid HTTPS certificate on that domain.
2) The second part of the handshake requires encrypting a message via a public key that is stored on Roborock's cloud where the private key pair is on the vacuum. We are able to reverse engineer the public key as the robot sends signatures with its message. Because of how RSA works, each signature is mathematically tied to the secret public key plus some extra noise. By gathering a few signatures across multiple onboarding attempts and taking their greatest common divisor, the noise cancels out and cleanly isolates the vacuum's actual public key which allows the server to encrypt its response and complete the pairing.
I have a full technical write up here: https://python-roborock.github.io/local_roborock_server/tech...
I wanted to share this on HN as I think this points to a very interesting thing that is happening. I have been playing with this idea for years in my head and I have not been able to get it to work (and I am not the only one who had looked into the api-%s avenue). I'm not a cryptography expert and had no idea that the signature exploit was even possible. I was stuck for long enough that I decided to throw the problem at some long-running agents, and they found the greatest common divisor exploit.
IoT companies put most of their security effort into the cloud, since that's what they actually run. The vacuum is just one device on someone's home network, so it gets less attention and corners get cut. I think LLMs that are willing to throw themselves at a problem for hours are going to make stuff like this a lot easier to pull off and a lot more common.