±Forensic Focus Partners

Become an advertising partner

±Your Account


Username
Password

Forgotten password/username?

Site Members:

New Today: 1 Overall: 34295
New Yesterday: 7 Visitors: 249

±Follow Forensic Focus

Forensic Focus Facebook PageForensic Focus on TwitterForensic Focus LinkedIn GroupForensic Focus YouTube Channel

RSS feeds: News Forums Articles

±Latest Articles

RSS Feed Widget

±Latest Webinars

Destination drives smaller than the source drives

Computer forensics discussion. Please ensure that your post is not better suited to one of the forums below (if it is, please post it there instead!)
Reply to topicReply to topic Printer Friendly Page
Forum FAQSearchView unanswered posts
Go to page 1, 2  Next 
  

Destination drives smaller than the source drives

Post Posted: Wed May 16, 2018 8:24 am

The day is finally here, usually we buy 3gb HDD's in bulk and the image process is no problem. However in one case right now the suspect had 4 disks, 8gb each. The destination drives is much smaller than the source drives.

How would you guys go ahead and image these? In fragments using FTK Imager? Won't that be a mess anyways? I would need to mount 3 Hdd's in order to index and examine the evidence.
How will the fragmented, i.e 01.E01, 02.E01 etc affect the hash values?  

imsdal
Member
 
 
  

Re: Destination drives smaller than the source drives

Post Posted: Wed May 16, 2018 12:48 pm

You can try to create a RAID and E01 compression.
_________________
"Simplicity is the ultimate sophistication." 

calimelo
Senior Member
 
 
  

Re: Destination drives smaller than the source drives

Post Posted: Wed May 16, 2018 1:01 pm

As calimelo suggested, since you need a temporary solution for this task only, having handy the original source drives if anything goes wrong, it is pretty safe to create a RAID0 (stripe) from the smaller drives you got.

For the long run I really suggest you to get drives big enough to handle your tasks. Please don't rely on a temporary solution like this, because if any fault occurs on any of the RAID0 members, it will cause total data loss!
_________________
With a little luck, I can access Android userdata partitions from binary dumps. Full dump is required, physical access to the device helps a lot, but it is optional. 

passcodeunlock
Senior Member
 
 
  

Re: Destination drives smaller than the source drives

Post Posted: Wed May 16, 2018 4:20 pm

How full are the source drives?

And what kind of content do the source disks contain? Some file types compress really well, others won't compress at all as they are random data, encrypted data or already compressed.

If the disks aren't full then, if you were desperate, you could just take the files and ignore the free / allocated space (Sometimes called a logical image). Depends on the nature of the job as well.

If you don't have RAID hardware have a look at Storage Spaces in Win10
support.microsoft.com/...age-spaces
(note that I haven't tried it myself, but it seems like it should work)  

Passmark
Senior Member
 
 
  

Re: Destination drives smaller than the source drives

Post Posted: Thu May 17, 2018 2:25 am

Hey guys, Dynamic Disks anyone?

They are around since Windows 2000, no need for fancy RAID hardware.

Of course a more recent Windows will be needed to use 3 TB disks, but anything Vista or later would do, and since OP is already using them, it means that he already has a 2TB+ compatible OS.

jaclaz
_________________
- In theory there is no difference between theory and practice, but in practice there is. - 

jaclaz
Senior Member
 
 
  

Re: Destination drives smaller than the source drives

Post Posted: Thu May 17, 2018 7:58 pm

Dynamic disks are now considered deprecated.

See,
msdn.microsoft.com/en-...gement-api  

Passmark
Senior Member
 
 
  

Re: Destination drives smaller than the source drives

Post Posted: Thu May 17, 2018 11:05 pm

- Passmark
Dynamic disks are now considered deprecated.


That seems to be relevant for anyone creating storage solutions, i.e. using dynamic disk management APIs and tools as an architectural component in applications or systems. Basically, if you base your solution on VDS API, you may be in for a surprise as Microsoft is going towards WMI instead.

But is that the suggested usage here? I got the impression that it was more of a 'how do we solve this particular problem in this particular case?' question.

The 'depreciation period' mentioned in the cited page is not stated, it seems. The table suggests that it may be related to the transition from VDS API to WMI as well as the transition from Disk Management GUI to Powershell etc., but nowhere is there an indication that backwards compatibility will be lost entirely in a near future, only that current management solutions are being transitioned.

As long as it's a temporary solution, and in the absense of indications of disk structure support going end-of-life I wouldn't worry too much. If the images are something that needs to be archived for multiple years, support for dynamic disk on-disk structures will be necessary to keep track of, of course. But that is true for RAID solutions as well. I'd try to verify that some current Linux is able to read the resulting disc structure, and add a copy of it to the archive as a alternative access method in case Windows 11 drops support for dynamic disk HDDs altogether.  

athulin
Senior Member
 
 

Page 1 of 2
Go to page 1, 2  Next