Help identify bricked PTZ camera

Joined
Aug 3, 2015
Messages
3,791
Reaction score
12,182
Location
Charlotte
No luck yet. If I add the init=/bin/sh to the bootargs in u-boot, then boot the camera, it boots, but I do not get a root shell, and the telnet port is no longer active, so it apparently doesn't like the init=/bin/sh. For the heck of it, I tried init=/bin/bash and the camera booted as though no init param was added. I'm running john the ripper now on the passwd file. The passwd file is the same on both the "bad" firmware and the new firmware supplied by the vendor. We will see in a couple days/weeks if I can crack the root password. If I can get in via telnet, I should be able to figure out what is going on.
I was concerned when your previous boot log didn't show the details of the console output. It looks like they're swapping/changing the output device away from the console port, precisely so the BOOTARGS trick won't work. :(

Have you run nmap against the camera's IP address, to see if any other ports are active?
 

vmsguy

Young grasshopper
Joined
Jul 27, 2016
Messages
30
Reaction score
1
I was concerned when your previous boot log didn't show the details of the console output. It looks like they're swapping/changing the output device away from the console port, precisely so the BOOTARGS trick won't work. :(

Have you run nmap against the camera's IP address, to see if any other ports are active?
The only other port I found open was 20203. Not sure what is running there, if I telnet to it, it just echos back keystrokes.
 
Joined
Aug 3, 2015
Messages
3,791
Reaction score
12,182
Location
Charlotte
What might be interesting is, if you changed that init= argument to init=/bin/telnetd and then see if you can at least find port 23 open for telnet access.

Scratch that idea, it doesn't appear telnetd is available as a utility/file.
 
Last edited by a moderator:

nayr

IPCT Contributor
Joined
Jul 16, 2014
Messages
9,329
Reaction score
5,325
Location
Denver, CO
@pal251, no idea..

@Vault, I entirely disagree.. when it comes to embedded devices like IP Cameras.. people should NEVER update to new versions when possible.. If its working as expected then by definition its not having issues.. this is not your PC you can just format and reinstall when it blows up in your face.. unless you know for a fact that an issue that is hurting your deployment has been fixed in a newer version, you are doing nothing but taking unnecessary risk by taking a device your perfectly happy with and updating it.. New Features, Bug Fixes and Security Updates? Lol, more than likely: Removed Features, More Bugs, and not a damn bit of attention given to security just like always.. If they were security updates we'd betting new firmware 2-3 times a month.. dont put these on networks where they need local security and you wont have any need for security updates.

Ive never updated the firmware on any of my cameras, they all worked as expected.. and gladly continue to do so.
 
Joined
Aug 3, 2015
Messages
3,791
Reaction score
12,182
Location
Charlotte
It's really too bad the camera manufacturers don't take a cue from wifi router manufacturers and include more complete Linux distributions in their product. Memory and flash ram are (relatively) inexpensive, but I also understand they're trying to build it as cheaply as possible and sell it for as much as possible, so they skimp on the hardware. Plus, the less chance there is for users to hack the device, the fewer returns they can expect. I just know the routers that were most hackable were generally the biggest sellers. You'd think the same could be true for Linux-based IP cameras.
 

pal251

Getting comfortable
Joined
Mar 15, 2014
Messages
1,012
Reaction score
133
@pal251, maybe a bit of background on my motives will help. I've been an IT professional since 1984 starting with Digital Equipment Corporation, and have always liked to tinker with things. I take DSLRs apart to remove filters to make them more sensitive to do astrophotograpy, converting old Philips based CCD web cams to do long exposure by adding a logic chip, cutting traces, and lifting pins on the control chip to control exposure length, building arduino kits, flashing new builds where I tweaked some code, playing around building scratch built quad copters using different flight control boards, etc. I'm curious and like to see how things work. I purchased this camera to play with PTZ features but it didn't have any motion detection setting, so I went looking for a firmware update. I made the choice to roll the dice on firmware that matched the model number and had just been released on another site. My mistake, but I knew the possbility of bricking the camera and I made that choice to go ahead. I'm usually quite successful in my tinkering adventures, but I do have a drawer of "spare parts" from some failures.

In hindsight, by bricking the camera, I have learned a great deal on how these things work, and picked up some new skills along the way. I don't recommend people go wild and try to apply any software update unless it has been tested and stable, especially in production/critical applications. Tinkering with cameras is a hobby for me, so I take chances, and sometimes I pay the price of having a non-usable device.

I'm still hopeful that I can recover this camera, and in doing so will have gained significant insight on how they work.

and BTW, I didn't take your comment as being rude, but I just wanted to give you some insight on to why I would go down the path of updating with unproven/unknown firmware in the first place.
Brent
Play enough with toys and one will get broken I guess :)

Id like to start tinkering with arduino, Linux and pi someday.
 
Last edited by a moderator:
Joined
Aug 3, 2015
Messages
3,791
Reaction score
12,182
Location
Charlotte
I'm generating MD5 rainbow tables to use the rtcrack program against that password hash. It will probably take at least a day or two to generate and sort the rainbow table files, then another day or more to run against the password hash. We'll get there, eventually.
 

vmsguy

Young grasshopper
Joined
Jul 27, 2016
Messages
30
Reaction score
1
I'm generating MD5 rainbow tables to use the rtcrack program against that password hash. It will probably take at least a day or two to generate and sort the rainbow table files, then another day or more to run against the password hash. We'll get there, eventually.

Thanks!!!
 

vmsguy

Young grasshopper
Joined
Jul 27, 2016
Messages
30
Reaction score
1
I'm in!

I noticed on Sergei's bootargs, the console was ttyAMA0, mine is tty. I went ahead and tried the ttyAMA0 console device, and I was able to get init=/bin/sh to work. I have root
access, and was able to start the services using /etc/init.d/rcS. There is a process name watchall that is consuming all of the %nic in top. I'm going to try to copy pieces of the good
firmware to the camera if I can get scp to work.

I also now get a full boot console output by using ttyAMA0.

more later, hopefully
Brent
 

vmsguy

Young grasshopper
Joined
Jul 27, 2016
Messages
30
Reaction score
1
Success! Using Sergei's blog postings, and the firmware I received from the vendor, I was able to recover the camera.
This blog posting in particular was the key: http://sergei.nz/ildvr-inc-mh40d06-or-hacking-cheap-chinese-camera-part-2/

Thanks @VorlonFrog for your support and encouragment.

Now I have to put the camera back together, it's completely apart (I had to disconnect the motors to keep them from twisting my cables after every reboot).

First imageScreenshot 2016-08-28 08.48.10.png
 
Last edited by a moderator:

Vault

n3wb
Joined
Aug 1, 2016
Messages
16
Reaction score
1
@pal251, no idea..

@Vault, I entirely disagree.. when it comes to embedded devices like IP Cameras.. people should NEVER update to new versions when possible.. If its working as expected then by definition its not having issues.. this is not your PC you can just format and reinstall when it blows up in your face.. unless you know for a fact that an issue that is hurting your deployment has been fixed in a newer version, you are doing nothing but taking unnecessary risk by taking a device your perfectly happy with and updating it.. New Features, Bug Fixes and Security Updates? Lol, more than likely: Removed Features, More Bugs, and not a damn bit of attention given to security just like always.. If they were security updates we'd betting new firmware 2-3 times a month.. dont put these on networks where they need local security and you wont have any need for security updates.

Ive never updated the firmware on any of my cameras, they all worked as expected.. and gladly continue to do so.
As an IT security officer i just can't agree.. I've thought about your given response and i *could* agree if it's a closed home installation. Why? Well pesonally I will upgrade if a security update is available, but the risk of being infected or taken over is very small so i could understand people won't spend time and money on it. Hence the possibility is still there.
But even closed installations could be taken over if you've got outdated firmware running on your devices and someone attaching a device to it. Think about a device like a pineapple wifi (not going to talk about it right now). Someone attaches it and has remote access to your so beloved 'closed' network.


A companies network should always be updated with security updates. Note that this has to be planned and tested. A lot of companies have people monitoring the cams. If someone (at least one person) has connection to this stream, there's a possible vulnerability. Ofcourse you can just trust the person they won't. But you just never know.
I know it's not a PC which you can format and reinstall. It's a camera which you can install if bricked or buy another... Security #1.


And about security updates... i agree your statement that most manufacturers are not into security updates but i think the most really DO. Great examples are panasonic, mobotix, brickcom and axis. There are more for sure. Also, if no-one tells them about vulnerabilities, they can't fix them.


A secure network costs time and money. This time of internet of things are quite good for hackers and such. People just attach everything to a network.
It might be my state of mind but i hope you understand what i mean. There are vulnerabilities and there will always be. Just take care about it so it's unlikely you'll be the one getting hacked.

Some exmples of last month:
View Samsung config file inlcuding password:
https://www.exploit-db.com/exploits/40262/ (applies to vanderbilt and JVC cameras too)
Honeywell IP-Camera (HICC-1100PT) allows to unauthenticated user disclose the username & password remotely by simple request which made by browser.


Another subject about Dahua NVR's containing bots (by Level 3 and Flashpoint):
http://blog.level3.com/security/attack-of-things/
[FONT=&amp]Of the bots we’ve observed participating in attacks, peaking at more than 1 million devices, a large percentage are located in Taiwan, Brazil and Colombia. A large majority of these bots were using white-labeled DVRs generically described as “H.264 DVRs” and DVRs manufactured by the company Dahua Technology. We have contacted Dahua Technology to make them aware of this issue. Our investigation shows more than one million of these two types of devices are accessible on the internet, providing a large pool of potential bots.
[/FONT]
 

nayr

IPCT Contributor
Joined
Jul 16, 2014
Messages
9,329
Reaction score
5,325
Location
Denver, CO
If your a IT security officer whom thinks some cheap no-name Chinese camera should be on your corporate network; well then I guess your right.. whats the point when your already so clearly owned already.

These devices are easily secured with external measures in place, safely.. without the need for updates.. its neither expensive nor time consuming to put IP Cameras in a walled garden w/only VPN access.. your taking the wrong approach, if someone has already compromised the underlying network infrastructure and reached your surveillance network, well then you really think having the latest firmware running on some cameras is going to help you at this point? A honeypot on the surveillance network will be much more effective than the latest firmwares.

My production servers that are exposed to the internet I can apply only security updates to on a regular, even automatic basis without any interaction from anyone.. no new features, no changes to behavior, only security updates.. What video surveillance company offers realtime CERT response to security issues and backports fixes to every product they have ever sold, even discontinued ones.

Relying on the vendors to keep you secure is for chumps.. Here is a 0-day for NetGear NVR that the guy reported back in February still not fixed: http://seclists.org/fulldisclosure/2016/Aug/36

IF a firmware update came out that fixed a major security issue I was concerned about; I would likely apply it.. but it's never happened so far, and I am not expecting it to ever happen.
 

Vault

n3wb
Joined
Aug 1, 2016
Messages
16
Reaction score
1
If your a IT security officer whom thinks some cheap no-name Chinese camera should be on your corporate network; well then I guess your right.. whats the point when your already so clearly owned already.

These devices are easily secured with external measures in place, safely.. without the need for updates.. its neither expensive nor time consuming to put IP Cameras in a walled garden w/only VPN access.. your taking the wrong approach, if someone has already compromised the underlying network infrastructure and reached your surveillance network, well then you really think having the latest firmware running on some cameras is going to help you at this point? A honeypot on the surveillance network will be much more effective than the latest firmwares.

My production servers that are exposed to the internet I can apply only security updates to on a regular, even automatic basis without any interaction from anyone.. no new features, no changes to behavior, only security updates.. What video surveillance company offers realtime CERT response to security issues and backports fixes to every product they have ever sold, even discontinued ones.

Relying on the vendors to keep you secure is for chumps.. Here is a 0-day for NetGear NVR that the guy reported back in February still not fixed: http://seclists.org/fulldisclosure/2016/Aug/36

IF a firmware update came out that fixed a major security issue I was concerned about; I would likely apply it.. but it's never happened so far, and I am not expecting it to ever happen.
Woah! Wait. I never said i'd reccomend using chinese no-name cameras.
As you said, you'd be owned already

And of course security goes further than just a firmware upgrade. You're absolutely right about that. I see vulerabilities on a regular base when getting a companies network scheme or when i scheme someones deployed network. What I mean is; try to keep thw damage as low as possible. Because if they got into a router or heating control, doesnt mean we shouldn't do anything with the devices which it can reach. Don't rely on one (good) security component. Even the best have been hit.

I really appreciate your thoughts and I think I'm more paranoid on security as anyone else.. hehe
Just keep up the good work and lets try to keep the bastards out together and report vulnerabilities! We could create a list of manufacturers who are serious about this issues and who are not. It could provide more confidence for other users when buying camera devices.
 
Joined
Jan 20, 2017
Messages
1
Reaction score
0
Sorry to open an old thread but I'm in the same position with, what looks like, the same camera. Only open ports are telnet 23/tcp and unknown 20203. Did anyone manage to find a working username/passwd combo for the telnetd process running on 23?

Thanks
 

vmsguy

Young grasshopper
Joined
Jul 27, 2016
Messages
30
Reaction score
1
I never did find a password, I let jontheripper run for a few days on the hash found in the passwd file for root, but never got anything. I was able to reflash the camera at the uboot console using tftp to copy a good firmware to the camera. Let me know if you want to try doing that, I think i still have the files already built on ubuntu, and if I can remember/find the details I can give you the commands to load the files to the camera and then flash. You will also need a USB/rs232 cable at 3.3V, and you have to completely dissasemble the camera, even the camera module to get to the rs232 pad on the board.

Brent
 

lichtimc

n3wb
Joined
Jan 5, 2017
Messages
5
Reaction score
0
I never did find a password, I let jontheripper run for a few days on the hash found in the passwd file for root, but never got anything. I was able to reflash the camera at the uboot console using tftp to copy a good firmware to the camera. Let me know if you want to try doing that, I think i still have the files already built on ubuntu, and if I can remember/find the details I can give you the commands to load the files to the camera and then flash. You will also need a USB/rs232 cable at 3.3V, and you have to completely dissasemble the camera, even the camera module to get to the rs232 pad on the board.

Brent
I am in the same situation with my HANKVISION camera. Before I bricked it with the "newest firmware update" ;), I read out following information with ipctool:
Code:
board:
  vendor: Hankvision
  model: V6202IR-BRV0500
chip:
  vendor: HiSilicon
  model: 3516AV100
ethernet:
  mac: "00:2a:2a:2c:21:04"
  u-mdio-phyaddr: 6250537
  phy-id: 0xa5a5a5a5
  d-mdio-phyaddr: a5a5
rom:
  - type: nor
    block: 64K
    partitions:
      - name: boot
        size: 0x50000
        sha1: 8e569ea5
        contains:
          - name: uboot-env
            offset: 0x40000
      - name: kernel
        size: 0x2b0000
        sha1: f848b1e2
      - name: rootfs
        size: 0x200000
        path: /,jffs2
        sha1: cf51c57c
      - name: data
        size: 0xb00000
        path: /mnt/flash,jffs2,rw
    size: 16M
    addr-mode: 3-byte
ram:
  total: 256M
  media: 160M
firmware:
  u-boot: "2010.06 (May 18 2015 - 09:40:27)"
  kernel: "3.4.35 (Sat Sep 12 11:02:20 CST 2015)"
  toolchain: gcc version 4.8.3 20131202 (prerelease) (Hisilicon_v300)
  libc: uClibc 0.9.33.2
  sdk: "Hi3516A_MPP_V1.0.4.0 B040 Release (Jun 28 2015, 09:24:48)"
  god-app: /mnt/flash/Server/mediaserver/sdk_app
Working firmware versions (I already tried) include:
V1.04.10-171202
V1.04.10-180820
3516AD100 (directly from 升级固件 - 深圳市瀚晖威视科技有限公司EN - Shenzhen Hankvision Technology Co., Ltd.)
I then bricked it with firmware 3516D_20191126. :facepalm: (It ran fine after upgrade, but then I rebooted and suddenly it was dead.)

So now my camera also has ip 192.168.1.18 telnet and 20203 ports open and appears dead otherwise.
I guess I have to climb up the roof and get the camera to revive it throug uboot, or is there another possibility nowadays?
Do you have the same HiSilicon 3516AV100 board (pinout)? And would you please be so kind and provide the commands you used to revive the cam?

EDIT:
I did not have to climb up to the roof! ILDVR sent a tool to recover cameras with ip 192.168.1.18 and port 20203 open! For reference I blogged about it:
Here you can find 3 different firmware images and the recovery/unbrick tool for Hankvision cameras:
 
Last edited:
Top