Reverse Engineering DVR firmware
Update: Read part 2, where I reverse engineer the system using a dump from the flash chip.
This is an article about my journey of reverse engineering DVR firmware with no prior knowledge about the topic, and just google as my mentor.
I have a DVR which has a password set, which of course has been forgotten. I have taken the entire thing apart, removed the battery, but the user password still remains. There is no option that I can find for a factory reset, that doesn’t require me knowing the admin password. I ran nmap on it, and discovered quite a few open ports, as well as… yes, you guessed it: telnet 🙂 That sounds fun! Anyway, this telnet option is not documented anywhere, so I have no idea what to type in when it asks for my login credentials. (It is not the same as the password for the DVR, I know this because I later recovered the password and tried the same for telnet) I think I should be able to avoid future hassles of forgetting passwords if I could somehow get into that telnet. Well, I downloaded a firmware update from the support website, the file looks like this: ICR-DVR_H41_H81_firmware_V4.00.R10.20130104.zip. I extracted the zip, and I got this: 6204&08-S_V4.00.R10.20130104.bin. I booted up my trusty Backtrack in VMWare and got to work.
First I tried this: (I renamed the firmware file to dvr.bin, so it would be easier to type)
root@bt:~/Desktop# file dvr.bin
dvr.bin: Zip archive data, at least v2.0 to extractWell if this .bin file is just another zip, we better extract it:
root@bt:~/Desktop# unzip dvr.bin
Archive: dvr.bin
inflating: custom-x.cramfs.img
inflating: user-x.cramfs.img
inflating: romfs-x.cramfs.img
inflating: logo-x.cramfs.img
inflating: InstallDescWell the InstallDesc file is just ASCII text, looks like this:
{"UpgradeCommand" : [{"Command" : "Burn","FileName" : "romfs-x.cramfs.img"},{"Command" : "Burn","FileName" : "user-x.cramfs.img"},{"Command" : "Burn","FileName" : "custom-x.cramfs.img"}],"Hardware" : "BLOCK5008","Vendor" : "General"}
Looks to me like the commands for flashing this “img” files to system ROM. Anyway, what I am interested in, is what those other img files contain. I’m guessing the logo-x would probably contain a bitmap image or some other kind of image with the IDENTIVISION logo, and the other imgs probably contain the Linux OS itself.
Running file against the img files.
root@bt:~/Desktop/firm# file custom-x.cramfs.img
custom-x.cramfs.img: u-boot/PPCBoot imageNow I’ve searched all over to try and decompress or extract .cramfs.img files, but have found nothing.
Some forums say to use this: (after installing cramfs support)
mount -o loop -t cramfs image_file /mount/pointBut I get this:
root@bt:~/Desktop/firm# mount -o loop -t cramfs user-x.cramfs.img /tmp/image
mount: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or sorunning dmesg | tail gives me cramfs: wrong magic.
Running cramfsck gives me ramfsck: superblock magic not found .
So I have a few cramfs.img files, which I have no idea what to do with.
I ran strings on romfs and got some interesting stuff:
linux
Compressed ROMFSv
Compressed
boot
home
linuxrc
proc
root
sbin
share
...
mactab
memstat.conf
mtab
passwd
passwd-
profile
protocols
resolv.conf
...
1.jpg
11.jpg
16.jpg
161.jpg
25.jpg
251.jpg
36.jpg
361.jpg
4.jpg
41.jpg
9.jpg
91.jpg
DVR.htm
English.js
Login.htm
+ a lot more that I ommited...So there is definitely something inside, I can see the filenames, so its not encrypted or anything. I need to extract this somehow.
So I talked with Domonkos Tomcsányi, and he suggested that the .cramfs.img file is not a cramfs file, but instead as file suggests a u-boot/PPCBoot image.
But how do we extract a u-boot/PPCBoot image? Time to google again. Google returns some interesting results. The first link was http://boundarydevices.com/hacking-ram-disks/ saying something about mkimage adding 64 bytes of header, and stripping it with dd would reveal some gzipped data. Lets try this!
root@bt:~/Desktop/firm# dd bs=1 skip=64 if=user-x.cramfs.img of=user-x2.cramfs.img
3133440+0 records in
3133440+0 records out
3133440 bytes (3.1 MB) copied, 4.43597 s, 706 kB/sOkay, now lets run file, and see what it says.
root@bt:~/Desktop/firm# file user-x2.cramfs.img
user-x2.cramfs.img: Linux Compressed ROM File System data, little endian size 3133440 version #2 sorted_dirs CRC 0xa13058c3, edition 0, 1066 blocks, 121 filesCool! 121 files sounds nice! Now lets mount up the img with the stripped header!
root@bt:~/Desktop/firm# mkdir /tmp/foo
root@bt:~/Desktop/firm# mount -o loop user-x2.cramfs.img /tmp/foo/Now lets see whats inside!
root@bt:~/Desktop/firm# cd /tmp/foo
root@bt:/tmp/foo# ls
bin etc lib sbinCool! We successfully mounted img file. Now its time to dig around and look for that telnet password!
Whats this in romfs-x? at /etc/passwd 🙂
we have a line like this:
root:absxcfbgXtb3o:0:0:root:/:/bin/shthen there is another file called passwd- (have no idea what this is for…)
root:ab8nBoH3mb8.g:0:0::/root:/bin/shOkay, so we see from these files, that they are not shadow-ed… Instead of looking like this: username:x: they have some kind of hash in the place of x
Now this the part where I realised that this entire process has already been done by some Russian guys 🙂 My friend Domonkos Tomcsányi googled the hash 😉 Seems to be the same for a lot of IP-Cameras and DVRs. I downloaded hash-identifier and it identified it as a DES hash. So now we basically just need to crack this hash somehow. I used John-the-ripper for this task! By the way, john also immediately identified the hash as DES128.
The hash in passwd- was cracked instantly, the one in passwd took a few hours.
I also took a look at a firmware for a CP-Plus DVR (A lot more complex than the Identivison) It has a similar structure, except the bin file is not just a zip archive, its more complex. Now this is the part, where I realised again, that instead of doing everything manually, I could just usebinwalk, and have this entire process automated 😉 Try this: binwalk -Me firmware.bin and watch the magic happen 🙂 Binwalk is awesome!!! Oh, and the hash in the CP-Plus was a little different, it used a FreeBSD MD5 [32/32] hash according to john. John is currently cracking the hash 🙂
Security differences between the Identivision DVR and the CP-Plus DVR are actually quite big. For example the Identivison can make use of only numbers 0–9 and a “_” character for a 6 character long password. This gives us 11 to the power of 6 number of combinations. While the CP-Plus makes use of the entire alphanumerical range including special characters. Although this does not affect the login security via the VGA frontend, when using the exact same password for a WebUI which is often thrown out on the internet, and brute force protection not implemented, it is a big security risk!
I gave a presentation about this at Hacktivity. Below you can see the youtube video.
Originally published on my old blog on June 12, 2013.
