Its almost 2:00AM, and I’m tired as hell. I’ve gotten so close to the point of giving up, that I decided to write this article about my struggles.
I have an Identivision 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 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 extract
Well if this .bin file is just another zip, we better extract it:
root@bt:~/Desktop# unzip dvr.bin
Well 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 image
Now 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/point
But 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 so
running 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:
+ 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 actually 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/s
Okay, 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 files
Cool! 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
bin etc lib sbin
Cool! 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:
then there is another file called passwd- (have no idea what this is for…)
Okay, so we see from these files, that they are not shaddowed… Instead of looking like this: username:x: they have some kind of hash in the place of “x”
Now this the part where I realized 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 immediatly identified the hash as DES128.
The hash in passwd- was cracked immediately, 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 realized again, that instead of doing everything manually, I could just binwalk, 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 bruteforce protection not implemented, it is a big security risk!
Note: I’m going to rewrite this article soon, with much more precise information, including modifying the firmware images, and structure of the 64byte uImage header.
I’m also gonna be giving a speech about this topic at Hacktivity. I’ll be sure to upload the video and powerpoint soon after.