04-06-2026 ✦ #security ✦ #embedded ✦ #hardware From UART to Root: Vendor Shell Escape on a Uniview IP Camera There’s a gap between solving CTF challenges and poking at a real device running unknown firmware. I bought a Uniview SC3243 security camera off eBay to find out how wide that gap really is. With the camera in hand, the first step was opening it up. Hardware Enumeration Removing three screws and popping open the enclosure revealed a small PCB with a NAND flash chip: But the thing that immediately stood out to me was the unpopulated 4-pin header in the corner labeled J4. Unpopulated headers on embedded hardware are usually there for good reason, whether that’s debugging, manufacturing, or both. The next step was probing each pin with a multimeter to map the pinout. Mapping the Pinout The easiest thing to identify is a ground pin, so I started there. I placed the ground probe on some metal plating in the camera, and poked each of the four headers with the positive probe. After reaching the outermost pin, the multimeter read 0, so I knew I’d found it. In the process of finding GND, I also uncovered another important detail: the pins were using a 3.3v logic level. This hinted heavily at UART, which is a great sign. Next, I needed to figure out which pin was transmitting data. Assuming the TX pin would have something to output on bootup, I rebooted the device and observed the behavior of the remaining 3 pins. I noticed that one of them was fluctuating in voltage when the camera turned on, while the others seemed relatively constant around 3.3v. That’s our TX. The remaining two were suspected RX and VCC pins. Identifying these was a bit less scientific since both consistently sat around 3.3V. After trying both I got the final pinout identified in the picture below. Serial Access With the pinout identified, I hooked up my Tigard to the pins using some stripped jumper cables (because PCBite probes are not cheap) and set the level shifter to 3.3v. I used the following command to open up a serial console and connect to the Tigard with the most common UART baud rate (115200): picocom -b 115200 /dev/tty.usbserial-TG11171a0 Immediately after powering the camera on, I was greeted with boot logs: U-Boot 2020.04-00011-gddf6f040-dirty (Jun 17 2024 - 18:12:02 +0800), Build: jenkins-Compile_64位(10.188.40.119)-7385 U-Boot code: 5C000400 -> 5C095BEC BSS: -> 5C0BD52C Model: AXERA AX620E_Qnand Board <...> Seeing a bootloader banner is always a good sign. One thing that immediately caught my eye, before the logs started flashing faster than the eye can see, was this line: Press Ctrl+B to abort autoboot in 2 seconds I took note of that and let the camera continue to boot normally. Once it was done, I was prompted to enter a password. root login: I typed in “root”, hit enter, and then boom! Nothing happened… After about an hour of confusion and thinking that picocom was the problem, I realized I’d forgotten to hook up GND… Woops! Anyways, after everything was properly connected, I let the camera boot normally and tried logging in as root again. I didn’t find default credentials online, but after cycling through the usual suspects ( 123456 , admin , password ), I tried uniview on a whim and it worked! After logging in I was dropped into this: User@/root> help logout exit update systemreport.sh display ifconfig ping _hide sdformat resetconfig killall date catmwarestate catfpn <...> download_logo cleancfg iperf downloadsetup ls ps checksysready cleanlogo downloadlensinfo displaylensinfo clearlensinfo downstitchcal uploadstitchcal setmonocularid getudid route mountnfs secureboot A restricted shell. The vendor whitelisted a small set of commands and locked everything else out. This didn’t seem useful at first, but I noticed a few of those commands had .sh extensions, which meant they were scripts sitting somewhere on the filesystem. I took note of that and rebooted again to go dig deeper. On this second reboot, I was able to interrupt the autoboot process and was greeted with this prompt: uboot # Now, I could start interacting with the device a little more, albeit still in a restricted capacity. Investigating the U-Boot Shell The first thing I wanted to know was what I was working with, so I ran help : uboot # help ? - alias for 'help' adc - ADC sub-system axera_boot- axera boot axera_ota - ota from tftp server base - print or set address offset bdinfo - print Board Info structure bind - Bind a device to a driver blkcache - block cache diagnostics and control boot - boot default, i.e., run 'bootcmd' <...> printenv - print environment variables protect - enable or disable FLASH write protection pwm - pwm config random - fill memory with random pattern reset - Perform RESET of the CPU run - run commands in an environment variable saveenv - save environment variables to persistent storage sd_update - download mode setenv - set environment variable <...> There were quite a few interesting commands, but a few stood out to me immediatel...