±Forensic Focus Partners

Become an advertising partner

±Your Account


Username
Password

Forgotten password/username?

Site Members:

New Today: 0 Overall: 35965
New Yesterday: 0 Visitors: 144

±Follow Forensic Focus

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

RSS feeds: News Forums Articles

±Latest Articles

±Latest Videos

±Latest Jobs

Is my winhex gather free space doing what it's supposed to?

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
Page Previous  1, 2 
  

jaclaz
Senior Member
 

Re: Is my winhex gather free space doing what it's supposed

Post Posted: Mar 04, 18 12:00

- loonaluna

Another thing, these two big chunks are not exactly the size I remember them to be, they're about 52gb and 74gb, whereas I vaguely remember them to be around 50gb and 75gb, but I could be wrong.


Well, it is not like the containers (and the containers only) equates to the free space.

It is possible that the situation on disk around the "52 GB chunk" and/or "50 GB container" (before you accidentally deleted the container was (U for unallocated space C for container, F for some other files) something *like*:
FFUCCCCCUFFF
that became after the accidental deletion:
FFUUUUUUUFFF

If this is the case, the actual header (if survived) may well be 1 or 2 GB off the beginning of the unallocated large chunk.

In the case of the the 74 GB chunk where you remember a 75 GB container it could be that some data was re-written/re-allocated, in which case it may depend if the re-written area is at the beginning (and thus the bootsector has been overwritten) or at the end of the chunk.

In any case the sizes of the "chunks" you found and of the containers you remember are similar enough to allow excluding large parts of the disk.

If you remember a 50 GB container and find a 52 GB chunk, the bootsector can only logically be (if it survived) within the first 2 GB of the chunk, let's make it - to be on the safe side and to take care of the possible mis-measurement due to K/M/G being calculated with base 1000 or 1024 and your memory - double that, 4 GB.

It would make sense to extract only the first 4 GB of the 52 GB unallocated chunk and look only there for the bootsector (via the hunt.py or *whatever* similar tool).

Same goes for the other "chunk", given that your memory is approximate, at the very most the difference is within the initial 4 or - again let's make an "abundant" calculation - 5 GB of the unallocated "chunk".

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

loonaluna
Member
 

Re: Is my winhex gather free space doing what it's supposed

Post Posted: Mar 09, 18 20:22

- jaclaz


If this is the case, the actual header (if survived) may well be 1 or 2 GB off the beginning of the unallocated large chunk.

In the case of the the 74 GB chunk where you remember a 75 GB container it could be that some data was re-written/re-allocated, in which case it may depend if the re-written area is at the beginning (and thus the bootsector has been overwritten) or at the end of the chunk.

In any case the sizes of the "chunks" you found and of the containers you remember are similar enough to allow excluding large parts of the disk.



I couldn't help but notice when looking at a flash drive I was messing around with this week, that even though the sectors that were currently occupied were in the middle of the drive, defraggler showed the first sectors of the drive as the ones that were occupied. Winhex was contradictory, in the bottom half of the screen that shows the blocks, it showed this file beginning at about cluster number 90000, while the file reconstruction area of the winhex claimed its first sector was around 750000 or so. A brute hunt with pytruecrypt confirmed that it was indeed sitting at sector 750000 as that's where the header turned out to be. Does this mean that the information shown below in winhex, that shows only blocks but doesn't reconstruct files or file systems, isn't reliable and that a lot of file re-allocation goes on, even in HDDs, that make file recovery extremely difficult? If this is happening, does a write of a new file draw randomly from all parts of the drive, or does it stick to its own succession of blocks? Or maybe FAT32 of a flash drive behaves differently than an NTFS of an HDD? Still, I'm wondering if this would explain why Winhex was interpreting as free space, space that wasn't actually free space, or if it takes credibility away from the supposed two big blocks of space that are currently supposed to be sitting on the HDD.  
 
  

jaclaz
Senior Member
 

Re: Is my winhex gather free space doing what it's supposed

Post Posted: Mar 10, 18 11:50

- loonaluna

I couldn't help but notice when looking at a flash drive I was messing around with this week, that even though the sectors that were currently occupied were in the middle of the drive, defraggler showed the first sectors of the drive as the ones that were occupied. Winhex was contradictory, in the bottom half of the screen that shows the blocks, it showed this file beginning at about cluster number 90000, while the file reconstruction area of the winhex claimed its first sector was around 750000 or so. A brute hunt with pytruecrypt confirmed that it was indeed sitting at sector 750000 as that's where the header turned out to be. Does this mean that the information shown below in winhex, that shows only blocks but doesn't reconstruct files or file systems, isn't reliable and that a lot of file re-allocation goes on, even in HDDs, that make file recovery extremely difficult? If this is happening, does a write of a new file draw randomly from all parts of the drive, or does it stick to its own succession of blocks? Or maybe FAT32 of a flash drive behaves differently than an NTFS of an HDD? Still, I'm wondering if this would explain why Winhex was interpreting as free space, space that wasn't actually free space, or if it takes credibility away from the supposed two big blocks of space that are currently supposed to be sitting on the HDD.


Well, no idea, I cannot understand more than half what you are reporting.

You seem like having a not fully formed idea of the concepts around unallocated (what you call free) space.

Each and every sector on a mass storage device can be allocated when a given set of indexing is parsed and at the same time be unallocated when another given set of indexing (file system reconstruction) is parsed.


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

loonaluna
Member
 

Re: Is my winhex gather free space doing what it's supposed

Post Posted: Mar 12, 18 18:10

- jaclaz


Well, no idea, I cannot understand more than half what you are reporting.

You seem like having a not fully formed idea of the concepts around unallocated (what you call free) space.

Each and every sector on a mass storage device can be allocated when a given set of indexing is parsed and at the same time be unallocated when another given set of indexing (file system reconstruction) is parsed.


jaclaz


Yes my apologies. I had conflated sectors with clusters and couldn't tell the difference when I typed the above. I was also looking at a flash drive with a file I thought should be in the middle sectors, but because I'd misunderstood clusters and sectors, didn't realise it was at the beginning of the flash drive, so when I saw it represented on defraggler as being at the start, thought defraggler couldn't read flash drives properly, maybe because of the file system it was using FAT32, or maybe because it was a flash drive storage instead of HDD. I had also recovered a previously deleted truecrypt container on said flash drive, through the file system only, with winhex, so I thought the recovered container was the one occupying the start of the flash drive as it was on an earlier cluster. But it had actually been mostly if not completely overwritten by the new container, so it's no surprise that none of the passwords I remember using worked. Anyways, I describe my present status in the other thread.  
 

Page 2 of 2
Page Previous  1, 2