Freetime hacking of a YooSee Robot

Freetime hacking of a YooSee Robot

Author: Marco Lux
Date: 2023-01-27 12:51:25



The robot has slight flexibility in its movements, able to rotate its head in the left and right directions, both manually and through the use of head-tracking technology. Connecting to the device can be done through the modern approach of self-prepared WIFI by the robot to communicate the SSID and corresponding password of the owners WIFI. This is accomplished with a basic android or iOS application. The app itself provides remote control and configuration capabilities. On the side of the robot, it also allows for the storage of video streams on both a SD card and in cloud storage.

It was clear that the device was able to communicate over the internet and/or the local network, as I observed during my analysis of the network traffic, which was primarily based on a proprietary protocol using UDP as transport layer.

One aspect that particularly caught my attention during my analysis was the fact that the camera remained functional even when the visor was closed, obscuring the lens. It's worth mentioning that while this functionality may be intentional, it could be perceived as suspect and raise concerns.


After experimenting with the android application, I decided to delve deeper and examine the internal workings of the device.


Numbers in Red:

  1. Anyka CPU/SoC(System on Chip) - AK3918EV200
  2. Place of the camera lense itself before removed

The System on Chip (SoC) used in this device is specifically designed for IP cameras. From quick research, it is my belief that this chip, along with its subsequent revisions, as well as the Printed Circuit Board (PCB) are commonly used in low-cost Chinese surveillance cameras.

Upon further examination, I found that the device was more complex than I had initially anticipated. It was equipped with two motors, one for vertical head movement and the other for horizontal rotation.



  1. Motor for movement of the head
  2. Motor for movement of the head
  3. Wifi Card
  4. Slot for SDCard
  5. Reference for Chapter "Getting a shell"
  6. Power

On the back of the robot's shell, I discovered a micro-USB connector. However, upon inspection, I found that it was only being used to provide power and was not connected to any data transfer pins. Specifically, the RX and TX slots were not in use and the connector only provided access to Ground and Voltage connections.

Getting a shell

Upon further examination of the device's mainboard, I noticed three small holes located near the speaker connector (as seen in picture number 5). Upon testing with a low-cost logic analyzer, I discovered that data was being transmitted.


To replicate this discovery, you can use the logic analyzer linked in the appendix, along with software such as Saleae or the open-source alternative Sigrok.

In order to attach to sockets on the board, I found that using hook clips were an efficient and cost-effective solution. They are readily available and proved to be a reliable tool for this purpose.



  1. TX wire (left clip)
  2. RX wire (right clip)

As expected, additional experimentation uncovered the fact that by connecting a TTL converter to to the hooks and the converter to my Notebooks USB port, it was possible to access the Robots device's TTY interface. The connection was established at a baud rate of 115200.

Upon successful connection, I was presented with U-Boot, a popular open-source bootloader.

U-Boot 2013.10.0-AK_V2.0.04 (Apr 08 2021 - 12:40:06)

DRAM:  64 MiB
8 MiB
Create flash partition table init OK!
Load Env CRC OK!
In:    serial
Out:   serial
Err:   serial
Net:   AKEthernet-0

Hit any key to stop autoboot:  1                                                                                                                                   0 

Gaining access to the bootmanager also opens up the possibility to read and write to parts of the file system, memory, and bootloader. One could even potentially boot a different device. However, my primary focus was to determine if it was possible to access the operating system directly and uncover what occurs after the boot process.

   Booting kernel from Legacy Image at 81808000 ...
   Image Name:   Linux-3.4.35
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1329632 Bytes = 1.3 MiB
   Load Address: 81808000
   Entry Point:  81808040
   Verifying Checksum ... OK
   XIP Kernel Image ... OK

Anyka Linux Kernel Version: 2.5.05

Linux version 3.4.35 (root@linux-compiler1) (gcc version 4.8.5 (anyka (gcc-4.8.5 + binutils-2.24 + ulcibc- ) #41 Thu Jun 3 21:28:02 CST 2021
CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
CPU: VIVT data cache, VIVT instruction cache
Machine: AK3918EV200_GWELL_V1

Kernel command line: console=ttySAK0,115200n8 root=/dev/mtdblock4 rootfstype=squashfs init=/sbin/init mem=64M memsize=64M

To my advantage, the device had no password set, allowing me to easily log in as root.

Upon logging in, I found that the main application, called ipc, was generating a large number of debug messages and network access was not yet available. I decided to establish a network shell for further exploration. To my surprise, the device's developers had left a telnet daemon for my convenience.

telnetd &

Network Activity

IP Information after joined wireless network of camera: -- Client in Robot Network -- Robot dhcp  


There is port 5000/tcp (soap) and 554/tcp (rtsp) open.

Asks for the following dns servers

Host not found: 3(NXDOMAIN) domain name pointer
Host not found: 3(NXDOMAIN) domain name pointer

Some servers the unit is connecting too:

[msg] Nameserver has failed: Network is unreachable
p2pu_start_process_query_dns_v2: evdns_getaddrinfo( )
[msg] Nameserver has failed: Network is unreachable
p2pu_start_process_query_dns_v2: evdns_getaddrinfo( )
[msg] Nameserver has failed: Network is unreachable
[msg] All nameservers have failed
p2pu_start_process_query_dns_v2: evdns_getaddrinfo( )
p2pu_start_process_query_dns_v2: evdns_getaddrinfo( )
p2pu_start_process_query_dns_v2: evdns_getaddrinfo( )
p2pu_start_process_query_dns_v2: evdns_getaddrinfo( )
p2pu_start_process_query_dns_v2: evdns_getaddrinfo( )
p2pu_start_process_query_dns_v2: evdns_getaddrinfo( )
p2pu_start_process_query_dns_v2: evdns_getaddrinfo( )
p2pu_start_process_query_dns_v2: evdns_getaddrinfo( )

Dumping the Filesystem

Interestingly, during my research I came across a few other individuals who had also been working on this device, some years ago. However, one individual, known as T-Rekt, appeared to be currently active in this field. T-Rekt had published a dump of the file system, and if my understanding of the code is correct, an unpacker for the "encrypted" firmware downloaded from the cloud service. I have not yet investigated T-Rekt's work in-depth, but it may be worth looking into.

In order to gain a better understanding of what we are dealing with, I found it helpful to download the files of the device. Once again, the developers of the device made this task easy by providing the use of netcat, which facilitates the transfer of data over a network.

Camera side:

# nc -v 9999 | tar vf -

Notebook Side:

# nc -v -l -p9999 > fs.tar

As soon it is done we can unpack it and start investigating the downloaded files.

Telnet Shell

[root@anyka ~]$ ls
bin   dev   etc   init  ipc   lib   mnt   proc  rom   sbin  sys   tmp   usr   var
[root@anyka ~]$ uname -a
Linux anyka 3.4.35 #41 Thu Jun 3 21:28:02 CST 2021 armv5tejl GNU/Linux
[root@anyka ~]$ id
uid=0(root) gid=0(root) groups=0(root)
[root@anyka ~]$

Local Live Analysis

Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0  *               LISTEN      427/ipc
tcp        0      0   *               LISTEN      427/ipc
tcp        0      0    *               LISTEN      578/telnetd
tcp        0      1 10.x.x.x:35544      SYN_SENT    427/ipc
tcp        0      0 10.x.x.x:23            10.x.x.x:58140         ESTABLISHED 578/telnetd
tcp        0  65160 10.x.x.x:49670         10.x.x.x:8787          ESTABLISHED 7269/nc
tcp        0    171 10.x.x.x:23            10.x.x.x:41320         ESTABLISHED 578/telnetd
udp        0      0 *                           427/ipc
udp        0      0 *                           427/ipc
udp        0      0  *                           427/ipc
udp        0      0 *                           427/ipc
udp        0      0 *                           427/ipc
udp        0      0*                           434/
udp        0      0*                           427/ipc
udp        0      0  *                           427/ipc
udp        0      0 *                           427/ipc
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags       Type       State         I-Node PID/Program name    Path
unix  4      [ ]         DGRAM                       120 347/syslogd         /dev/log
unix  2      [ ]         DGRAM                       213 483/wpa_supplicant  /etc/Wireless/wlan0
unix  2      [ ]         DGRAM                       173 427/ipc


[root@anyka /etc] cat passwd

As root has no password set, there is also no password hash or alike in the shadowing system.

cat shadow

[root@anyka /etc] cat wifi*
cat wifi*
bssid / frequency / signal level / flags / ssid

Mounted filesystems:

rootfs on / type rootfs (rw)
/dev/root on / type squashfs (ro,relatime)
devtmpfs on /dev type devtmpfs (rw,relatime,mode=0755)
proc on /proc type proc (rw,relatime)
tmpfs on /tmp type tmpfs (rw,relatime)
tmpfs on /var type tmpfs (rw,relatime)
devpts on /dev/pts type devpts (rw,relatime,mode=600,ptmxmode=000)
tmpfs on /mnt type tmpfs (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
/dev/mtdblock6 on /rom type jffs2 (rw,relatime)
tmpfs on /mnt/ramdisk type tmpfs (rw,relatime)
tmpfs on /etc type tmpfs (rw,relatime)
tmpfs on /tmp type tmpfs (rw,relatime)
/dev/mtdblock5 on /ipc type squashfs (ro,relatime)
/dev/mtdblock5 on /usr type squashfs (ro,relatime)

It should be also noted that, there are some additional modules to control the motor. It is probably quite funny write a small remote app to control it.

In Regard of Security

This includes just some quick notes and is the tip of the iceberg at its best. Without doubt the robot has plenty of attacksurface available.

No login password

Physical connection to the device grants easy shell access.

Wifi Credentials

Regardless of the network configuration, the device will output the network name and password as debug messages during runtime. This is a critical security vulnerability as it allows for easy access to the device's network and potentially the device itself. Still a physical connection is needed.


[vInitNetSupportVal] fgEth0Support = 0,fgRa0Support = 1
Init SSID=testnet , EncType=2, Password=vrysecure
Init SSID=Free-AP1 , EncType=0, Password= 
Init SSID=Free-AP2 , EncType=0, Password= 
Init SSID=Free-AP3 , EncType=0, Password= 
Init SSID=testnet , EncType=2, Password=vrysecure 
[iParseWifiModuleType] wifi type: WIFI_TYPE_RDA5995


In conclusion, it is my strong belief that this type of camera should not be used in companies or other potentially sensitive environments.

IPC Main Component

I took some hours sweeping through the ARM assembly of the main-program. This and additional software on the device leave the impression of selfmade encryption and memory corruptions. I might publish a second piece of paper in future in regard.


This was a quick dive into accessing the device. Further research is necessary to analyse the software running.


I have sorted links for additional research.


System on Chip

Later version of the chip:

USB to TTL Serial

Those are just examples to get you going. You will find even cheaper ones. Those have not been the ones i used. However, its the type of device you can use to.

Logic Analyser

This one i used for attaching to the different slots and holes and analyzing the outcome.

Software for Logic Analyzers



It is currently being sold as a "robot camera" on the online marketplace AliExpress.

Who we are & Disclaimer