How to fix Xiaomi YI Home Camera “This Camera can only be used within China”?

on February 25th, 2017 by Hades | 1 Comment »

Recently I bought a Xiaomi Xiao Yi (IP) camera (also known as Yi Home), Chinese version. The camera looks nice, a picture quality is ok, and worked fine on my local Wifi.

However, I was unfortunate enough to receive and test the camera when Xiaomi decided to deny access from the iOS app to the camera outside of China (error 5400). I was hoping a firmware upgrade would solve this issue so I have upgraded from to Now my camera was useless. The camera would say “This camera can only be used in China” and would shut down.

This was the tipping point when I have decided I will investigate what’s happening with this camera and what can be done to make it functional again. At the time of writing the remote access (error 5400) has been solved by the provider so no additional action is required. (I tried to convert a CN camera to international one by changing the serial of the device, but couldn’t test from a European or US IP and probably I would have needed access to the system files  of a functional international camera to compare)

So the remaining issue was the camera shutdown with the latest firmware (tested with and

If you do a search there are heaps of websites describing how you can gain access to the camera and ultimately enable remote access via telnet. I won’t get into those details, you can check some of, websites I listed below.

Once you logged into the camera via telnet the fun part begins.  The camera is running a Linux version.

Welcome to HiLinux.
None of nfsroot found in cmdline.
# uname -a
Linux (none) 3.0.8 #1 Wed Apr 30 16:56:49 CST 2014 armv5tejl GNU/Linux

This is familiar territory, we can check what processes are running, log files, the /home directory and we can mess around with the system. I have to mention this is for educational purposes only and you can easily brick your camera.

Back to the “This camera can only be used in China” message. So if you look carefully in the log file “/tmp/log.txt” at some point you will see the forbidden.g726 sound being played and not long before that there is an API call to the mothership to check if you device is allowed to run on not. With this call, the camera sends your IP automatically so there is not much to be done about that.

[/home/cloud][4/29/22:51:48:52]: req_info=

Now the nice thing about this is that we can fake the response from the server in many different ways.

1. You set up a proxy to be used and the proxy will change the reply from “allow”: false to true.  The certificate on the camera can be changed so you can set up a valid proxy for https request for a man in the middle attack. (/home/ca.crt). Possible but too complicated and you need a proxy running.

2. You can set up a fake response on the camera via the local HTTP server and redirect (see point 3 ? ) the check_did call to this file. (/home/web/response.json -> {“allow”:true,”code”:”20000″}). Again possible but not really needed.

3. And finally, we got to the solution. In the log files, we saw that /home/cloud is responsible to check the permission for our device. This is a binary file and we can check what calls are made from this file:

# strings /home/cloud | grep http
%s -c 311 -url -uid %s -keySec %s
%s -c 139 -keySec %s -url -uid %s -version %s -mac %s 
/home/cloudAPI -c 301 -url ""
%s -c 140 -url -uid %s -version %s 
/home/curl http://%s/cgi-bin/luci/api/xqsystem/init_info | grep routerId | wc -l
%s -c 141 -url -keySec %s -uid %s -version %s
%s -c 304 -url -uid %s -keySec %s -EventTime %lu -EventStat %s -pic_url "%s" -video_url "%s" -pic_pwd "%s" -video_pwd "%s"
%s -c 138 -key %s -keySec %s -url -uid %s -version %s -mac %s -packetloss %d -p2pconnect %d -p2pconnect_success %d -tfstat %d 
%s -c 136 -url 
%s -c 310 -url -uid %s -vendor %s -timestamp %lu -token %s


Now if we change the call check_did to our local file mentioned above that would make /home/cloud happy and the camera will run. Luckily /home/cloud will lock your device just if the remote server replied with “allow”: false. Now all we need to do is to block that call or break/invalidate that URL (ie. DNS error).


Default login: root
Password: 1234qwer

# ps | grep /home/watch_process | grep -v "grep" | awk '{print $1}' | xargs kill -9
# ps | grep /home/cloud | grep -v "grep" | awk '{print $1}' | xargs kill -9
# sed -i  's||api.xiaoyi.cox/v4/ipc/check_did|g' /home/cloud
# reboot

First commands will kill watch_process so it doesn’t restart other processes.
The second command will stop the cloud service, so we can change the file.
The third one will change the text in the binary file. It will change com to cox which will invalidate the url and will not return the allow: false message anymore.

Once the camera reboots it will be functional just as before you upgraded to the latest firmware. In case anything goes wrong just install a fresh, unmodified firmware.

Drop me a line if this worked for you!

Update: Read the comments for CNxx160622 hardware with FW or

Serial port connection to the camera explained in this video (credit to fedeant):

{Leave a response }

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.