search

roleoroleo / yi-hack-MStar

Custom firmware for Yi 1080p camera based on MStar platform
GNU General Public License v3.0
849 stars 112 forks source link

Possible to support Kami Outdoor camera #220

Closed xannor closed 4 years ago

xannor commented 4 years ago

I recently purchased one(now two due to mistakes I had made) Kami Outdoor cameras. The look very similar to the Yi Outdoor, are made by the same company, have a different firmware number 4.7.0, but are a 9FUS QR code, and it seems an MStar processor. They have no telnet capability, but I managed to use a modification of your backups scripts on the allwinner to do some querying of the os, and I could run the busybox binary I managed to extract from your y203c build. I tried busyboxes from the allwinner and from v4 but they didnt execute. If I provided you the root and home images, is it possible you could make a hack build for this camera?

roleoroleo commented 4 years ago

I don't know it it's possible to make a hack but I could look into this.

xannor commented 4 years ago

Thank you for giving it a go. Here are the mtds for the root and home (from your helpful backup script) for the "latest" firmware mtdblocks.zip. If there is anything else you need me to pull off of the camera let me know.

I used "latest" in quotes because the camera actually shipped with a higher version number but the Kami Home app wanted to "upgrade" to the current version. I have a backup of both.

roleoroleo commented 4 years ago

Yes, I think it's possible to try to build a hack. But the file system is not so equal and we need a lot of work.

EDIT

Another problem. rootfs is a squashfs image and not a jffs2.

xannor commented 4 years ago

Please pardon my ignorance about this, but why does the rootfs need to be writable? Or is it an issue with creating a properly sized squashfs with any files you need to replace?

If you need more info on the running state of the device, let me know what commands to attempt, or if you know where I can get a telnetd binary that would work I can try to get it running on one and then relay any results to you, otherwise I will have to keep pulling the sdcard and running the config.sh script.

roleoroleo commented 4 years ago

This problem increases the differences between the projects. And it increases the work to make a hack. Probably it's necessary to create a different project.

xannor commented 4 years ago

Ok, if it looks like it is not that strait forward I can try to use the Docker to create a custom build. I am just not that familiar with the process/system so I felt it would be faster to ask first.

roleoroleo commented 4 years ago

The expensive part is to arrange partitions, processes start, scripts and testing. If you want to build programs and run them "only" I could help you.

xannor commented 4 years ago

I got a little way into modifying the hack, Im having an issue with compiling, it is throwing a missing file error during onvif_srvd in I think gsoap-2.8.

gcc -DHAVE_CONFIG_H -I. -I..      -DWITH_NO_C_LOCALE   -DLINUX -DWITH_OPENSSL -DWITH_GZIP -DWITH_DOM -DWITH_COOKIES -g -O2 -MT libgsoapssl_a-stdsoap2_ssl.o -MD -MP -MF .deps/libgsoapssl_a-stdsoap2_ssl.Tpo -c -o libgsoapssl_a-stdsoap2_ssl.o `test -f 'stdsoap2_ssl.c' || echo './'`stdsoap2_ssl.c
In file included from stdsoap2_ssl.c:65:
stdsoap2.h:941:11: fatal error: openssl/bio.h: No such file or directory
  941 | # include <openssl/bio.h>
      |           ^~~~~~~~~~~~~~~
compilation terminated.
make[5]: *** [Makefile:650: libgsoapssl_a-stdsoap2_ssl.o] Error 1

I am using the borodiliz docker so I dont know if it is a missing dep on it or something missing from the submodule --init, I have not done a lot of linux build so I dont know much about dep structures.

Any suggestions?

Edit: Also it looks like openssl-1.0.2u downloaded and there is a symlink in the gsoap folder, a bio.h under it, and I see the -I. and -I.. in the GCC so i believe it should see the file.

Edit2: configure for gsoap says is cannot find openssl, I tried a few --with-openssl paths and it didnt work so I ran configure with --disable-ssl and it built. I am going to see how the rest of the compile goes. onvif is probably broken but I want to at least get to a basic build so I can figure out the filesystem.

Edit3: looks like the compile script is forcing WITH_OPENSSL, I see the parameter passed even when I added --disable-ssl to the Makefile.onvif_srvd

Edit4: I did not realize the gsoap library was built twice, once for onvif and once for wsdd, I modified its make file as well so we will see if that at least gets me to a "build"

xannor commented 4 years ago

I got it to the point where I can telnet in, I am trying to minimally modify the running OS to make recovery easier. I cannot run dropbear because it has a lib dep and I don't know of a writable place I can put it for it to pick it up. My initial thoughts are that the best approach is to, like you said, fork this as a new repo, and I think model the structure off of allwinner since that one does not replace root fs and it seems in this case the rootfs is a minimal root.

Unfortunately this is getting beyond my limited skill set though it has been quite a learning experience.

roleoroleo commented 4 years ago

The first problem to solve is to know how the native upgrade procedure works. For example:

If you are in the 1st scenario, you have to create a jffs2 image (like MStar fw), otherwise a tar.gz archive is enough.

About openssl issue try to ask @borodiliz or try to build it using a Debian 10. Or you can disable it, onvif_srvd will work without ssl but it will work. See the history: https://github.com/roleoroleo/yi-hack-MStar/commit/623feb7bdbcdedab5475d92c084fc7a5a9825a91#diff-abe1f2ef5760aa9adc2f6081e32dd782

gsoap is compiled twice, it's not the best approach but is simpler.

xannor commented 4 years ago

Looking at the extpkg.sh it extracts just a home compressed file (not a dd image) decomps and runs an update script. the update scripts seems to do the del/replace of the app base and ms folders. However I am fairly certain the bootloader will do a replace of the home image if home_h31 exists on the root of the sd because that is how I bricked my first camera, and using your backup.tar.gz from allwinner, made a backup of a second one and unbricked the first.

Mt best guess is that it is using the allwinner approach, at least going forward.

for openssl, I think the gsoap build is using the host openssl includes instead of the donwloaded ones, which in the borodiliz would fail because there is no host openssl dev package installed. I added in -disable-ssl to the makefile(s) and it builds, haven't gotten far enough along to test those binaries though.

I think next I will have to see how to adjust the dropbear build to not depend on libutil.so.1 being in /lib/arm-linux-gnueabihf, since the mstar build is based off of adding that to the rootfs.

roleoroleo commented 4 years ago

Looking at the extpkg.sh it extracts just a home compressed file (not a dd image) decomps and runs an update script. the update scripts seems to do the del/replace of the app base and ms folders. However I am fairly certain the bootloader will do a replace of the home image if home_h31 exists on the root of the sd because that is how I bricked my first camera, and using your backup.tar.gz from allwinner, made a backup of a second one and unbricked the first.

I think there are both procedures. The bootloader loads the images and extpkg loads a custom upgrade file (signed).

for openssl, I think the gsoap build is using the host openssl includes instead of the donwloaded ones, which in the borodiliz would fail because there is no host openssl dev package installed. I added in -disable-ssl to the makefile(s) and it builds, haven't gotten far enough along to test those binaries though.

Probably gsoap uses host openssl and onvif_srvd uses cross openssl.

I think next I will have to see how to adjust the dropbear build to not depend on libutil.so.1 being in /lib/arm-linux-gnueabihf, since the mstar build is based off of adding that to the rootfs.

I have to check if the toolchain is correct.

roleoroleo commented 4 years ago

Unfortunately the toolchain also is different. Yi is based on libc-2.19-2014.04 Your cam is base on libc-2.28.

xannor commented 4 years ago

I'm not that familiar with cross compiling and toolchains, does this mean a change to the parts your tools download or a change to the host build environment?

xannor commented 4 years ago

Given how much this is diverging from yours, I setup a repo to track progress and differences, feel free to close this and continue the discussion there.

roleoroleo commented 4 years ago

This means that the toolchain is different. gcc, g++, gdb, libc, etc... However, as it is based on libc (and not uclibc or musl), maybe the MStar toolchain might work.

After all, you said that busybox works...

xannor commented 4 years ago

Done some more reading and digigng and I think I know why things are a little different. It seems this is an Initinity6 Chipset, but I cannot quite match the version INFINITY6 SSC009A-S01A QFN88 I found some info on this site http://linux-chenxing.org/ but I cannot match this to the ones they list, though the kernel version does match 4.8.94. So I would guess it would need a new toolchain to build proper binaries.

roleoroleo commented 4 years ago

This is the toolchain: https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-a/downloads/8-2-2018-08 I think...

Probably "AArch32 target with hard float (arm-linux-gnueabihf)".

xannor commented 4 years ago

I will give it a shot when I next can and let you know the results

xannor commented 4 years ago

The toolchain seems to be working. I also managed to get dropbear runnable, I had to provide libutil and libcrypt as those are not present on the hardware. Now for the big leap and to see if I can make the proper modifications to your build process to build a viable hack image. Luckily it seems I can restore via my backup of the home partition so failure should not be detrimental.

xannor commented 4 years ago

I figured out part of the gsoap issue using with-openssl=@(CURDIR)/openssl will work, but now it also needs zlib.h (with a similar setup) , I found version 1.2.11 on the zlib.net site as the most recent since 2017, but I am not sure which one your environment is using to keep things consistent.

Also I noticed in the wsdd you did not include openssl again so I am assuming that one is building without ssl support so I am leavign the --disable-ssl in its gsoap makefile.

roleoroleo commented 4 years ago

I figured out part of the gsoap issue using with-openssl=@(CURDIR)/openssl will work, but now it also needs zlib.h (with a similar setup) , I found version 1.2.11 on the zlib.net site as the most recent since 2017, but I am not sure which one your environment is using to keep things consistent.

I don't remember that onvif_srvd depends on libz. Probably is the host version. In any case 1.2.11 is ok.

Also I noticed in the wsdd you did not include openssl again so I am assuming that one is building without ssl support so I am leavign the --disable-ssl in its gsoap makefile.

Yes.

wsdd doesn't need ssl to run.

xannor commented 4 years ago

I don't remember that onvif_srvd depends on libz. Probably is the host version.

gsoap checks for it and can compile with it and after I fixed the openssl issue I was getting a similar error about including zlib.h and dosing similar steps (and copying the process you used to build openssl) worked as well. might have something to do with the ssl portion because it does not come up in the disable-ssl version.

roleoroleo commented 4 years ago

gsoap is different from other components. It's the only software compiled with host gcc. If it checks for zlib it's the host part. Simply install zlib-dev on your host.

xannor commented 4 years ago

Ok, so host openssl-dev and zlib-dev are needed for gsoap, that explains some of the weirdness I have been seeing.

xannor commented 4 years ago

That fixed the gsoap issue, compiles without modification now. I got a build, now the fun of fixing up the firmware scripts.

xannor commented 4 years ago

At this point i'm going to close this issue here, I might ping you for help or questions on the other repo, but I dont want to clog up yours with now bascially unrelated issues.

RebeliusGaming commented 2 years ago

Did you get to make it work?

ihavetenfingers commented 9 months ago

Sorry fornopening a closed issue, but ive been tinkering around with these exakt cameras on the samw fw.

Using the fw files for 9fus does seem to be working, the sd card is updated with the completed folder, even the hostname changes to yihack, but they give no response on anything I've tried besides ping.

Anyone else having more success than me?