Re-organized the forum to more cleanly delineate the development section, as the end user support side appears to have taken a life of its own!

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - krokos

Pages: [1]

I have got my hands on a Yi home camera that is basically a hi3518 based camera. I have root terminal access to it via telnet and it is already running an FTP server among other stuff, so I can easily copy files over to it.

The first lines of dmesg are like this:

Linux version 3.0.8 (rock07@Server) (gcc version 4.4.1 (Hisilicon_v100(gcc4.4-290+uclibc_0.9.32.1+eabi+linuxpthread)) ) #1 Wed Apr 30 16:56:49 CST 2014
CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
CPU: VIVT data cache, VIVT instruction cache
Machine: hi3518

So, I want to cross compile a simple "Hello World" C program for it. I downloaded the hi3518 SDK (v. and I can successfully run the compiler.

$ arm-hisiv100nptl-linux-gcc --version
arm-hisiv100nptl-linux-gcc (Hisilicon_v100(gcc4.4-290+uclibc_0.9.32.1+eabi+linuxpthread)) 4.4.1
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO

Then I wrote the simplest Hello World program I could think:
Code: [Select]
#include <stdio.h>

int main(void){
    printf("\n-----------\nHello, I am the Yi camera!\n-----------\n\n\r");
    return 0;

I am trying to compile it with the following command:
$ arm-hisiv100nptl-linux-gcc hello.c -o hello

I also tried to specify the architecture, with the same results:
arm-hisiv100nptl-linux-gcc -march=armv5 hello.c -o hello
And an executable called "hello" is created as expected.
As soon I transfer it over the camera and making it executable (just to be sure), I get an "Illegal instruction" thrown at me when I am trying to run it.
Illegal instruction

Any ideas on why this happens? It should be pretty much straight forward to run this. What am I doing wrong?

First it's important to verify that the browser you are using is not caching the User credentials making you ("Think") there is no requirement to use a User Id and Password for CGI commands like get_params.cgi. You can test this theory by purging your browser cache and trying the CGI command again to verify that in fact your current firmware has a security vulnerability allowing some or all CGI commands to be executed without any User credentials.

Additionally. It would be a good idea to make sure that your browser is NOT using stored user credentials for your IP Cameras. By both its local IP Address and DDNS/WAN IP Address.
sorry, i forgot to answer this in the previous post. The findings were verified with other browsers that i don't frequently use (opera, firefox) and also by using a TOR browser (proxy, no cookies, no cache). The screenshots in my blog post are made from a TOR browser for example. Last but not least, other users who never had any access to the camera, like Craig Russell who was kind enough to write an article about this, were called to verify the situation. Their findings were exactly the same.

I'll look into the https solutions you guys made in that other posts and comment there if i have any questions. Thanks for your time! :)

Hey Don, nice answer! :)

It's very true that plain http is a larger and more general problem here. Using an external server to broadcast the feed through a safe connection is a smart idea (i might try to implement it, if my cam supports upload via sftp) and inexpensive, however would require some "hassle" and time (not necessarily technical skill) something which wouldn't be so popular among the users.

By the way, I also have an AXIS network camera which does support safe connections and can actually enforce secure connections if the administrator chooses so. However that one costs around 10 times more than the Tenvis and is mostly oriented towards professional and industrial solutions. Do you have any models/brands in mind that are both inexpensive and provide such connectivity (ssl) options?

Finally, getting back on topic now, the same model with different firmware wasn't prone to these particular vulnerabilities, but considering the fact that i just bought it and that there are no firmware updates for my firmware version, means that there are many more people out there who are in danger.

Hey, I'd like to report a serious security vulnerability with a rather popular network camera by Tenvis, model "JPT3815W". I haven't tested if other models or firmware is affected as of now. My firmware is "version" and it's a 2014 model.

Long story short, it's very easy to access the live video feed from the camera without supplying any credentials. However, that's not the worst of it.

The problem, is that it's equally easy to get the wifi password of the network that the camera is installed in, along with its SSID! All the attacker needs is the camera's IP address (or the unique URL from Tenvis' DDNS).

For more details on how to reproduce that please check my article. I'm very interested in learning if this is a vulnerability shared among other models, firmware versions or even brands. Since we are talking about clones, their software is pretty much the same.
The chinese weren't so particularly impressed when i contacted them about this and simply replied "I’m afraid at present, we have no better way to protect customer’s privacy. Hope you can understand our difficulty."  :P :P :P ::)

Anyway, if you find the same vulnerability elsewhere, please report it here! :)

Take care!

Pages: [1]