Progress with Yi Dome Camera (White)

[felixekman]

In short, what we need to find is someone who can compile the RTSP-server to work with the platform and someone who can possibly give some input to telnetd or ssh/dropbear as the busybody built in is to limited to run.

---

So I have a full dump of the flash for the Yi Dome (not 1080p). As people have mentioned the firmware files provided by Yi only update "home" which is related to the cloud services and other Yi services. It does not touch the busybox system or auxiliary at all.

I've also found the current busybox distribution on the cameras severely limited as many functions are not there including telnet. I've tried to replace the entire system with my own compiled version of busybox with no success/fails to boot and drops to U-boot. Same with any form of RTSP server. So if anyone can compile for the chips mentioned above I could give it a try.

For anyone exploring that does not want to fiddle with soldering leads to TX/RX pins. I can say that I've noticed that the system looks for /test/factory_test.sh on the SD card at boot. So a similar non-intrusive hack as this was originally should be possible as well. The camera also looks for these files at boot. u-boot_v201 env_v201 conf_v201 kernel_v201 rootfs_v201 home_v201

For people who want to dump the entire flash of the camera this is the pattern of the SPI flash that I found. mtd0: 00040000 00010000 "boot" mtd1: 00010000 00010000 "env" mtd2: 00010000 00010000 "conf" mtd3: 00190000 00010000 "os" mtd4: 00140000 00010000 "rootfs" //BUSYBOX mtd5: 00cb0000 00010000 "home" //The "Yi" part - what is touched by the firmware updates. mtd6: 00010000 00010000 "vd1" mtd7: 00010000 00010000 "ver

So if anyone as questions/suggestions, drop a line here and I'll se what I can help with. Because I also really want to get this thing working. As for region block, I have a EU/US version so I haven't seen that issue. But I can see that functions dispatch and cloud does check for region and ban.

/////More data dump if it helps anyone:

Booting kernel from Legacy Image at 81000000 ... Image Name: 7518-hi3518c-kernel Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 1384824 Bytes = 1.3 MiB Load Address: 80008000 Entry Point: 80008000

Linux version 3.4.35 (chenshibo@ANTS-SH-SV02) (gcc version 4.8.3 20131202 (prerelease) (Hisilicon_v300) ) #1 Wed May 25 19:18:17 CST 2016

CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177 Machine: hi3518ev200

Kernel command line: mem=22M console=ttyAMA0,115200 root=/dev/mtdblock4 rootfstype=jffs2 mtdparts=hi_sfc:256k(boot)ro,64k(env),64k(conf),1600k(os),1280k(rootfs),12992k(home),64k(vd1),64k(ver)

ominivision ov9732 sensor 720P30fps

/////

[burwdk]

This looks to be the same CPU as in the YI 1080P HOME CAMERA with 2.0 firmware, US version.

Processor : ARM926EJ-S rev 5 (v5l) BogoMIPS : 269.10 Features : swp half fastmult edsp java CPU implementer : 0x41 CPU architecture: 5TEJ CPU variant : 0x0 CPU part : 0x926 CPU revision : 5

Hardware : hi3518ev200

Just like you said, there is no telnet either. So far the only way to access is via the 3 pins and USB TTL.

[ygator]

@felixekman Some things in regard to busybox:

1. Did you try running busybox to see what functions it has, because maybe they just did not create the links.
2. Try using busybox from Yi Home Camera and see if that works
3. You could just cross compile a new busybox

[xcray]

@burwdk Another way is factory_test.sh in SD card/test directory. The camera will look for and load it on startup. With this method, all the partitions could be dumped to SD card with dd command. @ygator I'd tried on yi 1080p camera (not version 2, it's an update to the 720p type). It don't have telnetd included. With the busybox from 720p, telnetd cound be loaded and telnet access in works fine, but the rootfs and home partitions had been damaged and the camera fell into continues reboot. Thus the only choice is to cross compile a new busybox.

[shadow-1]

@xcray I accidentally corrupted my rootfs (libuClibc is damaged). Luckily I did backup my partitions before mucking around with the camera. Can you give me some advise on how to restore a partition on the camera?

On the other hand, since I got the proper SDK for this camera chipset, I have successfully cross compiled busybox. For the build I created, I statically linked the c library so busybox doesn't have any dependencies (although a relatively large file size).

Unfortunately I didn't transfer this version of busybox to my camera before damaging rootfs. Otherwise I probably could have repaired the OS easily.

[xcray]

@shadow-1, I guess you'd backup the rootfs with dd if=/dev/mtdblock4 of=/tmp/sd/backupofrootfs, then just put your backup file on SD card, and use the dd command to restore: dd if=/tmp/sd/backupofrootfs of=/dev/mtdblock4 sync halt pls pay attention to the path of backup file and mtdblock device number of rootfs partition. perform the commands via serial port is preferred, or you can use the sd card/test/factory_test.sh method.

I'm looking forward to your test result of busybox.

[shadow-1]

@xcray Thanks for the tips. It will come in handy in the future! Unfortunately I can not boot my system at all (kernel panic on boot) as my problem is with uClibc. From the boot log, it looks like U-Boot automatically looks for recovery images on the microSD card. The files have to be named: _u-boot_h20 env_h20 conf_h20 kernel_h20 rootfs_h20 homeh20

One file per partition, my guess is that if you have the appropriate file on the microSD card, U-Boot will either automatically write to the partition onto the cameras flash memory or it will mount the partition from the microSD card.

Alternatively, one could find a way to interrupt U-Boot and enter the appropriate commands manually. I have not been successful in interrupting U-Boot and getting to the command line so far.

I tried placing my backup file on the microSD card and named it rootfs_h20. Upon bootup I get an error message: _reading rootfsh20

_magic 0x85190320 0x27051956 arch 0x0 0x2 size 0x851901e0 0x40 type 0x0 0x2 crc 0xc name Image rootfsh20 bad MAGIC or ARCH

---

And now I realise that I did a backup of /dev/mtd4 rather than /dev/mtdblock4. I'm not sure if that would be a reason why the recovery image is failing. It still mounts properly on my Linux machine.

@xcray Would you happen be able to share your rootfs backup from your camera? I have a Yi Dome 1080p (Black), although the normal Yi Dome 720p (White) is almost the same hardware and rootfs is likely to be compatible between the two models and at least allow me to boot.

[xcray]

@shadow-1 backup of /dev/mtd4 and /dev/mtdblock4 are absolutely same, so don't worry, your backup file is right. But if you just rename it to rootfs_h20, it doesn't work as you mentioned, the reason is that the official update file is encrypted, while the backup file from dd command is NOT. So, the best way to restore is dd command. You can try the reset button on the rear and then check if it could boot to Linux shell interface. Or, try to get a flash programmer and connect to the flash chip directly. My yi 1080p home camera can't get into uboot command interface either, due to the timer has been set to 0 by the manufacturer. Unfortunately I don't know how to modify this timer now (maybe it's stored in the env partition. Anyhow, I really don't think backup file from a different type is a good idea. attachment is the backup of rootfs of yi 1080p home camera (update of version 1, with Hi3518E chip), the size is 1280k, just for your reference. 4rootfs.zip

[shadow-1]

@xcray Thanks a lot for the confirmation with regards to /dev/mtd4 vs /dev/mtdblock4! I have managed to restore rootfs on the camera through this automated restore file.

You are absolutely correct that official update file is encrypted. I have shown how to decrypt it in another thread. The official update file is quite simply an archive with update files that reside within the /home directory. There is a script on the camera that unpacks the update file, decrypts the file (RSA public key appears to be packed with the firmware file), extracts the archive and uses rm and cp to copy the files from the archive and replace the files within /home. It's not really a firmware file at all.

In knowing this, I found it very hard to believe that U-Boot would be capable of such sophisticated methods of protection of firmware files. Also note that the official update file is named home_h20m whilst U-Boot is looking for a file named home_h20.

I studied the documentation that came with the HiSilicon Hi3518e SDK. U-boot that HiSilicon provides support for automatic upgrading of the firmware and details how to create the firmware files. The JFFS2 filesystem is required to be wrapped with mkimage using the legacy image method. The example on wrapping the rootfs filesystem in the SDK is as follows:

_mkimage -A arm -T filesystem -C none -n hirootfs -d rootfs256k.jffs2 rootfs

I tried this whilst changing the output filename to rootfs_h20. I also named the image rootfs as that seemed more logical.

Unfortunately Xiaomi implementation of U-Boot is a bit customised compared to the generic provided in the SDK. This didn't work and gave an obscure error message that didn't make much sense to me at the time.

_Image rootfsh20 wrong type, not has hi3518

After a bit of experimentation, thinking what the error message could refer to, looking at the other partitions. I worked out that the error message refers to the name of the image!

Wrapping the rootfs partition with the following command:

_mkimage -A arm -T filesystem -C none -n hi3518-rootfs -d mtd4 rootfsh20

Copied the resultant file onto the microSD card and upon boot. U-Boot wrote the rootfs partition on the camera from the upgrade file.

The camera is now restored!

---

By the way, it appears that the U-Boot timer is set in the env partition.

[xcray]

@shadow-1 Congratulations! and Thanks for your comments. This is a very important guide for really firmware update. And more and more possibility will come with the non-official rootfs and home partition. It seems that I was wrong on the reason of "bad magic or arch", it's not encryption? Thus the home partition could also be modified and upgrade without encryption?

[xmflsct]

Yep, when I simply open the env dump with a text editor, I see the bootdelay=0 in plain text..

[death2all110]

This is awesome. I wonder if the Yi Home Cam 720p has similar implementation!

[shadow-1]

@felixekman Do you mind sharing the dump of your Yi Dome (white)?

I have had a few requests to create a custom firmware that is compatible with the Yi Dome (white). However as I don't have this camera, I can not create a compatible firmware without a dump of the system.

At the moment, I do not have RTSP server working. However I know @xmflsct among others is working hard on getting RTSP server working on the Yi 1080p Home which uses the same chipset as the Yi Dome (white).

The latest efforts are detailed in the link below: https://github.com/xmflsct/yi-hack-1080p/issues/5

Unfortunately I won't have time to develop much in the next few weeks.

[shadow-1]

@death2all110 After looking at serial logs posted by others. Yi Home 720p does have a similar implementation.

[saundersrg]

Hoping I'm not resurrecting something that has been answered elsewhere. I've got the Dome 1080p, and I'm trying to get this going. Try as I might with all sorts of methods (and between all the different GitHub projects for this) and I cannot get it to load anything in the /test/ folder.

I'm assuming from reading that the firmware I have needs to be home_h20 for this camera (not home as per other projects), and restoring the rescue from @shadow-1's project works like a charm, but it will not read the test folder. I'm not concerned about having the phone app work (sorry shadow-1, your work is epic though!), I just want RTSP for Zoneminder. But try as I might I cannot get it right. Am I missing something blatantly obvious? Should I be using a firmware other than the recovery from yi-hack-v3, perhaps from the other folders in box?

It's currently showing firmware 1.9.2.0C_201611011902.