ILDVR INC-MH40D06 or hacking cheap chinese camera

Continuation of ILDVR INC-MH40D06

Since manufacturer will not divulge the super secret telnet password, and not having ability to turn off the telnet from web ui, I have decided to get access to camera via more brute method.

This involves opening the camera, soldering a pin header/wires to RS232 pads on the SoC board:

ildvr_rs232_pads_labels

ildvr_1.27mm_rs232

ildvr_1.27mm_to_2.54mm_rs232

ildvr_1.27mm_rs232_2

ildvr_usb_rs232

The RS232 is connected to a 3.3V (NOT 5V!) USB RS232 TTL adapter (a few bucks on ebay). BTW the ebay sourced USB adapter did not come with instruction/pin-out. It is in fact the following:

Red - 3.3V
Green - TX
White - RX
Black - GND

The pin spacing is 1.27mm. I could not find the connector that would fit so I botched 1.27mm->2.54mm header adapter (since the USB adapter came with 2.54mm sockets):

I disconnected the 3.3V pin as the SoC was using that for power and would not reboot when PoE was disconnected.
I used minicom with following settings:

115200 8N1
ttyUSB0

Once power is applied immediately press any key to interrupt the boot process and get uBoot prompt:

U-Boot 2010.06 (May 18 2015 - 09:40:27)

Check spi flash controller v350... Found
Spi(cs1) ID: 0xC2 0x20 0x18 0xC2 0x20 0x18
Spi(cs1): Block:64KB Chip:16MB Name:"MX25L128XX"
In:    serial
Out:   serial
Err:   serial
Hit any key to stop autoboot:  0 
hisilicon #

To find out correct boot parameters run printenv:

hisilicon # printenv 
bootcmd=sf probe 0;sf read 0x82000000 0x50000 0x2b0000;bootm 0x82000000
bootdelay=1
baudrate=115200
ethaddr=00:00:23:34:45:66
ipaddr=192.168.6.99
serverip=192.168.6.10
netmask=255.255.252.0
bootfile="uImage"
board=hi3516d
bootargs=mem=128M console=ttyAMA0,115200 root=/dev/mtdblock2 rootfstype=jffs2 mtdparts=hi_sfc:320K(boot),2752K(kernel),2M(rootfs),11M(data)
stdin=serial
stdout=serial
stderr=serial
verify=n
ver=U-Boot 2010.06 (May 18 2015 - 09:40:27)

To get root you will need to modify the bootargs variable:

setenv bootargs mem=128M console=ttyAMA0,115200 root=/dev/mtdblock2 rootfstype=jffs2 mtdparts=hi_sfc:320K(boot),2752K(kernel),2M(rootfs),11M(data) init=/bin/sh

It is pretty much exactly the same as original bootargs from printenv except the init is changed to shell (/bin/sh).

To boot, simply run the values from bootcmd variable from printenv:

sf probe 0;sf read 0x82000000 0x50000 0x2b0000;bootm 0x82000000

To continue with boot (to get rest of the mounts and things up and running) run following:

/etc/init.d/rcS

At this stage you can change the root password (via passwd). This will not stick, to make it stick modify Server.tar.xz with desired etc/passwd entry (see below).

Horrible stuff below.
Everything runs as root!

The point of interest is /mnt/flash/Server.tar.xz, I believe init script unpacks it into /mnt/flash/.
It is possible to get the whole file without using tfpt or any other trickery by simply copying it accross into accessible area from webui:

cp /mnt/flash/Server.tar.xz /mnt/flash/web/browse/


From there you can simply type http://${camera_ip}/browse/Server.tar.xz and download the whole thing.

Examining the "server" binary I discovered major security flaw. Specifically in Server/LINUX/webs there are following strings:

name=HANKVISION
password=HANKVISION

I tested it against web ui, and to my horror these credentials allowed me to log in (with admin right nevertheless).

Here is the Server.tar.xz for curious types.

Other things.

The /etc/passwd contained the following:

root:$1$EnVGPLqH$OmqpejDjDsF8NQkcwH/og.:0:0::/root:/bin/sh

I am using JTR with Cuda (on GTX970) against it (at this stage alpha 4-8), but I doubt I will get anywhere. I need to find an exploit to change /etc/passwd without using serial.

The /etc/passwd- contained the following:

root:$1$y3A1TsGe$n7RvgOkNPb1PhGPGnh9v5.:0:0::/root:/bin/sh

There are a lot of references to Justin and paths like /home/zhangxq/

Since you can get Server.tar.xz and there is wget, you can modify Server.tar.xz and replace modified version via wget, which opens to plenty of possibilities.

root password is hkvision888

45 thoughts on “ILDVR INC-MH40D06 or hacking cheap chinese camera”

  1. Did you get any further with the telnetd root password?

    I recently installed an outdoor mast-mounted HD x33 PTZ camera bought via a seller on aliexpress.com. It works well and until recently I’ve not had the need to hack it. Yesterday an nmap scan showed it had port 23 open with the busybox telnetd listening (it is on an isolated VLAN though) so I began to try to figure out how to access it and so far have been unsuccessful. As the device is mounted on a mast 10 meters high I don’t feel inclined to attach a serial cable to its UART port!

    After a lot of research it turns out my device is actually manufactured by SHENZHEN UNITOPTEK ELECTRONICS CO.,LTD who trade outside China as BOAVISION. The web-site is at http://unitoptek.com.

    The web-server returns the same ID as you reported: “Server: Hankvision-Webs” and the Javascript has comments by ‘Justin’ but as I don’t (yet) have access to a firmware update file (have requested one) I can’t investigate if the packages are essentially identical to those on the MH40D06.

    HankVision’s Chinese site is the best place to get more info on them and their download page is: http://www.hankvision.com/kehu/ but the download site they use requires payment for some downloads (including of firmware images for their own-brand devices).

    Email me privately if you remain interested in hacking this or similar devices.

    1. I haven’t got anywhere with cracking ssh root password.
      You could always try to exploit it with via update firmware uploader.
      I simply lost interest as I certainly will not be buying this brand or recommend anyone buying it either, unless there is option of opensource firmware (there is none).

    2. anyka$printenv
      baudrate=115200
      board=ak3918ev300
      bootargs=console=ttySAK0,115200n8 root=/dev/mtdblock2 rootfstype=squashfs init=/bin/sh mem=64M memsize=64M mtdparts=spi0.0:212K(uboot),1452K(kernel),896K(rootfs),512K(config),5120K(data)
      bootcmd=sf probe 0:0 20000000 0; sf read 0x82208000 0x35000 0x16b000; bootm 0x82208000
      bootdelay=1
      ethact=AKEthernet-0
      ethaddr=00:55:7b:b5:7d:f7
      ipaddr=192.168.1.77
      netmask=255.255.255.0
      serverip=192.168.1.20
      stderr=serial
      stdin=serial
      stdout=serial
      ver=U-Boot 2013.10.0-AK_V3.0.07 (Nov 10 2020 – 21:53:40)

      /etc/init.d # ls
      S02moutfs S80network S90decompress S91update rcS

      /etc # cat passwd
      root:$1$0Me7S3z5$.uQ4Pr/QjJQ/0JUZI0w4m.:0:0::/root:/bin/sh/etc # part

      /tmp is not mounted
      i need this file /tmp/factory_wifi

      when the camera boot
      hotspotNum 7
      ignore AP Adi 00:31:92:B1:95:27 signal -31 !
      skip AP hank_factory 02:31:92:91:95:27 signal -33 too weak !
      ignore AP Adi_AP 0C:80:63:B1:4B:C6 signal -51 !
      ignore AP B-9877 @ SPEEDEX INTERNET B4:B0:24:3F:7D:2E signal -55 !
      ignore AP LinkNet-Manik03132344466 3C:84:6A:F8:CD:D2 signal -65 !
      ignore AP Speedex(734)net03149667123 F6:8C:EB:20:5B:6A signal -67 !
      ignore AP Tenda_B033C0 D8:32:14:B0:33:C0 signal -81 !
      do not found factory wifi, retry 5
      wlan0 Link encap:Ethernet HWaddr 18:C8:E7:52:81:57

      my all cameras are wifi
      it search for factory wifi (Wifi NVR is dead)
      i want to change it to connect to my local wifi router
      after alot of research i found that it search for hank_factory i changed my wifi ssid to this but it still not connecting its skipping to this SSID

      i hope will get some help from you

      1. skip AP hank_factory 02:31:92:91:95:27 signal -33 too weak !

        It seems that it would connect to hank_factory if it had stronger signal (although -33 is quiet strong). Maybe place the camera right next to the access point?

  2. Hi there,

    Have same firmware in my camera, different model with no serial port available.
    Any progress with cracking that salted pass?

    1. No success on the hash.
      Are you sure there is no serial port on the board? It would be 4 through holes on the boards where you need solder the connector to.

      1. Tried every connector with oscilloscope – found only rs485 for PTZ control, no UART or rs232, nothing else than PTZ on rs485.

        Camera I have is: LE-SDM38L

        Perhaps they did use UART for 485…

        I will try to hack it through web interface to temporarly change password on it and log in via telnet once I will find time for that 🙂

  3. Don’t have fast enough graphic card to crack that password but HASHCAT is much faster than JOHN.

    command for HASHCAT bruteforce is (6 signs long – letters, caps, digits, special): hashcat -a 3 -m 500 password ?a?a?a?a?a?a

    Can you check if hashcat is faster? I’m checking 1-5 long passwords. since 6 long would take me like 140 days.

  4. All right, found UART it was on the other side behind metal plate, had to open module.

    Way to set own password is:

    in /mnt/flash create 2 files. First one is own passwd file with md5crypt password. Second one is “mountnfs” with this line inside: “sleep 60&&cp /mnt/flash/passwd /etc/passwd&” if you want you can tweak the time – it is needed to wait for rootfs remount. Perhaps 15 sec will do…

  5. are you still interested in this project. ive copied server.tar.xz and changed the root password also figure out how to change the webui hidden accounT password HANKVISION_2016. I would like to pull the firmware image off the camera and make some permanent changes to the webui?? my camera is the 30x 4mp ptz.

    1. Interesting that they still up to no good with hardcoded passwords. I “blacklisted” anything that has boards from Hankvision.

  6. Just checked my BOAVISION camera.
    Indeed, it has HANKVISION_2016 user with HANKVISION_2016 password.
    Mailed a message to them.
    Will keep you updated regarding their reaction.

  7. i found a way to change the hidden account password but it dont really matter because nothign on these cameras besides maybe ptz use authentication anyways. to cahgne it just hit f12 on chrome and modify the webpage to pass the userame as HANKVISION_2016 when changing an account password.

    1. Are you sure you are actually changing it, as on previous iteration of this firmware it was hardcoded in the binary…

  8. Hi,

    This is really interresting.
    I just recieved for review this one and I have excatly same hardcoded account in the WebUI.

    Here’s the link :
    https://www.amazon.fr/gp/product/B077N6VKF9/ref=oh_aui_detailpage_o01_s00?ie=UTF8&psc=1

    When I’d like to add new user named HANKVISION_2016, it simply says “sorry, username is taken”.
    So i used the form to change admin password and just modified the hidden input “admin” to “HANKVISION_2016”.
    After changning password, it seems to be OK but I don’t know if it’s safe to use camera or not !

    Anyway, i just wrote firewall rule in my router to drop packets coming from camera’s MAC address to WAN

    By the way, nice work on it, thanks for the url’s and now i’m trying to get working PTZ via http get/post with curl.

    Bye

    Valentin

  9. Evening,

    I managed to change the password HANKVISION_2016 and now the URL “http://192.168.10.223:10081/OwnUserInfo.txt” only show that :
    admin : admin : 6

    I managed to get work PTZ with CURL request like this :

    http://$username:$password@$hostname/form/setPTZCfg?command=$move_id

    where $move_id =
    0 to stop
    1 for up
    2 for down
    3 for left
    4 for right

    I have to make 2 curl request to make it move and stop like that :

    http://$username:$password@$hostname/form/setPTZCfg?command=3
    http://$username:$password@$hostname/form/setPTZCfg?command=0

    Hope it helps ppl with same chip

  10. One possible way to find out camera root password is to expose telnet to public internet. Then setup port mirror and sniff telnet traffic for successfull logins with tshasrk. This could be faster method than bruteforce password cracking.

  11. I very interesting indeed I have ordered 2 different camera from 2 different Chinese supplier and got the same Security flaw ( assess with =HANKVISION_2016 ) so I am glad that now I am convince that this is really a security issue.
    I have been searching any info on this forum and internet for a year and it is about time any info begin to show.

    Thank to all for the comment and info

  12. Hi there!
    Could someone get the telnet root user? My camera is an AZ-IPZ45530E and it also has the access HANKVISION_2016

  13. Look what i found

    HANKVISION_2016 e765eb4aa1863fa6fb6d935baae0d044333c00d110a8c4ec86e1972ab1462324 cfc84b6b0f7074b82416e92dcd26dac6 952e7a5ddaaaaf93712b78d656fa201b

    admin 8c6976e5b5410415bde908bd4dee15dfb167a9c873fc4bb8a81f6f2ab448a918 21232f297a57a5a743894a0e4a801fc3 76eb00c6458e9b2755b570ae565ba0a6

  14. I have dumped the firmware from the chip with CH341 memory chipreader. If anybody is interested just reply and I’ll post a link

    1. Sure, I can trawl it and see if there any gems like hard-coded passwords are inside.

        1. Thanks :).

          Here is the first thing that jumps out:
          root:$1$EnVGPLqH$Jwh/FgaqrrHwHsmzHibnc1:0:0::/root:/bin/sh
          root:$1$y3A1TsGe$n7RvgOkNPb1PhGPGnh9v5.:0:0::/root:/bin/sh

          Exactly same thing as in the article above.

          Second thing:
          OwnUserInfo.txt
          HANKVISION : HANKVISION : 6
          admin : admin : 6

          1. how did you binwalk the dump, god damn I’m incompetent.hahaha

            Any chance you can replace the shadow file.
            would make a nice update post. ; )

            does this open any new avenues with the firmware now?

            I might have another go at John with the hash just for the hell it.

          2. binwalk -e 3516.bin -xzlib to get rid off the false positive zlib hits.
            I had to install jefferson to unpack the JFFS2 filesystem, but it seems the Server.tar.xz is corrupt…

        2. Not sure if your dump is complete NAND image..

          I bypassed binwalk completely:


          modprobe jffs2
          modprobe mtdram total_size=65536 erase_size=128
          nandwrite /dev/mtd0 3516.bin
          mount -t jffs2 mtd0 jffs/

          Server.tar.xz was still corrupted.

          I tried erase_size=256 which this might suggest:
          Server/etc/fw_env.config:/dev/mtd0 0x00040000 0x40000 0x40000

          Still no luck.

          Update: I went back to my previous notes to find correct erase_size (here) and turns out it is 64kb.

          Once everything is mounted I got it to extract fully.

          So, the hardcoded password is still present:
          strings Server/LINUX/webs | grep HANK
          name=HANKVISION_2016
          password=HANKVISION_2016

          These idiots never learn :(.

          Also similarly these looks like special users:
          strings Server/LINUX/hiapp | grep HANKVISION_2016 -B1 -A2
          /mnt/flash/data/UserInfo
          HANKVISION_2016
          admin
          123456

          As to answer the question about repacking, one could use the nanddump after the the modification were done to the file system. There is a gotcha, is that NAND has OOB region and I am not sure how that will affect everything (without knowing exact layout of the NAND flash), maybe it is not an issue…

          1. Continuing with terrible security practices:
            The /data/UserInfo contains following strings:
            HANKVISION_2016 e765eb4aa1863fa6fb6d935baae0d044333c00d110a8c4ec86e1972ab1462324 cfc84b6b0f7074b82416e92dcd26dac6 952e7a5ddaaaaf93712b78d656fa201b
            admin 8c6976e5b5410415bde908bd4dee15dfb167a9c873fc4bb8a81f6f2ab448a918 21232f297a57a5a743894a0e4a801fc3 6eb00c6458e9b2755b570ae565ba0a6
            #REMOVED#

            So there seems to be another user: #REMOVED#.

            The MD5 hash cfc84b6b0f7074b82416e92dcd26dac6 is for HANKVISION_2016.

            The /data/OwnUserInfo.txt file contains the following:
            HANKVISION : HANKVISION : 6
            admin : admin : 6
            #REMOVED# : #REMOVED# : 4

            The “admin” matches the 21232f297a57a5a743894a0e4a801fc3.

            EDIT: look like the 3rd user has been added by an end user and I have redacted the passwords and hashes.

  15. you work so fast, putting me to shame,
    This is excellent however lots to unpack, any chance you can post the unpacked Bin on Github for slowpokes like myself.

    Thanks for you help BTW, Awesome job !!

    the godmode account was indeed myself if thats the redacted details.

  16. looking at the OOB from what i’ve read its designated free area but still has some low level read and write ability and also the error correction code scheme uses the OOB for storage of ECC data, and the layout of ECC should be checked to make sure that it fits within the OOB.

    Still i have the ability to write directly to the chip so i don’t think it would hurt to give it a bash unless the chip has write protections enabled. Ive had the problem before where there is no restrictions in sequential read over the NAND but you cant sequential write without passing some other verification procedure.

  17. I have an exploit for one of the internal daemons able to open a remote shell. I’m able to run it on my camera (which has uClibc 0.9.33.2 with sha1sum 6d7093bb4ca79137b1ae5286f5d28e5285cb5655 libuClibc-0.9.33.2.so)
    Please can you check if you have the same uClibc? Because the binary exploitable in my camera is different from the one present in the Server.tar.xz posted here (both have the same vulerability).
    If it is different if you provide it me, I can adapt the exploit for other library versions

      1. Thank you! I will work on it and I will release the exploit also for that version. Please can you confirm also that the binary “watchall” in /mnt/flash/Server/root/ (if i remember correctly the path) has sha1sum 5959ead28bb0aa7134a3763512331871ddd704b2
        or ca4a38bf7c1e49cd12c125ac3d730cfea897c2b0 (mine version)?
        If not can you also post it?

        1. hi can you help
          my watchall version hash is
          f889275b5309a023800b9e3b1c16297de463bf74
          Thanks

    1. You cannot, without messing with the binary in the firmware.
      The simplest method to avoid such critical vulnerability is not to buy any camera based on this firmware/SDK.

      And if you already have bought it, do not put it on a routable network (ie: don’t give it a gateway).

Leave a Reply

Your email address will not be published. Required fields are marked *