Czy wolisz polską wersję strony elektroda?
Nie, dziękuję Przekieruj mnie tam
p.kaczmarek2 wrote:I still have LN8825 LED strip controller, maybe we can also check that one for some endpoints?
divadiow wrote:Still the only bin that gives me a console out is as here https://www.elektroda.com/rtvforum/topic4023264.html#21029890
divadiow wrote:AT+UPURL=http://10.10.123.4:1111/update?version=33_48_20240428_OpenBeken&beta,pierogi | nc -u 10.10.123.3 48899
makejoint wrote:Any idea why? With another module (different form) flashing worked using mflasher...
makejoint wrote:Might it be that the AT string is not right for the currend ZENGGE firmware?
makejoint wrote:AT+UPURL=http://10.10.123.4:1111/update?version=33_188_20230208_ZG-BL\r
TL;DR: With 0 solder joints and "back ok" as the key success reply, this method lets Magic Home BL602 owners push an OpenBeken OTA file over the device’s own AP using UDP port 48899 and a local HTTP server. It suits users who want a faster no-solder path, but only on firmware that still accepts the vendor OTA trigger. [#21056057]
Why it matters: This gives BL602 Magic Home owners a real no-solder upgrade path, while also showing exactly where newer Zengge firmware blocks it.
| Method | Hardware access | Main transport | Typical result in thread | Recovery path |
|---|---|---|---|---|
| Magic Home OTA exploit | No | UDP 48899 + local HTTP | Works on some BL602 firmwares | Restore dump or solder later |
| mhflasher on Android | No | Automates same OTA path | Works on vulnerable devices | Same limits as OTA exploit |
| UART / BLDevCube flashing | Yes | Serial flashing | Most reliable overall | Full dump restore possible |
| Factory dump restore | Yes | Serial flashing | Confirmed working on 2 MB dumps | Returns device to stock |
Key insight: The no-solder path is real, but it is firmware-dependent. Older Magic Home BL602 builds can fetch and install an OTA image from your own server, while newer builds such as 33_227_20231220_ZG-BL return OTA errors and appear patched. [#21418610]
AT+UPURL=http://10.10.123.4:1111/...; users reported success after about 1 minute. [#21056057]ota download is done! before reset. [#21063222]OpenBL602_...OTA.bin.xz.ota on a local HTTP server, often on port 1111. 3. Send AT+UPURL=http://10.10.123.4:1111/update?... to 10.10.123.3:48899. A working device replies back ok, then usually reboots after about 1 minute and appears as OpenBL602_XXXXXXXX. [#21056057]OpenBL602_1.17.553_OTA.bin.xz.ota, not the plain .bin. The OTA method calls the manufacturer’s updater, so it expects an OTA-formatted image rather than a raw UART-flash binary. The thread explicitly says to choose the version for the BL602 chip and OTA. A regular OpenBL602_...bin is used for wired flashing through tools like BLDevCube, not for the WiFi-only exploit path. [#21056057]AT+LVER reads the installed firmware version, and AT+UPURL tells the device where to fetch an update. In the working example, AT+LVER returned +ok=33_48_20201219_ZG-BL from UDP port 48899. AT+UPURL then pointed the device at a local HTTP URL on 10.10.123.4:1111 so it could download and install OpenBeken. "AT+UPURL is a device OTA trigger that makes the stock firmware fetch a new image from a supplied URL, using the vendor update path rather than UART flashing." [#21056057]+ok=up_ErrType appeared on newer or incompatible Magic Home firmware, including 33_227_20231220_ZG-BL, and on a 35_162_20220801_ZG-BL-BP101 device that did not exploit. +ok=up_ErrHttp points to a fetch or URL issue. A blank +ok= can happen before reboot; one user saw it before disconnect, but the HTTP listener never received a request. Check firmware version, URL reachability, exact query format, and whether that device family still accepts custom OTA payloads. [#21245497]HttpListener on port 1111 and serve OpenBL602_...OTA.bin.xz.ota. 2. Connect your PC to the device AP, usually with the controller at 10.10.123.3 and your PC at 10.10.123.4. 3. In Packet Sender, send AT+UPURL=http://10.10.123.4:1111/update?version=...&beta,pierogi as UDP to port 48899. The thread reports you should see the upload, an OK, then a reboot into OpenBeken. [#21063222]+ok=+ok=up_ErrType, and its UART log showed *system:ota fail after comparing the OpenBeken version string against stock values. Another user also suspected newer versions had been patched against custom firmware via OTA. The thread’s working pattern is clear: exploit success depends on firmware family and date, not just on using a BL602 chip. [#21418610].bin files, and tested full-image writes from address 0x0 or app-region writes from 0x10000. One successful restore to a 4 MB dev board from a 2 MB Magic Home dump booted the stock LED... AP and even paired in the app. That made BLDevCube the main recovery tool when OTA failed. [#21063112]LEDnet... AP and normal app pairing. One user called this a tested dump-and-restore path for putting BL602 devices back to factory firmware. If OpenBeken config is broken, a full restore is the recommended reset path before trying another flash. [#21063222]{"cmd":0,"pv":0,"sn":"...","msg":{}} and returned JSON with fields such as did, pid, mac, ip, and res. "CozyLife local JSON protocol is a device-control API that exchanges structured JSON commands and responses, unlike Magic Home’s short AT strings sent to the vendor pairing port." The thread also tied CozyLife cmd:5 to OTA experiments. [#21068684]