Reversing DVR firmware dumped from an EEPROM flash chip

Following up on my article about reversing DVR firmware from a firmware update file, we will look at a similar scenario. We want to reverse engineer the firmware running on a DVR, but this time we don’t have a firmware update file available. So what we do is take the thing apart, desolder the EEPROM flash chip and dump its contents with an EEPROM reader. At this point we have something quite similar to the firmware update file, with some key differences. The binary we have is an exact copy of what is running on the system bit for bit. While the firmware update binary usually has only a few cramfs filesystem images, we will be dealing with not only cramfs but also with jffs2 filesystem data, as we dumped both the read-only and r/w partitions.

Lets take a look at an example firmware dump from a DVR.

As we can see the unix file utility doesn’t really tell us much about this file. Its up to us find out what it is. Lets fire up my favorite tool binwalk.

What binwalk does is go through the entire binary file and look for magic numbers which tell us what kind of files are inside this blob 🙂 See a list of these magic numbers here. (Also known as the file signature)

So from the output of binwalk we can see the types of files it found and their offset. With this information we can dissect the file from the binary, and do something with it.

Our first problem is we see a lot of files and offsets, but we don’t really know which one to start with. Our first priority on this device was to find out the telnet password. In linux these passwords are usually stored in /etc/passwd so we can use strings to do a search.

On the left we have listed the offsets, so we can get an idea of where to look in the file. The first line looks promising, so lets check back on our binwalk output, to see what is around that area. (Remember these are HEX values, so use the second column of binwalk)

So this file must be somewhere around this part:

That JFFS2 filesystem looks perfect. Let’s take this file out of the binary so we can work with it. We need to start from the offset, and go till the end of the file. Since we don’t know where it ends, we don’t worry about this. Most tools with ignore trailing garbage at the end of files.

bs=1 is telling dd to use a blocksize of 1. We can make this larger to speed up the process, but then we must divide the skip number with whatever number we use for our blocksize.

Now lets look at our newly created file called system.jffs2

Looks good, lets mount it 🙂 For mounting it, here is a handy script.

Let’s take a look around our mounted jffs2 image.


Looks like a linux system with busybox. let’s take at the file /etc/passwd

The passwd file contains users and their password hashes. By default passwords are encrypted with Crypt under embedded linux systems. We see a root user here, with its password hash. This still needs to be decrypted for us to see the password. If you haven’t already, install john with sudo apt install john. Now we can tell john to crack this password hash.

John starts brute-forcing the password hash to reveal the password. This can take anywhere from a few seconds to a few months depending on the speed of the computer used, and the complexity of the password. Press any key to view the status of john. John has pretty good documentation, and you can see a step by step guide here, including a way to download a larger wordlist for dictionary based cracking. When john is done, use john --show etc/passwdto view the cracked password.

Using this method, you can take apart the firmware running on system, and analize its internal structure and workings. You will come across many types of filesystems and archives, jffs2, cramfs, cpio, gz, zip, etc. They each work differently, but they can all be extracted.

Happy reversing!

  3 comments for “Reversing DVR firmware dumped from an EEPROM flash chip

  1. Rob
    February 9, 2017 at 14:27

    Did you find the password for hash hldf85ln3UUCA

  2. February 17, 2017 at 19:34

    I’m a bit surprised that you didn’t share the results of the attack on the hash hldf85ln3UUCA. Since it’s a default used on so many DVRs (such as the TD_2316ME) it might help others that happen along your page while working to reverse their own firmware images.

    • halftome
      February 17, 2017 at 20:37

      The hash is trivial to break, and it was not my intent to provide information about the hash, but more of a method to reversing firmware in general.

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.