I wanted to see if a connected sleep hub could talk to a server on my LAN in place of the vendor’s cloud, without opening the hub. The lead I gave the agent was a reported leak of certificate material associated with eMudhra.

[agent obo nadeesha]

  1. The experiment asked whether leaked certificate material associated with eMudhra could help intercept a connected sleep device’s cloud traffic and replace the vendor backend with a local server, with the hub left closed. A certificate contains a public key. To present it as a TLS server, the server also needs the matching private key, and the client needs to accept the certificate chain and hostname. Even a usable server key would not ordinarily decrypt previously captured sessions that used ephemeral key exchange. The leaked material was never inspected or tested during the experiment.

  2. Multicast DNS resolved the device’s local hostname, and the workstation’s neighbor information linked its IP address to a link-layer address. Direct TCP probes checked common web, MQTT, and control ports. An SSH service answered and returned an OpenSSH banner. The other ports checked did not expose a local control API. These probes established which services answered from the LAN, while the device’s outbound connections were still unknown.

  3. Packet capture on the workstation required elevated privileges. The workstation was also an ordinary Wi-Fi client, so it would generally miss the device’s unicast traffic. The proposed setup was to connect only the device to a dedicated Linux or OpenWrt access point and run tcpdump on its LAN bridge. Filtering by the device’s link-layer address at that point would cover IPv4 and IPv6. The plan was to capture an idle baseline and a fresh connection, then timestamp a few app actions such as powering on, changing the temperature, and powering off. DNS, destination addresses, visible handshake metadata, and traffic timing could then be compared against those events. Another owner had reported that their unit queried a public DNS resolver directly, so the plan accounted for traffic that might bypass the DHCP-provided resolver. The gateway was never set up, and no device-to-cloud capture was collected.

  4. DNS or routing could steer traffic to a local listener, but the device would still authenticate the server for the vendor hostname. Trusting a proxy certificate on the phone would affect the phone app’s connection. The hub’s connection would have to be tested separately. For passive decryption, the proposed route was obtaining the session secrets. For a live proxy, the first test would be whether the device accepted the proxy’s certificate on an observed connection. A rejection alone would leave several explanations open, including ordinary certificate validation and pinning. Source review also found that a script advertised as a pinning bypass only logged TLS failures and requests that already succeeded. No certificate acceptance test ran. If the proxy had worked, the next step would have been to relay traffic to the real backend and observe the plaintext exchanges before attempting to reproduce the device’s authentication, commands, and state.

  5. Community projects showed how to replace the vendor’s Device API Client (DAC) and have the stock hardware process connect to the replacement over an internal Unix socket. That socket carries framed commands and responses. A separate local server could use the replacement’s REST API or MQTT integration, while the on-device service handled hardware control and scheduling. The documented access path required opening the hub and attaching a low-voltage UART adapter to reach a serial console. The vendor’s Bluetooth fallback was another possible route for basic local controls, but its protocol was not reverse-engineered during the experiment.

  6. An SSH host-key scan confirmed that the service completed enough of the handshake to present a host key. Two documented account candidates were then tested with the workstation’s existing Ed25519 key, with password authentication and SSH agent fallback disabled. The server offered public-key authentication and rejected that key for both accounts. The workstation had no prior SSH configuration or saved host entry for the device, and its SSH agent had no loaded identities. The test established that SSH was reachable and the offered key was unauthorized. A working login still depended on finding an already authorized private key or finding a way to enroll a new public key. The eMudhra material was not used in this test.

  7. The final discussion compared replacement hardware with documented local Bluetooth control or reported LAN HTTP APIs. On the original device, the hands-on work ended with discovery, port probing, and failed SSH authentication. The gateway capture, firmware inspection for endpoint or trust-store settings, and software-only key enrollment remained proposed work. No firmware was changed, no cloud traffic was decrypted, and no mock server was built.