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.