1

I was presented with a task. I have .vmdk disk available and I have to check its contents - forensically check the data on it without modifiying it and then check whether some data on this disk has been deleted. I also have to check whether some data has been deliberately hidden somewhere on the disk.

I do not know a lot about disks, so any help (also just the basic idea of how to solve this task) would be very appreciated.

What I have done so far (I am working on Linux Ubuntu)

As I understand, merely mounting the .vmdk with mount is not OK, since this immediately writes some data on the disk and the disk as evidence is therefore not valid anymore.

I came up with the idea to convert .vmdk disk to .raw file with:

qemu-img convert vmdk original.vmdk -m 16 -p -O raw converted.raw

and then just check the contents of .raw with cat.

But how do I check if something has been modified or deliberately hidden on .vmdk disk without modifying it so that the disk can still be presented as valid evidence?

1 Answer 1

0

"As I understand, merely mounting the .vmdk with mount is not OK, since this immediately writes some data on the disk and the disk as evidence is therefore not valid anymore." -- you're right, but remember you can copy a vmdk image and operate on the copy. That defuses the "proof contamination" problem. Also, you will want to copy the VMDK on the fastest device available (e.g. internal NVMe).

As for the deletion, you might need to check several boxes.

  • Evidence for deleted files may be uncovered by using the undelete utility appropriate for the file system. This is the fastest way for common deletions.
  • Evidence for deleted and scrubbed, but not (completely) overwritten files may be detected running a variance analysis on the "free" space. This is especially good for deleted compressed archives (PDF, JPG, MP3, video files, DOCX; not for text files. For those, a frequency analysis is called for). You'll also need specialized tools to do this efficiently.
  • In addition, a further more lengthier, more complex method is to examine the slack space on the file system: FS space is usually allocated in blocks, blocks are usually of a fixed size (e.g. 64K) or a few fixed sizes, so when you write a e.g. 12 Kb file, the FS locks a free block and of course writes on the first 12 Kb of it. All well and good, but... what is in the rest of the block? In most unsecured system, the answer is: whatever was written there before, when the block was part of a no-longer-existing file. But that small sample is now immortalized by being owned by a different file, that has not been deleted. You need to either examine physically the block or have access to an API that will change a file size without erasing the space (i.e., when changing the file size to the next multiple of the block size, the space reclaimed must not be zeroed, obviously).
  • data might be hidden or left over in less usual places - Alternate Data Streams, manifests, inodes, resource forks, or thumbnail files (when you delete a JPEG, the Thumbs.db file for that directory might not be updated immediately, and might yield a small, low-res crop of the lost image).
  • indirect and less damning evidence could be gleaned from the existence of empty areas in the logical block map that do not fit the filesystem's choice of allocation strategy. These areas being completely blank are a strong hint that something has been carefully scrubbed, and sometimes the data on the files owning the blocks immediately before and after the blanks might yield information about the missing content.

Some very useful information may be found, if available - not in your case, I gather - in files such as vmname-number.vmdk, vmname-number-delta.vmdk, vmname-number-sesparse.vmdk that might contain snapshots from before the deletion took place.

Without knowing what file system is on the VMDK, it's difficult to be more precise.

Also, in many cases you might have an inkling about some cleartext keywords that might be in the target data. In that case a simple strings command followed by grep can be used to quickly zoom on the relevant areas of the VMDK.

2
  • mount -ro should not write to the partition but I would still avoid it to eliminate any possibility of contamination. I might suggest making a snapshot of the vmdk and mounting that. Essentially the same as making a copy but possibly conceptionally simpler.
    – doneal24
    Apr 18, 2023 at 18:44
  • 1
    There are some circumstances where just using -ro is not enough. github.com/msuhanov/Linux-write-blocker "Note that, depending on the filesystem type, state and kernel behavior, the system may still write to the device. For example, Ext3 or ext4 will replay its journal if the filesystem is dirty. To prevent this kind of write access, you may want to mount ext3 or ext4 filesystem with "ro,noload" mount options or set the block device to read-only mode, ..."
    – secfren
    Apr 18, 2023 at 22:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .