Skip to content

LCW 007

Andrzej Szombierski edited this page Mar 22, 2026 · 8 revisions

General

LCW-007 is the name of the Wi-Fi module used in some of LG's connected appliances. The module (also called a "modem" in various places) acts as a bridge between the appliance and LG's cloud services.

The main component is the RTL8711AM SoC by Realtek. This is an ARM-based Wi-Fi SoC. Application code and data is stored on an externally accessible SPI flash chip. The name "ameba" appears in various places referring to this SoC family.

Firmware

The firmware is not encrypted so it can be easily downloaded from the flash using a generic SPI flash programmer (I've used raspberry pi with flashrom). The code is proprietary so I'm not at liberty to publish the downloaded binaries. The firmware (as found on my module) contains heaps of debugging code which allows us to easily identify the names of many functions (because they are used in debug messages).

Contrary to the popular Espressif chips, the flash contents is loaded into the spacious on-chip DRAM before execution (although the datasheet mentions something about memory-mapping as well).

User data is encrypted with a key that seems to come from eFuses. The key can be retrieved by debugging the chip via SWD

I don't know if there is any kind of signature check on the firmware, but since the debugging interface is available, you can modify the firmware in a variety of ways at runtime.

My findings are based on the firmware marked with version "clip_v2.00.15.05-RTK_RTL8711am-SDK-8-RELEASE".

Persistent state

The firmware stores various user-provided information (such as Wi-Fi settings), cached values (such as MQTT topics or certificates) and identifying data (such as device type and uuid) in the same non-volatile memory block. I haven't found any command that clears all the non-persistent values while maintaining identity. This means that some state may be retained for unexpected periods of time, causing confusion during RE-ing. Beware!

Interfaces

The 6-pin connector supplies power (5V) to the board and provides a 3.3V UART interface for full-duplex communications between the appliance and the modem. The voltage levels conveniently match most hobby-level UART modules on the market :)

On the back side, a footprint for a debug connector is available. It offers access to the debug UART interface as well as SWD debug interface. Both are 3.3V as well.

Communications UART

This interface is used to communicate with the appliance. The module cycles through a range of baud rates, 9600 is one of them. The protocol likely depends on the appliance - so far only the "TLV" protocol has been positively identified. It's likely the "AABB" protocol, used by some appliances, is also used at the UART layer.

Debug UART

The debug UART runs at 38400 baud during the bootloader phase. During the main application execution it is disabled by default. If enabled, it runs at 115200 baud and offers a simple text console for inputting commands.

The command shell is implemented using realtek's SDK code as a base. Most of the SDK-provided commands are not useful (or outright don't work), application-specific can be accessed using the clip prefix. For example: clip debug 1

ptm-set, ptm-get, ptm-del, ptm-dump

ptm is the non-volatile key-value store used by the firmware. These commands allow you to query and modify the storage

ptm-mod-set, ptm-mod-get, ptm-mod-del

ptm-format, flash-reset, flash-format

Various kinds of destruction. Haven't tested :)

debug

Sets the debug level. Higher values cause more debug output.

set-time, get-time

set-keepalive

fwinfo

mem

clog

crash

SWD

The SWD debug interface is unlocked (at least it is on my device), offering huge insight into the workings of the module. This project contains the necessary configuration files to connect to the device with openOCD.

Annotated PCB photos

The pictures come from the FCC submission. I've aligned them and traced some of the signals.

image

image

Documentation

Clone this wiki locally