I had recently the chance to analyse a camera, build into a neat robot shell. The device comes with a short descritopn howto integrate and connect to the device. After setting it up and watching the network traffic, i was interested in digging a bit deeper.
- Revision: 0.1
- Contact me at: dash@undisclose.de
- You can also catch me at #nullsecurity.net:matrix.org
The robot is able to turn its head up, down, left and right. This can be done manual or with head-tracking enabled. Installing an android or ios application allows pairing and controling it. Also storing videostreams on a SDCard and in a cloud storage is possible.
As the device can be controlled remotely it is clear, that there is communication over the internet and/or the local network available. Looking at the network traffic that time, most of it is based on UDP.
What also surprised me, was that the camera was still working when the visor is down covering the lense.
After tinkering with the android application, i decided to take a look at the internals of the device.
Numbers in Red:
- Anyka CPU/SoC(System on Chip) - AK3918EV200
- Place of the camera lense itself before removed
The used SoC is especially built for IP Cameras. It is the believe of the author that this Chip (further revisions), as well as the PCB are massivly used in cheap chinese surveillance cameras.
All in all, the whole device was a bit more omplex as i assumed. It had two motors, one for turning the head up and down, one for turning it from left to the right.
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-shelf is a micro-usb connector, however it only
supports power and non-conductor. The RX and TX slot are unused. Only
Ground and Volts.
On the mainboard of the device are three small holes close to the connector of the speaker(Remember Number 5 of second picture?). As it turned out by basic testing with a cheap logic analyser, data was sent through it.
For this you can use the linked analyser in the appendix and use the software
from saleae or better the open source variant sigrok.
For attaching at chips or holes at boards i used hook clips. They are quite cheap and do their work.
Numbers:
- TX wire (left clip)
- RX wire (right clip)
Some more testing revealed that with a TTL converter connected to the USB port
the tty of the device can be accessed. With 115200 baud.
After successful connection i was greeted with uboot a free 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#
As access to the bootmanager is possible as well, parts of the filesystem, memory and the bootloader can be read and written. Also booting a different device would be possible. But i'am more interested to figure if the OS can be accessed, whats happening after the boot.
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
Luckily there was no password set on the device, so a root login was achieved in the next step.
As the main application, called ipc is littering the screen with endless
debug messages and no network access was available yet, i decided to give me a
network shell. The developers of the device have left a telnet daemon for our
convinience.
telnetd &
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 )
Funnily enough, during my research i found some few people also working on this, some years ago, but one right now: t-rekt. T-Rekt published a dump of the filesystem, and if i interpreted the code correctly also an unpacker for the "encrypted" firmware downloaded from the cloudservice. I have not furhter investigated the work but you might be interested to have a look.
For getting an idea what we are up against, i like to download the files of
devices. Again, the developer/s of the device made our task easy. There is
netcat which supports us in sending data through the net.
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.
[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 ~]$
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.
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.
Easy shell access if physical connection is made. Make no mistake, this just made it even easier. With access to the bootloader, the devices can be rewritten or read, which leads also to system access. However, giving not even a password on a IOT device was to be past in my imagination.
Whatever network is configured, it will be printed as debug message during runtime. This includes the network name and the password.
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
It is the strong believe of the author, that such cameras should not be placed in companies or other maybe even restricted environments. Even personal usage is discouraged. All data ends up at chinese servers, opens up all sorts of misuse.
I took some hours sweeping through the 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.
Later version of the chip:
https://www.unifore.net/ip-video-surveillance/anyka-ak3918ev300-1080p-ip-camera-solution.html
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
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
https://www.saleae.com/downloads/
https://sigrok.org/wiki/Main_Page
https://github.com/c0decave/yoosee-ipc
https://github.com/t-rekttt/yoosee-exploit
https://thao.pw/hacking-yoosee-camera/ - Additional Ressource of t-rekttt, guess .vn or.th
Currently you can find it at ali express as robot camera.