logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda

Reading Firmware from Wi-Fi Sensors Over the Air: ESP8266, ESP32, Tuya, Beken, Realtek Security

Ask a question on the Forum

User question

Is it possible to read firmware of a Wi-Fi sensor connected to the one on the air?

Artificial Intelligence Response

Direct answer to the question

  • Short answer: Not in the general case. You cannot reliably “read” (dump) the firmware of a Wi‑Fi sensor purely over the air during normal operation.
  • Key points:
    • Standard Wi‑Fi/IoT stacks do not expose a memory‑read primitive.
    • Modern devices protect firmware with TLS‑based delivery, signing, and often encryption at rest.
    • Practical firmware extraction typically requires physical access (UART/JTAG/SWD/SPI‑flash) or a very specific remote vulnerability.

Detailed problem analysis

  • What “over the air” would require:
    • To read firmware wirelessly, the device would need code that will serve flash contents back to you, or you would need to passively capture the same firmware as it is being transmitted (e.g., during an OTA update). Production images intentionally omit any “read back” API.
    • OTA pipelines are designed for write/update, not readback. They fetch images from a server via HTTPS and verify signature(s) before install.
  • Why normal network traffic won’t help:
    • Application protocols in typical sensors (MQTT/HTTP/CoAP/TCP/UDP) carry telemetry/configuration, not raw flash contents.
    • Even if you sniff traffic in monitor mode, you see encrypted payloads (WPA2/3 + TLS). Without keys, you cannot reconstruct the firmware.
  • Where it can be possible (edge cases):
    • During an OTA update if the vendor distributes unencrypted binaries over HTTP or via non‑pinned TLS and you can perform a man‑in‑the‑middle to capture the file. This is uncommon on current products.
    • If the device exposes an unintended service (debug web route, telnet/SSH with default creds, backdoor CLI) that allows file system or MTD access.
    • If there’s a known remote exploit yielding arbitrary read/shell access (rare, device‑specific, typically patched quickly).
    • If the device already runs custom firmware that intentionally allows backup/export (some community firmwares expose config backups; full flash dumps are less common).
  • Platform notes you’re likely to encounter:
    • ESP8266/ESP32: Default OTA uses HTTPS; ESP32 widely supports Secure Boot and Flash Encryption, preventing useful dumps even with shell access. No built‑in OTA readback.
    • Beken BK7231/Realtek RTL8710/ASR/others: Modern Tuya/Beken builds use HTTPS with signing; tools like “tuya‑convert” (ESP8266) are largely obsolete; “cloudcutter” class tools replace firmware but do not read out original flash.
    • Tuya‑MCU class devices: Even if you decode DPIDs over the UART link between Wi‑Fi SoC and external MCU, that reveals API fields, not the Wi‑Fi or MCU firmware contents.

Current information and trends

  • Industry trend is toward stronger supply‑chain security:
    • TLS with certificate pinning for OTA, signed images, and anti‑rollback.
    • Growing adoption of secure boot and (on some SoCs) flash encryption, making captured images unusable without keys.
    • Remote exploits that yield full readout are increasingly rare, short‑lived, and very model/firmware‑version specific.
  • Community tooling emphasis has shifted from “intercept and read” to “replace safely” (e.g., guided OTA/wired flashing of open firmware) because readback is either blocked or legally complicated.

Supporting explanations and details

  • Even if you capture an OTA payload:
    • It may be encrypted and signed; signature verification prevents tampering, and encryption prevents analysis without keys.
    • It may not match the exact image on your device (partition layouts, device‑specific NVS/calibration/keys are separate).
  • Reading “what is currently in flash” is more than the application image:
    • Partitions for credentials (Wi‑Fi, tokens), calibration, logs, NVS/Key‑Value stores. These are the sensitive portions vendors protect most aggressively.
  • Why physical beats wireless for forensics:
    • UART/boot ROM readers, JTAG/SWD, or SPI‑flash clips can retrieve full contents (unless readout protection/flash encryption is enabled).
    • Wired access lets you control power, clocking, and boot modes to enter ROM loaders (e.g., ESP bootloader, Beken/Realtek tools).

Ethical and legal aspects

  • Only attempt firmware extraction on hardware you own or with explicit written authorization.
  • In the United States, unauthorized access can implicate the CFAA; circumventing signature/encryption may raise DMCA §1201 concerns. There are limited research exemptions with strict conditions.
  • Firmware may contain personal data or credentials; handle and store any dumps securely.

Practical guidelines

  • If you still want to try “over the air” first:
    • Observe update behavior: force a firmware check in the vendor app; capture network traffic (AP logs, Wi‑Fi monitor mode) and look for large downloads. If you see HTTPS to a pinned endpoint, interception is typically a dead end.
    • If traffic is HTTP or non‑pinned TLS via a proxy you control, you may capture an update package. Validate with a firmware analysis tool (e.g., look for container headers, entropy). Expect encryption or signing.
    • Enumerate exposed services: scan the device from the local network, check for inadvertent shells or debug endpoints. If present and authenticated, a shell may allow reading /dev/mtd partitions; success depends on build options and protections.
  • Reliable approach (requires opening the device):
    • Identify the Wi‑Fi SoC and any external SPI‑NOR (common: 8‑pin Winbond/GD/ESMT).
    • Method A: UART/bootloader
    • ESP8266/ESP32: esptool.py can read flash if flash encryption is disabled and ROM loader accessible (GPIO0 boot strap, 3.3 V only).
    • BK7231/Realtek: use the corresponding vendor/community flasher; some SKUs allow readback, some don’t.
    • Method B: SPI‑flash clip
    • Use a SOIC‑8 clip with a level‑correct 3.3 V programmer (e.g., CH341A with 3.3 V mod) and read the chip in‑circuit if the board allows; otherwise desolder.
    • Beware back‑powering through the SoC; isolate VCC or remove the chip if reads are unstable.
    • Method C: JTAG/SWD (if routed and not locked)
    • Locate pads, identify pinout with a JTAGulator/logic analyzer; dump if readout is not protected.
  • Tuya‑specific notes:
    • “tuya‑convert” (old ESP8266 HTTP OTA hijack) largely fails on post‑2020 firmware due to TLS and pinning.
    • “Cloudcutter”-style tools target certain Beken/Tuya builds to replace firmware without opening the case; they do not preserve or read out the original firmware image.
  • Safety and handling:
    • Always use 3.3 V logic only; never 5 V on Wi‑Fi SoCs.
    • Isolate power rails when using clips; confirm pinouts before connecting.
    • Make multiple reads and compare hashes to ensure integrity.

Possible disclaimers or additional notes

  • Some platforms (e.g., ESP32 with Secure Boot + Flash Encryption) cannot be meaningfully dumped even with physical access—the ciphertext is useless without device keys.
  • Even when you obtain an OTA package, it may be a delta patch or container that does not reconstruct a full image.
  • Device revisions vary; techniques that work on one lot/firmware version may fail on another.

Suggestions for further research

  • Identify your exact device (model, FCC/IC ID, Wi‑Fi SoC marking) to look up known pads, boot straps, and whether readout protection/flash encryption is used.
  • Search for model‑specific teardown notes and community flashing guides for the exact module (e.g., WB3S/WB2S/WB2L, CB2S/CB3S, TYWE3S, RTL8710BN, BK7231N/T).
  • If your goal is only to discover DPIDs or local control options, consider protocol logging between the Wi‑Fi module and MCU, or replace the Wi‑Fi firmware with an open alternative that exposes datapoints locally.

Brief summary

  • Reading a Wi‑Fi sensor’s firmware “on the air” is generally not feasible; OTA paths are write‑only by design and wrapped in encryption/signatures. Practical, reliable extraction requires physical interfaces (UART/JTAG/SPI‑flash) unless a very specific vulnerability exists. If you share the exact sensor model and what you need (full image vs. just DPIDs/config), I can outline a targeted, step‑by‑step method.

User question

An unknown PCB of an unknown Wi-Fi sensor/MCU (black box -- BB) does not have a physical access. Hard breaking is possible. The BB's labels and its description supplied are absent/obsolete. The BB has LED blinking in three ways: the 1st -- 50 times per 30 sec during 3 minutes, the 2nd -- 11 times per 30 sec during 3 minutes, and the 3rd -- short double blinks after dark pausing also during several minutes. The first mode does not provide any response while searching Bluetooth and/or Wi-Fi. The second mode provides only the single connection per 3 minutes for any local Wi-Fi station and allows free reading of some attributes: Access point MAC: 80:64:7C:B6:EE:18; SSID: SmartLife-EE19; Security: None; Channel: 6; IP/CIDR//GW[DNS]: 192.168.175.101/24//1[1], 192.168.175.100/24//1[1], 192.168.43.37/24//1[1], 192.168.1.128/24//1[8.8.8.8, 8.8.4.4]. The BB must include a temperature sensor (at least). However, the sensor detection fails during the mentioned Wi-Fi connection. Is it possible to reveal the temperature/humidity device within the BB and soft AP configuration via local (not cloud) OTA method?

Artificial Intelligence Response

Direct answer to the question

  • Short, precise answer:
    • No, not via the device’s SmartLife soft‑AP alone. That AP implements a provisioning protocol and does not expose sensor inventory or telemetry. A “local (not cloud) OTA” path that reveals the internal temperature/humidity device is generally not available unless a known OTA exploit exists for that exact firmware—and with your MAC OUI and behavior, that is unlikely.
  • Key points:
    • AP SSID “SmartLife‑EE19” with OUI 80:64:7C (Espressif) strongly indicates a Tuya‑ecosystem device running on an ESP8266/ESP8285 module (e.g., TYWE3S/TYWE3L).
    • The three blink modes map to Tuya/Espressif provisioning/operational states; the slow‑blink AP mode is for credential provisioning only.
    • Modern Tuya ESP firmwares closed the historical “tuya‑convert” OTA path; Cloudcutter‑style local OTA mainly targets Beken (BK7231) devices, not ESP8266.
    • To “reveal” the actual temperature/humidity IC and gain local AP + telemetry, the realistic routes are: 1) Pair temporarily and extract the device’s local key (then read data locally over LAN), or 2) Open the enclosure and flash alternative local firmware (e.g., Tasmota/ESPHome for ESP8266), which gives a local web UI and MQTT/HTTP telemetry.

Detailed problem analysis

  • Interpreting the observations
    • MAC/BSSID 80:64:7C:B6:EE:18: OUI 80:64:7C is assigned to Espressif. That makes ESP8266/ESP8285 the most probable Wi‑Fi SoC for this Tuya device generation.
    • SSID “SmartLife‑EE19”: “SmartLife‑xxxx” is Tuya AP‑mode naming. The “EE19” suffix commonly derives from the station MAC bytes (often ±1 vs. BSSID).
    • AP parameters: Open security, channel 6, and 192.168.175.x addressing are typical for Tuya AP provisioning.
    • LED patterns:
    • ≈1.7 Hz (50/30 s) for 3 min: EZ/SmartConfig mode (no AP, listening for broadcast provisioning frames).
    • ≈0.37 Hz (11/30 s) for 3 min: AP provisioning mode (the SmartLife‑xxxx SSID you see).
    • Short double blinks, long pauses: post‑provision “normal” operation (connected and reporting on interval).
    • The four IP/CIDR tuples you listed strongly suggest prior client‑mode joins to various subnets (192.168.43.0/24 is the Android hotspot default; 192.168.1.0/24 is common for home routers), plus the 192.168.175.x Tuya AP subnet.
  • Why sensor detection “fails” while connected to the SmartLife AP
    • In AP mode the firmware only accepts a very small set of provisioning requests (HTTP/UDP/TCP). It is not a general web server and does not present sensor telemetry or an API for inventory. So “no temperature/humidity found” is the expected result.
  • OTA realities for this class of device
    • ESP8266‑based Tuya devices used to be flashable over the air with “tuya‑convert.” That path relies on intercepting unsecured OTA downloads. Tuya patched this years ago (HTTPS + signing + pinning), so modern units no longer permit that local OTA.
    • Cloudcutter‑class local OTA targets Beken BK7231 families; it fingerprints during AP provisioning and can sometimes push OpenBeken without opening the case. Your OUI and behavior point to an Espressif design, so Cloudcutter is unlikely to help here.

Current information and trends

  • Vendor mix: Many recent Tuya devices have migrated to BK7231T/N modules; older/legacy or certain model lines still use TYWE3S (ESP8266) or ESP8285. Your OUI indicates Espressif, which aligns with TYWE‑series modules.
  • Security posture: Tuya firmwares now enforce signed, TLS‑protected OTA; broad “local hijack” methods (tuya‑convert) are effectively obsolete on updated ESP builds.
  • Local control trend: Community tooling (LocalTuya, TinyTuya) enables LAN control once you obtain the device ID and local key. However, acquiring that key typically requires pairing with the Tuya cloud at least once or using a developer account linkage.

Supporting explanations and details

  • Network probes you can try (expect limited results):
    • While attached to SmartLife‑EE19, scan the module IP (often 192.168.175.1):
    • TCP: 80, 443, 6668; sometimes 6667/7000. Use nmap service detection and curl http://192.168.175.1/ to enumerate any minimal endpoints.
    • Capture traffic with Wireshark; the app‑expected provisioning handshake is narrow and won’t disclose sensor type.
  • Datapoints (DPIDs) vs. sensor IC:
    • Tuya represents temperature/humidity as datapoints (e.g., temp in deci‑degrees C). Even when you can read status over LAN after pairing, DPIDs don’t reveal the exact IC (e.g., SHT3x vs. AHT20); only the app/firmware driver “knows” the bus address.

Ethical and legal aspects

  • Opening mains‑powered devices carries shock and fire hazards; disconnect power and wait for capacitors to discharge. If it is line‑powered and not SELV‑isolated, use an isolation transformer for any live probing.
  • Replacing firmware can void certifications (FCC/CE) and warranties and may violate terms of service. Keep the device off public networks while experimenting.
  • Do not attempt deauth/DoS on third‑party networks during testing.

Practical guidelines

  • If you insist on “local only,” non‑destructive first: 1) Recon in AP mode:
    • Connect to SmartLife‑EE19; identify the module’s IP (commonly 192.168.175.1).
    • Run a full TCP/UDP scan and HTTP probes. Save responses for fingerprints (sometimes headers leak “ESP”).
    • If no meaningful endpoints appear, accept that AP mode is provisioning‑only. 2) Controlled pairing for LAN‑only use (minimal cloud exposure):
    • Temporarily pair with the official Smart Life/Tuya app while the device is in slow‑blink AP mode.
    • Obtain device ID and local key (TinyTuya/LocalTuya wizard; developer linkage if required).
    • Put the device on an isolated LAN/VLAN without internet access.
    • Use TinyTuya/LocalTuya to poll status() locally and read DPIDs for temperature/humidity. This yields sensor data locally, albeit without revealing the exact sensor IC model. 3) If “no cloud ever” is a hard requirement:
    • Open the enclosure (“hard breaking”).
    • Identify the Wi‑Fi module (likely TYWE3S/ESP8266 or ESP8285) and the sensor IC (look for AHT10/20/21, SHT3x/SHT4x, Si7021/HTU21D, BME280/BMP280, or a DHT‑style package).
    • Flash alternative local firmware:
      • ESP8266/ESP8285: use UART flashing (3.3 V only). Typical sequence:
        • Pins: 3V3, GND, TX, RX, GPIO0→GND to enter bootloader.
        • Backup if possible: esptool.py read_flash 0x0 0x100000 fw_backup.bin (adjust size to your flash, often 1–2 MB).
        • Flash Tasmota or ESPHome build supporting your sensor; reboot and configure GPIOs and I²C.
      • After flashing, the device will expose a local AP for configuration and a web UI + MQTT/HTTP endpoints with live temperature/humidity.
  • What to expect by platform:
    • ESP8266 Tuya (your most likely case): No working universal local OTA today; UART flashing is the reliable path.
    • BK7231 Tuya: Sometimes Cloudcutter OTA works; not applicable here if the OUI truly indicates Espressif.

Possible disclaimers or additional notes

  • Some vendors randomize or reuse OUIs; while rare, the Espressif OUI is a strong (not absolute) indicator. If Cloudcutter unexpectedly fingerprints it as BK7231, adjust accordingly.
  • ESP flash readback is usually possible; certain modules may have flash encryption or protection, but that’s uncommon in low‑cost Tuya ESP8266 devices.
  • If the unit is battery‑powered, UART flashing can be done without mains hazards; if it’s mains‑powered (e.g., thermostat, plug), desolder the module for safer bench flashing.

Suggestions for further research

  • Search terms: “TYWE3S pinout,” “ESP8285 TYWE3L UART flashing,” “TinyTuya local key,” “LocalTuya DPIDs,” “AHT20 pinout vs SHT30 package ID,” “Tasmota I2C sensor drivers,” “ESPHome temperature humidity components.”
  • If you can share clear PCB photos, I can help identify the exact module and sensor and provide a pin‑accurate flashing and firmware configuration map.

Brief summary

  • Your SmartLife‑EE19 device is almost certainly a Tuya ESP8266/ESP8285 design. The soft‑AP you can join is a provisioning interface; it does not expose the sensor or telemetry.
  • A generic “local OTA” path to reveal the internal temperature/humidity IC does not exist for current ESP‑based Tuya firmwares.
  • For local, cloud‑free access you must either:
    • pair once, extract the local key, and read temperature/humidity over LAN, or
    • open the device and flash local firmware (Tasmota/ESPHome), which will give you a local AP, a web UI, and MQTT/HTTP telemetry—and will definitively reveal and use the on‑board sensor.

Ask additional question

Wait...(2min)
Disclaimer: The responses provided by artificial intelligence (language model) may be inaccurate and misleading. Elektroda is not responsible for the accuracy, reliability, or completeness of the presented information. All responses should be verified by the user.
Report illegal content (Article 16 DSA)