Exploring A9 Minicam Variation: XF16 PB380EA6341 MCU, T25S80 SPI Flash, XR872, Skylark SDK

Question

Another A9 minicam variation. Will just use this post to dump some bits rather than add to which has been about the Beken BK7252 and Taixin TXW817 based A9s. The MCU in this labelled as XF16 PB380EA6341 which has a mention in that long HA thread about the A9s here this one has an 8mbit flash...

andrewjhull · Accepted Answer

As you can see, there are strings in the Flash Dump that suggest the XF16 camera is running a version of RTOS Added after 7 [minutes]: I have a couple of PTZ cameras that run the same protocol as the A9 Cams and have an XF16 variant processor. Can I ask how you dumped the firmware on yours? I presume you clipped on to the flash chip. Did you need to hold the camera in reset while you dumped it?

gusgorman402 · Accepted Answer

I have the PTZ version also. The serial port is JST GH connector. Thanks for the flash dump. Strings revealed the serial password is runtop1029

alistairjordan · Accepted Answer

Just opened one of these up and started looking..
I get a similar bin extract from the SPI chip.

Going through the strings this is an XR872 base design. The 2.0 SDK can be found on "gitee" here: https://portrait.gitee.com/Dozingfiretruck/xr872_sdk/

The strings actually give quite a way about the base design also. I would note that the ipc application doesn't appear to be in the demos folder so there is no instant drop in solution to build.

Other things I've noticed is the csi interface (camera) is using the driver/chip/hal_csi_jpeg.c driver.
This gives me a good guess that all the included drivers in the repo will actually be compatible with the device (to be fair, everything does appear built into the SoC.)

In regards to the other configuration required by configure.sh, it looks to be a 40MHz oscillator from the markings, although I may have made a mistake with this one.

gusgorman402 · Accepted Answer

>>21352083 I did not find the Stealer string in the dump posted on here. However I do find "WAR %d wlan steal active" if I run strings on XradioSDK libxretf.a and librxwireless.a files.
These cameras usually transmit data in cleartext, so you could sniff the traffic if you think it's exfiltrating personal data. Sometimes the cameras use encryption, but the original A9 HA thread has posts on how to decrypt

Added after 42 [minutes]:

My PTZ camera, just like the A9, uses the iLnkP2P protocol, which has been pretty well documented.
If you watch the Defcon video, he explains how to extract the video stream from the packets:. https://hacked.camera/
The original A9 Home Assistant postings explain & link to methods to communicate UDP packets to the camera: https://github.com/DavidVentura/cam-reverse
I think the Defcon talk shows an example of a CGI request too. You can see which CGI scripts are on the cam by searching for ".cgi" files in the Strings output. The manual for these CGI are here: https://github.com/DavidVentura/cam-reverse/blob/master/data/cgi_ip_cam.pdf
I attached a screenshot of the serial console menu from my PTZ. The command line help isn't very helpful, so I've had to read the source code for these commands to learn their syntax. Most of the commands' source is in the xradioSDK projects/common/cmd directory

I think if you wanted to get total control over this cam, you would have to write a script to communicate UDP packets in iLnkP2P protocol, and interact with the CGI scripts. If you get access to serial console, there are commands to edit the memory. You could change the IP address of the Chinese P2P relay servers, or change the device UID so it doesn't authenticate with the servers.
Temu is flooded with these cams, that's where I got mine for $10. I thought it would make a good device for a hardware hacking class. I was hoping it was running embedded linux. Some of the linux versions have the iLnkP2P libraries in the filesystem, and you can RE the library to get the device ID algorithm, as explained in the Defcon talk

p.kaczmarek2 · Accepted Answer

I got one:

Trying to read flash in circuit gives me strange IDs:


Current programmer: CH341 Black
SPI ID: 8E8029
Current programmer: CH341 Black
SPI ID: 1313

but later:


Current programmer: CH341 Black
SPI ID: C74014
Current programmer: CH341 Black
SPI ID: C74014
Current programmer: CH341 Black
SPI ID: C74014
Current programmer: CH341 Black
SPI ID: C74014
Current programmer: CH341 Black
SPI ID: C74014

AWIH header like in other XR devices

p.kaczmarek2 · Accepted Answer

So has anyone tried to build a hello world image of that? Maybe then we could find the flash offset in that 1MB chip where we could flash this hello world... Added after 1 [hours] 37 [minutes]:Compiling under WSL experience so far: 1. I got SDK from here: 2. At first, it acted like path is wrong Code: text Expand Select all Copy to clipboard tester@DESKTOP-6SD9MUK:/mnt/w/GIT/xr872_sdk/project/demo/hello_demo/gcc$ make lib make  -C ../../../../src install make[1]: Entering directory '/mnt/w/GIT/xr872_sdk/src' make _install TARGET=install make[2]: Entering directory '/mnt/w/GIT/xr872_sdk/src' make  -C driver/chip install make[3]: Entering directory '/mnt/w/GIT/xr872_sdk/src/driver/chip' ~/gcc-arm/bin/arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -mfpu=fpv4-sp-d16 -mfloat-abi=softfp -c -gdwarf-2 -fno-common -fmessage-length=0 -fno-exceptions -ffunction-sections -fdata-sections -fomit-frame-pointer -Wall -Werror -Wpointer-arith -Wno-error=unused-function -MMD -MP -Os -DNDEBUG -D__CONFIG_CHIP_XR872 -D__CONFIG_CHIP_ARCH_VER=2 -D__CONFIG_ARCH_APP_CORE -D__CONFIG_CPU_CM4F -D__CONFIG_HOSC_TYPE=40 -D__CONFIG_LIBC_REDEFINE_GCC_INT32_TYPE -D__CONFIG_LIBC_PRINTF_FLOAT -D__CONFIG_LIBC_SCANF_FLOAT -D__CONFIG_LIBC_WRAP_STDIO -D__CONFIG_OS_FREERTOS -D__CONFIG_OS_FREERTOS_VER=80203 -D__CONFIG_LWIP_V1 -D__CONFIG_LWIP_VER_1_4_1 -D__CONFIG_LWIP_V1 -D__CONFIG_MBEDTLS_VER=0x02100000 -D__CONFIG_MBUF_IMPL_MODE=0 -D__CONFIG_WLAN -D__CONFIG_WLAN_STA -D__CONFIG_WLAN_AP -D__CONFIG_WLAN_MONITOR -D__CONFIG_WIFI_CERTIFIED -D__CONFIG_DEFAULT_FLASH_FLASHC -D__CONFIG_XIP -D__CONFIG_SECTION_ATTRIBUTE_XIP -D__CONFIG_SECTION_ATTRIBUTE_NONXIP -D__CONFIG_SECTION_ATTRIBUTE_SRAM -D__CONFIG_ROM -D__CONFIG_ROM_FREERTOS -D__CONFIG_ROM_XZ -D__CONFIG_PM -D__CONFIG_OTA -D__CONFIG_OTA_POLICY=0x00 -D__CONFIG_CACHE_POLICY=0x02 -D__CONFIG_DMAHEAP_PSRAM_SIZE=0 -D__CONFIG_MSP_STACK_SIZE=1024 -D__CONFIG_MALLOC_MODE=0x00 -D__CONFIG_MBUF_HEAP_MODE=0 -D__CONFIG_MBEDTLS_HEAP_MODE=0 -D__CONFIG_HTTPC_HEAP_MODE=0 -D__CONFIG_NGHTTP2_HEAP_MODE=0 -D__CONFIG_MQTT_HEAP_MODE=0 -D__CONFIG_NOPOLL_HEAP_MODE=0 -D__CONFIG_WPA_HEAP_MODE=0 -D__CONFIG_UMAC_HEAP_MODE=0 -D__CONFIG_LMAC_HEAP_MODE=0 -D__CONFIG_CEDARX_HEAP_MODE=0 -D__CONFIG_AUDIO_HEAP_MODE=0 -D__CONFIG_CODEC_HEAP_MODE=0 -D__CONFIG_ZBAR_HEAP_MODE=0 -std=gnu99 -I../../../include -I../../../include/libc -I../../../include/driver/cmsis -I../../../include/kernel/FreeRTOS/FreeRTOSv8.2.3 -I../../../include/kernel/FreeRTOS/FreeRTOSv8.2.3/portable/GCC/ARM_CM4F -I../../../include/net -I../../../include/net/lwip-1.4.1 -I../../../include/net/mbedtls-2.16.0 -I../../../include/net/nghttp2//lib/includes -I../../../include/net/lwip-1.4.1/ipv4 -o codec/ac101.o codec/ac101.c /bin/sh: 1: /home/tester/gcc-arm/bin/arm-none-eabi-gcc: not found make[3]: *** [../../../gcc.mk:212: codec/ac101.o] Error 127 make[3]: Leaving directory '/mnt/w/GIT/xr872_sdk/src/driver/chip' make[2]: *** [Makefile:105: driver/chip] Error 2 make[2]: Leaving directory '/mnt/w/GIT/xr872_sdk/src' make[1]: *** [Makefile:96: install] Error 2 make[1]: Leaving directory '/mnt/w/GIT/xr872_sdk/src' make: *** [../../../../project/project.mk:353: lib] Error 2 3. but path is ok. File exists, but it can't be executed, it's something else, I checked it with readelf: Code: text Expand Select all Copy to clipboard tester@DESKTOP-6SD9MUK:/mnt/w/GIT/xr872_sdk/project/demo/wlan_demo/gcc$ readelf -l ~/gcc-arm/gcc-arm-none-eabi-4_9-2015q2-20150609-linux/gcc-arm-none-eabi-4_9-2015q2/bin/arm-none-eabi-gcc | grep interpreter       [Requesting program interpreter: /lib/ld-linux.so.2] 4. Then I checked for ld-linux.so: Code: text Expand Select all Copy to clipboard tester@DESKTOP-6SD9MUK:/mnt/w/GIT/xr872_sdk/project/demo/wlan_demo/gcc$ ls /lib/ld-linux.so.3 ls: cannot access '/lib/ld-linux.so.3': No such file or directory 5. ld-linux.so is missing, so I did update: Code: text Expand Select all Copy to clipboard sudo apt update sudo apt install libc6-i386 lib32z1 lib32stdc++6 6. now it seems to compile fine? More info soon Added after 4 [minutes]: Added after 3 [minutes]:attached firmware

divadiow · Answer

strings in bin lots of OTA

divadiow · Answer

Code: TextLog in, to see the code

divadiow · Answer

captured it reaching out to these IPs on 32100. same as listed at Added after 41 [minutes]: sample HD video

divadiow · Answer

Hello! Yes, I clipped onto the flash chip. I did not need put anything into reset mode first.

divadiow · Answer

oh nice. good work. I didn't do anything more with my one. feel free to post all your findings!

gusgorman402 · Answer

How are you getting Flashrom to work? I'm trying to use Bus Pirate with a SOIC8 clip, but it won't recognize the chip. It keeps backfeeding power into the board too, causing the lights to turn on briefly. I think my PTZ camera has a different chip too

insmod · Answer

>>21349910 There is this: But it looks like only for GC0308 and GC0328C sensors

divadiow · Answer

cloned here for safe keeping Added after 19 [minutes]: me? no more steps than what was in the first post I'm afraid. As it's only an 8 pin SOIC my next step would have been to desolder and then clamp up to read flash.

alistairjordan · Answer

So making a couple of notes on the above replies:
* The BusPirate is a pile of doo doo, and WILL drive you nuts (Trust me I have one, long abandoned in a drawer). For your own sanity I would use a CH341A programmer (and included SOP8 clip) for reading the flash, and also you can pop it in serial mode to get access to the console.
For the things this won't cover well, I tend to directly solder onto a RPI Pico (They are dirt cheap) and write the relevant code.
Links: https://www.aliexpress.com/item/1005006520623353.html
https://www.aliexpress.com/item/1005003371056277.html
* Unless I'm wrong, https://portrait.gitee.com/Dozingfiretruck/xr872_sdk/blob/master/project/example/jpeg/main.c will only cover taking a picture and saving to SD.

So I've come across this string in the dump:

WAR WLAN Stealer
(I guess WAR is warning)

Does anyone know what this could be about?
It sounds rather ominous.

I will try flashing an example for the XR872 onto a board in the next few days, it should at least give a PoC that assumptions are all correct and this thread is going in the right direction.

1864mponepound · Answer

hey gusgorman402 how were you able to overcome this problem you describe?I have the same problem.My PTZ camera has the same memory chip.

1864mponepound · Answer

hi what tool did you use to read the flash I have a ch341 but for some reason it is failing - did you desolder or use a probe?

divadiow · Answer

I clipped on to the flash chip like I did with this

1864mponepound · Answer

Thanks for clarifying.

divadiow · Answer

I have wondered if an XR872 SDK demo compiled and flashed directly to flash would boot. Might try someday.

https://github.com/divadiow/xr872_sdk/tree/main/project/demo

The only official reference to XF16 I've seen in relation to Allwinner is an entry in a drop-down or two in their developer portal

divadiow · Answer

good going. I haven't been able to try anything since posting. I have one eye on this thread and the other on work.

p.kaczmarek2 · Answer

Do you have time to try my binaries?

Comparison (build vs read):

Comparison of two binary files in a hex editor, with differences highlighted.

Added after 39 [seconds]:

String refs similar:

Screenshot of a hex comparison tool displaying differences between two binary files.

Added after 4 [minutes]:

XR872 in original flash of A9 camera:

Screenshot of a hex editor showing the contents of a binary file in hexadecimal and text (ASCII) form.

Added after 31 [minutes]:

Original bootlog:


[bl ERR] main():629, build:20:38:52
[FD I]: mode: 0x4, freq: 48000000Hz, drv: 0

Password:PMA: mode select:e

wlan information ===================================================
firmware:
    version : R-XR_C10.08.52.64_01.80 Jul  6 2019 20:05:10-P01.46-R
    buffer  : 12
driver:
    version : XR_V02.05
====================================================================

PMA: wlan mode:a

platform information ===============================================
XRADIO Skylark SDK 1.2.0 Oct 17 2024 10:39:50

sram heap space [0x21fc70, 0x25fc00), total size 262032 Bytes
cpu  clock 240000000 Hz
HF   clock  40000000 Hz

sdk option:
    XIP           : enable
    INT LF OSC    : enable

mac address:
    efuse         : 18:9e:2d:81:89:ce
    in use        : 38:0a:8d:47:2b:71
====================================================================

StartupState:5
[os E] OS_MutexDelete():54, handle 0
io=20 mode=0 pull=1
HAL_Wakeup_SetIO en:40 mode:0 pull:1000
[0;32;31mEnter Sleep Mode 1[m
[os E] OS_MutexLock():65, handle 0
[os E] OS_MutexUnlock():80, handle 0
[os E] OS_MutexLock():65, handle 0
[os E] OS_MutexUnlock():80, handle 0
rec enter sleep mode
[0;32;31m<-500119_192428 rtb_av_api.c:2063>[mmedia not init
ntp enter sleep mode 0
[0;32;31mEnter Sleep Mode 2[m
HAL_Wakeup_ClrTimer
[bl ERR] main():629, build:20:38:52
[FD I]: mode: 0x4, freq: 48000000Hz, drv: 0

Password:PMA: mode select:e

wlan information ===================================================
firmware:
    version : R-XR_C10.08.52.64_01.80 Jul  6 2019 20:05:10-P01.46-R
    buffer  : 12
driver:
    version : XR_V02.05
====================================================================

PMA: wlan mode:a

platform information ===============================================
XRADIO Skylark SDK 1.2.0 Oct 17 2024 10:39:50

sram heap space [0x21fc70, 0x25fc00), total size 262032 Bytes
cpu  clock 240000000 Hz
HF   clock  40000000 Hz

sdk option:
    XIP           : enable
    INT LF OSC    : enable

mac address:
    efuse         : 18:9e:2d:81:89:ce
    in use        : 38:0a:8d:47:2b:71
====================================================================

StartupState:5
[os E] OS_MutexDelete():54, handle 0
io=20 mode=0 pull=1
HAL_Wakeup_SetIO en:40 mode:0 pull:1000
[0;32;31mEnter Sleep Mode 1[m
[os E] OS_MutexLock():65, handle 0
[os E] OS_MutexUnlock():80, handle 0
[os E] OS_MutexLock():65, handle 0
[os E] OS_MutexUnlock():80, handle 0
rec enter sleep mode
[0;32;31m<-500119_192428 rtb_av_api.c:2063>[mmedia not init
ntp enter sleep mode 0
[0;32;31mEnter Sleep Mode 2[m
HAL_Wakeup_ClrTimer

You can use USB breakout to get TX without soldering

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.

divadiow · Answer

just hooking up to flash now

p.kaczmarek2 · Answer

Why verify fails at random offets, omg?

Added after 1 [seconds]:

Why verify fails at random offets, omg?

Added after 20 [seconds]:

Verify flash fails for randomly.

Added after 11 [minutes]:

UART access via USB;

Desoldering flash:

Trying flasher outside circuit:


Current programmer: CH341 Black
SPI ID: C74014

Outside circuit, Verify is OK:


Current programmer: CH341 Black
15:31:59
Verify memory...
Success
Execution time: 00:00:09.503

read_outsi...ircuit.bin Download (1 MB)

divadiow · Answer

SREG read before programming. detected as 1313 first time and now C74014, as it did originally. flashed with Neo but nothing from TX. trying flashrom and other things

p.kaczmarek2 · Answer

I seemingly can flash outside circuit:


Current programmer: CH341 Black
15:39:48
Programming memory... Main Memory
Success
Execution time: 00:00:18.015

but then verify always fail:


15:40:38
Verify memory...
Verification error on address: 0x00000008, Device: 0xA2, Buffer: 0xE2
Execution time: 00:00:00.086

Probably it does not flash in reality.

divadiow · Answer

yes, this is annoying. read-back is rubbish and erase is mostly ineffective in Neo and As. I've been toggling protections bits but still no joy. Just moving onto other flash chips I might have lying around.

p.kaczmarek2 · Answer

Just make sure that you erase first:

but it does not help for me:


Current programmer: CH341 Black
16:23:42
Erasing memory...
Success
Execution time: 00:00:03.954
Current programmer: CH341 Black
16:23:46
Erasure control...
Success
Execution time: 00:00:22.254
Current programmer: CH341 Black
16:24:08
Programming memory(verifying)... Main Memory
Verification error on address: 0x00000384, Device: 0xFF, Buffer: 0x29
Execution time: 00:00:00.268

divadiow · Answer

frustrating. not getting anywhere with any erase/sreg bits /programs tried.

Added after 28 [minutes]:

in As what do your SREG bits read out as?

and does the selection change if you click read again and again?

Exploring A9 Minicam Variation: XF16 PB380EA6341 MCU, T25S80 SPI Flash, XR872, Skylark SDK

Post #1

Post #2

Post #3

Post #4

Post #5

Post #6

Post #7

Post #8

Post #9

Post #10

Post #11

Post #12

Post #13

Post #14

Post #15

Post #16

Post #17

Post #18

Post #19

Post #20

Post #21

Post #22

Post #23

Post #24

Post #25

Post #26

Post #27

Post #28

Post #29

Post #30

Topic summary