Solved: Mounting Block Device under Debian

This is not exactly a installing question, I know :slight_smile:
I have a TP-Link router with USB and a telnet connection. I copied the block devices of the original firmware onto the usb flash device. Now I want to mount the block device under Debian linux to see whats there. How can I do that?

https://manpages.debian.org/jessie/gnome-disk-utility/gnome-disk-image-mounter.1.en.html

1 Like

It depends a bit on what your original blockdevice was - and how your copied it (e.g. NAND needs nanddump instead of dd/ cat).

If you copied the mtds individually, you should be able to just loop mount the files (mount -o loop,ro image.bin /mnt/), if you didn't copy them individually but have the bulk blockdevice, you will need to either cut them later (dd) or use devmapper to map regions of your image file to individual logical volumes.

3 Likes

Hi, for firmware extraction and looking inside I use binwalk (https://github.com/ReFirmLabs/binwalk/wiki/Usage). It's in your package manager.

It takes care of finding/labeling/extracting/ firmware image contents.

2 Likes

I have created the images individually for each mtd device with cat:
cat /dev/mtd0 > /var/usbdisk/sda/mtd0.bck

The gnome-disk-image-mounter does nothing. I provide the mtd file as a parameter and no new filessystems are mounted. If I start it with the GUI, it asks for a file and nothing mor happens.

mount -o loop,ro mtd2.bck /mnt/tmp/

mount: /mnt/tmp: wrong fs type, bad option, bad superblock on /dev/loop5, missing codepage or helper program, or other error.

With binwalk I could extract the root filesystem at mtd2. Thanks :slight_smile:
On the other mtd images, I could extract .7z files, but 7zip says they are broken.
I can install new software on the router. It was ok to copy the data with cat instead of nanddump?

Thats the complete firmware? From /dev/mtd0 to /dev/mtd6

If a NAND-based device, you're playing with fire to use anything but NAND-aware utilities. NAND "naturally" has stuck bits and bad blocks and there is a driver layer that corrects bit errors and remaps bad blocks. Typically only the first block in a NAND chip is "guaranteed" to be good when new, and it may have "bit flips" (within the number of correctable errors). Depending on how the device's NAND drivers are written (most are "custom", rather than from the "approved" ones from upstream Linux from 4.19 onward), utilities like dd and cat on the "raw" device may provide the "wrong" data.

Edit: I typically just use binwalk (with UBI tools available), but you might want to look at https://integriography.wordpress.com/2015/03/16/mounting-a-jffs2-dd-image-in-linux/ if you are intent on formally mounting the image. As I recall, squashfs on UBI is more complex, as there is a "fake block device" on which the squashfs image resides, creating another layer that needs to be replicated on a "desktop" host.

1 Like

I tried the solution with the squashfs device. But it didnt work. But binwalk is enough for me to take a look at the software. Thanks for the NAND clarification, I didnt know about it :slight_smile:

2 Likes

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.