Join Us!

Is disabling indexi...
 
Notifications
Clear all

Is disabling indexing on a secondary drive required?  

  RSS
loonaluna
(@loonaluna)
Junior Member

Noob question here. I'm trying to recover a truecrypt container inside a truecrypt encrypted HDD. The OS, Win7, is on another drive.

I've mirrored the truecrypt drive and I'm working on it. Getting ready to use hexeditor on it. I assume I should make it read-only, but should I bother disabling windows search index if the Win7 is on another drive? Is there anything else I should do before I start figuring out how to try to find the header that contains the password?

Quote
Posted : 14/02/2018 6:02 am
AmNe5iA
(@amne5ia)
Active Member

I don't understand most of this. Are you saying you have a truecrypt encrypted HDD that you have decrypted and mounted and you are now trying to locate a truecrypt container file somewhere in the filesystem?

What has windows indexing got to do with anything?

What do you think you are going to achieve by using a hex editor? You are aware that the header of truecrypt containers are encrypted too….

ReplyQuote
Posted : 14/02/2018 10:06 am
loonaluna
(@loonaluna)
Junior Member

I don't understand most of this. Are you saying you have a truecrypt encrypted HDD that you have decrypted and mounted and you are now trying to locate a truecrypt container file somewhere in the filesystem?

What has windows indexing got to do with anything?

What do you think you are going to achieve by using a hex editor? You are aware that the header of truecrypt containers are encrypted too….

I haven't decrypted the HDD, but I can access it with my password. I used winhex a few months ago to read it, and it saw two huge chunks of unused space that I assume are my two truecrypt containers. They were 75gb or so, and I had a bit of activity for a small amount of time after the accidental deletion, so this increases the chances that my endeavour will fail.

I'm trying to recover any one of those two truecrypt containers.

I hope to carve the file out with winhex, am I being too hopeful? I also don't know if it's right to assume that the headers will be sitting at the beginning of this 'empty' space that I saw in winhex a few months ago. It's NTFS. The space isn't empty of course though, it just showed on winhex as not having any current files on it but not being totally empty, so I assume this could be my hope.

I'm also not sure if these two containers are exact copies or if they were different containers to begin with, but I do know that they contained the same data. So trying to find the header by looking for exact copies of the headers in these two spaces may or may not work.

Disabling Windows indexing, like enabling read-only, is what I assume are the steps I should take before I do this properly. But of course this being a secondary drive in which the OS is not stored, maybe disabling indexing doesn't help at all? What do you think of all this?

Btw, this is a mirror image of the drive where the deletion happened, just in case I commit an error in the recovery.

ReplyQuote
Posted : 14/02/2018 8:55 pm
AmNe5iA
(@amne5ia)
Active Member

I haven't decrypted the HDD, but I can access it with my password.

What do you mean by accessing it with your password? Doesn't that decrypt the HDD?

What exactly is it that is encrypted and that you are trying to recover?

Truecrypt can encrypt
1. The whole HDD
2. A single partition on the HDD
3. A container file that resides on a filesystem

Your original posting implied that you were looking for an encrypted container (type 3 above) within an encrypted HDD (Type 1 or 2 above). It also implied that you could decrypt the HDD and were searching the decrypted HDD looking for the (deleted?) truecrypt container.

The problem you will have trying to recover a deleted truecrypt container within a encrypted HDD is that the previously unused areas will be random data. The truecrypt container is designed to look like random data. Therefore it will be difficult to find the start and the end of the container.

If you were trying to recover an encrypted container from an unencrypted HDD it would be easier as previously unused areas would simply be 0x00s (zeros). The truecrypt container would therefore stand out as random data sat in amongst zeros.

Truecrypt headers are not like regular headers, they are encrypted and can only be read by truecrypt when decrypted with the correct password.

ReplyQuote
Posted : 15/02/2018 8:43 am
loonaluna
(@loonaluna)
Junior Member

I can access the truecrypt encrypted HDD with my password, so I think we can assume its decrypted in a sense. The problem are these two big containers I deleted accidentally, they're inside this drive. There really isn't much free space on the HDD, so on Winhex in the 'allocation of visible drive space' there are two big clusters that seem to stand out a lot, as they are the only ones that are described as free space. Would it be correct to assume that the beginning of these two big ''free spaces'' might be the ones that contain my header, that is if I didn't overwrite them before I mirrored the drive? Indeed they don't show up as zeros on winhex but as random data, and yet winhex describes it as free space.

ReplyQuote
Posted : 15/02/2018 10:52 pm
tracedf
(@tracedf)
Active Member

My understanding of what you're saying is this

1) You had full-disk encryption enabled with TrueCrypt.
2) You can access the drive with your password so you are able to decrypt it.
3) On that same drive, you also had two TrueCrypt containers that were separately encrypted.
4) The containers were deleted by accident.

There is a possibility that you can recover the containers but I'm skeptical. Since the containers were large, it's very likely that they were fragmented. If you're not successful in recovering even a part of the container, that could prevent you from recovering the rest. If you miss part of it, carve certain blocks out of the order they were originally in, or include blocks that were not part of the original file, the attempt will probably fail. I've used TrueCrypt but I have never attempted to recover a delete container so I don't know if there is any unencrypted information that will help you (e.g. a standard header/footer for all .tc files).

I don't know if the indexing matters. I'd be more concerned about accidentally writing anything else on the drive you're trying to recover from.

ReplyQuote
Posted : 16/02/2018 1:33 am
loonaluna
(@loonaluna)
Junior Member

There is a possibility that you can recover the containers but I'm skeptical. Since the containers were large, it's very likely that they were fragmented. If you're not successful in recovering even a part of the container, that could prevent you from recovering the rest. If you miss part of it, carve certain blocks out of the order they were originally in, or include blocks that were not part of the original file, the attempt will probably fail. I've used TrueCrypt but I have never attempted to recover a delete container so I don't know if there is any unencrypted information that will help you (e.g. a standard header/footer for all .tc files).

Is there any reason to assume that on winhex when you have a suspiciously big chunk of ''free space'' as it says, that the truecrypt headers won't be stored at the beginning of that free space and that carving isn't as easy as selecting that free space on winhex from beginning to end? Are you saying that 'free space' can have the headers anywhere and that the blocks it shows aren't in order somehow? I've never carved out anything before and haven't a clue how it's done.

I don't know if the indexing matters. I'd be more concerned about accidentally writing anything else on the drive you're trying to recover from.

so making the HDD read-only is advisable?

ReplyQuote
Posted : 16/02/2018 8:59 pm
loonaluna
(@loonaluna)
Junior Member

Up.

tracedf or amnesia or anyone else, thank you all for your input, but what do you think of this? You're all talking about carving sectors in the wrong order, do you think this free space winhex talks about won't be in order and so won't be carveable, and that the headers and footers won't be at the beginning and the end of the free space?

ReplyQuote
Posted : 20/02/2018 3:24 am
tracedf
(@tracedf)
Active Member

The free space probably includes more than just your container files so it's likely that there is other data intermingled with the container files. It's also possible that parts of the file are not in order. I'm not sure what the probability would be. I think it depends on when you first stored the containers relative to whatever else you had on the drive.

ReplyQuote
Posted : 20/02/2018 4:47 pm
4144414D
(@4144414d)
Junior Member

If I've understood correctly, you are trying to recover data from a deleted TrueCrypt container and you know the password.

If so this may help you https://github.com/4144414D/pytruecrypt

The examples should give you an idea on how to go about it hunt.py, in particular, may help.

ReplyQuote
Posted : 21/02/2018 11:29 am
loonaluna
(@loonaluna)
Junior Member

If I've understood correctly, you are trying to recover data from a deleted TrueCrypt container and you know the password.

If so this may help you https://github.com/4144414D/pytruecrypt

The examples should give you an idea on how to go about it hunt.py, in particular, may help.

Hey thanks for your suggestion mate. Is there any python in there or elsewhere that can copy a block found in winhex or in some other hexeditor into a file, and try to open that with the known password? Winhex evaluation copy won't allow me to copy into a new file anything over 200kb or 200mb not sure what exactly. I tried HxD and it doesn't seem to have such an option.

Also, I'm so incompetent I may have managed to forget the filename but probably not the password. Do you think hunt.py or something else can hunt for the file without the filename, and just the password? But anyways, Pytruecrypt says it's slow at what it does, and I feel I could have the entire sequence of blocks in front of me in winhex, don't get me wrong I'm probably wrong about that too. It's a 75gb or so file in a 2tb drive.

ReplyQuote
Posted : 27/02/2018 5:38 pm
4144414D
(@4144414d)
Junior Member

The dump.py example will do that for you, if you comment out the last two lines (about dumping the first sector) then you only need the 512 bytes that makes up the truecrypt header. (It assumes it's the default options were picked in truecrypt, so if you changed the encryption algorithm you'll need to modify it a bit)

You have to be spot on with it though, if you're one byte off with the header it won't decrypt (or use the wrong password)

Test it on a brand new container just to make sure you know how it's working.

ReplyQuote
Posted : 27/02/2018 5:57 pm
Share: