小米 sells a small little wifi camera which works quite painlessly.
I’ve bought several over the last few years.

My recent ones don’t work oversea’s though (which is where I install them).
Its extremely bogus selling equipment that is limited to a country, especially when they don’t tell you about it.

Annoying, as my older models aren’t “region locked”, but the newer ones are.

There is a fix for it, although it will likely get more difficult to patch at xiaomi’s whim.
If so, I’ll probably stop buying the camera’s. Lovely how vendors want to mess with customers…

—

First up, enable telnet on the camera.
Get an SD card or take the card out of the camera.

Create a folder named test on the card.
Create a plain text file called equip_test.sh in that folder, and add the following bash script:


#!/bin/sh
# Telnet
if [ ! -f "/etc/init.d/S88telnet" ]; then
echo "#!/bin/sh" > /etc/init.d/S88telnet
echo "telnetd &" >> /etc/init.d/S88telnet
chmod 755 /etc/init.d/S88telnet
fi
dr=`dirname $0`
# fix bootcycle
mv $dr/equip_test.sh $dr/equip_test.sh.moved
reboot

The script will enable telnet on the camera, and then rename the script so it doesn’t run again on the next boot.

Stick the prepared card into the camera, power on, and it should reboot (twice).
If you check the open ports on the camera ip you should now see port 23 (telnet) is open.

Login with the default user/pass (as below) via telnet

User: root
Password: 1234qwer


Once telnet’d in, enter the following, line by line –

Find and kill the watchdog process

killall watch_process


Find and kill /home/cloud process so we can edit it without the watchdog watch_process restarting it

killall cloud


Change the check within /home/cloud executable to query a fake domain so it never returns a failure, then reboot.


sed -i 's|api.xiaoyi.com/v4/ipc/check_did|api.xiaoyi.foo/v4/ipc/check_did|g' /home/cloud
reboot


Notes – The camera checks for the country by running an executable called /home/cloud
This calls an api at api.xiaoyi.com which does a ip check, then returns a true or false value if it thinks you’re in China or not. We change the /home/cloud executable ip check call to a bad url, which means it can’t perform its check.

Worked on my camera’s running version 1.8.6.1Q_201607271501

The SSL certificate for the all servers have been updated to use a wildcard certificate.

We *finally* changed over to use a wildcard cert, as pricing has come down enough to not warrant having separate certificates per server.
Our new wildcard certificate is valid until 2019.

What does this mean for you?

The bad news
Really old browsers won’t be able to open our site
If you are an XP user running IE6, you won’t be able to load our encrypted sites anymore. We strongly suggest you upgrade though if you fall into that category!
Same goes for those running Android 2.x (which is equally ancient in computer terms).

The good news
Email is now encrypted point to point using AES256 SHA encryption where possible, and webmail is SHA256 encrypted from server to your browser.
Mail servers that support it (i.e. all of ours, plus the major providers like Google, Yahoo etc, will send encrypted mail to our servers).
Mail Headers will include things like the below if encryption is supported –
Received: from usa4.computersolutions.cn (162.210.36.26) by mail.computersolutions.cn with AES256-SHA encrypted SMTP;

Lastly – our new cert gets us a test rating of A at the SSL Labs site.
https://www.ssllabs.com/ssltest/analyze.html?d=computersolutions.cn&latest

Some of our clients are experiencing delivery issues to some domains that use Gmail/Google for their email.

I previously covered that here – http://www.computersolutions.cn/blog/2015/04/gmail-and-other-google-hosted-mail-delivery-issues/

The issue is that China is still blocking Gmail/ Google hosted mail, and the recipient domain hasn’t setup their MX records correctly.

This is fine for servers outside of China, where all of googles mail servers (should) work, but breaks things for those inside China, where only a few servers are reachable.

Google hosted mail settings are here: https://support.google.com/a/answer/33915?hl=en

You’ll note that there are 5 different email servers that are listed in priority order.

Priority Mail Server
1 ASPMX.L.GOOGLE.COM.
5 ALT1.ASPMX.L.GOOGLE.COM.
5 ALT2.ASPMX.L.GOOGLE.COM.
10 ALT3.ASPMX.L.GOOGLE.COM.
10 ALT4.ASPMX.L.GOOGLE.COM.

For mail servers, the higher number is more important, so a priority of 1 will be the first server tried, then the next highest number, and so on.

If I try to connect to the servers from China.

telnet ASPMX.L.GOOGLE.COM 25
Trying 74.125.200.27…
(times out)

telnet ALT1.ASPMX.L.GOOGLE.COM 25
Trying 173.194.72.26…
(times out)

telnet ALT2.ASPMX.L.GOOGLE.COM 25
Trying 74.125.25.26…
(times out)

telnet ALT3.ASPMX.L.GOOGLE.COM 25
Trying 64.233.169.26…
Connected to ALT3.ASPMX.L.GOOGLE.COM.
Escape character is ‘^]’.
(yay, we have a winner!)

telnet ALT4.ASPMX.L.GOOGLE.COM 25
Trying 74.125.70.27…
Connected to ALT4.ASPMX.L.GOOGLE.COM.
Escape character is ‘^]’.
(yay, we have a winner!)

So, we can see that alt3, alt4 work, but none of the others do (as of 9th September 2015 from Shanghai)

So, some rudimentary testing shows that some servers work, and some do not.
How does that apply to real world examples.

Lets look at a non-working domain – ihg.com

dig mx ihg.com

;; ANSWER SECTION:
ihg.com. 600 IN MX 100 aspmx3.googlemail.com.
ihg.com. 600 IN MX 50 alt1.aspmx.l.google.com.
ihg.com. 600 IN MX 50 alt2.aspmx.l.google.com.
ihg.com. 600 IN MX 100 aspmx2.googlemail.com.
ihg.com. 600 IN MX 10 aspmx.l.google.com.

You should easily be able to see 2 things.
1 – that the MX records are not as per Google settings.
2 – that the 2 working MX records are not listed.

This means that while their MX records probably work oversea’s, they will not be deliverable from China. They need to amend their MX records to Googles recommended settings.

Lets look at another example.

dig mx rsms-west.com

;; ANSWER SECTION:
rsms-west.com. 6238 IN MX 30 alt2.aspmx.l.google.com.
rsms-west.com. 6238 IN MX 10 aspmx.l.google.com.
rsms-west.com. 6238 IN MX 40 aspmx2.googlemail.com.
rsms-west.com. 6238 IN MX 50 aspmx3.googlemail.com.
rsms-west.com. 6238 IN MX 20 alt1.aspmx.l.google.com.

Once again, we can see that the alt3, and alt4 servers are missing, and unfortunately none of the other listed servers are connectable from China.

Lastly, lets look at a working server

dig mx teamsequel.com

teamsequel.com. 12878 IN MX 1 ASPMX.L.GOOGLE.com.
teamsequel.com. 12878 IN MX 5 ALT1.ASPMX.L.GOOGLE.com.
teamsequel.com. 12878 IN MX 5 ALT2.ASPMX.L.GOOGLE.com.
teamsequel.com. 12878 IN MX 10 ALT3.ASPMX.L.GOOGLE.com.
teamsequel.com. 12878 IN MX 10 ALT4.ASPMX.L.GOOGLE.com.

You can see that they have the correct Gmail settings as per Gmail / Google settings page, and mail to them is deliverable (as alt3, alt4 are currently not being blocked by the beneficent government of China).

Unfortunately as this is an issue that is out of our control (MX records are incorrect, and China is being difficult), we cannot mitigate against it. The affected domains will need to amend their MX records appropriately as per the page here- https://support.google.com/a/answer/33915?hl=en.

The Mercury MAC1200R (TPLINK WR6300) is one of the cheapest AC based routers on the planet, as I have a few AC devices I thought I’d buy one to try out. They’re available for under RMB120 or so online.

Mercury hardware is TPLink hardware, albeit using a different name. Same stuff, same factory, different casing.

The router has 64M ram, and 8M flash. CPU / Wifi AR9344 / QCA9882

OpenWRT says it has support, so I had a quick go at taking a look at flashing one.

First steps:

Open up the unit (remove the 2 screws underneath, then use a spare credit card or similar to jam open the plastic case).

The serial headers are to the right of the SoC.
You’ll need a rs232 to ttl or usb to ttl adaptor.

Pin 1 is GND
Pin 2 is TX (connect to rx)
Pin 3 is RX (connect to tx)
Pin 4 is VCC (don’t connect).

Port speeds are 115200,8,n,1

Connect up, and you should see a flurry of activity on boot.

To get into the bootloader (uBoot), you’ll need to type tpl
May take a few tries, so prepare to pull power and retry again, and again till you get in.

You’ll need a TFTPD server running on 192.168.1.100 to push files over. My Mac no haz ethernet (and Thunderbolt to Ethernet is crud), so I use my venerable X40 and tftpd software.

Firmware is up here. (Or you can compile your own) -> http://pan.baidu.com/s/1hqkVOfa

Firmware locations in flash (see below)
printenv
bootargs=console=ttyS0,115200 root=31:02 rootfstype=jffs2 init=/sbin/init mtdparts=ath-nor0:256k(u-boot),64k(u-boot-env),6336k(rootfs),1408k(uImage),64k(mib0),64k(ART)
bootcmd=bootm 0x9f020000
bootdelay=1
baudrate=115200
ethaddr=0xba:0xbe:0xfa:0xce:0x08:0x41
ipaddr=192.168.1.111
serverip=192.168.1.100
dir=
lu=tftp 0x80060000 ${dir}u-boot.bin&&erase 0x9f000000 +$filesize&&cp.b $fileaddr 0x9f000000 $filesize
lf=tftp 0x80060000 ${dir}db12x${bc}-jffs2&&erase 0x9f050000 +0x630000&&cp.b $fileaddr 0x9f050000 $filesize
lk=tftp 0x80060000 ${dir}vmlinux${bc}.lzma.uImage&&erase 0x9f680000 +$filesize&&cp.b $fileaddr 0x9f680000 $filesize
stdin=serial
stdout=serial
stderr=serial
ethact=eth0

Environment size: 686/65532 bytes

Upload to the uBoot

It should boot into OpenWRT, you can flash from there.


...[long kernel bootlogs redacted]

I highly recommend replacing the bootloader with an unlocked one.
i.e. this one – https://github.com/pepe2k/u-boot_mod

Bootloader sits at 0x9f000000 and is 64kb in size.
Suggest load in ram at 0x80060000 like they do, and flash from there.

eg from the bootloader –

tfpboot 0x80060000 uboot.bin
erase 0x9f000000 +0x20000
cp.b 0x80060000 0x9f000000 0x20000


Pray that it didn’t mess up (or you need an spi flasher…), and reboot!

Other bits n bobs –

You’ll need to adjust the opkg.conf file

ssh into the router @ 192.168.1.1 / root / root

mv /etc/opkg.conf /etc/opkg.conf.orig

#src/gz barrier_breaker_base http://downloads.openwrt.org/snapshots/trunk/ar71xx/packages/base
#src/gz barrier_breaker_management http://downloads.openwrt.org/snapshots/trunk/ar71xx/packages/management
#src/gz barrier_breaker_oldpackages http://downloads.openwrt.org/snapshots/trunk/ar71xx/packages/oldpackages
#src/gz barrier_breaker_packages http://downloads.openwrt.org/snapshots/trunk/ar71xx/packages/packages
#src/gz barrier_breaker_routing http://downloads.openwrt.org/snapshots/trunk/ar71xx/packages/routing
#src/gz barrier_breaker_telephony http://downloads.openwrt.org/snapshots/trunk/ar71xx/packages/telephony' >> /etc/opkg.conf

…and install Luci (the openwrt webui)

opkg update
opkg install luci


You should be able to visit http://192.168.1.1 and start changing settings.

Yet another SSL vulnerability has hit the news – the Poodle SSLv3 vulnerability.

Our servers are already patched against this (we’ve disabled SSLv2 and SSLv3 functionality, and use TLS).

You can check this on the 3rd party site here –

https://www.ssllabs.com/ssltest/analyze.html?d=mail.computersolutions.cn&s=211.144.68.16

Unfortunately this now means that Windows XP and IE6 are no longer supported.

Our rating from the SSLLabs checker is below.
Note that the A- rating is due to our certificate, not our security!

(We can only update that in 2016 when it comes up for renewal).

SSL negotiation in use on our server