IoT hacking field notes #2: Using bind mounts to temporarily modify read-only files

TL;DR: The second of our short, IoT-related posts shares a simple trick we use in IoT pentests to temporarily change the contents of read-only files in Linux-based devices. Very useful when trying to proxy network traffic or temporary change the behavior of a device!

IoT field notes is a series of short stories about interesting (hopefully 🙂 ) observations, vulnerabilities and techniques, inspired directly from the IoT assessments we perform at NVISO and from our IoT R&D activities. Interested in the first part of this series, where we talked about Glitching Attacks? Read it here:

Read only filesystems

IoT devices running Linux-based OSes often use the following partition configuration:

  • The main filesystem partition, containing most of the OS files and application executables, is mounted as read-only;
  • A secondary, smaller partition is mounted as read-write and used to hold configuration files and logs.

This is useful to protect the integrity of the OS and the application executables and prevent unwanted modifications.

However, during pentests, we often need to temporarily modify the contents of OS and application files. A typical use case is updating the hosts file, or some application-specific configuration file, to redirect a device’s traffic to an intercepting server. Bind mounts are an easy way to achieve that!

Example scenario

To demonstrate this technique, we configured one of our trusted Raspberry Pis, in order to mount the main partition as read-only and use a temporary in-memory filesystem for the logs and transient files. In the mount command output below, we highlighted the main partition carrying all the OS files in red and the temporary filesystem in green:

Read-only and temporary filesystem partitions on RPi

Now, suppose we want to modify the /etc/hosts files of the Pi, to redirect traffic to “” towards an intercepting proxy on our local network, listening on Predictably, trying to directly modify the /etc/hosts file is futile:

Trying to modify /etc/hosts results in an error, since its located on a read-only partition

The obvious solution

In this case, the obvious solution would be to remount the main partition as read-write and then modify the hosts file. However, this approach has some disadvantages:

  • We need to manually back-up the original hosts file and restore it after we are done;
  • We need to be very careful about not causing unintended modifications to other files – we have no guarantees that some application on the device will not run rampart (because it was designed to operate in a read-only filesystem) and damage it;
  • Sometimes, it might not be possible to remount the main partition as read-write, due to hardware constraints.

The easy solution: using bind mounts

In very simple terms, using a bind mount will allow us to mount a file to a different location inside the filesystem, creating a temporary view. The only prerequisite for using bind mounts is to have an area on the device where we can create files – in our scenario this is the temporarily filesystem holding the log files.

In the snippet below, we move into the /tmp folder of the temporary filesystem, create a copy of the read-only /etc/hosts file into etc.hosts.modded and finally modify etc.hosts.modded to force to resolve to

Preparing the modified hosts file to mount bind

We are now ready to create a bind mount from the modified file to the original /etc/hosts file. The actual command is highlighted in red:

Bind mounting /tmp/etc.hosts.modded to /etc/hosts

After bind mounting, the contents of /etc/hosts now reflect those of /tmp/etc.hosts.modded. Any modifications to the etc.hosts.modded file will immediately show in /etc/hosts as well.

Notice that in the output of traceroute (highlighted in green above), now resolves to our intercepting proxy address: mission accomplished!

Last thoughts

Bind mounts are very useful because they allow us to temporarily modify the contents of read-only files, without risking permanent changes to them. Using “umount <mount_point>” or simply rebooting is enough to restore everything back to its original configuration.

We hope this trick will be useful in your IoT hacking adventures and hope to see you back for our next IoT fieldnotes post!

About the author

Théo Rigas is an IT Security Consultant at NVISO. He has researched the security of connected alarm systems and is currently working on more IoT and embedded device security projects. Outside of his Research work, he performs Web, Mobile and IoT security assessments for NVISO.

Leave a Reply