[SOLVED] Xiaomi Xiao Yi HOME CN12 – This camera can only be used within China

[UPDATE!] 2019 08 06: The provided fix works also with the latest firmare ver. 1.8.7.0C_201705091058

[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.  

Controllo volume (mute) indipendente per applicazione su Windows XP

A partire con Windows Vista, Microsoft ha introdotto nei suoi sistemi operativi il controllo del volume indipendente per ciascuna applicazione.
Mi meravigliavo di quale potesse essere il vantaggio di avere un controllo volume per ciascuna applicazione a livello di sistema operativo, dato che normalmente le applicazioni che riproducono audio hanno il loro proprio controllo del volume.
Ma, a parte le applicazioni che fanno uso dei suoni di notifica di sistema che sono sempre riprodotti al massimo del volume master di sistema (il chè potrebbe anche far "spaventare" se succede che un suono di notifica viene emesso quando hai il volume master e quello degli altoparlanti impostati al massimo per poterti godere della musica o un video con un basso livello del segnale audio) , al giorno d'oggi è abbastanza probabile che capiti di aprire una pagina web che automaticamente comincia a riprodurre un qualche audio, di solito pubblicità, del quale non è immediato e facile identificare la sorgente all'interno della pagina e fermare la riproduzione, e alcune volte non è nemmeno disponibile un controllo volume o un pulsante mute.
Pertanto quando si ha accheffare con suoni di notifica (come quelli usati da Facebook, Skype, e molti altre applicazioni di messaggistica istantanea) e pagine web "maleducate", avere a disposizione un controllo volume indipendente per ciascuna applicazione è una comoda soluzione.
Quindi, bene per chi sta usando le versioni più recenti dei sistemi operativi Windows, ma come fare per i molti che ancora stanno usando Windows XP per una delle molte ragioni che ancora rendono un opzione non conveniente l'aggiornamento del sistema operativo?
La soluzione più semplice è acquistare una copia di IndieVolume (http://www.indievolume.com)  al costo di $24,25.
Ma se non hai veramente bisogno di un controllo volume indipendente per ogni applicazione, ed è abbastanza avere un browser Internet "muto" mentre le altre applicazioni o browser possono comunque riprodurre suoni e audio, allora io ho trovato una soluzione, gratuita, che sto per condividere con te... seguimi! ;-)

Per prima cosa scarica ed installa Virtual Audio Cable (http://software.muzychenko.net/eng/vac.htm).
Al momento l'ultima versione è la 4.14 ed è disponibile gratuitamente solo in "modalità prova" (che è quanto basta per lo scopo qui); clicca qui per scaricare la versione di prova.
Per avere la versione funzionante senza le limitazioni della "demo", bisogna pagare $25,25 di licenza (clicca qui per acquistare).
(Ci deve ancora essere qualche vecchia versione in giro per Internet o in qualche rete di file-sharing. Per quanto ne so la vecchia versione 4.10, sebbene contenente vari errori, era ancora una versione completa e freeware; io la uso dal 2011).
Una volta installato Virtual Audio Cable, una scheda audio virtuale, chiamata "Virtual Cable 1", è aggiunta al sistema.
A meno che lo strumento Audio Repeater (che appartiene all'installazione di Virtual Audio Cable) non sia in esecuzione, tutto l'output audio di qualsiasi applicazione che vada su "Virtual Cable 1" non è riprodotto attraverso la reale scheda audio hardware collegata agli altoparlanti, quindi l'output audio dell'applicazione è come "ammutolito".

Quindi, per avere un'applicazione "ammutolita" abbiamo solo bisogno di fare in modo che il suo output audio sia inviato alla scheda audio virtuale "Virtual Cable 1".

Molte applicazioni, come i browser Internet, non permettono di scegliere quale sia il dispositivo audio a cui l'applicazione deve inviare il proprio output audio; semplicemente l'applicazione userà il dispositivo predefinito nel sistema che troverà nel momento in cui viene avviata.

Quindi, il punto chiave è di impostare "Virtual Cable 1" come dispositivo audio predefinito del sistema PRIMA di avviare l'applicazione che noi vogliamo "ammutolire".
Il modo più conveniente per farlo è di installare e usare un piccolo programma di utilità chiamato STADS (System Tray Audio Device Switcher).
STADS è un programma che permette di passare facilmente da un dispositivo audio ad un altro semplicemente con un click destro sulla sua icona presente nell'angolo dello schermo (system tray icon) evitando di dover usare e passare per il pannello di controllo di Windows. Verrà visualizzato un elenco dei dispositivi audio disponibili da cui è possibile scegliere quello che sarà impostato come "predefinito", e se si clicca su "Show Recording Devices" permette di selezionare il dispositivo di registrazione predefinito.

STADS può essere scaricato da questa pagina web ricca di informazioni: https://www.raymond.cc/blog/easily-change-or-switch-the-default-audio-sound-output-in-windows-vista-and-xp

Quindi, mettiamo che voglia guardarmi un video su Youtube ma non voglio essere infastidito dai suoni di notifica di Facebook o altri suoni che potrebbero improvvisamente partire mentre sto navigando; diciamo che ho sia Mozilla Firefox che Google Chrome installati e che Chrome è il mio browser Internet preferito.
Userò Firefox per riprodurre il video su Youtube e "ammutolirò" Chrome.

Prima di aprire il browser Chrome userò STADS per impostare come dispositivo audio predefinito "Virtual Cable1", quindi aprirò Chrome... fatto! :D
Ora Chrome invierà tutto il suo output audio al "Virtual Cable 1", così nessun audio verrà effettivamente inviato agli altoparlanti o alle cuffie.
Una volta che l'applicazione "ammutolita" è aperta/in esecuzione, non dimenticare di reimpostare nuovamente il dispositivo audio hardware come predefinito di sistema, altrimenti tutte le altre applicazioni che verranno aperte successivamente saranno anch'esse "ammutolite".
Tieni presente che se l'applicazione "ammutolita" viene chiusa, all'avvio successivo essa userà come dispositivo audio quello che troverà impostato come predefinito nel momento dell'avvio.

Abilitare automaticamente l'ICS sulla connessione attiva

Se hai visitato la pagina Web che riporta le istruzioni per ottenere un sistema in grado di condividere automaticamente una qualsiasi connessione Internet attiva, e hai domande da porre o commenti da fare, sei invitato ad usare il link sottostante ("Posta un commento")

Grazie

Halnovemila

DUTraffic_Reset&Run: una soluzione per chi naviga con 3

Coloro che sono clienti Tre e usano l'opzione "dati" Naviga 3 30 giorni, Naviga 3 7 giorni, Tre.Dati, Tre.Dati Plus, hanno solitamente un problema da risolvere: evitare che, durante la navigazione, si possa accidentalmente superare la soglia del traffico disponibile.
Se è abbastanza facile trovare un programma in grado di monitorare il traffico "consumato" (la stessa 3 ne fornisce uno), non altrettanto facile può dirsi trovare un programma che in automatico interrompa la connessione Internet non appena raggiunto il limite del traffico utilizzabile.
Io, ho sviluppato una soluzione personalizzata, un programma di tipo script, che agendo in combinazione con il software DUTraffic, è in grado di rispondere a tutte le esigenze di chi, come me, è un abituale fruitore della connessione dati con traffico prepagato offerta da 3.
Il programma, che ho chiamato DUTraffic_Reset&Run, fornisce le seguenti funzioni:

• consente di impostare la disconnessione automatica al superamento di una determinata soglia di traffico giornaliero o mensile.
• permette di modificare il valore dei contatori (è possibile, quindi, allineare il valore misurato da DUTraffic con quello letto nell'Area Clienti di 3; particolarmente utile quando la connessione Internet viene usata anche per navigare dal "telefonino")
• distingue le connessioni Dial-Up e non mescola il traffico effettuato con una connessione con quello effettuato con un'altra (utile quando si dispone anche di una connessione Internet alternativa).
• consente di usufruire del traffico disponibile anche al superamento della mezzanotte.
• consente di impostare una data di scadenza superata la quale viene impedito l'uso SOLO della connessione Internet soggetta a soglie.

in più DUTraffic_Reset&Run.vbs, essendo uno script, ha questi vantaggi intrinseci:

• è Open Source, e chiunque può leggerne il codice ed eventualmente correggerlo o migliorarlo.
• può essere modificato per rispondere ad altre esigenze (come quella di impostare un limite di tempo anzichè di traffico).
• non richiede installazione.
• è piccolissimo (occupa 95Kbyte).

Per maggiori informazioni: http://www.controsensi.it/DUTRR/DUTRR.html

Chiunque voglia lasciare un commento su questa mia realizzazione può farlo qui.

CPU Multiplier and HT/RAM ratio finder

A questo indirizzo http://www.controsensi.it/A64_Multipliers_Finder/A64_Multipliers_Finder.html, è disponibile una tabella di calcolo interattiva, che ho personalmente realizzato con lo scopo di identificare velocemente quali combinazioni di Moltiplicatore CPU e Rapporto HT/RAM consentono di ottenere le frequenze di CPU e RAM desiderate per una determinata velocità di clock dell'HT, su di un PC con processore Athlon64.
Una volta inserite le frequenze massime e minine di CPU e RAM nell'apposito riquadro in basso a sinistra, basterà far scorrere il cursore del clock dell'HT; le combinazioni che daranno i risultati ricercati verranno automaticamente evidenziate in giallo!

I valori in blu dei rapporti HT/RAM sono stati impostati prendendo come riferimento quelli utilizzati dalla scheda madre Asus A8V; mentre i moltiplicatori e i divisori (D1), sono quelli di un Athlon64 x2 4200+.

I valori della colonna D2 (Rapporto CPU/RAM) sono calcolati secondo la formula:
D2=(Moltiplcatore CPU / (rapporto HT/RAM)) arrotondato all'unità intera superiore.

Per aderenza alle impostazioni del BIOS della A8V la formula è stata modificata così:
((Moltiplcatore CPU / (rapporto HT/RAM))*2) arrotondato all'unità intera superiore.
Ad esempio: 8.5*2/(3:2) = 12

La velocità della RAM è cacolata così: RAM Clock=CPU Clock/D1
Si ricorda che le RAM DDR raddoppiano il clock di base, pertanto per le DDR400 il clock di base è di 200MHz.

Nella Asus A8V non tutti i valori reali (inseriti nelle colonne D1) corrispondono a quelli calcolati (D2), pertanto la tabella calcola la velocità della RAM utilizzando il divisore contenuto nella colonna D1. Il valore D2 viene utilizzato per il calcolo solo quando D1 è assente.

Chi volesse sperimentare altri valori di Moltiplicatore CPU,Rapporto HT/RAM, Rapporto CPU/RAM può agire sulla tabella modificando qualsiasi dei numeri di colore blu.

Il pulsante "Mode" consente di cambiare il comportamento della tabella per adattarsi al modo in cui i BIOS di schede madri diverse dalla Asus A8V riportano i valori dei rapporti HT/RAM e delle velocità di clock della RAM.

Chiunque voglia lasciare un commento su questa mia realizzazione può farlo qui.