Is my winhex gather...
 
Notifications
Clear all

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

11 Posts
2 Users
0 Likes
1,751 Views
(@loonaluna)
Posts: 33
Eminent Member
Topic starter
 

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?

 
Posted : 02/03/2018 4:50 pm
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

I wonder what exactly you did/are doing. ?

"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

 
Posted : 02/03/2018 7:13 pm
(@loonaluna)
Posts: 33
Eminent Member
Topic starter
 

I wonder what exactly you did/are doing. ?

"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.

 
Posted : 02/03/2018 7:53 pm
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

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. ?

You can try using DMDE for checking the unallocated space
https://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

… 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)

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

And in your reply there is

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

 
Posted : 02/03/2018 8:58 pm
(@loonaluna)
Posts: 33
Eminent Member
Topic starter
 

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.

 
Posted : 03/03/2018 11:57 am
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

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
https://www.x-ways.net/winhex/specialist_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 ( , and that that feature of Winhex is aimed to reduce the size of a haystack ) , 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

 
Posted : 03/03/2018 2:12 pm
(@loonaluna)
Posts: 33
Eminent Member
Topic starter
 

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.

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?

 
Posted : 03/03/2018 9:05 pm
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

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

 
Posted : 04/03/2018 11:00 am
(@loonaluna)
Posts: 33
Eminent Member
Topic starter
 

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.

 
Posted : 09/03/2018 7:22 pm
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

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

 
Posted : 10/03/2018 10:50 am
Page 1 / 2
Share: