Introduction
Welcome to a deep dive into the inner workings of a smart light bulb. In this article, we're going to explore both the hardware and software aspects of one of these everyday IoT devices. We'll start with a physical disassembly to see what's inside and then move on to the more technical side, where we'll dump, decrypt and reverse-engineer the firmware. This journey is not just about taking apart and understanding a smart bulb; it's about gaining a deeper appreciation for the technology in the devices around us. Whether you're a tech enthusiast, an engineer, or just curious about smart devices, this article aims to shed light on the complex yet fascinating world of smart technology.
Disclaimer
This article is purely for educational purposes. I do not encourage or endorse any illegal activities, including unauthorized reverse engineering. While exploring the technical aspects of the smart bulb, I've been careful not to disclose sensitive or proprietary information. Remember, tampering with devices can have legal consequences, especially when it involves intellectual property rights. This content is meant to inform and educate about smart device technology, not to guide unauthorized actions.
Unveiling the Inner Workings
Opening the Device:
The first step was to open the bulb to access its internal electronics. This involved cracking the outer shell and removing the plastic cover, essential for exposing the electronic components inside.
Identifying the Components
Upon opening, the bulb revealed several key components. For a clearer understanding, these components have been separated and displayed in an image, highlighting the distinct parts of the bulb.
The Main Components
Before delving into the detailed examination of each board, let's first outline the three primary components that form the core of the smart bulb's hardware. These components are critical for understanding the bulb's overall functionality and the interplay between its hardware and software.
- Power Supply Board: Manages the conversion of AC to DC power.
- LED Boards: Contains the LEDs and a PWM dimmable linear LED driver.
- MCU Board: Hosts the microcontroller and an LED driver, crucial for smart functionalities.
The Power Supply Board
The first component is the power supply board, which connects directly to the bulb's base.
This appears to be an analog AC to DC converter. Noteworthy aspects of this board are:
- Input Pins: Two inputs for the 230V AC line.
- Output Pins: Three outputs, consisting of 12V, GND to power the low power circuit and VIN (presumably for powering the LEDs)
The LEDs board
Following the power supply is the LED board, which houses the bulb's lighting elements.
Besides the two connectors for the power supply and MCU board, this board features a significant IC, the kp18055esp. This is a Two-Channel PWM Dimmable Linear LED Driver, controlling the cold and warm LEDs.
The MCU board
The final critical component is the MCU board.
This board includes:
- LED Driver IC (BP3316): A BP3316 IC, a PSR Single-Stage APFC Offline LED Driver, used for driving the LEDs.
- Additional Mini Board (WB2L): Attached to the MCU board is a smaller white board, the WB2L, containing the MCU with 7 connections to the main board. This MCU governs the smart functionalities of the bulb.
While each component is integral to the smart bulb's functionality, our focus will now shift to an in-depth analysis of the WB2L board, as it plays a central role in controlling and executing the bulb's smart features.
WB2L Module Analysis
In this section, we delve into the WB2L module, a key component of the smart bulb's functionality. Extensive online research has yielded valuable insights about this module:
Module Specifications:
- The WB2L is identified as a Tuya IoT module.
- It supports both Wi-Fi and Bluetooth LE connectivity.
- The core of the module is a BK7231T microcontroller.
Documentation Review:
- The module's documentation is available at the Tuya developer portal Tuya WB2L Datasheet. This resource provides detailed information including the module layout, pinout, and other technical specifications.
- Notable details from the documentation include descriptions of the back pins and the seven pins connected to the main board. These connections consist of VCC, GND, and five PWM signals. The PWM signals are used to control various LED colors—cold, warm, red, green, and blue.
Additional Resources:
- A detailed description of the microcontroller and the flashing procedure is available on an electronics forum, which can be accessed here.
- The GitHub repository hosting the SDK for the BK7231T microcontroller is found at OpenBK7231T_App GitHub Repository.
- Additionally, the SDK specific to this board is provided by Tuya: Tuya IoT Embedded SDK for BK7231T.
Flashing Procedures:
- The module can be flashed using SPI and UART protocols, both offering firmware read capabilities.
The subsequent phase of this analysis will be to dump and reverse-engineer the firmware. This step is pivotal for a comprehensive understanding of how the WB2L module operates within the smart bulb ecosystem and its interaction with other components.
Dumping the firmware
In this phase of the analysis, we focus on extracting the firmware from the WB2L module, a crucial step for understanding its inner workings.
Setup for Firmware Dumping
Utilizing the information from the documentation, I identified UART1 on the board as the key interface for firmware readout.
To facilitate this, I soldered wires to the power supply points and both UART1 and UART2 ports on the board.
Hardware Connections
The board was powered using a USB connection from my PC.
A PL2303 module was employed to bridge the UART to USB, facilitating communication with the board.
Modifications to Flash Utility
The flash utility from the OpenBK7231T_App was initially used, but several modifications were necessary for successful firmware dumping:
- Reduced the chunk size for data transfer due to noise in my setup.
- Modified the utility to bypass the RST (reset) pin, necessitating manual resets when the board became unresponsive.
- Implemented a check to halt the process if CRC checks failed, ensuring data integrity.
- Added a retry mechanism to reattempt downloading any failed chunks.
Firmware Extraction Outcome
Eventually, I successfully extracted the firmware file. However, a preliminary examination revealed no plain text strings, suggesting encryption, particularly towards the end of the binary file.
This successful firmware dump is a significant milestone, as it provides a foundation for the reverse-engineering phase. The apparent encryption poses an intriguing challenge and warrants a deeper investigation into the firmware's structure and functionality.
Decrypting the firmware
Having successfully dumped the firmware, the next step was to decrypt it, which initially seemed daunting. However, a breakthrough came from revisiting the SDK for the WB2L module.
Exploring the SDK
To gain a better understanding, I started by creating a simple "Hello World" program using the SDK. This exercise was aimed at comprehending the overall flow and structure of the code compilation process within the SDK.
Discovering the Encryption Tool
During the compilation of the "Hello World" code, I noticed that the SDK automatically downloads a compilation toolchain. Intriguingly, this toolchain included a "packing" utility featuring an "encrypt" tool.
A deeper examination of the MAKEFILE used for building revealed a particularly interesting line:
./encrypt ${APP_BIN_NAME}_${APP_VERSION}.bin 5******3 a******c 5******e c******3 1***0
(Note: Certain characters have been masked for security reasons.)
Decrypting Approach
Initially, I considered reverse-engineering the encrypt binary to understand its decryption mechanism. However, a simpler approach presented itself: running the encrypt tool with the same parameters on my "Hello World" binary surprisingly resulted in its decryption.
The resulting hex dump of the "Hello World" binary clearly displayed readable strings, indicating a successful decryption.
Applying to Dumped Firmware
Encouraged by this success, I applied the same command to the previously dumped firmware. The command effectively decrypted the firmware, revealing its contents and paving the way for a thorough reverse-engineering process.
The decryption of the firmware marks a crucial step forward. With the now-readable firmware, the focus shifts to reverse-engineering its contents to unravel the functional intricacies of the WB2L module within the smart bulb.
Reverse the Firmware with IDA
To responsibly manage the risks of sensitive information disclosure, I'll be explaining the reverse engineering process using a simplified code example. This approach is intended to demonstrate the main techniques employed without exposing any confidential or critical data from the actual firmware.
Identifying the CPU Type
The CPU was determined to be ARM based on the gcc-arm-none-eabi-4_9-2015q1.tar toolchain used during compilation.
Extracting Memory Mapping
Essential memory mapping details were obtained from the linker script:
- flash (rx) : ORIGIN = 0x00010000, LENGTH = 2M
- ram (rw!x): ORIGIN = 0x00400000, LENGTH = 256k
This information was validated against the "Hello World" binary.
Loading the Binary in IDA
Now that we have information about CPU type and RAM and ROM segments, we can load the binary into IDA.
Starting with Strings
Since the binary doesn't have a standard structure (like a MZPE or ELF file) IDA cannot auto analyze the code and map functions or resources.
The string region was my initial focus point for understanding the code structure.
Analyzing Strings
By converting these bytes into strings, it became easier to track their usage in the code.
Tracing String References
In the decrypted binary, I located several elements of interest, including function names like 'my_test_function,' file paths, and various messages. These strings can offer significant insights into the functionality of the code.Manual searching led me to specific offsets in the binary, such as the function string at 0x000BFE0C.
Decoding the Bytes
Having located the string reference, the next step is to delve into the code surrounding this offset. This involves several key actions:
- Conversion to DWORD: The bytes at the offset are converted into DWORD format. This step is crucial for a more structured view of the data.
- Offset Identification: We then transform this DWORD data into an offset. This transformation helps in pinpointing exactly which string the code is referencing.
- Code Conversion: The bytes preceding the offset are converted back into executable code.
- Function Start Identification: The beginning of the function is identified, typically marked by a PUSH instruction or similar.
- Marking the Function Start: Finally, the start of the function is explicitly marked. This marking is not just for clarity, but also serves as a reference point for further analysis.
Analyzing the Code
Upon examining the code, we encounter a specific execution flow:
- The function sub_56DE0 is called with a parameter value of 100.
- Subsequently, the result of this function call is checked. If the register R0 (commonly used for return values in ARM architecture) holds a value of 0, indicating a possible failure in the allocation, another function sub_570BC is invoked.
- The sub_570BC function is called with three parameters: a file path, a string (which seems to be the name of a function), and a message ("Malloc failed"). This pattern suggests error handling or debugging functionality.
Inference and Renaming Functions
- Based on these observations, it's reasonable to infer that sub_56DE0 is likely a memory allocation function, perhaps analogous to malloc in C.
- sub_570BC seems to be a function used for debugging or error logging, given its parameter structure and usage context.
To aid in further analysis and readability, it would be appropriate to rename these functions according to their inferred purposes. For example, sub_56DE0 could be renamed to something like "malloc", and sub_570BC to "debug_print" or similar.
By renaming these functions based on their inferred roles, the code becomes more comprehensible, facilitating easier navigation and understanding of the firmware's functionality. This process is an essential part of reverse engineering, transforming cryptic assembly code into a more readable and meaningful format.
Function Identification through Strings
In the analyzed firmware, a large majority (about 90%) of the user-defined functions include at least one debug print statement. These statements often contain valuable details such as the function name, file path, and even line numbers (though not demonstrated in this example).
Ease of Analysis
The presence of these debug prints within functions makes the task of reverse engineering much more manageable. Instead of delving deeply into the complexities of assembly code, I can glean substantial information about the function's role and context just from these strings.
Inferences from Error Messages
Additionally, error messages found in the firmware are another rich source of information. By examining these messages, many more functions can be inferred and understood, even without an in-depth analysis of the corresponding ASM code.
This approach not only simplifies the reverse engineering process but also accelerates the understanding of the firmware's structure and logic. It's a clear demonstration of how high-level artifacts within the code, like debug prints and error messages, can be leveraged to reveal lower-level details with minimal effort.
Conclusion of Firmware Reverse Engineering
After dedicating several hours to meticulously reverse-engineering the firmware, I achieved substantial progress in unraveling its complexities:
Function Mapping
A significant portion of the firmware's functions were successfully mapped. This mapping provided a clear view of the firmware's structure and the specific roles of various functions.
Library Identification
Key libraries embedded within the firmware were identified. These included:
- BSP (Board Support Package)
- Tuya OS
- Wi-Fi and Bluetooth drivers
- An extensive LED control library with over 200 functions, showcasing complex logic for flashing, gradients, and other effects.
- An HTTP client
- JSON handling library
- Gateway client
- MQTT library, complete with all topics used, and the specifics of request/response formats.
Understanding the Flow
The firmware of the smart bulb orchestrates a comprehensive flow, beginning with the establishment of an initial Wi-Fi connection, crucial for network integration. Upon connecting, it interacts with an IoT Gateway, serving as a communication hub with external networks. This setup enables the usage of the MQTT protocol, a key component for messaging and command processing, ensuring the bulb's responsiveness to external controls and commands. Simultaneously, the firmware manages various internal functions, from LED control logic, encompassing intricate patterns and gradients, to handling HTTP and JSON for data exchange, and leveraging libraries like BSP and Tuya OS for seamless hardware-software interaction. This intricate orchestration of components and protocols illustrates the bulb's complex yet efficient operational architecture.
Extracting Connection Details
Critical connection details, such as IP addresses and used passwords, were extracted. This information is pivotal in understanding how the device communicates and interfaces with external networks and services.
Conclusions
In this article, we ventured through a comprehensive journey of reverse-engineering the hardware and software of a smart light bulb. Starting with a detailed disassembly to understand the hardware components, we identified the key boards - the power supply, LED boards, and the MCU board. The most significant revelations came from delving into the MCU board, particularly the WB2L module, where we encountered the Tuya IoT module with Wi-Fi and Bluetooth LE support.
Our exploration further led us to decrypt and reverse-engineer the firmware, a process that involved meticulous analysis using IDA and other tools. This enabled us to map out the functions, identify libraries, and understand the overall flow of the firmware. We discovered a sophisticated structure that included a diverse range of functions from LED control to network communication protocols like MQTT.
The insights gained from this reverse-engineering exercise are invaluable. Not only do they offer a deeper understanding of the inner workings of smart devices, but they also highlight the complexity and sophistication of modern IoT devices. This knowledge is crucial for anyone looking to develop, enhance, or secure similar technologies.
In conclusion, the process of dissecting and understanding the smart bulb serves as a testament to the intricate world of IoT devices. It underscores the importance of thorough analysis for those involved in technology development, security, and innovation. The journey from hardware analysis to firmware reverse-engineering reveals the layered complexity of devices that we often take for granted in our connected world.
Comments
Post a Comment