How to Tame a Light Switch

Introduction

The rapid growth of Internet of Things (IoT) devices has transformed our daily lives—from smart homes to industrial automation. But with increased connectivity comes heightened risk. Many IoT devices, built for convenience and efficiency, often lack strong security protections, making them easy targets for cyberattacks.

IoT security focuses on protecting these devices from threats such as unauthorized access, data breaches, and remote exploitation. Securing them is essential to protect personal data, maintain privacy, and prevent disruptions to critical infrastructure.

In this post, we explore the security evaluation of a commercially available smart light switch—the Orvibo A10. Designed for user convenience with features like remote control and scheduling, this device also exposes several security weaknesses. As we show, these same features can be exploited to compromise a home network.

Through reverse engineering of the firmware and analysis of encrypted network traffic, the researcher identified critical flaws, including reuse of encryption keys and vulnerability to malicious control servers. This case study walks through the entire process, from initial reconnaissance to physical teardown and in-depth testing.

In this post, you’ll learn about:

Hardware Analysis: How the teardown of the Orvibo A10 revealed its internal components and system architecture.

Exploiting Misconfigurations: How weak configurations and poor security practices allowed unauthorized control of the device.

Remote Flashing: How the smart switch’s remote firmware update feature over HTTP can be hijacked to extract sensitive data like account and Wi-Fi credentials.

Network Access: How a compromised smart switch can serve as a gateway for attackers to infiltrate the broader home network.

The analysis of the Orvibo A10 underscores the serious security risks embedded in many IoT devices. It highlights the urgent need for manufacturers to implement stronger encryption, avoid hardcoded credentials, and deliver regular firmware updates.

Whether you're a cybersecurity professional, IoT developer, or simply interested in tech security, this post offers a clear view into the vulnerabilities that threaten connected devices—and what can be done to stop them.

Target Choice and Initial Info Gathering

Following a brief market survey, we selected the Orvibo A10 Smart Switch for analysis. This model had not been publicly examined before and offered a broad range of features, making it a promising target for security evaluation.

Tip: Devices sold in the U.S. that use radio frequencies must be certified by the FCC. This certification process often provides useful technical details. For many products, you can find radio frequency specs and internal images using fccid.io.

In the case of the Orvibo A10, we confirmed the presence of at least Wi-Fi and Bluetooth connectivity. The packaging also indicated 902 MHz communication support. FCC documentation provided valuable insights—particularly the "Internal Photos" section, which includes teardown images.

From the available materials, we identified two sets of through-hole test points and three notable chips on the board. With a general understanding of the internal layout, we proceeded with the physical teardown.

Note: The device is designed to operate on a 120V AC circuit, similar to standard wall light switches. To reduce electrical risks during testing, we used a bench power supply to operate the device at lower, safer voltages.

Teardown

Now to the teardown. Fortunately, disassembling the device is relatively straightforward. A few guitar picks and a standard Phillips screwdriver were sufficient to take it apart completely. The top PCB can be separated from the bottom section, which appears to function solely as an AC-to-DC converter to power the device.

Image 1: Disassembled Switch

With the board removed, we could take a closer look at the components. Two antenna wires are visible: a black one labeled “Wi-Fi” in the FCC internal photos, and a white one likely corresponding to the 902 MHz frequency noted on the packaging. To confirm this, we used a common technique—calculating the wavelength for 902 MHz and checking for antenna lengths that match half or quarter wavelengths. In this case, a quarter wavelength is just over 3 inches, which matches the length of the white wire. The angular metal pattern on the PCB is the printed antenna.

Although the FCC ID page doesn’t explicitly list 902 MHz, that’s likely because it only shows transmit frequencies. The smart switch comes with a remote, which is probably where the 902 MHz signal is utilized. We examined the remote as well.

The packaging includes a second FCC ID, which leads to a separate listing online. This confirms that the remote operates at 902.8 MHz and provides more detailed frequency information. With this knowledge, we attempted to capture radio traffic using a software-defined radio (SDR) device like the HackRF One.

Our initial goal was to identify a consistent packet format to control the switch—such as on/off commands. However, the captured data didn’t match any recognizable pattern, and attempts at decoding yielded inconsistent results. Without a clear understanding of the expected data structure, we decided to move on to the next phase of analysis.

Hardware Analysis and Testing

The next step was figuring out how to power the device without connecting it directly to 120V AC. As noted earlier, the device consists of two parts: the lower board, which handles AC-to-DC conversion, and the upper board, where all logic resides.

On the upper board, we identified three chips: the A7129, the C907B2, and the OW32C3C. The Amazon listing for the device mentioned an ESP32C3, so we initially assumed the OW32C3C was a customized variant. (Spoiler: it turned out to be a standard ESP32C3-FN4, just housed in a package with different pin mapping and a few additional components.)

Image 2: Power Pins for Orvibo A10

The logic board connects to the adapter section via an 8-pin interface. The 4 pins nearest the edge were connected exclusively to the C907B2, the next 2 to the ground plane, and the final 2 to VCC, providing power to the board. Since 3.3V and 5V are common operating voltages for ICs, we started with 3.3V and gradually increased voltage to observe behavior.

When connected to a bench power supply via the identified VCC and GND pins and set to 3.3V, the device began blinking white—indicating partial operation. Pressing the side buttons caused the LED to blink blue, confirming that the device was responsive.

With power confirmed, we probed the accessible test pins for useful signals. The left side had labeled pins: G, T, R, and V—likely UART. However, connectivity testing revealed these were connected to the C907B2 rather than the OW32C3C, which likely handles Wi-Fi and Bluetooth functionality.

Using an oscilloscope on the GTRV pins, we observed voltage changes, but connecting a serial cable didn’t yield any readable output. Probing the rightmost pins showed activity as well, though no useful data was captured. Given the limited results, it was time to consult documentation.

Searching for "OW32C3C" yielded no results, prompting us to physically remove the shielding over the chip. Using wire cutters and gentle prying, we exposed the actual component underneath: an ESP32C3-FN4. Its pins were remapped on the custom board, explaining the initial confusion.

To verify functionality, we powered the device and used the official Orvibo app. The device paired successfully, and toggling it on and off triggered the blue LED—confirming full operation at this stage.

Now with confirmed access to the ESP32C3, we turned to Espressif’s documentation. The datasheet and technical reference manual list available pins and features. One particularly helpful feature is the integrated USB-to-JTAG controller accessible via GPIO18 (D-) and GPIO19 (D+).

Image 3: esp32c3 with chip’s shield removed

We soldered wires to the D+ and D- pins and connected the device to a laptop. However, Windows returned a “device descriptor not recognized” error. Suspecting a bad connection, we adjusted the wires, but in the process accidentally tore off the metal via for D+, losing access entirely.

With USB access no longer viable, we explored additional pin mappings on the ESP32C3. Fortunately, the OW32C3C sub-board is removable using a hot air gun, making further analysis easier. Mapping out the remaining pins suggested that UART would likely provide a reliable access point for deeper communication and data extraction.

Reading Bootlogs

One tool that proved extremely useful for quickly testing pins and gathering debug data was the PCBite 20 kit. This kit includes spring-loaded pogo pins, which allow for a temporary, solderless connection to test points or vias—perfect for probing delicate boards during development.

Using these pogo pins, we re-examined the test points with a Flipper Zero configured as a USB-UART bridge at 115200 baud, as specified in the ESP32C3 documentation. After testing various pins, the only one that consistently produced readable output was labeled SWDIO. While some other pins occasionally output garbage data, SWDIO provided meaningful serial logs.

Image 4: Rx & Tx pin locations on Orvibo A10

Image 5: Full Hardware Setup

Despite its label suggesting SWD (Serial Wire Debug), SWDIO turned out to function as the UART TX pin. This may indicate that the board was reused or redesigned with different microcontrollers at some point, leading to a mismatch between labeling and actual functionality.

Our initial attempts to read UART output used PuTTY to connect to the COM port. However, PuTTY did not handle dropped or reset connections well, often requiring a full restart. To streamline the process, we switched to a more developer-friendly approach: using idf.py -p COMX monitor—Espressif’s standard monitoring tool. This tool automatically reconnects and is tailored for ESP32 development, making it ideal for capturing and analyzing device logs.

Once connected, the SWDIO pin began streaming bootlogs, including system events and runtime messages. These logs contained valuable insights into the device’s behavior, startup sequence, and even fragments of the running code.

Image 6: ESP32 Boot up Information

The initial section of the bootlog is typical of what developers see when flashing or debugging ESP32 projects. It provides key information such as:

• Boot mode
• Application image details
• RAM usage breakdown
• Debug information including variable names, line numbers, and source files

This level of detail is extremely helpful in understanding the device’s startup behavior and internal operations—especially when no source code is available.

We’ll break down the full contents of the captured logs in the next section, as all attempts to transmit data to the board (via UART or otherwise) had failed at this point, making the logs our best window into its internal logic.

Reversing

As the device continued to operate, it began printing sensitive information such as publicKey, privateKey, and safecode. It also displayed GPIO states and firmware details.

Image 7: gpio state (for boot mode) and firmware name

The gpio state, in particular, is useful since the ESP32C3 will boot in different modes based on these values. This allows the device to boot into download mode, which retrieves the full flash dump from this light switch.

Image 8: Network connections and dynamic key setup

Once the device connected to its control server, we observed JSON-based communication with homemate.orvibo.com over port 10001. At one point, a URL appeared in the logs, which raised the suspicion that the device might be downloading a firmware update upon receiving a specific command.

Image 9: json messages sent to and from Orvibo server

To investigate, we configured a Raspberry Pi as a router (following an online guide) and connected the Orvibo A10 to it using the Homemate app. This setup allowed us to intercept and inspect the network traffic between the device and its servers.

Image 10: Example network packet from Orvibo A10 to homemate server

With traffic flowing through a packet-capturing router, we began dumping data and analyzing it. Notably, all TCP packets sent to homemate.orvibo.com:10001 began with a consistent magic number, 68 64, found at offset 0x30.

We observed the following structure:

• Magic bytes: 68 64 (constant across packets)
• Length field: Big-endian encoded
• Identifiers: Fields with values like dk or pk
• Unknown field: 4 bytes with uncertain purpose
• Key field: A 32-byte string, consistent across packets

After the first 42 bytes, the data changed across each packet. Diffing multiple samples in ImHex revealed consistent patterns: some 16-byte blocks repeated. This suggested the use of AES-128 in ECB mode, which doesn't use an initialization vector and produces identical ciphertext for identical plaintext blocks aligned on 16-byte boundaries.

This assumption was later validated by documentation for a different Orvibo device (the Kepler), confirming this encryption scheme.

We extracted potential keys from both the mobile app and a flash memory dump of the A10. Using a simple Python script, we tried to decrypt the traffic using AES-ECB with these keys. None of them worked.

Further analysis of the mobile app revealed that a native library call had been missed during our initial inspection. This meant we were missing a crucial step in the key generation or decryption process.

At this point, we turned our attention to the firmware image retrieved from the device’s flash memory. Tools for reversing ESP32 firmware were largely outdated or focused on Xtensa, while the ESP32C3 uses the RISC-V IMC instruction set.

We initially attempted to analyze the OTA update binary using Ghidra, but it threw multiple errors. As a simpler first step, we ran strings on the binary. This revealed numerous useful strings—mostly leftover from ASSERT statements in the ESP-IDF build process. These strings led us to a GitHub repository containing source code for a similar Orvibo device, which helped identify toolchains and libraries, though not the final exploit.

To proceed, we created a custom script to properly load the firmware image into Ghidra with accurate memory mapping. Once loaded, we expanded memory regions to recover missing strings and cross-references. We also encountered references to esp32c3_rev3_rom.elf, indicating that portions of the ROM were being reused or referenced.

With Ghidra properly configured, we focused on identifying the encryption function. This involved tracking calls to memcpy, examining JSON-related operations, and identifying patterns indicative of AES processing.

Having access to the ESP-IDF SDK source code was instrumental here. By matching strings in the SDK to those in the firmware image, we pinpointed critical functions related to OTA updates and encryption.

Eventually, this led to the discovery of the encryption key—which, crucially, turned out to be shared across all devices of this model.

Lucky Break and A Malicious Control Server

While searching for the discovered encryption key online, we stumbled upon an old CTF challenge page in Chinese, which included a script for running a web server that could send on/off packets to an Orvibo Smart Plug. It turns out Orvibo has been reusing the same encryption key across multiple products for years.

However, there have been updates to the protocol. This original static key no longer works for every packet. Instead, it is now used to securely transmit a dynamic key, which aligns with the earlier observations of pk and dk values in Orvibo's packet structure. The dynamic key is sent in the server’s first response, as shown in the decoded packet logs.

Image 11: json packet from server setting the dynamic key for session communication

With this knowledge, we created a script that could decrypt all device traffic. Although much of this traffic mirrored the boot messages already visible on the device, knowing the encryption scheme allowed us to go a step further: we could now build a fake control server and modify the messages being sent to the device.

While analyzing the decompiled OTA image, we also found a command handler. This handler supported multiple commands and passed a wide range of data. To streamline things, we searched for OTA-related strings in the binary and were rewarded with several matches. Many functions matched those in the ESP-IDF SDK, confirming that the device expected a downloadUrl field, which would be written to memory and used to fetch the update.

Rather than reverse every detail, we leveraged our ability to send arbitrary messages and adapted the script we had found earlier for this use case.

By simulating an outdated firmware version, the device requested the expected OTA update format. Based on our earlier traffic analysis, we knew that a cmd value of 255 was required to trigger the OTA flow. Replaying the request from the light switch and modifying the version number led the device to respond with an update request containing:

• md5
• size
• isForce (included as a precaution, though likely not validated in firmware)
• downloadUrl

Image 12: firmware update json packet

We found that while downloadUrl can be customized, the device enforces checks to block local addresses like 192.168.4.X. To get around this, we used dnsmasq to redirect requests to download.orvibo.com toward a local file server.

Armed with the proper request structure and a fake OTA server, we restarted the device and watched it attempt to fetch the update.

The first attempt failed. Thankfully, with a disassembled light switch, we could read the boot logs and realized the wrong key type was used. After correcting this, the device successfully connected to our local server and began downloading the update.

However, the update failed mid-process. We discovered that the firmware was rejected due to a mismatched app_name. The running firmware expected an app name of general_uart. After recompiling the firmware with this correct project name, we retried—and this time the upload and update were successful.

With our custom firmware running, we were able to:

• Extract non-volatile storage data, including the Wi-Fi password
• Enable the device to automatically reconnect to the original Wi-Fi network
• Convert the device into an open-access Wi-Fi access point, exposing it to anyone nearby

This demonstrates how, with minimal firmware validation and a predictable encryption structure, a seemingly simple smart device can be turned into an access point for broader network compromise.

Impact

This type of attack significantly lowers the barrier for malicious actors to infiltrate a network. Devices like the Orvibo A10 store sensitive data locally, including Wi-Fi credentials and user account information. In the wrong hands, this information can be used to:

• Access the victim’s account
• Join and explore the local network
• Establish persistence for long-term control or further exploitation

While the use of a dynamic key for traffic encryption is a step in the right direction, it becomes ineffective if the initial static key used to negotiate that dynamic key is hardcoded and reused across all devices. Once that key is extracted from a single unit, it can be used to decrypt communications across all similar devices—or even inject malicious commands.

Remediation

There are several effective ways to mitigate the kinds of vulnerabilities uncovered in this analysis:

Implement Code Signing: Requiring firmware to be cryptographically signed ensures that only trusted, verified updates can be installed. This relies on private keys that are never stored on the device, making unauthorized firmware injection significantly harder.

Use Unique Per-Device Keys: Assigning a unique encryption key to each device drastically limits the scope of a compromise. An attacker would need to breach each device individually, reducing the impact of any single exploit.

Follow Chip Vendor Guidelines: Manufacturers should strictly adhere to security best practices provided by chip vendors like Espressif. This helps avoid common pitfalls and ensures the secure configuration of key features like bootloaders and debug interfaces.

Conduct Rigorous Security Testing: Engaging in thorough, proactive security assessments—especially before product release—can uncover vulnerabilities that might be missed during development. This includes penetration testing, firmware audits, and configuration reviews.

By adopting these measures, manufacturers can dramatically reduce the risk posed by device-level vulnerabilities and build stronger, more resilient products.

Conclusion

Who would expect a light switch to act as a rogue router? It sounds absurd—but with today’s IoT devices, it’s not only possible, it’s surprisingly easy. These devices pack significant computing power, and when paired with exploitable firmware, they can become a direct threat to network integrity. In this case, no user interaction was needed—just the right packet sequence and a spoofed server were enough to hijack the device. Once compromised, the possibilities are wide open. Anything you can do with an ESP32 can be scaled and automated.

Securing IoT: A Lifecycle Responsibility

Protecting IoT devices requires more than reactive fixes—it demands a holistic, lifecycle-driven security strategy. From design to deployment, every phase must prioritize resilience:

• Design Phase: Integrate secure communication protocols, proper authentication, and avoid shared cryptographic keys. Follow best practices and industry standards.
• Manufacturing: Implement supply chain protections and thorough hardware/software testing to identify tampering and design flaws early.
• Deployment and Maintenance: Apply regular firmware updates, enable secure boot and encrypted storage, and enforce strong access controls.
• Monitoring: Continuously audit and monitor devices for anomalies or breach indicators.

This approach ensures not just compliance, but lasting trust and protection for both users and infrastructure.

How Keysight Can Help

At Riscure Security Solutions, now part of Keysight, we offer a comprehensive, flexible, and scalable security solution tailored for IoT vendors and solution providers. Our expertise spans:

• End-to-End Security Consulting across product design, development, and deployment
• In-depth Penetration Testing to uncover and address vulnerabilities in embedded devices
• Support for IoT Security Certifications, including CC, ARM PSA, SESIP, and nuSIM
• Security Training and Tools that empower development teams to assess and improve device security in-house

We’re committed to helping you build secure, resilient products that are ready to withstand modern threats—without slowing down innovation.

Related Posts