02-08-2021, 07:04 PM
(02-08-2021, 05:27 PM)Karamba Wrote: What is your ultimate goal? Opening the TC-container and recovering the files inside, I suppose.
Without being an expert on this domain, I suggest you should consider the following:
- If the filesystem is broken (correct ?), one can only recover files in it by searching for their headers; since a TC-container does not have a header, that is going to be a difficult one
- you could look at entropy, to make a more educated guess
- If I understand it correctly, you want to try each sector as if it was a TC-header;
- Since you are talking about 200GB, are we sure that the file is on a continuous way saved by the file system? Or is it fragmented? If it is fragmented, I won't even bother to try to recreate the container
Well... Without calling myself an expert, I'd say I have some experience in forensics...
In this particular case I am working with a partial dump of borgbackup program. I could decrypt and dump it in sequential order of chunks... The backup itself should contain four TC containers, it's their pure data, no filesystem involved at all (at that layer).
I could successfully decrypt the first TC container (also 200Gb), since it started right at the beginning of the dump. It also proved that once I'll find the header, I have good chances of getting the content (at least partially with continuous sequence of chunks).
My problem is, that according to brogbackup docs (and I spoke with maintainers too) there is some metadata in between and there also can be another small TC container which size is known roughly and password not at all.
All together it results in the problem I described: I know very roughly where my target TC container starts (ultimate goal) and at maximum need to test ~100M binary TC hashes of 512b each. And I need some instrument that will allow me to feed them to hashcat (or other fast tool).