ubis / HI3536DV100

HI3536DV100 SoC based Techage N6708G5 NVR hacking
24 stars 6 forks source link

dump firmware #8

Open tripLr opened 3 years ago

tripLr commented 3 years ago

Hi, @tripLr

Seems like you have probably identical hardware. Perhaps you could dump firmware too?

I was able to Telnet into it, with root no password

So telnet was open the whole time? In my case it was closed and I had to modify rootfs in order to launch it.

dump and modify firmware Finally got some time to fiddle with these devices. The most recent firmware i have posted on my github, and created a new project to extract this firmware and modify it.

since i have the rootfsXXXX i am looking for a way to write the image

the result of fdisk show this is a complete image

fdisk -u -l image/rootfs-3536dv100 | tee rootfs-3536dv100.txt Disk image/rootfs-3536dv100: 9.56 MiB, 10027520 bytes, 19585 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes

Now I need to extract this and post the file system

  1. How do i "dump" filesystem if I have root access via telnet ?
  2. can I or how do i write the stock image to a folder or sdcard ?

Purpose: I have several of these NVR's and want to 1.change the IP address of the wireless network,

  1. change the security etc,
  2. and maybe change the UI to a simple web server.

These devices have a QR Access for the Zosi software which means that software can control the device from anwhere if you have the QR code.

Thanks !!! Again, this OS has telnet open, with admin as user and no password [triplr@triplr-server:]$telnet 192.168.0.149 Trying 192.168.0.149... Connected to 192.168.0.149. Escape character is '^]'.

(none) login: root Password: Welcome to HiLinux. None of nfsroot found in cmdline. ~ # df -h Filesystem Size Used Available Use% Mounted on /dev/root 12.6M 10.0M 2.6M 80% / tmpfs 47.2M 4.0K 47.2M 0% /dev tmpfs 25.0M 5.1M 19.9M 20% /mnt/mtd/modules tmpfs 5.0M 2.7M 2.3M 54% /mnt/mtd/wfcfg tmpfs 47.2M 4.0K 47.2M 0% /nfsdir tmpfs 47.2M 0 47.2M 0% /tmp ~ #

"" original quote "" However, later I found this - Full disclosure: 0day vulnerability (backdoor) in firmware for Xiaongmai-based DVRs, NVRs and IP cameras and indeed I could open telnet not just on NVR but on my cams too. It's good that I do not expose whole system to internet.

Originally posted by @ubis in https://github.com/ubis/HI3536DV100/issues/3#issuecomment-796491389

ubis commented 3 years ago

Hi,

If there is "dd" utility then you can dump from a live system. You need to get a mtd map first:

cat /proc/mtd:

dev:    size   erasesize  name
mtd0: 00050000 00010000 "boot"
mtd1: 003e0000 00010000 "romfs"
mtd2: 006e0000 00010000 "usr"
mtd3: 00190000 00010000 "web"
mtd4: 002c0000 00010000 "custom"
mtd5: 00020000 00010000 "logo"
mtd6: 00080000 00010000 "mtd" 

Then you can use dd to dump each partition:

dd if=/dev/mtdblock0 of=/tmp/boot.img
dd if=/dev/mtdblock1 of=/tmp/romfs.img

Note: do not mix if with of dd arguments, otherwise you might corrupt the partition and device might be unbootable.

You did mention to have a image file, can you run binwalk image/rootfs-3536dv100? I suppose there should be squashfs partition in there which you can extract and modify.

tripLr commented 3 years ago

Yes dd is part of the system probably hilinux standard . So cat proc mtd to get mounted partitions dd will copy the partitions to a separate image file. Then somehow transfer them off the DVR ? I'll see if I can use a USB or maybe there is a network copy file. I may be able to rsync it off. Dunno yet

Thanks for that method.

If you look at my GitHub.com/triplr I have the images both in my fork of your project, and my new repo project for IOT images. I will try the second method.

Having root access, I can download an arm binary of openssh and use rsync. However when I made changes to the NVR wireless name it did not take upon reboot.. My goal, change it's wireless address and name. It's not editable in the GUI

ubis commented 3 years ago

Yeah you should be to get them via USB or rsync. As for wifi, it could be it uses separate config partition and some application sets SSID on boot.

tripLr commented 3 years ago

Here is a note to export via NFS for hisilicon ( adding this as a note to my process ) Source : https://www.exploit-db.com/docs/english/44003-hisilicon-dvr-hack.pdf instructions to export via NFS Source: https://www.server-world.info/en/note?os=Fedora_34&p=nfs&f=1 instructions to set up NFS on fedora server ( my desktop machines )

tripLr commented 3 years ago

reply to "Yeah you should be to get them via USB or rsync. As for wifi, it could be it uses separate config partition and some application sets SSID on boot."

i can confirm that edits to the /mnt/mtd partition survive reboot, and there is a wfcfg.sh that erases and re-extracts and remounts the wfcfg dir , from the wfcfg.tar.bz file creates and mounts the folder with the wifi config file and kernel modules renaming the tar file fails to load the wifi modules and the GUI does not launch causing a bootloop

tripLr commented 3 years ago

in the telnet terminal , unfortunately , i have no way to access the nfs or usb mount on the device to export the images here is screenshot of top processes-dvr

tripLr commented 3 years ago

so , editing the wfcfg tar file is out. back to trying to export to a nfs share, have to try an windows 11 nfs

tripLr commented 3 years ago

second try to export firmware from image source : https://lynxbee.com/how-to-extract-files-from-jffs2-rootfilesystem-image/

ouput of fdisk -lu [root@triplr-dev:]$fdisk -lu rootfs-3536dv100 Disk rootfs-3536dv100: 9.56 MiB, 10027520 bytes, 19585 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes [22:26:13:Fri Oct 15:/run/media/triplr/16GB]

output of binwalk [root@triplr-dev:]$binwalk -B rootfs-3536dv100

DECIMAL HEXADECIMAL DESCRIPTION

0 0x0 uImage header, header size: 64 bytes, header CRC: 0xD80E222, created: 2020-05-07 01:55:05, image size: 10027840 bytes, Data Address: 0x0, Entry Point: 0x0, data CRC: 0xE410B603, OS: Linux, CPU: ARM, image type: Filesystem Image, compression type: none, image name: "hirootfs" 64 0x40 JFFS2 filesystem, little endian

assuming the first 64 bits 0-63 are the header and the next is the file system 64 to 10027840 is the image

so, I did [root@triplr-dev:]$dd if=rootfs-3536dv100 of=hirootfs bs=512 skip=63 19522+1 records in 19522+1 records out 9995648 bytes (10 MB, 9.5 MiB) copied, 2.72772 s, 3.7 MB/s

which gave me a file highrootfs

now after i stripped the header which i now know is an uncompressed JFFS2 image from the binwalk. this is the result of fdisk, a clean jffs2 image

[root@triplr-dev:]$binwalk -B hirootfs

DECIMAL HEXADECIMAL DESCRIPTION

900 0x384 JFFS2 filesystem, little endian

[22:37:14:Fri Oct 15:/run/media/triplr/16GB] [root@triplr-dev:]$fdisk -lu hirootfs Disk hirootfs: 9.53 MiB, 9995264 bytes, 19522 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes [22:38:02:Fri Oct 15:/run/media/triplr/16GB] [root@triplr-dev:]$

so cool, thanks for all the hints next up mounting the jffs2 image

thisispanthrax commented 1 year ago

@tripLr - Did you ever get any further with this?