# Target

The Target is a $10 IoT security camera. The camera has many features like remote microphone, infrared (night vision), saving footage to an internal SD card, a companion mobile application, panning and tilting. This many features in such a cheap device could be home to a large attack surface, anything from video feed capture to microphone eavesdropping. Additionally, low cost-focused devices such as this most likely call home and/or have unencrypted video and audio data transmission.

The tools I have used are basic. A regular 90W soldering iron with its accessories, jumper wires and TTL-To-USB adapter.

# Getting the Device Open

The first step is disassembling the device. It seems as though there are 2 screws holding the whole operation shut.

There is no need for destructive measures and simply unscrewing them shows me the internals and prying at the edges reveals the internals.

# Finding UART

Luckily, UART is clearly marked but there is a problem. The UART interfaces are pads and not through holes, since I don't have probes interfacing with UART is going to require a bunch of extra work.

Before proceeding though, I wanted to make things easier so I removed connecting cables since they were making the operation crowded.

3 pads under and to the left of the SD card reader, labeled RX, TX and GND.

Furthermore, I noticed that there are 2 sets of UART interfaces. One on what seems to be the main board which is what is showcased above. The second set is another board laying under the main one. I have never seen this before nor have I researched it. I prematurely assume that the same way there is a motor or battery controller/manager there is a similar thing for a camera and that UART is to interface with it specifically.

2 Pins above the camera lens labeled RX and TX, there is a 5V pin and GND seems to be under the lens housing, interesting design choice.

# Interfacing with UART

To interface with UART without pads I would have to solder jumper wires to the pads and connect those jumper wires to the TTL-to-USB adapter.

I inferred the baudrate 115200 which is the most common for similar devices.

After soldering the jumper wires I realized that they are too short and I would need to solder more jumper wires...

The last step is simply connecting the pins to their respective counterparts on the USB-to-TTL adapter.

# UART Findings

Serial interface accessed: UART1 (ttyS1 @ 0x10031000, 115200 baud).

Successfully captured full boot sequence from SPL through kernel initialization.

This confirms TX is working perfectly. RX on the other side seems to be an issue. That could be the result of multiple things: my poor soldering, an interrupted RX line, console is read-only, or no interactive shell.

SoC identification: Ingenic XBurst T23 is a low-cost MIPS SoC — common in budget IP cameras.

Flash chip: ZB25VQ64 (64Mbit = 8MB) — is this sufficient for firmware + rootfs + appfs?

RAM constraints: 32MB RAM + 27MB usable = tight. This explains why squashfs (read-only compressed filesystem) is used.

PCB design observations: Two-board design (main + camera module). Implication: modular but increases attack surface (inter-board communication = potential side-channel)

U-Boot 2013.07-svn8146 (Jan 18 2025 - 10:44:22)

Board: ISVP (Ingenic XBurst T23 SoC)
DRAM:  32 MiB
Top of RAM usable for U-Boot at: 82000000
Reserving 385k for U-Boot at: 81f9c000
Reserving 16416k for malloc() at: 80f94000
Reserving 32 Bytes for Board Info at: 80f93fe0
Reserving 124 Bytes for Global Data at: 80f93f64
Reserving 128k for boot params() at: 80f73f64

Booting kernel from Legacy Image at 80600000 ...
   Image Name:   Linux-3.10.14__isvp_pike_1.0__
   Image Type:   MIPS Linux Kernel Image (lzma compressed)
   Data Size:    1332627 Bytes = 1.3 MiB
   Load Address: 80010000
   Entry Point:  803277b0
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK

Linux version 3.10.14__isvp_pike_1.0__ (book@100ask) (gcc version 5.4.0 (Ingenic Ingenic r3.3.0-gcc540 Smaller Size 2023.05-22) ) #7 PREEMPT Thu Feb 13 15:09:34 CST 2025
Ingenic Kernel version H20241112a

cpufreq 	udelay 	loops_per_jiffy	
12000	 5942	 5942	
24000	 11884	 11884	
60000	 29710	 29710	
120000	 59421	 59421	
200000	 99035	 99035	
300000	 148553	 148553	
600000	 297106	 297106	
792000	 392180	 392180	
1008000	 499138	 499138	
1200000	 594212	 594212	
squashfs: version 4.0 (2009/01/31) Phillip Lougher
jffs2: version 2.2. © 2001-2006 Red Hat, Inc.

Creating 7 MTD partitions on "jz_sfc":
0x000000000000-0x000000040000 : "boot"
0x000000040000-0x000000048000 : "bootenv"
0x000000048000-0x0000001b8000 : "kernel"
0x0000001b8000-0x000000488000 : "rootfs"
0x000000488000-0x000000798000 : "appfs"
0x000000798000-0x0000007f8000 : "config"
0x0000007f8000-0x000000800000 : "confbak"

This is the bootlog minus noise (or what I deem to be noise)

The bootlog reveals several security-critical design choices. The device boots with console=null (no interactive shell on primary UART), yet the absence of secure boot mechanisms and presence of older, unpatched kernel versions suggests the firmware was designed for cost optimization over security.

# Possible CVEs

U-Boot 2013.07 reached end-of-life back in 2015. A simple Google search reveals at least 5 publicly disclosed vulnerabilities affecting this version, including:

• CVE-2024-57254
• CVE-2024-57255
• CVE-2024-57258
• CVE-2024-57259
• CVE-2020-8432

Linux 3.10.14 similarly reached LTS end-of-support in 2017, accumulating 2205 known kernel CVEs unpatched in this firmware.

Without confirming which patches, if any, are present in this device's firmware build, specific vulnerability enumeration requires binary analysis.

# Next Steps

Network reconnaissance will be the next phase. By connecting to the device's hotspot and capturing traffic with Wireshark, I can identify the communication protocols (likely HTTP or proprietary binary protocol), detect information leakage, and assess network-layer security. If RX remains inaccessible, SPI flash extraction via CH341A programmer becomes the primary path forward for firmware analysis.