Shenzhen Pinmei / Linklemo A9 Mini Camera with Beken BK7252NQN481 – Photos, Boot Log, Flash Backup

yes, I believe app and bootloader are CRCd



also printed out in boot log





Added after 31 [minutes]:

this *might* be the unCRCd app partition from my device

method: https://github.com/ouaibe/dreo-cloudcutter

divadiow wrote:

https://github.com/ouaibe/dreo-cloudcutter

very interesting but ltchiptool gives me lots of ValueError: Invalid Magic 1 (b'\x0e\x00\x00\xea'), ValueError: Input file is not 34-byte aligned and segfaults, can't read chip nor identify

Yes. I mean the unCRC bit specifically further down in the article. You can edit the python somewhere to not fail on 34 byte alignment. Cutting the app partition out from 0x11000 and feeding that in I did not get 34 byte error

great! I'll try.
In my ignorance it's incredible that there is a CRC16 every 32 bytes!!!!
Anyway I tried to calculate CRC for the first 32 bytes with every available model and I didn't get the result of bytes 33-34.
I'll check later... thanks a lot!

I could be wrong of course. Good luck!

Still don't know how ltchiptool calculates CRC but I changed one character of wifi password and added correct CRC. Worked like a charm!!! Booted correctly and I can connect to wifi in AP mode with the new password. Little step.... next one is feeding Ghidra with the uncrcd app partition and next is analyze ltchiptool python scripts to understand how it calculates CRC (just curious). I'll let you know and possibly ask for help. Hoping to eventually modify software to trigger mpeg_server on boot. Thank you.

For anybody interested... the firmware on my BK7252N (I assume also others) uses CRC16 CMS variant (model). ltchiptool library crc16 class contains over 50 different models and uses "CMS" for BEKEN72XX.
CMS poly=0x8005, init=0xFFFF, ref=False, out=0x0000

There's a gzipped json file in application partition:
{"base":{"protocol":"pprpc","encode":1,"encrypt":3,"sec_code":0,"hb_interval":0,"offline_cmd":1,"offlime_interval":10,"led":0,"battery":1,"send_mode":0,"apsec":0,"events":[9,12,255],"tamper":0,"sync_name":0,"threshold":0,"file_forwarding":1,"reboot_time":60,"multi_rom":0,"multi_rom_names":[],"sleep_recv":0,"contact":0,"var_chan":0,"pbs_len":256,"multi_msg":0,"unbind":1,"only_matter":0,"time_task":0,"datacid":[],"spu_type":[],"notify_add":0,"dp":0},"mconf":[{"class_code":"IPAV","conf":{"spec":1,"audio":2,"mic":1,"speaker":0,"siren":0,"light":0,"pixel":[2,1,3],"pixel_local":[0],"sdcard":1,"aspect_ratio":"4:3","motionzones":1,"ptz":0,"face":0,"clouds":2,"can_buy":0,"zoom":1,"ai_vendor":0,"pir":{"num":0,"ranging":0,"values":[0,1,2,3]},"num":0,"flip":1,"app_rotate":0,"view_rec":0,"osd":2,"psp":0,"cruise":0,"sound_detect":0,"audio_codec":0,"video_codec":0,"gps":1,"local_httpdown":1,"remote_action":0,"night_light":0,"vqos":[],"record_mode":0,"link":1,"power_freq":[0,50,60],"low_power_state":0,"ircut_level":1,"auto_close":1,"ap":2,"video":0,"ring_expired":0,"motion_grid_scale":"4:3","render":1,"chans":1,"dec_mix":1}}],"support_cmds":[{"class_code":"PUBLIC","cmds":[60]},{"class_code":"IPAV","cmds":[2600,2601,2602,2603,2610,2611,2612,2613,2614,2615,2616,2617,2625,2626,2627,2628,2630,2631,2632,2635,2636,2639,2640,2647,2648,2649,2650,2661,2662,2663,2664,2685,2780,551,573,574,575,576,587,577,578,582,584,585,579,580,581,586,590,560]}]}
It seems more like descriptive of device characteristics but I'm wondering if modifying "local_httpdown" or "video" variables something good could happen...
Anybody dealt with anything similar?

Added after 3 [hours] 39 [minutes]:

Last two lines must be RPC commands. 2610 is VideoPlay.
All happens through TCP port 20190. Sniffed traffic... hope I can catch a magic packet.

Added after 34 [minutes]:

Traffic must be encrypted 🤬
I don't even know protocol...
I know it's an mpeg stream. In your experience those devices use HTTP, RTP or some raw proprietary protocol?

I'm watching with interest. I don't know the answers to your latest questions, but please keep updating the thread with new findings

Wouldn't this help? We can access this camera stream... if it's the same camera.
https://www.elektroda.com/rtvforum/topic4117962.html

I already read that thread but unfortunately cam-reverse doesn't work on this camera. Camera is similar but not the same. I'll try to post some pictures...

Added after 23 [minutes]:

Here's my cam:







Added after 6 [minutes]:

https://www.aliexpress.us/item/3256807542361615.html

p.kaczmarek2 wrote:

Wouldn't that help? We can access the stream from that camera.... If it's the same camera.
https://www.elektroda.com/rtvforum/topic4117962.html

The cam-reverse is for cameras based on the TXW817a, not the BK7252N.
Post 19 and 24 mentions unsuccessful attempts to extract the stream from BK7252N based cameras using cam-reverse.

Almost stuck...

Hello!

I have the same camera (A9) with the same chip BK7252NQN481 AU4508XA INO-IPC-A9-V2.4.

There is a tutorial how to change the firmware to an opensource one?

Thanks.

This thread contains everything you need though at the moment afaik there's no readymade firmware with cam support. Anyway wait for gurus confirmation about what I wrote.

While there is a firmware that can boot, there is no support for cameras.
The only things you would've been able to do is control leds, buttons and get battery voltage.

Received my order of 4 cameras.
One of them is TXW817-810, but 3 others are ALL BK7252N.
One is the same as here, but with a blue PCB.

interesting. I didn't know those X5 barrel types were also BK7252N. Not a surprise they vary though.

your TXW looks to be the same as @d1nuc0m's https://www.elektroda.com/rtvforum/viewtopic.php?p=21694718#21694718

Cameras:
With this one - GC0329C
TXW817 A9 - SP0828
X5 - GC0310(a3)/GC0312(b3)
The square one, marked as INO-A13N-V2.2 - GC0329C

Added after 20 [minutes]:

This one backup is named 7252n, square one - 7252n_square.
Didn't take X5 backup, UART pins are difficult to solder, and i didn't bother because i need only one for a dev board.

There is no RF partition, only MAC as text at 0x1F6000

insmod wrote:

TXW817 A9 - SP0828

im getting close(r) with SP0828 driver.


Can I trouble you for your backup of TXW when you get to that point?

insmod wrote:

i need only one for a dev board.

would be interested to know how far you go with one. removing resistors and components to get as many pure IOs as possible? sticking to test pads only?

I never did make anything yet with any of the cams. I don't have a 3D printer so decent casing is maybe an issue.

One of them is identical to mine. Hope you can do something with it. I gave up after trying to replicate sniffed traffic with scapy. Camera reacts but no stream. Also traffic is encrypted with no known patterns and also with strange packets over 5k in size! Think new firmware is the only way to go. Please keep us updated! 😊

Currently I'm trying to make a better SPI flasher for them so development is easier:

Well, it all depends on which chip your camera is using.
If BK7252U or BK7252N - then camera support looks to be pretty far away.
If TXW817 - then camera already works and can be used right away.
TXW806 - not supported, but it probably can be

Laloshifrin wrote:

I already read that thread but unfortunately cam-reverse doesn't work on this camera. Camera is similar but not the same. I'll try to post some pictures...

Added after 23 [minutes]:

Here's my cam:







Added after 6 [minutes]:

https://www.aliexpress.us/item/3256807542361615.html

it has BK7252N

insmod wrote:

TXW806 - not supported, but it probably can be

still yet to get a TXW806