This would probably be a good time to mention that I haven’t really reversed engineered much of anything since my Commodore VIC-20 days. So I am unfamiliar with any new techniques and I’m sure someone with experience could find any number of “Beta, why are you doing shit this way”, so please be patient. And yes, I realize how much the above date me. What can I say, I’m old.
Dumping the firmware was easy enough. The SPI flash chip is an XMC XM25QH64DHI. It’s a 64Mb chip in a SOP-8 package. I used a cheap CH341A USB programmer/reader to dump the flash, after modding the programmer to supply the correct 3.3V power to all the pins. (I need to do a separate post about that later).
Once I got the flash dumped, I ran it thru the binwalk (ver 3.1.1) program to have it try and extract any partitions, files, etc. from the dump. Fortunately, the firmware wasn’t encrypted and it found 5 partitions that contained the following:
- Partition 1: u-boot, ver. 2020.1
- Partition 2: Toybox Linux, ver 0.8.8
- Partition 3: device tree blob for the Goke GK7202 SoC
- Partition 4: Busybox Linux, ver 4.9.37
- Partition 5: Camera software and drivers
The bootloader, u-boot, had been compiled to not allow interception of the boot: no timeout nor break keys. This meant the device had to boot the whole way up before I could do anything on the serial console. This is a pain, especially after I lifted a pad off trying to solder some wire to make it easier.
The basic boot process has these high level steps:
- u-boot, which extracts Toybox Linux and the device tree blob
- Toybox is a very tiny version of Linux built for the Android platform. Toybox startup scripts runs a program named “sample_quickstart_v2”, then hands off to Busybox Linux
- Busybox is the main Linux platform. At the end of Linux set up, it hands off to the camera startup script, “start.sh”
- The “start.sh” just what it says, it starts the rest of the camera programs up
The sample_quickstart_v2 program seems to set up the local camera interface, which seems to be a Xmedia API. As I know nothing about Xmedia’s API, there’s not a lot for me to say here, so I won’t.
The start.sh script, I can talk about a bit more. It does a lot of things:
- It kills the telnet daemon, which sucks.
- checks for and installs firmware updates for both the WiFi and the SPI flash
- Looks to see if there’s a SD card available, mounts it if so.
- Looks to see if there’s a file called “debug_cmd.sh”, and if so execute it.
- Loads some additional driver modules
- Kicks off the main program, “p2pcam”
- Checks if the p2pcam is running and reboots the camera if not. This is a loop in the script.
The important item here is the 4th bullet point: debug_cmd.sh This is finally where you can intercept the boot process.
When looking for info on the Goke SoC and IP cameras, I came across a site that used the debug_cmd.sh check to enable other programs from the SD card. Unfortunately, it just crashed my cam, but it did give me a way into the camera, at least until the various watchdog timers put the thing to sleep. That did allow me to get some info off the camera like the dmesg output, check out the filesystem, see what programs were running, etc., but I had to be quick about it, because of the damn timeout. I suck as a typist, so I didn’t do this for too long before saying screw it..
Given the hassle of the above, I turned to the files that binwalk extracted from the firmware. First thing I looked at were the passwd file, start up scripts and config files.
There are actually two passwd files in the file: One from the toybox part of the boot, the other from the busybox portion. Considering that I really cant access the system in the toybox stage, I ignored the toybox passwd file and looked at the busybox one. Here’s the contents:
root:QUrcFBj1CkP6E:0:0::/root:/bin/sh
I tried running it thru “jack the ripper”, but no luck after 4 days. I probably had some setting wrong.
The next thing I looked at was the “/etc/resolv.conf, and yes, it has hard coded IP addresses for Google and Alibaba DNS servers.
There wasn’t much interesting in the start up scripts or configs past the above, so I started looking at the camera programs. First thing I ran was the “file” command to see what kind of executable they were (both were stripped and static, bummer). Next was “strings” to see if there was anything interesting text in the program files.
In the “sample_quickstart_v2” file. there didn’t seem to be anything other than camera feed processing using the XMedia API. The p2pcam proved more interesting, tho.
The p2pcam program is a big program that has other programs compiled into it: Some clients, some servers, some video feed oriented, some I’m not sure about. It also kills the telnet daemon, if it happens to be running.
In the p2pcam text strings. I found hard coded IP addresses, hostnames, and URL strings:
- www.goke-agps.com
- http://www.goke-agps.com:7777/brdcGPD.dat
- 192.168.200.1 – For unconfiged cam, AP address
- foo.tas-tech.com
- http://ihome-ota-service.tange365.com/
- http://ihome-ota-service.test.tange365.com/
- http://ep.test.tange365.com
- http://ep.tange365.com
- http://139.224.31.65/device_log_upload.php
- 203.107.1.1
- 203.107.1.33
- 203.107.1.34
- 203.107.1.35
The goke-agps address is hidden behind a Cloudflare proxy, which gives me a big “You have been blocked” message, so nothing I can see there. If I use the 7777 port, I just get a timeout.
The tange365.com base domain redirects to tange.ai, a chinese language website that has its whois info hidden. tange365.com’s info isn’t hidden and belongs to Alibaba. The full URLs either give me a “Hello World” landing page, a 404 error, or my external IP address. AI related.
139.224.31.65 belongs to Aliyun Cloud Computing, which seems to be part of Alibaba (or maybe the other way around). AI related.
The 203.107.1.* addresses belong to Alibaba US.
foo.tas-tech.com and tas-tech.com currently do not resolve and ownership is hidden in whois. A DDG search turns up several a couple of possible hits, but nothing that really seems to work in context of this device.
So much non TLS comms in the above, which is something I’ve noticed about many Chinese websites. I guess the Chinese gov. doesn’t want TLS protected comms as a general rule. Easier than doing MitM everywhere. At least the primary comms of the camera do seem TLS protected.
I’m know there are other addresses in the firmware stored numerically, rather than as text strings, because I’ve seen them in my Wireshark captures, but I haven’t dug all that deeply yet.
I tried using ghidra to decompile the programs, mainly to see if I could find the timeout settings and modify them, but no luck so far. From what I’ve noticed after joining the camera to my test AP and letting it register, the timeout seems to no longer happen, based upon using the app to get realtime video, even after the camera has sat for a while. I need to investigate this more.
Between killing the telnet daemon over and over, and the timeouts, this camera seems relatively secure from casual wireless and even serial port hacking. Of course, this doesn’t mean its safe to sit on my network.
I guess next up ought to be some Wireshark and other network comms analysis.