±Forensic Focus Partners

Become an advertising partner

±Your Account


Username
Password

Forgotten password/username?

Site Members:

New Today: 0 Overall: 36125
New Yesterday: 1 Visitors: 140

±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 1, 2  Next 
  

loonaluna
Member
 

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

Post Posted: Mar 02, 18 17:50

Being the noob that I am, I was impressed initially by winhex's ability to differentiate between free space and currently occupied space in the hard drive I analyze with it. Compared to other hexeditors, like HxD, it doesn't show just the extents, it actually shows the file that's occupying the cluster. Not knowing the header of the truecrypt container I'm trying to recover, but knowing the password, I thought this was a glimmer of hope.

But maybe this was an illusion? I used the gather free space feature on an old winhex and the file it creates with this supposedly free space isn't free at all, as when I search the hex values that have been transferred to it, when I search these values on the original drive, they're not free space at all, they're currently occupied by files. Is this just an old buggy version of winhex from 2010 that isn't working properly, or is winhex's definition of free space just unreliable all-around?  
 
  

jaclaz
Senior Member
 

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

Post Posted: Mar 02, 18 20:13

I wonder what exactly you did/are doing. Confused

"Free space" is what is usually called "unallocated space", i.e. extents that are not "indexed" in the filesystem structures as being "in use" (at the moment), they may well be full of "deleted" (actually "de-indexed") data differing from "current data" by a handful of bytes (think of various versions of a same text file, with a few lines added at the end).

On a "normally used" volume, this may amount to gigabytes of data and endless possibilities of (partial or full) duplication, what do you mean by "hex values that have been transferred"?

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 02, 18 20:53

- jaclaz
I wonder what exactly you did/are doing. Confused

"Free space" is what is usually called "unallocated space", i.e. extents that are not "indexed" in the filesystem structures as being "in use" (at the moment), they may well be full of "deleted" (actually "de-indexed") data differing from "current data" by a handful of bytes (think of various versions of a same text file, with a few lines added at the end).

On a "normally used" volume, this may amount to gigabytes of data and endless possibilities of (partial or full) duplication, what do you mean by "hex values that have been transferred"?

jaclaz


Well I'm fiddling about with an old winhex torrent from 2010 that works okayish. That explains why a noob like myself is playing around with the very expensive specialist license that has the gather free space option, together with the gather slack space option. The gather free space option allows you to extract all the free space from drive space into new files. You input the desired file size and it goes creating files of that size until, I assume it's searched the entire drive for all its free space. But I search for any of the hex values in the new files and they all belong originally in the drive to occupied space. I can only conclude that this feature on winhex isn't working properly. Do you know of another program that sees a cluster and attaches the file description to it like this, but works properly?

The data indeed isn't all 00s like you'd get with a full format. It's all random data and that's where I hope my container is sitting.  
 
  

jaclaz
Senior Member
 

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

Post Posted: Mar 02, 18 21:58

WHICH "hex values"?

Really I am not understanding the theory of what you are saying/attempting to do, let alone whether you are correctly putting it in practice. Question

You can try using DMDE for checking the unallocated space:
dmde.com/

But the point remains, DMDE is a tool, ad only a tool (like WinHex) if you miss a (proper) plan and the basics no tool will unfortunately solve the *whatever* problem you are having.

And if you don't somehow manage to describe/explain what you are doing it will be also difficult or impossible to try and assist you.

You stated:

- loonaluna

... as when I search the hex values that have been transferred to it, when I search these values on the original drive, they're not free space at all, they're currently occupied by files.


I asked you (since I cannot understand what you are trying to do):
- jaclaz

... what do you mean by "hex values that have been transferred"?


And in your reply there is:
- loonaluna

But I search for any of the hex values in the new files and they all belong originally in the drive to occupied space.


Which tells me nothing more.

Can you post an example of one of these "hex values" you search for?


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 03, 18 12:57

Hi jaclaz.

Thank you for your assistance. Let's see if I can explain clearly what I'm trying. I'm trying to recover at least one of two deleted truecrypt containers (that might or might not have the same header info I can't remember). I don't know the header hex values, so I can't search for them on the ''find hex values'' tab as I assume is usually done when the header is known.

The containers were inside a truecrypt drive, but I know the password to the drive, so there's no issue from that angle, and winhex can read the decrypted drive. There is currently about 200gb free space on this 2gb drive. So I thought about using the ''gather free space'' feature in winhex, to isolate this free space that I suspected would contain my containers. Even though this drive has two big contiguous spaces that winhex claims is 'free space', I had previously failed to decrypt these two spaces by using the first few kb of each of these winhex 'free space' areas. So I thought my next best chance would be to isolate all of what winhex says is ''free space'', until I figure out a way to get a script or a program that go kb by kb applying the container password, in order to find out the exact size of the container and if it isn't fragmented, to successfully carve the file.

However, whenever I get a string of hex values, like 7EC73E7212EA7D4D, that are extracted into new files by the winhex 'gather free space' feature, and I input them back into ''find hex values'' tab in winhex but with the original drive open instead, it doesn't show as free space, but as currently occupied by some other file. What could this mean?


Thanks for your suggestion, I'm running the drive through DMDE right now, but if this is like recuva, then the containers will be too big to be findable, plus, from reading other threads on this issue, I didn't immediately unplug the drive so the MFT information that these recovery softwares rely on will probably be messed up.  
 
  

jaclaz
Senior Member
 

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

Post Posted: Mar 03, 18 15:12

- loonaluna

Thanks for your suggestion, I'm running the drive through DMDE right now, but if this is like recuva, then the containers will be too big to be findable, plus, from reading other threads on this issue, I didn't immediately unplug the drive so the MFT information that these recovery softwares rely on will probably be messed up.


What makes you believe that DMDE is (even remotely) similar to Recuva?
Surely it offers (among a zillion others features) the possibility of recovering some files (like Recuva does or - often - only claims to do) but it is a completely different program.

About the "7EC73E7212EA7D4D" (or *any* other hex values), what would you expect to do with those (or what would you expect them to provide)?

Anyway, forget about the "gather free space" feature you are using (or misusing) in WinHex.

That feature of Winhex is not what you want to do:
www.x-ways.net/winhex/...tools.html

Gather Free Space: Traverses the currently open logical drive and gathers all unused clusters in a destination file you specify. Useful to examine data fragments from previously existing files that have not been deleted securely. Does not alter the source drive in any way. The destination file must reside on another drive.


It is true that you are looking for a needle in a haystack Sad , and that that feature of Winhex is aimed to reduce the size of a haystack Smile , but you are in a situation in which your needle is actually two needles in two separate haystacks, and mixing them together (and with all the rest of the hay laying around) doesn't seem (to me) a good idea anyway.

Your two haystacks are (hopefully) corresponding to two (large) chunks of unallocated space.

Additionally your two needles are (or should be) on the first sector of these two chunks.

You should have - even if approximate - an idea of the size of these containers (still in the idea that they were/are contiguous, it shouldn't be so difficult to find visually (let's say in the Defrag->Analyze graphical view of *any* defragmenting software) the approximate location of these "large" chunks.

That Winhex function will consolidate each and every unallocated cluster it finds into the new file, removing any reference to the original position of the cluster in the original disk, this is not particularly useful.

What you want instead is to "extract" the two "large" unallocated chunks, separately, to two new files, not having them mixed together and together with a zillion other unallocated clusters before and after them.

Anyway, before that, run the DMDE and attempt a "pureFS" reconstruction, it is possible (very unlikely, but possible) that it can find where the containers were/are.

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 03, 18 22:05

Oh yeah, I agree that my ''plan'' while I was gathering free space on winhex was pretty stupid. If anything it meant reducing the amount of space I'd have to search for the truecrypt header once I found an actual program that would be able to run through the entire free space. But that's something that barely exists, a few years ago someone made a thread about it and no one came up with pytruecrypt as someone else so kindly pointed to in the other thread I made this week. But still, as far as ''gathering free space'' goes, it really was a headless chicken kind of plan :/. It does worry me though, that this feature is extracting ''free space'' that isn't free on the source drive, it leads me to think that something fishy might be going on in the big ''free spaces'' that I hoped would be my containers. As if I don't have to worry already about the possibility of fragmentation or whether I installed something over any part of the container that'll turn them into gibberish even if I do find the headers. Plus my attempt to extract the beginning of these free spaces, apply the truecrypt passwords to them, was met with failure, so things aren't looking good at all. The size of these two big chunks are similar but not quite what I remember the sizes that the containers were, but they are walled up in the middle of older files that aren't new and in danger of having overwritten the containers though. However, at least some of this ''free space'' according to winhex is actually fairly recent files that might have overwritten key information elsewhere, so I wouldn't be putting it past winhex to be relying on old outdated information to define its ''free space'' somehow.

Anyways, you're right about the defrag software. I just downloaded defraggler, and it does indeed show two huge masses of free space. However, my failure with what should be the headers, by failing to open the first dozens of kb (according to winhex) with the password in truecrypt, makes me think that something else is going on. I think this might have been the thought process initially, as it was because of the failure at decrypting the beginning of these two huge chunks that I wanted to get all the free space everywhere and apply a bot to it, to at least know I tried. Also, I read somewhere that truecrypt stores header information in the footer when it comes to encrypted partitions, but I don't know at what distance from the footer and even if it's the same with containers as it is with partitions.

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.


- jaclaz


Anyway, before that, run the DMDE and attempt a "pureFS" reconstruction, it is possible (very unlikely, but possible) that it can find where the containers were/are.

jaclaz



A pureFS reconstruction of the NTFS 0 doesn't seem to find me anything that resembles this huge file, and at the location I remember the containers were there are also no other entries of 0 bytes or anything as sometimes happens in these cases. So what do you think, a run through with a truecrypt header bot of those two big spaces, and if not, of the entire hex values of the drive is my last hope?  
 

Page 1 of 2
Page 1, 2  Next