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 (https://github.com/msuhanov/Linux-write-blocker) 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 INFORMATION
——————————————–
File System Type: NTFS
Volume Serial Number: 667CB02A6C3FD2E8
OEM Name: NTFS
Volume Name: NTFS
Version: Windows XP
METADATA INFORMATION
——————————————–
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
sdb.dd sdb.info
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/
root@VM-CAINE:~#
————————————————————————————————–
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