reflections

Using unsupported file systems in X-Ways ForensicsImaging and Mounting

Posted by @my4n6 Sun, February 04, 2018 20:17:14

As a computer forensic examiner I usually use common Software Suites. I do prefer X-Ways Forensics for most of my needs. In some cases I hit upon unsupported file systems. If I have to compare multiple evidences I do prefer not leaving the Software, so what can I do with unsupported file systems, i.e. BTRFS?

Using linux based virtual machines is what I like, unless there is no windows driver to help me import the file and folder structure into my case.

This example will show you "one" possible solution to get the logical files and folders into your case. I will use "NFS" instead of "SAMBA", because it is more "nix".
Shared Folders on Virtual Machines will work too, but if the Image is hosted somewhere else I do prefer "NFS", because it is reliable and fast.


1. Use Linux to mount the BTRFS-Image readonly:


root@VM-CAINE:~# chmod 444 BTRFS.dd

root@VM-CAINE:~# md5sum BTRFS.dd

60139fbf8cda079604367cb4b78c44f9 BTRFS.dd

root@VM-CAINE:~# mmls BTRFS.dd


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 0002097151 0002095104 Linux (0x83)

root@VM-CAINE:~# mount -t btrfs -o ro,loop,offset=$((512*2048)) BTRFS.dd /mnt/BTRFS/


Using "loop" and "offset=$((512*2048))" allows us to mount a partition at a special offset, remember offsets in "mmls" (sleuthkit) are sector based, so we have to do a little math. The "ro" option prevents manipulating the file system. I didn't find any "noload" mount option in BTRFS, so if it is needed to securely prevent journal replay and you know how to do it, send me a tweet on twitter @My4n6 and I will add it.


2. Create a NFS-Export / NFS-Share for the mountpoint:


You might have to install the nfs-kernel-server by using:


sudo apt-get install nfs-kernel-server


The next line will allow the IP-Address 192.168.178.87 to access the files and folders mounted to /mnt/BTRFS by an anon user:

echo '/mnt/BTRFS 192.168.178.87(ro,sync,anonuid,anongid)' >> /etc/exports

You need to refresh nfs by using:

root@VM-CAINE:~# exportfs

/mnt/BTRFS 192.168.178.87

3. Windows needs to be prepared for using NFS:

"NFS" ist not by standard activated under Windows, but it is simple to add this feature:

Blog imageUnder "Control Panel --> Programs --> Programs & Features" you can turn on Windows Features like "NFS".

4. Now mount the NFS-Share in Windows, please remind if you mount it as an administrator you won't see it as a user:

mount -o anon \\192.168.178.89\mnt\BTRFS L:

The IP-Address above belongs to my Linux-Machine hosting the mounted BTRFS.

Blog image
5. Using X-Ways Forensics:


First I tried to import the BTRFS.dd Image. --> "File system unknown "
Blog image
Then I added the share to my case:

Blog image
Blog image

Blog image
and I am able to do my X-Ways Forensics "Refine Volume Snapshot" to get the cakes :-)

Yes I know I am missing deleted files, files system metadata and lot more, but at least I have the content of the files and I am able to see the file and folder structure.

If you need to present the case to someone else it makes sense to use a "X-Ways Forensics Container" and include all the files, hashes and comments etc.

6. Don't forget to unmount the NFS-Share at the end:

Blog image

7. Last but not least! On Linux:

root@VM-CAINE:~# umount /mnt/BTRFS

root@VM-CAINE:~# md5sum BTRFS.dd

60139fbf8cda079604367cb4b78c44f9 BTRFS.dd

Nothing changed!















Mounting .vhdx Images with qemu-nbdImaging and Mounting

Posted by @my4n6 Wed, January 24, 2018 17:22:44

Image mounting in a forensic manner. Using qemu-nbd to mount special image

formats.

Checking the MD5sum of the image:

root@VM-CAINE:~# md5sum IMAGE.vhdx

958e7939cf7ce1e51e4bcbac81f9b5b6 IMAGE.vhdx

What kind of image is it?

root@VM-CAINE:~# file IMAGE.vhdx

IMAGE.vhdx: data

root@VM-CAINE:~# qemu-img info IMAGE.vhdx

image: IMAGE.vhdx

file format: vhdx

virtual size: 1.0G (1073741824 bytes)

disk size: 100M

cluster_size: 33554432

Load the nbd kernel module to work with qemu-nbd:

root@VM-CAINE:~# modprobe nbd max_nbds=10 max_part=10

Map the whole image to /dev/nbd0 (readonly):

root@VM-CAINE:~# qemu-nbd --connect=/dev/nbd0 --read-only IMAGE.vhdx

Partition- and File System checking with the sleuthkit:

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

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 0000000127 0000000128 Unallocated

002: 000:000 0000000128 0002091135 0002091008 NTFS / exFAT (0x07)

003: ------- 0002091136 0002097151 0000006016 Unallocated

root@VM-CAINE:~# fsstat -o 128 /dev/nbd0 | head -n 5

FILE SYSTEM INFORMATION

--------------------------------------------

File System Type: NTFS

Volume Serial Number: D6DC0DD6DC0DB233

OEM Name: NTFS

root@VM-CAINE:~# fls -o 128 /dev/nbd0

r/r 4-128-4: $AttrDef

r/r 8-128-2: $BadClus

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

r/r 6-128-4: $Bitmap

r/r 7-128-1: $Boot

d/d 11-144-4: $Extend

r/r 2-128-1: $LogFile

r/r 0-128-6: $MFT

r/r 1-128-1: $MFTMirr

d/d 40-144-1: $RECYCLE.BIN

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

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

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

r/r 10-128-1: $UpCase

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

r/r 3-128-3: $Volume

r/r 39-128-1: linuxintro-LEFE-4.31.pdf

d/d 36-144-1: System Volume Information

V/V 256: $OrphanFiles

Mapping the Partitions using kpartx (readonly):

root@VM-CAINE:~# kpartx -r -a /dev/nbd0

root@VM-CAINE:~# ls /dev/mapper/

control nbd0p1

Or using qemu-nbd to map the first partition (readonly):

root@VM-CAINE:~# qemu-nbd --connect=/dev/nbd1 -P 1 --read-only IMAGE.vhdx

Mounting the NTFS-File System, different ways:

root@VM-CAINE:~# mount.ntfs -o ro,allow_other /dev/mapper/nbd0p1 /mnt/NTFS/

root@VM-CAINE:~# ls /mnt/NTFS/

linuxintro-LEFE-4.31.pdf $RECYCLE.BIN System Volume Information

root@VM-CAINE:~# umount /mnt/NTFS

root@VM-CAINE:~# mount.ntfs -o ro,show_sys_files,streams_interface=xattr,allow_other /dev/mapper/nbd0p1 /mnt/NTFS/

root@VM-CAINE:~# ls /mnt/NTFS/

$AttrDef $Bitmap $Extend $LogFile $RECYCLE.BIN System Volume Information $Volume

$BadClus $Boot linuxintro-LEFE-4.31.pdf $MFTMirr $Secure $UpCase

root@VM-CAINE:~# umount /mnt/NTFS

Unmap and detach the disk image from the system:

root@VM-CAINE:~# kpartx -d /dev/nbd0

root@VM-CAINE:~# qemu-nbd -d /dev/nbd0

/dev/nbd0 disconnected

Final check of the md5sum. Everything OK!

root@VM-CAINE:~# md5sum IMAGE.vhdx

958e7939cf7ce1e51e4bcbac81f9b5b6 IMAGE.vhdx





Virtual write support on blocked disksImaging and Mounting

Posted by @my4n6 Sat, January 20, 2018 11:03:47

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