Czy wolisz polską wersję strony elektroda?
Nie, dziękuję Przekieruj mnie taminsmod wrote:BK7252N build, untested.
p.kaczmarek2 wrote:That's the great news! I assume it's the new PR that was open?
Laloshifrin wrote:I noticed that app version for linux is stuck on V2.1.11.15 though windows one is at V3.0.1.4.
divadiow wrote:Battery was de-soldered and power applied from micro-USB port.
Laloshifrin wrote:So you powered it with 5V?
divadiow wrote:If a device takes USB 5V or 12/24v barrel jack connector I tend to use that for power rather than bothering to solder up 3.3v
Laloshifrin wrote:Having a look at log I assume that if I trigger reading at this stage it should work:
Laloshifrin wrote:I thought that 3.3V were necessary to get flash mode
TL;DR: For hackers, repairers, and OpenBeken users, this FAQ shows how to back up a 2 MB BK7252N A9 camera safely and why “it shows repeat at 2mb though” explains the fake 4 MB readout. It also clarifies CRC, pad mapping, AP-mode networking, and today’s limits of alternative firmware on Linklemo/XCThings cameras. [#21527055]
Why it matters: These $1–$9 A9 variants look identical, but the chip, flash behavior, sensor, and cloud dependence change what you can dump, patch, or replace.
| Platform | Flash/backup status | Local video extraction | Alternative firmware status |
|---|---|---|---|
| BK7252N A9 | Full UART backup works; 2 MB image commonly repeats when read as 4 MB | Not yet reliably extracted on this family | Boots OpenBeken builds, but no camera support yet |
| BK7252U A9 | Backup methods exist, but behavior differs from N | Limited; model-dependent | Earlier support focus than N |
| TXW817 A9 | Different toolchain and reverse-engineering path | Better supported for stream access | Camera already works on that platform |
Key insight: On these Linklemo BK7252N cameras, the hard part is no longer reading flash. The real blockers are per-block CRC, proprietary PPRPC messaging, and missing camera-driver support in OpenBeken.
bk_loader read before power-on or reset, using BK7252N mode and -f 0-200000 for a 2 MB read. 3. Reboot the camera at the prompt so the boot ROM catches. One successful read used 115200 baud and finished in 190.981 s for 0x200000 bytes. Easy Flasher also reads it, but BKFIL handled BK7252N more cleanly in-thread. [#21526681]protocol:"pprpc", TCP traffic on port 20190, and command 2610 = VideoPlay after packet decryption work. That makes PPRPC central to pairing, control, and stream negotiation. [#21635182]0329 id_data:62, switches camera mode, and ends with GC0329C init finish. The thread identifies that sensor as GalaxyCore GC0329, 0.3 MP, 640×480 at 15 fps. That finding also explains why “4K” seller claims are not credible for this board revision. [#21528651]LinkCheck Timeout even though UART logs worked, then later succeeded after changing the setup. The strongest advice in-thread is to avoid powering the camera only from a USB-TTL adapter at 3.3 V. Instead, power the camera the normal way through 5 V USB, keep a common ground, and let UART carry only data. Wires under 10 cm were also mentioned, but stable supply mattered more than wire length. [#21627036]go os_addr(0x10000) or later boot messages. If you see normal boot logs first, you already missed the handoff and should restart the read attempt. [#21627044]beken_onchip_crc, and later experiments confirmed that changing one Wi‑Fi password byte made the camera fail until CRC was recalculated. The thread also notes that bootloader and app are CRC-protected, while some later config partitions are not. That is why naïve hex edits work in plain config areas but can brick bootable regions. [#21632638]prod.glbs.xcthings.com with several IPs. When the phone stays on the AP with no Internet, pairing times out and the camera logs failed server lookups and No conn Platform!. Local preview may appear, but normal binding does not complete offline. [#21532561]nmap -sS -sU -T4 -v -p T:0-65535,U:0-65535 192.168.9.252 and found 20023/tcp open, 20190/tcp open, 67/udp open|filtered, 20190/udp open|filtered, and 62562/udp open|filtered. The camera AP handed the client 192.168.9.100, while the device itself sat at 192.168.9.252 and identified as Beken by MAC prefix. That scan is the cleanest baseline for local service discovery on this model. [#21529763]