Imagine you are forced to do a forensic investigation on a disk, but you are not allowed to create a forensic copy first. You are not able to remove the disk and therefore not able to use a hardware blocker. You do know that you may need to tamper files for your analysis, but you are usually not willing to do this. What can you do?

Starting the System with a forensic Linux Live CD like “caine” or “deft” is one of the possible solutions.

In this “reflection” I will use the Linux Live System “Caine 9.0” installed to a VM and modified for my purposes. I am trying to tamper data on a USB-Pendrive virtually.


First I attach the USB-Pendrive and check the device-name:

root@VM-CAINE:~# dmesg | tail -n 20

[43089.772532] usb 1-1: New USB device found, idVendor=090c, idProduct=1000

[43089.772535] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3

[43089.772536] usb 1-1: Product: USB DISK

[43089.772537] usb 1-1: Manufacturer: SMI Corporation

[43089.772538] usb 1-1: SerialNumber: 00000000000000001988

[43089.778152] usb-storage 1-1:1.0: USB Mass Storage device detected

[43089.778751] scsi host7: usb-storage 1-1:1.0

[43090.785858] scsi 7:0:0:0: Direct-Access USB Flash Disk 2040 PQ: 0 ANSI: 0 CCS

[43090.786434] sd 7:0:0:0: Attached scsi generic sg2 type 0

[43090.797809] sd 7:0:0:0: [sdb] 245504 512-byte logical blocks: (126 MB/120 MiB)

[43090.804829] sd 7:0:0:0: [sdb] Write Protect is off

[43090.804832] sd 7:0:0:0: [sdb] Mode Sense: 43 00 00 00

[43090.812159] sd 7:0:0:0: [sdb] No Caching mode page found

[43090.812163] sd 7:0:0:0: [sdb] Assuming drive cache: write through

[43090.862938] sdb: sdb1

[43090.904296] sd 7:0:0:0: [sdb] Attached SCSI removable disk


Because I am not using a hardware blocker I need to check the

blocking status of the disk. The commands “blockdev” and “hdparm”

can be used to do a kind of software blocking on the device.

The command “blockdev –report /dev/sdb*” checks the blocking status

on the device “sdb” and its partition “sdb1”.

ATTENTION: Maxim Suhanov ( does talk about possible pitfalls while using the options above. Especially dealing with journal file systems, LVM and DM-Raid, a physical drive may be written to, before udev-rules with hdparm or blockdev have set the read-only flag. Some file system driver do have special options to prevent writing through. Test your Tools! Prefer working on forensic images, deactivate auto-mounting.

root@VM-CAINE:~# blockdev –report /dev/sdb*

NurL RA SGr BGr Startsek Größe Gerät

rw 256 512 4096 0 125698048 /dev/sdb

rw 256 512 4096 2048 124649472 /dev/sdb1

Because “ro” is not set, use the command “blockkdev –setro /dev/sdb*” to set

the “ro” flag.

root@VM-CAINE:~# blockdev –setro /dev/sdb*

Another Check. Everything fine!

root@VM-CAINE:~# blockdev –report /dev/sdb*

NurL RA SGr BGr Startsek Größe Gerät

ro 256 512 4096 0 125698048 /dev/sdb

ro 256 512 4096 2048 124649472 /dev/sdb1


Before I start to virtually manipulate the disk I check the md5sum of

the device.

root@VM-CAINE:~# md5sum /dev/sdb

0549b7cd101d54199c74143857f5d387 /dev/sdb


So lets try if the blocking is working! Suicide! 🙂

The following dd command overwrites the data on a disk with

zero values. But here it quits and says “writing not allowed”.

root@VM-CAINE:~# dd if=/dev/zero of=/dev/sdb

dd: Schreiben in ‘/dev/sdb’: Vorgang nicht zulässig

1+0 Datensätze ein

0+0 Datensätze aus

0 bytes copied, 0.000245053 s, 0.0 kB/s

Checking the md5sum will confirm this.

root@VM-CAINE:~# md5sum /dev/sdb

0549b7cd101d54199c74143857f5d387 /dev/sd


I am interested on the structure of the disk. The sleuthkit command mmls

shows the media management layer (Partitions) of the disk.

root@VM-CAINE:~# mmls /dev/sdb

DOS Partition Table

Offset Sector: 0

Units are in 512-byte sectors

Slot Start End Length Description

000: Meta 0000000000 0000000000 0000000001 Primary Table (#0)

001: ——- 0000000000 0000002047 0000002048 Unallocated

002: 000:000 0000002048 0000245503 0000243456 NTFS / exFAT (0x07)

The sleuthkit command fsstat shows the file system statistic of the Partition sdb1, i.e. type of file system (if supported).

root@VM-CAINE:~$ fsstat /dev/sdb1 | head



File System Type: NTFS

Volume Serial Number: 667CB02A6C3FD2E8


Volume Name: NTFS

Version: Windows XP



What files do I find on the root of the file system. The sleuthkit command fls shows

the files and folders with their inode number (file record on ntfs).

root@VM-CAINE:~# fls /dev/sdb1

r/r 4-128-1: $AttrDef

r/r 8-128-2: $BadClus

r/r 8-128-1: $BadClus:$Bad

r/r 6-128-1: $Bitmap

r/r 7-128-1: $Boot

d/d 11-144-2: $Extend

r/r 2-128-1: $LogFile

r/r 0-128-1: $MFT

r/r 1-128-1: $MFTMirr

r/r 9-128-2: $Secure:$SDS

r/r 9-144-3: $Secure:$SDH

r/r 9-144-4: $Secure:$SII

r/r 10-128-1: $UpCase

r/r 10-128-2: $UpCase:$Info

r/r 3-128-3: $Volume

r/r 64-128-2: Automating Disk Forensic Processing with SleuthKit XML and Python.pdf

V/V 65: $OrphanFiles


For my example of virtually tampering the filesystem I try to delete the .pdf file on sdb1. Why this? Just for fun!
Imagine you want to start the operating system on a disk in a virtual environment (virtualizing the operating system) and you need to clear or change the password of the login. That is a real world example 🙂

So, using xmount from Daniel Gillen is probably the best way to mount forensic images. It supports raw files, .E01 and .aff files and lots more.

Question: Isn’t a disk also a raw file?! Remember, on linux everything is a file!

Let’s try this!

root@VM-CAINE:~# xmount –owcache tempfile –in raw /dev/sdb –out raw xm

root@VM-CAINE:~# ls xm


What did we do? We mounted the raw disk to a raw file using a temporary cache file to get virtual write support.


Now let’s create a blockdevice from the raw file xm/sdb.dd, but concentrate just on the NTFS file system witch is located on Sector 2048, the sector size is 512. A little calculation is needed.

root@VM-CAINE:~# losetup -o $((2048*512)) -f xm/sdb.dd

root@VM-CAINE:~# losetup -a

/dev/loop6: [0050]:2 (/home/my4n6/xm/sdb.dd), offset 1048576


Now let us mount the NTFS file system read write!

root@VM-CAINE:~# mount -t ntfs -o rw /dev/loop6 mp/

root@VM-CAINE:~# ls mp

Automating Disk Forensic Processing with SleuthKit XML and Python.pdf


I want to delete the .pdf file. Just for fun 🙂

root@VM-CAINE:~# rm mp/Automating\ Disk\ Forensic\ Processing\ with\ SleuthKit\ \ XML\ and\ Python.pdf

… and it is gone!

root@VM-CAINE:~# ls mp/



Unmount the file system!

root@VM-CAINE:~# umount mp/

Detach the virtual drive!

root@VM-CAINE:~# losetup -d /dev/loop6

Unmount the xmounted disk!

root@VM-CAINE:~# umount xm


Did the md5 of the USB-Pendrive change? No, not at all!

root@VM-CAINE:~# md5sum /dev/sdb

0549b7cd101d54199c74143857f5d387 /dev/sdb

Keep the xmount cache file. You will be able to reproduce the result. If you want to remount the disk with xmount and the cache file, use –cache instead of –owcache.
“–cache” will reuse your cache file.
Think about imaging the virtually tempered disk. You will be able to compare it with the image of the original disk and document your changes.


Please accept that I do not give any guaranty for this workaround! Test your tools! You are the person who will have to testify in court for your analysis.

I strictly do not recommend working directly on the evidence, but if you are forced to do it, this workaround may help you.

@my4n6 20.01.2018