Specifications
It does however, have som decent specifications
- 1280x720p h.264 video over RTSP
- 802.11bgn single chain wireless
- Microphone & speaker
- microSD/TF slot
- Some ONVIF compatibility
- Solenoid IR-cut filter for night/day-vision
- Infrared LEDs for night
Hardware
The SoC is quite a beast.
-
GOKE Electronics GK7102 - Single chip camera SoC
ARM1176 @ 600MHZ
512MBit DDR2 on chip
H.264 BP / MP / HP, MJPEG / JPEG / G.711 / G.726 / ADPCM / MP3 encoding
4 encoding processing capacity - 720P @ 30fps + VGA @ 30fps + QCIF @ 30fps + 720P JPEG @ 1fps
USB 2.0, Ethernet, SPI, I2S, UART, I2C and AES, DES, 3DES security engines
https://www.unifore.net/company-highlights/goke-hd-ip-camera-solution-gk7101-gk7102.html -
Macronix MX25L12835F - 128Mbit (16MB) SPI Flash
-
Mediatek MT7601U - USB 2.0 single chip WiFi
Then there is some OP-amps for speaker/microphone and voltage regulation.
Software
This is were the total meltdown is, as usual. The camera is discovered and controlled by an obscure unknown UDP protocol of some kind. It has to register to a Chinese cloud service called Cloudlinks then you have to use a very dodgy Android/iOS application called Yoosee to manage the registered devices. The Yoosee app is also used to configure the WiFi via a quite innovative "transmit by sound" technique.
The authentication also doesn't make sense and is probably very insecure.
Fortunately, it's accessible via RTSP with the URL rtsp://camera-ip:554/onvif1. And it will work fine without Internet-access. It also has a ONVIF SOAP interface on TCP port 5000, but it's quite unusable.
Reverse engineering
The real software author of the camera seems to be GWellTimes and the software product seems to be is named NPC, and the actual product might be this one.
The camera tries to contact the following servers on UDP/51700 or UDP/51880, then it uses more random UDP ports. It actually looks like some kind of tunnel. After I configured mine, I firewalled it for internet-access.
60.205.107.59 (Aliyun Computing Co., LTD) 104.250.144.74 (GorillaServers, Inc. (GORIL-3)) 85.195.88.14 (Jeff King, jeff9023@gmail.com) 220.231.142.84 (Shenzhen Runxun Data Communication Co. Ltd.) 114.67.48.145 (Vcloud, Beijing Internet Harbor Technology Co.,Ltd) 183.202.215.187 (China Mobile Communications Corporation?)
It also tried to check for updated on some servers
http://upg.cloudlinks.cn/upg/22/00/latestversion.asp?ID=XXXXXX&MAC=XXXXXX&SEID=XXXXXXX&MVS=22.00.00.10&SubType=0
If it gets a response that there is a higher software available, it fetches it
http://upg.cloudlinks.cn/upg/22/00/npcupg_22.00.00.14.bin
The file it downloads seems to be some kind of firmware at first, consisting of a JFFS2 filesystem and a binary ending
$ binwalk npcupg_22.00.00.14.bin DECIMAL HEXADECIMAL DESCRIPTION -------------------------------------------------------------------------------- 32 0x20 JFFS2 filesystem, little endian 3054100 0x2E9A14 ELF, 32-bit LSB executable, ARM, version 1 (SYSV)
If we unpack the JFFS2 filesystem, we can see that it's only a form av upgrade package, since it lacks kernel and a ordinary linux root filesystem. Probably it's only targeted to a flash partition for OEM customization. It seems to support various camera sensors. The config/*.xml
contains video encoding settings.
Main application seems to be npc
(4M), and gwellipc
(997K) for more basic functions.
└── fs_1 ├── boot.sh ├── config │ ├── image_ar0130.xml │ ├── image_h42.xml │ ├── image_sc1135.xml │ ├── image_sc2135.xml │ ├── video_ar0130.xml │ ├── video_h42.xml │ ├── video_sc1135_bak.xml │ ├── video_sc1135.xml │ └── video_sc2135.xml ├── config-鱼眼-20161124.rar ├── dhcp.script ├── gwellipc ├── language │ ├── cf │ │ └── PushMesg.txt │ ├── ch │ │ └── PushMesg.txt │ └── en │ └── PushMesg.txt ├── minihttpd.conf ├── npc ├── patch │ ├── ar0130.ko │ ├── dsa.ko │ ├── gpioi2c1.ko │ ├── gpioi2c.ko │ ├── hi_gpio.ko │ ├── jxh42.ko │ ├── motor_drv.ko │ ├── sc1035.ko │ ├── sc1135.ko │ ├── sc1145.ko │ └── sc2135.ko ├── readme.txt ├── sensors │ ├── ar0130.bin │ ├── jxh42.bin │ ├── sc1035.bin │ ├── sc1135.bin │ ├── sc1145.bin │ └── sc2135.bin ├── sound │ ├── alarm_1.amr │ ├── alarm_2.amr │ ├── alarm_3.amr │ ├── alarm_4.amr │ ├── alarm_5.amr │ ├── alarm_6.amr │ ├── alarm.amr │ ├── beingcalled.amr │ ├── calling.amr │ ├── ch │ │ ├── wifi_ap_mode.amr │ │ └── wifi_sta_mode.amr │ ├── clear.amr │ ├── di.amr │ ├── DoorBell.amr │ ├── en │ │ ├── wifi_ap_mode1.amr │ │ ├── wifi_ap_mode.amr │ │ ├── wifi_sta_mode1.amr │ │ └── wifi_sta_mode.amr │ ├── key_press.amr │ ├── numbers_ch │ │ ├── 0.amr │ │ ├── 1.amr │ │ ├── 2.amr │ │ ├── 3.amr │ │ ├── 4.amr │ │ ├── 5.amr │ │ ├── 6.amr │ │ ├── 7.amr │ │ ├── 8.amr │ │ └── 9.amr │ ├── Reset_ch.amr │ ├── Reset_en.amr │ ├── set.amr │ ├── set_fail.amr │ ├── set_ok.amr │ ├── Unlock.amr │ ├── WifiLink_ch │ │ ├── LinkFail_again_ch.amr │ │ ├── Linking_ch.amr │ │ ├── LinkOk_ch.amr │ │ └── WaitLink_ch.amr │ └── WifiLink_en │ ├── LinkFail_again_en.amr │ ├── Linking_en.amr │ ├── LinkOk_en.amr │ └── WaitLink_en.amr ├── upgfile_ok └── version.txt 14 directories, 81 files
The strings of the binary data at 0x2E9A14
also reveals some interesting lines.
$ strings endbinarydata.bin /mnt/disc1/flash_erase /patch/bin/flash_erase /mnt/disc1/flashcp /patch/bin/flashcp /dev/mtd5 reboot -f
Probably a upgrade program in some way, that writes the JFFS2 to to mtd5
partition maybe?
Drawbacks
- Initial configuration needs to be done via Yoosee app, and needs online cloud registration to activate.
- No simple web interface, only configurable by app or Windows "CMS" software
- Video only, no JPEG stills
- Video bitrate/quality is not possible to configure, usually about ~1-2Mbps.
- Doesn't care about NTP options via DHCP - seems to sync tome via UDP cloud tunnel.
- No complete firmware files available anywhere
I will in time try to get root access to the device, and see if i can change the video encoding bitrate and if it's possible to output (M)JPEG via the built in web server.
Lämna en kommentar
Sorry, I don't have the manual
– Adam (http://www.adamwesterberg.se) – 4 februari 2018 16:59
Hello! Do you still have the manual for this camera? I need the default password for the cam..
– Magnus Westerlund – 23 december 2017 21:28
Hi! Root access should be easy. I have the same cam, listens to telnet. User root, no password :/
– Anders – 21 december 2017 22:14
For a jpeg-snapshot try to open cameras-IP-address/tmpfs/auto.jpg
– Jan Neumann – 25 november 2017 01:05
For a jpeg-snapshot try to open cameras-IP-address/tmpfs/auto.jpg
– Jan Neumann – 24 november 2017 14:00
Would it be possible to change a cloud ip cam into a webcam with webinterface by using the software of other (similar) cams? I only have the option to use it via Cloud and I want to use it local. In my case I have an EYEplus ZS-GX1 (same as Guudgo SC-GD03. Thanks.
– Sander – 6 november 2017 08:33
Initial configuration can? be done with SD card containing WiFiInfo.txt (case sensitive name and no <> of course): WifiName:<yourSSID> Password:<yourWPA> PasswordType:2 Insert card, power up, hold reset for 15-30 seconds. Works on my Escam Q6 and Digoo equivalent
– Simple Simon – 26 september 2017 11:11
Hi Domi, best would to buy old router 54mbit with tomato / openwrt on e-bay and disable all wan traffic via iptables. You may want to use it as separate network connected to main and use hardware port forwarding or software socat + ip filtering in order to provide some security for rtsp streams in local network. This would also give possibility to setup simple vpn and share it to internet in secure way (for android check out the onvifer, for windows pls try vlc for single stream, or for multi cameras - simple website vlc plugins + old version of firefox [all browsers stopped supporting required api, used by, among others , by vlc). Quality of streams for example in 720p camers will not be avaiable, at least as long as nobody will hack firmware (assuming hw will handle 720p streaming istead of 640x360). additional streams (554) are around 128 kbps, so most of nowadays broadbands will handle it.
– lukasz – 23 juni 2017 13:18
Hi Domi, best would to buy old router 54mbit with tomato / openwrt on e-bay and disable all wan traffic via iptables. You may want to use it as separate network connected to main and use hardware port forwarding or software socat + ip filtering in order to provide some security for rtsp streams in local network. This would also give possibility to setup simple vpn and share it to internet in secure way (for android check out the onvifer, for windows pls try vlc for single stream, or for multi cameras - simple website vlc plugins + old version of firefox [all browsers stopped supporting required api, used by, among others , by vlc). Quality of streams for example in 720p camers will not be avaiable, at least as long as nobody will hack firmware (assuming hw will handle 720p streaming istead of 640x360). additional streams (554) are around 128 kbps, so most of nowadays broadbands will handle it.
– lukasz – 23 juni 2017 13:18
Lovely!! Well done work, it would be great if you continue your good work!! BR// Andy.
– Andy – 12 mars 2017 14:47
Read your blog post with great interest and also found some guys already trying to do the same stuff http://robert.penz.name/1348/hikam-a7-iot-security-at-its-worst/ https://4pda.ru/forum/index.php?showtopic=681058 I came as far as you and did not find any other resources until now :/ Really curious to ban the cloud connection for the cam to work in my local network. Btw the cam is also cheaply available at ebay and aliexpress (~30€)
– Domi – 4 mars 2017 16:48