DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Related

  • A Deep Dive Into Firmware Over the Air for IoT Devices
  • How You Can Avoid a CrowdStrike Fiasco
  • Upgrade Your Hobbyist Arduino Firmware To Work With STM32 For Wider Applications
  • Optimizing Firmware: The Key to Shipping IoT Devices on Time

Trending

  • End-to-End Event Streaming With Kafka, Spring Boot and AWS SQS/SNS (Production-Ready Code Guide)
  • RAG Done Right: When to Use SQL, Search, and Vector Retrieval and How To Combine Them
  • Understanding MCP Architecture: LLM + API vs Model Context Protocol
  • A Comprehensive Guide to Prompt Engineering

A Firmware Filesystem

Someone else's firmware can help organize your own thoughts and projects. By diving into it with binwalk, you can learn how to avoid simple mistakes.

By 
Christopher Lamb user avatar
Christopher Lamb
·
Apr. 26, 17 · Tutorial
Likes (4)
Comment
Save
Tweet
Share
6.8K Views

Join the DZone community and get the full member experience.

Join For Free

So far, we've extracted the firmware contents of the NC200 cloud camera system from TP-Link, and we've learned about the active kernel version and the bootloader. Now let's look a little more closely at the filesystem. This particular distribution is pretty interesting too, because it looks like we have two of them!

First, let's go to the CPIO encoded filesystem. This one actually looks like a full Unix filesystem:

cclamb@fawkes:~/Work/tplink/nc200/a/rebuilt_fs $ ls
bin dev etc_ro init lib mnt proc sbin sys tmp usr var


The JFFS2 filesystem, on the other hand, seems kind of odd:

cclamb@fawkes:~/Work/tplink/nc200/a/_NC200_2.1.7_Build_160315_Rel.27420.bin.extracted/jffs2-root/fs_1 $ ls
bin config etc lib sbin share www


So what gives? Well, we have a couple of clues. First, on the JFFS2 side, take a look at config/lighttpd.conf:

var.home_dir = "/var/run/lighttpd"
var.log_root = home_dir
var.state_dir = home_dir
var.server_root = "/usr/local/www"
var.conf_dir = "/usr/local/config"


Hmm. We don't have a /usr/local in the JFFS2 distro, but we do in the CPIO distro, though the CPIO distro doesn't have anything in /usr/local. We do have a www and a config directory in the JFFS2 distro though. What else?

Well, on the CPIO side, we have a /etc_ro/rcS file. Take a look at the top of the file:

#!/bin/sh
# mount /usr/local from flash
mount -t jffs2 /dev/mtdblock5 /usr/local
mount -t jffs2 /dev/mtdblock6 /usr/local/config/ipcamera


Whhhhaaaaat? Well, it looks like the JFFS2 filesystem is actually mounted on /usr/local at boot! So, to make things easier, let's copy the contents of the JFFS2 filesystem into the CPIO filesystem at /usr/local (I suggest you use a copy of the CPIO filesystem contents to do this, just in case you mess something up like I did the first time).

Don't worry about the contents of fs_2 — the files there are the same ones as are in the CPIO filesystem.

Why would you design a filesystem like this? Well, notice that most of the application specific stuff is in the JFFS2 filesystems, while typical Unix-y things are in the CPIO filesystem. This kind of design would allow you to update only the application code, without needing to deal with the Linux installation. Bundling everything together might require you to update the Linux code with every application update — something you probably don't want to do. Also notice that of the JFFS2 images that are installed on flash, one is dedicated to the camera, while the other seems to handle mostly configuration and communication. Honestly, a pretty good example of the separation of concerns in practice. Good job TP-Link!

So now we have a complete filesystem to work with. Next, we can look over the Linux configuration, and start to figure out what code is core to this particular device and what isn't.

Firmware

Opinions expressed by DZone contributors are their own.

Related

  • A Deep Dive Into Firmware Over the Air for IoT Devices
  • How You Can Avoid a CrowdStrike Fiasco
  • Upgrade Your Hobbyist Arduino Firmware To Work With STM32 For Wider Applications
  • Optimizing Firmware: The Key to Shipping IoT Devices on Time

Partner Resources

×

Comments

The likes didn't load as expected. Please refresh the page and try again.

  • RSS
  • X
  • Facebook

ABOUT US

  • About DZone
  • Support and feedback
  • Community research

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 215
  • Nashville, TN 37211
  • [email protected]

Let's be friends:

  • RSS
  • X
  • Facebook