Notifications
Clear all

Analyze vdi file

10 Posts
4 Users
0 Likes
3,398 Views
(@ibernato)
Posts: 28
Eminent Member
Topic starter
 

Hello to all,
I have to analyze a virtual machine (virtualbox) that has the vdi format.
Unfortunately FTK imager fails to open the file.
Is it right to convert the vdi file to raw with vboxmanage and then analyze it with the foremost tools, photorec?

 
Posted : 01/10/2019 10:14 am
keydet89
(@keydet89)
Posts: 3568
Famed Member
 

What happens when you try that?

 
Posted : 01/10/2019 12:25 pm
(@rich2005)
Posts: 535
Honorable Member
 

X-Ways should be able to read VDIs I believe (although I'm guessing you don't have that or you'd have just used it).

 
Posted : 01/10/2019 2:12 pm
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

And - just for the record - there are several formats of .vdi files, among which the "fixed" or "flat" type is already a RAW image with a number of sectors (header) prepended to it.

The command
VBoxManage internalcommands dumphdinfo IMAGE

will tell you the kind of image and the offset to the MBR (in case it is a flat file you can simply strip the initial bytes until the MBR and then it will be a RAW image).

Example
https://www.mimamau.de/stuff/mount_vdi_linux.htm

in the above the offset to the MBR is the "plain" offData=36864, the example is to get the volume start and thus it adds one head, i.e. 63*512=32256

jaclaz

 
Posted : 01/10/2019 3:41 pm
(@ibernato)
Posts: 28
Eminent Member
Topic starter
 

And - just for the record - there are several formats of .vdi files, among which the "fixed" or "flat" type is already a RAW image with a number of sectors (header) prepended to it.

The command
VBoxManage internalcommands dumphdinfo IMAGE

will tell you the kind of image and the offset to the MBR (in case it is a flat file you can simply strip the initial bytes until the MBR and then it will be a RAW image).

Example
https://www.mimamau.de/stuff/mount_vdi_linux.htm

in the above the offset to the MBR is the "plain" offData=36864, the example is to get the volume start and thus it adds one head, i.e. 63*512=32256

jaclaz

Thanks.
I have a question.
I tried to delete some pdf files, then I ran foremost to try to recover them, but I got nothing.
Why? The virtual machine is installed on an HDD, so deletion does not occur immediately as with SSDs.
Am I wrong?

 
Posted : 02/10/2019 8:16 am
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

The virtual machine is installed on an HDD, so deletion does not occur immediately as with SSDs.
Am I wrong?

Why wrong?
Your statement more than wrong is absolutely non-consequential.

Example of consequential statement
Today the sun is shining, so there are little chances that my postillion could be struck by lightning. 😯

Example of non consequential statement
Today the sun is shining, so the cake is baking in the oven.

There are a zillion reasons why a just deleted file in a VM may or may not be recovered/found by a carving pass, including as non-exhaustive list
Operating system in use
Filesystem in use
Fragmentation status of the filesystem
Exact method of deletion
Exact method of creation/saving of the file
Exact type of backing image (if any) and actual device hosting it
Activity, manual or automated after the deletion occurred
… insert here another few tens of reasons

The ONLY unrelated reason seems having the VM installed on a hard disk as opposed to a SSD.
I mean, nothing prevents you from having the VM installed on hard disk BUT have the image on the SSD, the point is however that unless you mount the SSD directly as physicaldrive for all the SSD knows the filesystem image is just a (largish) file, nothing connected to the SSD operation (TRIM, garbage collection, DRAT, DZAT or *whatever*) should affect the contents of a file.

jaclaz

 
Posted : 02/10/2019 8:45 am
(@ibernato)
Posts: 28
Eminent Member
Topic starter
 

Why wrong?
Your statement more than wrong is absolutely non-consequential.

Example of consequential statement
Today the sun is shining, so there are little chances that my postillion could be struck by lightning. 😯

Example of non consequential statement
Today the sun is shining, so the cake is baking in the oven.

There are a zillion reasons why a just deleted file in a VM may or may not be recovered/found by a carving pass, including as non-exhaustive list
Operating system in use
Filesystem in use
Fragmentation status of the filesystem
Exact method of deletion
Exact method of creation/saving of the file
Exact type of backing image (if any) and actual device hosting it
Activity, manual or automated after the deletion occurred
… insert here another few tens of reasons

The ONLY unrelated reason seems having the VM installed on a hard disk as opposed to a SSD.
I mean, nothing prevents you from having the VM installed on hard disk BUT have the image on the SSD, the point is however that unless you mount the SSD directly as physicaldrive for all the SSD knows the filesystem image is just a (largish) file, nothing connected to the SSD operation (TRIM, garbage collection, DRAT, DZAT or *whatever*) should affect the contents of a file.

jaclaz

Ok, So what would be the correct procedure?
I'm currently doing this
- I created a logical partition E
- I create the virtual machine on partition E (Windows 10, ntfs file system)
- Download files to PDF
- Delete files (Delete + empty recycle)

On SSD I have the virtualbox software and a Kali Linux virtual machine.
- I open Kali Linux and with the foremost tool I analyze the file windows10.vmdk.

Host system Windows 10

 
Posted : 02/10/2019 9:07 am
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

Ok, So what would be the correct procedure?
I'm currently doing this
- I created a logical partition E
- I create the virtual machine on partition E (Windows 10, ntfs file system)
- Download files to PDF
- Delete files (Delete + empty recycle)

On SSD I have the virtualbox software and a Kali Linux virtual machine.
- I open Kali Linux and with the foremost tool I analyze the file windows10.vmdk.

Host system Windows 10

From what I can get the procedure is fine, though you are omitting all the relevant details (and providing a few unneeded ones), you can create the VM on an external disk, on a USB stick, the relevant point is whether you are using a file (.vdi, .vmdk. etc.) for the virtual mass storage device (as opposed to a physicaldrive) what specific format of the file you are using (flat/static, sparse/dynamic/growable, redo/snapshot, etc.) which filesystem is used in the volumes in it and which OS you are running inside the VM.

Here are the actual relevant parts
WHICH EXACT format is the image file (if any) used in the VM?
WHICH filesystem is used in the partition(s)/volume(s) inside it?
WHICH Operating System are you using inside the VM?
WHICH EXACT procedure are you using to create the test files on that filesystem?
WHICH EXACT procedure are you using to delete the test files from that filesystem?
WHICH EXACT procedure are you using to attempt to retrieve the (deleted) test files from that filesystem?

You seem like missing some basic concepts of what a VM and what its (virtual) mass storage devices are.

A VM is a Virtual Machine, i.e. a Machine that exists in software only and that represents (with some limits) an (almost) exact replica of real hardware.

The Virtual Machine is the (simulated) hardware.

On real hardware you
attach some mass storage devices (physical disks), you partition them, create volumes and format them then you install an OS to one of the volumes, make it bootable, etc..

In a Virtual machine you
attach some (virtual) mass storage devices (usually in the form of a virtual disk file) , you partition them, create volumes and format them then you install an OS to one of the volumes, make it bootable, etc..

Now, what is vital is the exact actual format of the virtual disk file.

Since you are using Virtualbox and your intention is to use it to simulate the real behaviour on real hardware of this (or that) OS and procedure, you want to choose a format that is the most similar to the "real" physical disk drive.

This format is a flat .vmdk, which is nothing but a RAW image file (thus compatible with *any* forensic software) + descriptor file, see

https://www.forensicfocus.com/Forums/viewtopic/t=15861/

or - alternatively - you can connect (almost) directly a physicaldrive to the VM, and this (and this only) would be the case where a different device (hard disk vs. SSD) may provide different results for the same procedure.

So, if the Windows10.vmdk you mention is a flat .vmdk (again a RAW file with a .vmdk descriptor), your setup seems just fine.
Usually virtualbox would create a descriptor file (less than 1 kb in size) Windows10.vmdk and the actual RAW disk image file named Windows10-flat.vmdk.

You can (with the VM turned off) mount the RAW file with Kali Linux (or whatever) and then run *any* tool on the mounted image or, in the case of foremost you can use the image offline without mounting it, i.e. (very basically)
foremost -t pdf -i Windows10-flat.vmdkis this what you are doing?

jaclaz

 
Posted : 02/10/2019 2:39 pm
(@ibernato)
Posts: 28
Eminent Member
Topic starter
 

Ok, So what would be the correct procedure?
I'm currently doing this
- I created a logical partition E
- I create the virtual machine on partition E (Windows 10, ntfs file system)
- Download files to PDF
- Delete files (Delete + empty recycle)

On SSD I have the virtualbox software and a Kali Linux virtual machine.
- I open Kali Linux and with the foremost tool I analyze the file windows10.vmdk.

Host system Windows 10

From what I can get the procedure is fine, though you are omitting all the relevant details (and providing a few unneeded ones), you can create the VM on an external disk, on a USB stick, the relevant point is whether you are using a file (.vdi, .vmdk. etc.) for the virtual mass storage device (as opposed to a physicaldrive) what specific format of the file you are using (flat/static, sparse/dynamic/growable, redo/snapshot, etc.) which filesystem is used in the volumes in it and which OS you are running inside the VM.

Here are the actual relevant parts
WHICH EXACT format is the image file (if any) used in the VM?
WHICH filesystem is used in the partition(s)/volume(s) inside it?
WHICH Operating System are you using inside the VM?
WHICH EXACT procedure are you using to create the test files on that filesystem?
WHICH EXACT procedure are you using to delete the test files from that filesystem?
WHICH EXACT procedure are you using to attempt to retrieve the (deleted) test files from that filesystem?

You seem like missing some basic concepts of what a VM and what its (virtual) mass storage devices are.

A VM is a Virtual Machine, i.e. a Machine that exists in software only and that represents (with some limits) an (almost) exact replica of real hardware.

The Virtual Machine is the (simulated) hardware.

On real hardware you
attach some mass storage devices (physical disks), you partition them, create volumes and format them then you install an OS to one of the volumes, make it bootable, etc..

In a Virtual machine you
attach some (virtual) mass storage devices (usually in the form of a virtual disk file) , you partition them, create volumes and format them then you install an OS to one of the volumes, make it bootable, etc..

Now, what is vital is the exact actual format of the virtual disk file.

Since you are using Virtualbox and your intention is to use it to simulate the real behaviour on real hardware of this (or that) OS and procedure, you want to choose a format that is the most similar to the "real" physical disk drive.

This format is a flat .vmdk, which is nothing but a RAW image file (thus compatible with *any* forensic software) + descriptor file, see

https://www.forensicfocus.com/Forums/viewtopic/t=15861/

or - alternatively - you can connect (almost) directly a physicaldrive to the VM, and this (and this only) would be the case where a different device (hard disk vs. SSD) may provide different results for the same procedure.

So, if the Windows10.vmdk you mention is a flat .vmdk (again a RAW file with a .vmdk descriptor), your setup seems just fine.
Usually virtualbox would create a descriptor file (less than 1 kb in size) Windows10.vmdk and the actual RAW disk image file named Windows10-flat.vmdk.

You can (with the VM turned off) mount the RAW file with Kali Linux (or whatever) and then run *any* tool on the mounted image or, in the case of foremost you can use the image offline without mounting it, i.e. (very basically)
foremost -t pdf -i Windows10-flat.vmdkis this what you are doing?

jaclaz

Yes exactly.
I have the windows-flat.vmdk file

Thanks man.

 
Posted : 03/10/2019 11:24 am
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

Yes exactly.
I have the windows-flat.vmdk file

Thanks man.

Good.
You are welcome, I am sure.

jaclaz

 
Posted : 03/10/2019 12:22 pm
Share: