1

I have a 500GB raw disk image file on my HDD that I’ve called dysk.img and that is a result of dd'ing the contents of an external single NTFS partion drive. Its purpose is to attempt data recovery with the ntfsundelete program (and the results of the initial scan are promising).

Before that, however, I’d like to examine its current, not deleted content. Thus I’d like to mount it. For obvious reasons, I want to ensure that mounting this file will not result in a single bit being written to it.

mount --read-only doesn’t seem to be the solution, sadly. Because, according to man mount:

Note that, depending on the filesystem type, state and kernel behavior, the system may still write to the device. For example, ext3 and ext4 will replay the journal if the filesystem is dirty. To prevent this kind of write access, you may want to mount an ext3 or ext4 filesystem with the ro,noload mount options or set the block device itself to read-only mode, see the blockdev(8) command.

Can the above apply to NTFS as well? Sadly mount doesn’t support the noload option…

Unfortunately, I had carelessly written some files with Windows-incompatible names (containing the ? character for instance), and this had made Windows mark this filesystem for scheduled check – thus, I’m getting constant warnings from ntfsundelete now and cannot run ntfsundelete without the --force option. Can this further increase the risk of some accidental writes?

As of now, only root has write access to this file. I’m not sure if this is enough, as IIUC there’s always some rights elevation when mounting.

Would making root the owner of this file and denying anyone, even the owner, write access be helpful?

Would it be helpful to attempt to use the blockdev command suggested by man mount to this file? Or would it be risky or harmful to issue blockdev --setro to an image file, as opposed to an actual device?

Gilles 'SO- stop being evil'
  • 807,993
  • 194
  • 1,674
  • 2,175
gaazkam
  • 1,400
  • 3
  • 10
  • 17
  • 1
    You could always `chattr +i` the image file. :) Now, allow me to make a small self-promotion... my open source software called RecuperaBit reconstructs NTFS and it doesn't write *anything* on the image file. – Andrea Lazzarotto Feb 12 '17 at 18:07
  • @AndreaLazzarotto Thank you, it really helped me! You really should convert this comment to an answer, so I can upvote and accept it. BTW, if I can suggest something, it would be convenient if you’d allow writing the tree directory structure to a file. – gaazkam Mar 09 '17 at 17:33
  • Good! But which one of my remarks helped you precisely? The one about chattr or the one about RecuperaBit? Please add suggestions to the issue tracker on GitHub. :) – Andrea Lazzarotto Mar 12 '17 at 01:12
  • @AndreaLazzarotto Well, your RecuperaBit managed to recover most of the important data that had been lost :) – gaazkam Mar 14 '17 at 11:40

1 Answers1

2

Part of the answer you are looking for is given in the quote you've cited:

set the block device itself to read-only mode

In your case, that's a simple file. So you can:

chmod a-w disk.img

Not even the owner needs to write to it.

Would making root the owner of this file and denying anyone, even the owner, write access be helpful?

Basically, yes, but remember that root can bypass most permission "limitations". So you should run your data recovery program as a user different from root.

If you want to mount the file, you cannot simply do that. However, if the image file is saved inside a file system that support chattr (basically EXT4 and other common Linux file systems) you can make the file immutable:

chattr +i disk.img

Now not even root can do anything to it. It cannot be written or deleted. Use chattr -i to revert the flag after you are done.

Alternative approach

If you want to extract data from a (possibly damaged) NTFS drive, you might want to consider using RecuperaBit, which is a software I developed to perform file system reconstruction. Currently it only supports NTFS, but it has a couple of advantages:

  • It doesn't write anything on the image file. Simply put, it doesn't support writing on a drive, because it's oriented to digital forensics. Hence you don't risk doing it accidentally.

  • It can read the directory tree even if it's broken. You will get the most accurate depiction of each partition, at least from the metadata that is available.

I have discussed its usage in the following answers:

Community
  • 1
Andrea Lazzarotto
  • 526
  • 5
  • 15