Hacking the Foscam FI8908W

I recently bought a Wireless Pan/Tilt IP Camera in an effort to eventually replace all of the old 2.4GHz wireless cameras around the house, which have ruthlessly stressing my Wireless B/G (also 2.4GHz) Internet.  I found these cameras, and lots of reviews and articles about how good they are, despite their rather small price-tag.  In the world of P/T Cameras, let alone IP Cameras, you’d typically be looking at 2-3x the price for the next best thing.  They aren’t perfect, but updated to the more recent versions of their firmware, they are great cameras that almost equally well in Windows, OS X, or Linux.  Top that with a company that is reportedly very responsive to customer needs, open documentation for protocols and APIs to manipulate the camera, and you’ve got the makings of a great product.  You can read up on any number of reviews via Google, but I’ll link one in particular here.

Based on the title of this post, I suspect you’re not interested in which camera to buy… rather, you’ve already bought one and you’re wondering what else it can do.  I did too.  After a little searching around, I decided to download the latest firmware files and take a look at them under the proverbial microscope of the Hex Editor.

Foscam has two separate firmware files.  One is a ‘core’ firmware, and the other is the ‘WebUI’.  Immediately, it was clear that the ‘core’ firmware was a much more complicated beast; my current, best assumption is that the file is a bonefied, honest-to-God self-extracting binary.  I haven’t taken my camera apart yet to figure out which processor its running, but I suspect I’ll find an ARM processor inside.  What I can tell from scanning the core firmware file is that the underlying OS which the firmware provides is, you guessed it, Linux.  I like these Foscam guys more and more.  I digress.  About this point, I decided to go check out the other file.

The second file, the WebUI firmware, was much easier to tame.  A few simple guesses about what the header information in the file meant, and a couple hours of validating my theories produced the following truth table.

Offset:     Data Type/Size:    Description/Value/Etc:
0x0000      INT32_LE           Size of file
0x0004      Byte[4]            Version Number, each byte a min/minor  value (2.4.8.12)
0x0008      Char[21]           File Description

{ ## Repeats until End-Of-File

+0x000      INT32_LE           Length of File Name
+0x004      Char[...]          File Name
+(Filelen)  Byte               File Type (0 = directory, 1 = file)

{ If 'File Type' == 1 then
+0x001      INT32_LE           Length of File Data
+0x004      Char[...]          File Data
}

}

Based on this data, I was able to whip out the utterly mind-numbing C code below:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/stat.h>

int main(int argc, char **argv) {
  FILE *f = NULL;
  int len = 0, type = 0;
  char src_file[512], dst_file[512], *data = NULL;
  int max_data = 0;

  if ( (f = fopen(argv[1], "rb")) == NULL)
    exit(-1);

  fseek(f, 0, SEEK_END);
  int file_len = ftell(f);
  fseek(f, 0, SEEK_SET);

  fread(&len, 1, 4, f);
  if (len != file_len) {
    fprintf(stderr, "File size doesn't match that reported in the header: %d/%d\n", len, file_len);
    exit(-1);
  }

  fseek(f, 29, SEEK_SET); // seek to first file

  while(!feof(f)) {
    memset(src_file, 0, sizeof(src_file));
    memset(dst_file, 0, sizeof(dst_file));

    fread(&len, 1, 4, f); // read filename length
    fread(src_file,1,len,f); // read filename
    sprintf(dst_file, "%s%s", argv[2], src_file);

    type = 0;
    fread(&type, 1, 1, f); // read entry type
    if (type == 0) {
      if (mkdir(dst_file, 0770) != 0) {
        fprintf(stderr, "Unable to write file: %s", dst_file);
        exit(-1);
      }
    } else if (type == 1) {
      FILE *f2 = fopen(dst_file, "wb");
      if (f2 == NULL) {
        fprintf(stderr, "Unable to write file: %s", dst_file);
        exit(-1);
      }

      fread(&len, 1, 4, f); // read data length
      if (len > max_data) {
        data = realloc(data, len);
        max_data = len;
        if (data == NULL) {
          fprintf(stderr, "Unable to allocate  data necessary to extract file.  Requested: %d bytes.\n", len);
          exit(-1);
        }
      }
      fread(data,1,len,f);

      fprintf(stdout, "Extracting %s (%d bytes)...\n", src_file, len);
      fwrite(data, 1, len, f2);
      fclose(f2);
    }
  }

  fclose(f);
  free(data);
  return 0;
}

You should be able to copy/paste this into and empty .c file (for example, “extract.c”) and run the following command:

gcc extract.c -o extract

Change “extract.c” and “extract” to whatever you want to call it.  Running that command will create an executable file named “extract” (or whatever you changed it to).  This is the executable file that will extract the contents of the firmware file.

When you have that file, you should be able to run the following command:

./extract <path_to_firmwarefile> <path_to_destination>

This should extract all the files in the firmware file into the path specified.  I would encourage you to first create a directory for the extracted firmware files.  If you want to extract to the current directory, you must still enter this parameter as “./”  (but without the quotes) Ie:

./extract ../FI8908W-fw11.14.1.46bis/2.4.8.12.bin ./

Have fun, and happy hacking…  Hopefully soon, I’ll post the code for a second utility to repackage a firmware file.  If someone beats me to it, please feel free to post, or ask any questions about the format of the file.  At the least, being able to see how the web/javascript interact with the underlying OS should provide options for making a back door.

~ by kylemallory on March 30, 2010.