[HINT!] Direct downgrade from firmware ver. 1.8.7.0C to ver. 1.8.6.1 isn't possible. You need to first downgrade to ver. 1.8.5.1 (I used 1.8.5.1K_201508311131), then upgrade to ver. 1.8.6.1
THE STORY
This last 14th July a friend of mine has appointed me to fix his camera Yi Home 720P model CN12 which all of the sudden, after an unintentional consent to the camera firmware upgrade, stopped to work.The camera would say “This camera can only be used in China” and would shut down.
I first tried the "old school" fix... which was to downgrade the camera firmware to one of the 2015 versions.
To my great dismay with none of the five, year 2015 (1.8.5.1 B to N), "region unlocked", original firmwares for CN model that I tried, the camera were able to connect to the given Wi-Fi network.(it took me hours of attempts to rule out the possibility that there was something wrong on the Wi-Fi settings or on the camera hardware, and that instead the failure on connecting to the Wi-Fi was only due to the firmware and Yi Home app versions in use. Grrrrrrrr )
Only with use of year 2016 firmwares (1.8.6.1 A to B) the camera were able to connect to the local Wi-Fi, but then the "region lock" were operative and the camera would shut down soon after saying "This camera can only be used in China".
That was the 1ST "NO GO".
I realized that the manufacturer have been able to prevent the use of old firmwares by changing the way the YI Home app encode the Wi-Fi ID and password in the QRcode. They implemented a new way that only the newer firmware versions were able to decode properly.
I then tried to search, find, download, install, try, some older version of the YI Home app, to see if I could get to have the camera connected to the Wi-Fi with a 2015 firmware running on it... after having tried about ten apps in vain, it turned out that it was all just another waste of time.
That was the 2ND "NO GO".
So, established that a firmware downgrade couldn't solve the problem, I started to search for any possible "hack" of a 2016 version firmware.
I first found the yi-hack-v4 (https://github.com/TheCrypt0/yi-hack-v4) which apparently could have contained a workaround to the "region lock" issue... I was going to give it a try when, by reading the Issues list on yi-hack-v4 Github page, I found one thread specifically related to the CN12 model (https://github.com/TheCrypt0/yi-hack-v4/issues/46).
By reading that thread I realized that the yi-hack-v4 was defenitely not compatible with the camera I was working on.
That was the 3RD "NO GO".
By going on reading the said thread I then learned of the existence of another "hack", the Fritz Yi-hack project (https://github.com/fritz-smh/yi-hack), which anyway wasn't a solution to the "region-lock" issue.
But, luckily, in the README of the Fritz Yi-hack project, the author had written a paragraph dedicated to the "models that are usable only in China" and there he provided the link to this web page https://diy.2pmc.net/solved-xiaomi-xiao-yi-ant-home-camera-can-used-china
The clever solution I found there was based on the use of a Telnet session to access the camera filesystem and doing the required modification.
Unfortunately, as my camera couldn't connect to the local Wi-Fi, it wasn't possible for me to start a wireless Telnet session.
That was the 4TH "NO GO".
Fortunately in that same page, the author has provided the link to the work of JonesChi which should have been able to perform the "hack" "off-line" without the use of a Telnet session and manually given commands... that was a great news for me... but... that solution was claimed to run only on camera with firmware version 1.8.6.1C.
I only had available the original CN version 1.8.6.1B_201603181307 (found here http://xiaoyi.querex.be/firmwares/) so I tried to find the "C" version... it turned out that finding that version wasn't easy at all.
After having checked dozens of sites, broken links, fake download, wrong firmwares versions, etc... I finally found one only download (this one https://drivers.softpedia.com/get/SCANNER-Digital-CAMERA-WEBCAM/XiaoYi/XiaoYi-Yi-Home-Camera-Firmware-1861C201605191103-CN.shtml) wich apparently was a valid 1.8.6.1C for CN cameras... yet using that firmware had made me feel very uncomfortable due to unknown and untrusted uploader which could have been someone who had hacked the firmware to open a backdoor and remotely access the camera video streaming... uhmmmmm.
Anyway, I took the risk and I installed the firmware on the camera, then copied the JonesChi scripts on the micro SDcard, inserted the card in the camera, switched on an waited for the "hack" to be automatically applied according to the author claim...
But... nothing happened! :-/
That was the 5TH "NO GO".
I couldn't understand what was actually going on, I wasn't even sure that the firmware I installed was actually version 1.8.6.1C as the name of the downloaded file isn't a sure proof of the file contents.
I decided to give a look at the shell script code that JonesChi wrote in factory_test.sh file saved inside the "test" folder...
The script was fairly simple; basically what it was supposed to do was just to rename the original cloudAPI file (which is a binary executable), make a backup copy of that file with name cloudAPI.bak in the SD card and copy a new cloudAPI file (which is a shell script) from the SDcard to the same location of the original cloudAPI file.
So, when the script is executed a new file cloudAPI.bak should appear in the SD card, but in my case that didn't happen!
Now, the question was... is the script executed but then something goes wrong so that the original cloudAPI file can't be copied to the SD card or... the script isn't executed at all?
I was in need to access the camera via a Telnet session to check the boot process and get some clues of why the "hack" didn't work.
As I already said above my camera couldn't connect to the local Wi-Fi, it wasn't possible for me to start a wireless Telnet session, I had to try to make a wired connection.
I remembered I had somewhere a very old (about 17 years old) Serial RS232 UART to TTL adapter which was an accessory of my Panasonic GD76 first Polyphonic GPRS mobile phone...
I then opened the camera casing, found the TTL serial port lines pads, identified the Rx and Tx pad, soldered a couple of wire, connect the wires to the UART to TTL adapter, connect the adpater to the computer serial port, downloaded the proper version of Putty terminal emulator, run the emulator, power on the camera and...
NOTHING! no go! it didn't work, nothing were displaying on the terminal emulator window... eventually the adapter I tried wasn't suitable for the use I was making of it.
That was the 6TH "NO GO".
I had no other choice than going back to the test script and trying to use it to get the information I needed and debug the execution.
After a few additions and modification to the script I found out that it wasn't executed at all... why? the filename factory_test.sh wasn't recognized as valid filename by the camera firmware.
I then renamed the script from factory_test.sh to equip_test.sh and, yes!, the script was executed... but then the camera went in a bootloop :-/
The script tries to make the “hack” modifications, then it reboot the camera... at the next boot the camera execute again the script, the script code checks if the “hack” has been applied or not, if not it repeat the modifications and the reboot...
So, for some reasons, the script commands to apply the “hack” were failing and therefore the script kept repeating the commands and rebooting in an endless loop.
Now I had to find out why the script commands to apply the “hack” were failing...
Using a various combination of Linux shell commands and redirection of the standard output to a file (and borrowing some commands from the script equip_test.sh, found in 1.8.6.1B_rtspfix.zip mod available here http://xiaoyi.querex.be/firmwares/ ) and repeating the cycle
"- cycle BEGIN
1) unplug the camera cable
2) remove the sd card from the camera
3) insert the sd card to the card reader connected to the PC
4) open the sd card and check the contents
5) edit the script
6) unmount the sd card
7) remove the sd card from the reader
8) insert the sd card on the camera
9) plug the power cable to the camera
10) wait for the boot to be completed till reboot
- cycle END”
dozens times, i I've finally been able to figure out what was the problem and to apply a fix.
Finally... “I DID IT!” :-D
The JonesChi script commands were failing because their source and target file were given with a wrong path (wrong for the case of the CN12 model camera I was working on).
The source file path was set to /home/app while the correct one was /home... and the destination file path pointing to the SD card was set to /tmp/sd instead of /home/hd1.
Moreover, as the camera boot process halts after the complete execution of the script, then the script must be renamed or deleted after its first execution, when the "hack" is applied.
Once I fixed the script and the “hack” have been applied, the camera was finally running on firmware 1.8.6.1B and free from the “region-lock/region-ban” restriction.
THE SOLUTION
For convenience of whoever found this page in search of a solution that works on a CN12 camera here below is the modified version of the JonesChi script that works on that camera.
Just replace the text in /test/factory_test.sh with the following and rename the file to equip_test.sh [ATTENTION! In Windows you need to use a text editor that can keep the Unix line endings (LF) when saving the file. See here http://wiki.secondlife.com/wiki/How_to_avoid_DOS_line_endings_in_Windows_tools]
Hope this helps! :)
P.S. Many thanks to Csaba Peter for his findings and clever solution and the article he published on this page https://diy.2pmc.net/solved-xiaomi-xiao-yi-ant-home-camera-can-used-china/.
All the best!
#!/bin/sh
# JonesChi's script.
# Modified by halnovemila (HalEx) to work on CN12 model
timestamp=`date`
sdcarddir=`dirname $0 | sed -n 's/\/test//p'`
testdir="${sdcarddir}/test"
logfile="${testdir}/hacklog"
echo "Current dir= ${testdir}" >> $logfile
echo "SDcard dir= ${sdcarddir}" >> $logfile
cat /home/version >> $logfile
echo "========== LIST OF /home ============" >> $logfile
ls -l /home >> $logfile
if [ -f /home/cloudAPI_real ]
then
echo "Already hacked ${timestamp}" >> $logfile
sync
else
echo "Start hacking ${timestamp}" >> $logfile
cp /home/cloudAPI $sdcarddir/cloudAPI.bak
mv /home/cloudAPI /home/cloudAPI_real
cp $sdcarddir/cloudAPI /home/cloudAPI
echo "Done hacking ${timestamp}" >> $logfile
# fix bootcycle
mv $testdir/equip_test.sh $testdir/equip_test.sh.moved
sync
reboot
fi
# ATTENTION!
# Once the script is executed the boot process is halted,
# nothing else will be executed.
# Therefore if the hack has been already applied
# and this script executed,
# the camera will not complete the boot process
# and will seem like if it's not working.
# JonesChi's script.
# Modified by halnovemila (HalEx) to work on CN12 model
timestamp=`date`
sdcarddir=`dirname $0 | sed -n 's/\/test//p'`
testdir="${sdcarddir}/test"
logfile="${testdir}/hacklog"
echo "Current dir= ${testdir}" >> $logfile
echo "SDcard dir= ${sdcarddir}" >> $logfile
cat /home/version >> $logfile
echo "========== LIST OF /home ============" >> $logfile
ls -l /home >> $logfile
if [ -f /home/cloudAPI_real ]
then
echo "Already hacked ${timestamp}" >> $logfile
sync
else
echo "Start hacking ${timestamp}" >> $logfile
cp /home/cloudAPI $sdcarddir/cloudAPI.bak
mv /home/cloudAPI /home/cloudAPI_real
cp $sdcarddir/cloudAPI /home/cloudAPI
echo "Done hacking ${timestamp}" >> $logfile
# fix bootcycle
mv $testdir/equip_test.sh $testdir/equip_test.sh.moved
sync
reboot
fi
# ATTENTION!
# Once the script is executed the boot process is halted,
# nothing else will be executed.
# Therefore if the hack has been already applied
# and this script executed,
# the camera will not complete the boot process
# and will seem like if it's not working.
