Cheap Chinese camera teardown

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.

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.

IPsec VPN - RouterOS and FreeBSD

FreeBSD suggests using Racoon as the IKE daemon, and I buy that recommendation since RouterOS also uses racoon internally (hint: look at the ipsec,debug)

But this "simple"-tunnel method of RouterOS it a bit tricky to replicate on a default racoon setup. In this example I will use a IP-in-IP tunnel (also called ipencap) and has IP Protocol 4 (IP/4), but using a GRE (IP/47) should also be fine.

  • Route-based tunnel - not Proxy/Policy-based
  • Using IP-in-IP tunnel type ("ipencap" / IP Protocol 4)
  • Site A tunnel endpoint - 192.168.254.1/32
  • Site A local network - 192.168.1.0/24
  • Site B tunnel endpoint - 192.168.254.2/32
  • Site B local network - 192.168.2.0/24

SITE_A_IP and SITE_B_IP is the corresponding public IP-addresses. This howto doesn't cover any required firewall openings.

This is what I found out and works.

Site A - RouterOS

1. Setup tunnel interface on RouterOS, and setup a linknet

/interface ipip
add name=tun1 ipsec-secret=XXXXXXXXXX local-address=SITE_A_IP remote-address=SITE_B_IP
/ip address
add address=192.168.254.1/30 interface=tun1
/ip route
add dst-address=192.168.2.0/24 gateway=192.168.254.2

You're done on RouterOS.

Site B - FreeBSD

1. Setup tunnel interface and services on your FreeBSD (or similar system)

/etc/rc.conf:

cloned_interfaces="gif0"
ifconfig_gif0="inet 192.168.254.2 192.168.254.1 netmask 255.255.255.255 tunnel SITE_B_IP SITE_A_IP"
racoon_enable="YES"
ipsec_enable="YES"
ipsec_file="/usr/local/etc/racoon/setkey.conf"

gateway_enable="YES"
static_routes="net1"
route_net1="-net 192.168.1.0/24 192.168.250.1"

2. Configuration for racoon. Please note the "address SITE_B_IP 4 address SITE_A_IP 4" where the 4 is for ipencap (IP/4) tunnel packets.

/usr/local/etc/racoon/racoon.conf:

path pre_shared_key "/usr/local/etc/racoon/psk.txt";
log notify;

listen {
    isakmp          SITE_B_IP [500];
}

remote SITE_A_IP [500] {
    exchange_mode       main;
    proposal_check      obey;

    # phase 1
    proposal {
        encryption_algorithm    aes 128;
        hash_algorithm          sha1;
        authentication_method   pre_shared_key;
        lifetime time           3600 secs;
        dh_group                2;
    }
}

# phase 2
sainfo (address SITE_B_IP 4 address SITE_A_IP 4) {
    pfs_group                       2;
    lifetime                        time 3600 sec;
    encryption_algorithm            aes 128;
    authentication_algorithm        hmac_sha256, hmac_sha1;
    compression_algorithm           deflate;
}

3. This one is tricky, the IPsec kernel policy configuration. This tells the kernel IP-stack - that traffic from SITE_B_IP to (out) SITE_A_IP that is of type ipencap (IP/4) shall be of encrypted with IPsec transport type ESP. The next line is for the opposite direction.

/usr/local/etc/racoon/setkey.conf:

flush;
spdflush;
spdadd SITE_B_IP SITE_A_IP ipencap -P out ipsec esp/transport/SITE_B_IP-SITE_A_IP/require;
spdadd SITE_A_IP SITE_B_IP ipencap -P in ipsec esp/transport/SITE_A_IP-SITE_B_IP/require;

4. And of course the shared secret.

/usr/local/etc/racoon/psk.txt:

SITE_A_IP    XXXXXXXX

Then of course restart services or do a full reboot.

I prefer route-based tunnels since they work almost like a physical link, and you can use traceroute and standard tools. Your routes decide whats reachable. Policy based tunnels are a bit magic and bypasses standard routing, and I find them hard to troubleshoot.

The theory of operation here is that the tunnel itself gets encrypted, not the specific packets going trough it.

  1. Packet arrives at Site A router. Router makes route lookup and the decision to forward packet to tunnel inteface.
  2. Tunnel encapsulates packet.
  3. Packet then matches Source, Destination and Protocol number defined in IPsec kernel policy (setkey.conf), witch applies the transport encryption.
  4. Encrypted payload leaves router

ifconfig gif0 should display:

gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1280
    options=80000<LINKSTATE>
    tunnel inet SITE_B_IP --> SITE_A_IP
    inet 192.168.254.2 --> 192.168.254.1  netmask 0xffffffff 
    inet6 fe80::a3d9:9ef1:721c:a309%gif0 prefixlen 64 scopeid 0x4 
    nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
    groups: gif

A tcpdump should show the something like:

19:04:14.700751 IP SITE_A_IP > SITE_B_IP: ESP(spi=0x06b57eb9,seq=0x12), length 136
19:04:15.706837 IP SITE_B_IP > SITE_A_IP: ESP(spi=0x02a7da91,seq=0x10), length 136
19:04:15.707011 IP SITE_A_IP > SITE_B_IP: ESP(spi=0x06b57eb9,seq=0x13), length 136
19:04:16.715800 IP SITE_B_IP > SITE_A_IP: ESP(spi=0x02a7da91,seq=0x11), length 136

Good luck!

How are you doing these days? (English)

For a long time I just ran a Linux machine with a simple iptables-firewall. But when the need for wireless arrived, the choice fell on the Linksys WRT54G, which also took over the firewall duties. It was later replaced with a Netgear WNR3500L since it had Gigabit-ports.

Unfortunately, in a couple of years, most people have acquired wireless at home and the 2.4GHz domain was becoming very noisy with all neighbors. Then the ISP's started to ship their combined modem and WiFi-router to just everyone.

I realized that it was time to enter the 5GHz band, since my laptop already had support for this. I've also realized that I wanted to run OpenWRT, and the chipsets from Broadcom did not play well with the opensource community. So the choice fell on a TP-Link WDR3600. This dual-band router really does its job well and is basically made for running OpenWRT.

Why not DD-WRT?

DD-WRT felt phenomenal when it was released. All of a sudden you had SoHo-enterprise features that you never thought possible with cheap sub-$100 routers. But after a few years, I found the project a bit weird. There was never any stable releases, only new "builds" that seem to be the complete mess which builds that were stable or not. No changelogs, no security updates. The whole project seems to be a one-man-show, but at the same time some kind of commercial product? No one really knows. Are they still working on v24?

Why not OpenWRT?

OpenWRT is a great project. It is much more than just an alternative firmware; it is a complete solution for embedded platforms. But it is still "only" a Linux distribution to be fair, even if LuCI is a very nice interface. It also lacks some proprietary optimizations and features that only a manufacturer can have full knowledge of (due to NDA agreements, and so on...) There is also no continuous updates and security fixes. You simply have to nicely wait for a new release or build from trunk.

Hello RouterOS

I work with IT-security and networking equipment. It ranges from stuff sitting in a closet somewhere to 4-unit gear in noisy datacenters. These usually have very specific functions or exceptional performance, and exceptionally high price tags. What can you use at home, but without paying hundreds of dollars for hardware and licenses?

I can recommend the Latvian manufacturer Mikrotik with it's RouterOS and Routerboard. They made previously only a little more pricey pure router modules, but has now begun to use the same type of Atheros/Qualcomm chipsets such as TP-Link and others.

Advantages

  • Has support for everything you would expect from entry/mid-level enterprise router.
  • They have different types of hardware depending on performance requirements ($40 to $2000).
  • They develop on their own hardware for their software and everything is tested, hence very reliable.
  • They have the opportunity to use the specific hardware support (NAT, crypto and forwarding in hardware)
  • They release new software continuously, and it is almost ridiculously easy to upgrade.
  • They have a proper CLI which is actually really good and useful (and colorful). Some big-player vendors should actually be ashamed when compared.
  • It is good quality radio design, construction and components.
  • Web interface is great to!
  • Larger models support encryption in hardware, providing lovely VPN performance.

Cons

  • Licensed - But new hardware includes one standard license, and it's not that pricey.
  • Their switches do not support IGMP snooping (Not quite sure this)
  • No "cluster" support - However, failover with standard VRRP is available.
  • Some of the cheap models (home-ones) have limited flash-storage - Not possible to use all functions/packages.

I myself have now this gear for the moment, on different physical locations.

  • RB260GS - Switch _ (SWOS, not RouterOS) _
  • RB wAP AC 802.11ac + 802.11n - AP
  • RB922UAGS-5HPacD - 802.11ac - AP + Firewall
  • RB hAP - 2.4Ghz 802.11n (2x2) - At my parents place

RouterOS Neighbours Neighbors list

Wireless performance Wireless performance is great to (2x2 11ac-40Mhz)

OpenWRT as Ad&Tracker blocker

Step 1: Install block-list script

Create a new script named /overlay/update-adblock.sh

#!/bin/ash
dummyhost="0.0.0.0"

echo -n "updating domains list..." wget -q -O- "http://pgl.yoyo.org/adservers/serverlist.php?hostformat=dnsmasq&showintro=0&mimetype=plaintext"|grep address >/var/adblock.domains sed -i s/127.0.0.1/$dummyhost/g /var/adblock.domains echo " done"

echo -n "updating adhosts list..." wget -q -O- http://winhelp2002.mvps.org/hosts.txt|grep "0.0.0.0" >/var/adblock.hosts sed -i -e 's/\r//g' /var/adblock.hosts sed -i -e 's/0.0.0.0/$dummyhost/g' /var/adblock.hosts echo " done"

echo -n "restarting dnsmasq..." /etc/init.d/dnsmasq restart echo " done"

Make it executable

chmod +x /overlay/update-adblock.sh

Force creation of files at boot and create a scheduled run (I'll use 07:23 every Sunday) with crontab -e

@reboot                 touch /var/adblock.domains /var/adblock.hosts
23 7         * * 0         /overlay/update-adblock.sh

Step 2: Add additional config for dnsmasq

Add the following line to /etc/dnsmasq.conf

conf-file=/var/adblock.domains
addn-hosts=/var/adblock.hosts

Make sure that these files exists at boot, or else dnsmasq will fail. Add the following lines to /etc/rc.local

touch /var/adblock.domains
touch /var/adblock.hosts

Step 3: Update and restart dnsmasq

Run the update manually with /overlay/update-adblock.sh

Now all your hosts on your network will be redirected to the dummyhost for the blocked domains and hosts. The lists will also be regulary updated. For further security, block outgoing DNS directly from clients (only allow the router to be source of DNS on your network)

AirPlay on OpenWRT

If you have a OpenWRT-capable router with USB and a USB Soundcard laying around, you can now use it as a AirTunes compatible reciever.

I have built packages for bcrm47xx and ar71xx type SoC's for OpenWRT Barrier Breaker

Atheros AR71xx (for example TP-Link WDR 3xxx/4xxx)
shairport_new_0.08_ar71xx.ipk

Broadcom 47xx (for example Netgear WNR3500L)
shairport_new_0.08_brcm47xx.ipk

Thanks to sm3rt for OpenWRT packaging: https://github.com/sm3rt/OpenWRT-ShairPort

If you are running Linux on your clients, you can always use PulseAudio for network audio streaming.

Update

Shairport and Shairport-sync is now included in OpenWRT 15.05. Just install the packages :)

Att bli fri från Telia SMART router

Thomson-routern (789VN) är rätt osnygg och fysiskt oplacerbar så får ligga ner i hyllan, obegripliga menyer på dåligt översatt Svenska. Fungerar som lokal DNS-server men har varken forward eller reverse lookup av lokala enheter. De försökte även sälja på mig 250Mbps-tjänst, vilket jag tyckte var poänglöst eftersom det bara är 100Mbps-switchportar i routern. Usch ja.

Jag plocka fram min Cisco 2950 och gjorde analysera trafiken från uttaget Wireshark.

# monitor session 1 source interface Fa0/11
# monitor session 1 destination interface Fa0/5 encapsulation dot1q

IPTV kommer alltså på Vlan ID 845 med QoS 3. Man kan dumpa ner multicast-strömmen i VLC om man vill, men den faktiska h264 videon är givetvis krypterad så man ser bara skräp. Men TV4 har t.ex udp://239.16.16.133:5555. Själva Internet ligger på default Vlan 1 (QoS 0), så i princip får man internet utan Thomsonlådan om man vill

Lilla mysteriet är, att Thomson-lådan verkar ha två publika Vlan-interface, ett för Internet (2.248...), ett för IPTV (217.215...). IPTV-boxen har en vanlig intern 192.168.1.0/24 och är nåbar lokalt på nätverket. Thomson-lådan måste agera som en typ av Multicast-router, alltså inte enbart switch. Detta är troligen en något proprietär lösning/konfigurering av Telia (men jag vet att det går att göra med rätt utrustning).

Intressant nog så verkar inte IPTV-boxen ha något emot att kopplas direkt på VLAN 845, den får istället då en publik adress själv (217.215...) och det fungerar bra att se TV ändå. Dock märker jag att kanalskiftena är något långsammare, skulle tro Ciscon som är lite fascist med Multicast-hoppandet möjligen :)

Men eftersom jag inte känner för att ha en 24-portars switch stående bakom TV-bänken så insåg jag att jag fick försöka hitta något annat. Switchen i min Netgear WNR3500L inte klarar VLAN ID högre än 15, så var jag tvungen att ha någon vettigare switch framför.

Jag skaffa en liten Netgear GS150E som ska klara både 802.1Q, IGMP Snooping och port-mirroring. Något labilt konfigurationsverktyg (vad är det för fel på telnet...?), skulle det inte funka så kan jag alltid ha den som switch istället för Thomson-lådan, men den verkar göra vad man ska och gav inte mer än 300:- för den.

Konfigurerade följande:

p1  PVID 1  VLAN1 untagged  (till egen router)
p2  PVID 1  VLAN1 untagged  (framtida behov...)
p3  PVID 845    VLAN845 untagged    (IPTV-box)
p4  PVID 1  VLAN1 untagged, VLAN845 tagged  (framtida behov...)
p5  PVID 1  VLAN1 untagged, VLAN845 tagged  (inkommande)

IGMP Snooping = Enabled
IGMP Snooping VLAN ID = 845
IGMP Static Port = p5

Och vips var Telias router borta! Känns bra att vara tillbaks på DD-wrt och en vettig hemnätverksmiljö igen.

Updatering

Jag har inte längre Telia sedan ett tag, så vet inte hur det fungerar idag. Jag kör inte längre dd-wrt heller. Men samma lösning bör fungera för liknande tjänster.