Freetime hacking of a YooSee Robot
Author: Marco LuxDate: 2023-01-27 12:51:25
General
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.
Hardware
After experimenting with the android application, I decided to delve deeper and examine the internal workings of the device.
Numbers in Red:
- Anyka CPU/SoC(System on Chip) - AK3918EV200
- 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.
Numbers:
- Motor for movement of the head
- Motor for movement of the head
- Wifi Card
- Slot for SDCard
- Reference for Chapter "Getting a shell"
- 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.
Numbers:
- TX wire (left clip)
- 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!
ANYKA SDHC/MMC4.0: 0
Load Env CRC OK!
In: serial
Out: serial
Err: serial
Net: AKEthernet-0
Hit any key to stop autoboot: 1 0
anyka#
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-0.9.33.2)(20170223)) ) #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:
10.200.226.100 -- Client in Robot Network
10.200.226.1 -- Robot dhcp
Note:
There is port 5000/tcp (soap) and 554/tcp (rtsp) open.
Asks for the following dns servers
Host 184.181.43.121.in-addr.arpa. not found: 3(NXDOMAIN)
5.5.5.223.in-addr.arpa domain name pointer public1.alidns.com.
Host 247.77.91.47.in-addr.arpa. not found: 3(NXDOMAIN)
114.114.114.114.in-addr.arpa domain name pointer public1.114dns.com.
Some servers the unit is connecting too:
p2pu_start_process_query_dns_v2
[msg] Nameserver 8.8.8.8:53 has failed: Network is unreachable
p2pu_start_process_query_dns_v2: evdns_getaddrinfo( p2p1.cloudlinks.cn )
[msg] Nameserver 114.114.114.114:53 has failed: Network is unreachable
p2pu_start_process_query_dns_v2: evdns_getaddrinfo( p2p4.cloud-links.net )
[msg] Nameserver 223.5.5.5:53 has failed: Network is unreachable
[msg] All nameservers have failed
p2pu_start_process_query_dns_v2: evdns_getaddrinfo( p2p2.cloudlinks.cn )
p2pu_start_process_query_dns_v2: evdns_getaddrinfo( p2p3.cloud-links.net )
p2pu_start_process_query_dns_v2: evdns_getaddrinfo( p2p5.cloudlinks.cn )
p2pu_start_process_query_dns_v2: evdns_getaddrinfo( p2p6.cloudlinks.cn )
p2pu_start_process_query_dns_v2: evdns_getaddrinfo( p2p7.cloudlinks.cn )
p2pu_start_process_query_dns_v2: evdns_getaddrinfo( p2p8.cloudlinks.cn )
p2pu_start_process_query_dns_v2: evdns_getaddrinfo( p2p9.cloudlinks.cn )
p2pu_start_process_query_dns_v2: evdns_getaddrinfo( p2p10.cloudlinks.cn )
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 10.1.1.1 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 0.0.0.0:5000 0.0.0.0:* LISTEN 427/ipc
tcp 0 0 0.0.0.0:554 0.0.0.0:* LISTEN 427/ipc
tcp 0 0 0.0.0.0:23 0.0.0.0:* LISTEN 578/telnetd
tcp 0 1 10.x.x.x:35544 47.91.77.247:51701 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 0.0.0.0:51463 0.0.0.0:* 427/ipc
udp 0 0 0.0.0.0:38922 0.0.0.0:* 427/ipc
udp 0 0 0.0.0.0:3702 0.0.0.0:* 427/ipc
udp 0 0 0.0.0.0:51109 0.0.0.0:* 427/ipc
udp 0 0 0.0.0.0:51880 0.0.0.0:* 427/ipc
udp 0 0 127.0.0.1:4278 0.0.0.0:* 434/
udp 0 0 127.0.0.1:4279 0.0.0.0:* 427/ipc
udp 0 0 0.0.0.0:8899 0.0.0.0:* 427/ipc
udp 0 0 0.0.0.0:60617 0.0.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
Password-File:
[root@anyka /etc] cat passwd
root:x:0:0:root:/:/bin/sh
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
nobody:x:99:99:nobody:/home:/bin/sh
As root has no password set, there is also no password hash or alike in the shadowing system.
cat shadow
root::0:0:99999:7:::
bin:*:10933:0:99999:7:::
daemon:*:10933:0:99999:7:::
nobody:*:10933:0:99999:7:::
[root@anyka /etc] cat wifi*
cat wifi*
bssid=xx.xx.xx.xx.xx.xx
ssid=testnet
id=0
passphrase=vrysecure
psk=ADDEADDE...
mode=station
pairwise_cipher=CCMP
group_cipher=CCMP
key_mgmt=WPA2-PSK
wpa_state=COMPLETED
ip_address=10.x.x.x.x
address=xx.xx.xx.xx.xx.xx
signal_level=169
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.
Example:
[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
Dataprivacy
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.
Outro
This was a quick dive into accessing the device. Further research is necessary to analyse the software running.
Links
I have sorted links for additional research.
Hardware
System on Chip
Later version of the chip:
https://www.unifore.net/ip-video-surveillance/anyka-ak3918ev300-1080p-ip-camera-solution.html
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.
https://www.amazon.com/Gumps-grocery-Module-Converter-Replace/dp/B081L482DP
https://www.amazon.com/DGZZI-PL2303TA-Console-Serial-Raspberry/dp/B07W42V16T/
https://www.amazon.com/Adapter-Serial-Converter-Development-Projects/dp/B075N82CDL
Logic Analyser
This one i used for attaching to the different slots and holes and analyzing the outcome.
https://www.amazon.com/KeeYees-Analyzer-Device-Channel-Arduino/dp/B07K6HXDH1
Software for Logic Analyzers
https://www.saleae.com/downloads/
https://sigrok.org/wiki/Main_Page
Repositories
https://github.com/c0decave/yoosee-ipc
https://github.com/t-rekttt/yoosee-exploit
https://thao.pw/hacking-yoosee-camera/
Product
It is currently being sold as a "robot camera" on the online marketplace AliExpress.