Reverse Engineering a Coway Air Purifier to Bypass Manufacturer Cloud Services

By exploiting a security oversight where a Coway Airmega IconS air purifier downloads its root certificate over unencrypted HTTP, a user was able to intercept the device's communication and redirect it to a private server. This maneuver effectively 'de-clouded' the device, allowing it to be integrated into a local home automation system without relying on Coway's official cloud infrastructure.

The Problem with Cloud-Dependent IoT

Many modern smart home devices, such as the Coway Airmega IconS, rely on manufacturer-hosted cloud services for remote control and app integration. While convenient, this dependency creates a single point of failure: if the manufacturer's servers go offline, change their API, or discontinue the service, the device's functionality can be lost.

The author of the project noted several instances where Coway's cloud service broke due to server maintenance, account bans for using third-party integrations, or changes to the mobile app's HTML layout. To ensure long-term reliability, the goal was to move the control logic from the cloud to a local server.

Intercepting the Bootstrap Request

The primary technical hurdle in bypassing a cloud service is the use of SSL certificates, which prevent a device from connecting to a fake server. However, the Coway device was found to download its root certificate from an Amazon S3 bucket over unencrypted HTTP during its initial setup.

By setting up a Man-in-the-Middle (MitM) environment using a Raspberry Pi and mitmproxy, the user intercepted this specific request. They used a custom plugin to swap the official certificate with one generated by their own lab, forcing the device to trust the user's local infrastructure instead of the manufacturer's.

This image illustrates the specific vulnerability where the device fetches its root certificate over plain HTTP, allowing for MitM interception.

Mapping MQTT Commands with AI Assistance

Once the device trusted the local certificate, the user could see the raw traffic. While the initial HTTP requests provided metadata like MAC addresses and certificate tokens, the actual operational commands were sent via the MQTT protocol over port 8883.

The user employed an LLM to help navigate the tedious process of configuring the network's firewall rules. By observing the encrypted MQTT stream while interacting with the official app, the user could map specific button presses to the corresponding messages on the message bus, eventually allowing for full local replication of the device's features.

This visual demonstrates the raw MQTT stream used to identify specific commands for fan speed and other controls.

The user utilized an LLM to navigate the complex process of mapping button presses to the underlying message bus.

Limitations and Security Implications

While the project succeeded, it highlights a significant security flaw: devices that fetch root certificates over HTTP are inherently susceptible to interception. This 'bootstrap' vulnerability allows an attacker—or a hobbyist—to redirect the device's traffic to any destination.

The author notes that while this method provides independence from the cloud, it requires a sophisticated setup involving network routing, proxying, and protocol analysis. Furthermore, the specific API calls for fan speed were not visible in the initial HTTP requests, requiring the user to further analyze the MQTT stream to achieve full control.