±Forensic Focus Partners

Become an advertising partner

±Your Account


Username
Password

Forgotten password/username?

Site Members:

New Today: 2 Overall: 36212
New Yesterday: 4 Visitors: 211

±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

Anyone got a bot to find deleted truecrypt container header?

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, 3, 4, 5, 6  Next 
  

4144414D
Member
 

Re: Anyone got a bot to find deleted truecrypt container hea

Post Posted: Mar 16, 18 07:46

- loonaluna
So anyway, my apologies, I didn't read the instruction manual fully. The 80gb file supposedly discovered by this truecrypt backup header at the end of the drive was most probably encrypted using non-default aes-twofish and sha512, as that's what the 52gb chunk (or indeed any chunk linked to the end of the chunk) says when it opens raw in truecrypt. I modified the hunt.py like it says to do so in the manual. Now I can use the backup header to write a header into the beginning of the 52gb file, and hunt.py will indeed see it. Once it's written over of course, and by the backup. One thing hunt.py can't do is see the backup header though when it's alone and hunt hasn't seen the actual header in the same run, am I doing something wrong, or is the backup header just not available unless the header has manifested its presence in the correct place beforehand?


To be clear, have you seen hunt ever output a header? (In brute or chain mode) If you have then you have found the keys you need to decrypt the container. The whole process so far is so that we can get those keys. If you have this please post the outcome here (but not the keys or the password!).

If you think it is not AES/ripemd you'll need to use the --all option. This is super slow, but once we have the header we can make it a little faster.

The whole goal so far is to see something like this:


Sector 28160: Fully valid header found
Hash Option: ripemd
Crypto Option: ['aes']
Password: password

Decrypted Header:
0000 54 52 55 45 00 05 07 00 2e c2 dd d8 00 00 00 00 TRUE............
0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0020 00 00 00 00 00 00 00 00 00 9c 00 00 00 00 00 00 ................
0030 00 02 00 00 00 00 00 00 00 9c 00 00 00 00 00 00 ................
0040 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00b0 00 00 00 00 00 00 00 00 00 00 00 00 b1 2d f8 8c .............-..
00c0 f3 00 d5 78 08 30 66 2f 17 99 08 27 28 17 c2 20 ...x.0f/...'(..
00d0 b7 2e 9a 14 79 da 01 77 63 98 37 af 75 da 95 41 ....y..wc.7.u..A
00e0 93 1f f6 7e 13 d3 b3 c5 de f2 2f cc 00 b5 98 b9 ...~....../.....
00f0 77 55 00 d4 5b b4 e4 7c 77 7e 5e 65 a3 ec 32 c3 wU..[..|w~^e..2.
0100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
01a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
01b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................


Hunt will find a backup header without a normal header just fine, that is what example two is.

I suspect that what might be happening is that the volume header inside the container might be overwritten or in a different location, meaning that windows does not understand it. That's fine we'll just have to work harder to get the data out. What types of files are you trying to recover?

If TrueCrypt is opening the container and displaying it as raw then you should be good. In TrueCrypt select your mounted container and click volume properties. Post that screenshot as a reply.




- loonaluna

Well the 2tb is unencrypted in the sense that I have the password, but it is a 2tb encrypted truecrypt drive though, I'm not sure if I formatted the truecrypt space or not when I started. I'm not sure if that makes it low or high entropy, but an image of the drive is getting copied to hunt for it with chain now that I know the correct password crypto and hash search parameters of the first container (lord knows what the second container will be though).


So to be clear, we are attempting to recover a TrueCrypt container that is inside another TrueCrypt container/volume?

Having the password is obviously useful but doesn't tell us about what the disk looks like. You've said there are lots of 00s which is a good thing. If you can remember when you encrypted the 2TB drive how long it took that will help us understand. If it took a long time the disk is likely filled with high entropy data (unless it has been overwritten by use), if it was very quick it will likely low entropy data.


- loonaluna

That would be awesome, but first I should try the chain method tomorrow on the entire volume. It will probably fail though, so eventually I'll probably be using --brute. Unfortunately I can't remember the exact combination of crypto and hash that I used so like the -all function in the script, it could take me a very long time to find it. Do you know if there's a tool that can spot backup headers without having to see the actual header, just like truecrypt did on the third attempt?


For the time being, we should focus on the 52gb where we might have a header. I'll do this update at some point. I'll also make changes to brute so that it only tries to decrypt high entropy data and will therefore be faster.  
 
  

jaclaz
Senior Member
 

Re: Anyone got a bot to find deleted truecrypt container hea

Post Posted: Mar 16, 18 09:31

@loonaloona
UNTRUE get the binary release here:
github.com/nccgroup/Untrue/releases

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

loonaluna
Member
 

Re: Anyone got a bot to find deleted truecrypt container hea

Post Posted: Mar 16, 18 22:26

- 4144414D

To be clear, have you seen hunt ever output a header? (In brute or chain mode) If you have then you have found the keys you need to decrypt the container. The whole process so far is so that we can get those keys. If you have this please post the outcome here (but not the keys or the password!).


I have seen hunt output a header, but only after the following steps happened: First I typed the password three times into truecrypt for the 52gb container. It told me to use the backup header to restore the header, so I did it on a backup of the 52gb container. On this new container, hunt does indeed see the header. However, I've run hunt various times on the end of the 52gb chunk once it's physically separated from the rest of the file and input into a new file, and it's never output the header. I've tested it various times on different smaller files and when the chunk is unlinked from the header, hunt won't see the backup header, and then I've tested in other files where it saw the header and the backup header, separated those files and it would also not see the backup header, however maybe I was doing something wrong, or maybe I had the hash and crypto options wrong at the time (but I doubt it).

- 4144414D

If you think it is not AES/ripemd you'll need to use the --all option. This is super slow, but once we have the header we can make it a little faster.


--all is very slow, so what I did was I edited the hunt file so that the --else part said aes and twofish and sha512, as that's what volume tools said it was. That was when hunt started seeing the header of the container that had used this backup to write in a header at sector 0.

- 4144414D

I suspect that what might be happening is that the volume header inside the container might be overwritten or in a different location, meaning that windows does not understand it. That's fine we'll just have to work harder to get the data out. What types of files are you trying to recover?


Yeah, that's going to be a tough one. It was an encrypted file that I couldn't remember the password to, but it probably contains important business documents from years ago. When I opened it in peazip it asked for a keyfile, which I might have as I think I saved the file that was sitting next to it and that might be it. And the password I might know if I try a number of attempts while I combine it with the keyfile. Either that or it was just another truecrypt container and that wasn't supposed to be opened in peazip. Anyway, it was a fairly medium file of 1 or 2gb in size, and I was looking to recover the file system to make it visible and easily recoverable, but if I have to go through the same process with it that I'm going through with this, I'll do it. That's why I'm also interested in seeing the second container, in case that one's undamaged and less fragmented.

- 4144414D

If TrueCrypt is opening the container and displaying it as raw then you should be good. In TrueCrypt select your mounted container and click volume properties. Post that screenshot as a reply.





- 4144414D

- loonaluna

Well the 2tb is unencrypted in the sense that I have the password, but it is a 2tb encrypted truecrypt drive though, I'm not sure if I formatted the truecrypt space or not when I started. I'm not sure if that makes it low or high entropy, but an image of the drive is getting copied to hunt for it with chain now that I know the correct password crypto and hash search parameters of the first container (lord knows what the second container will be though).


So to be clear, we are attempting to recover a TrueCrypt container that is inside another TrueCrypt container/volume?

Having the password is obviously useful but doesn't tell us about what the disk looks like. You've said there are lots of 00s which is a good thing. If you can remember when you encrypted the 2TB drive how long it took that will help us understand. If it took a long time the disk is likely filled with high entropy data (unless it has been overwritten by use), if it was very quick it will likely low entropy data.


The container is inside a truecrypt encrypted secondary file storage HDD. I have the password to this HDD

Unfortunately, the 00s aren't that frequent. Maybe they are for some of the linux virtual machines sitting in there, but for the bigger windows vm, there's a lot of random stuff in there, at least according to winhex.

- 4144414D

- loonaluna

That would be awesome, but first I should try the chain method tomorrow on the entire volume. It will probably fail though, so eventually I'll probably be using --brute. Unfortunately I can't remember the exact combination of crypto and hash that I used so like the -all function in the script, it could take me a very long time to find it. Do you know if there's a tool that can spot backup headers without having to see the actual header, just like truecrypt did on the third attempt?


For the time being, we should focus on the 52gb where we might have a header. I'll do this update at some point. I'll also make changes to brute so that it only tries to decrypt high entropy data and will therefore be faster.


Much appreciated, but I'm not sure what's the matter with the new hunt. Before with big files it would crash on ioerror and with a pickle file that was getting too large. But now with a 2tb image it says there are too many lines, and with 200gb of collected ''free space'' by winhex, it eats up all my ram (I see the ram shootup on task manager) and I have to reboot. Neither chain nor brute seem to work on large files and, as I predict it would be easier to recover the file I'm looking for with an easily spottable file system intact I'm still interested in finding one of the containers intact.

I can run untrue on monday though, on the 52gb file, right now I'm not sure what it means when it says it decrypts, whether it only outputs hex values and if it needs to the container to be intact to output actual files.  
 
  

4144414D
Member
 

Re: Anyone got a bot to find deleted truecrypt container hea

Post Posted: Mar 16, 18 22:35

- loonaluna
I have seen hunt output a header,


Then we're done. Hunt has done its job, we have the keys. It's now up to us extract the container and recover some files. More tomorrow.  
 
  

loonaluna
Member
 

Re: Anyone got a bot to find deleted truecrypt container hea

Post Posted: Mar 20, 18 14:43

So yesterday I got back on with untrue, to do what I think is decrypt (untrue.exe -p password -i inputfile -o outputfile) and I don't know what to do with the resulting output file. It's just a file that doesn't open anywhere, not in daemon tools, not in peazip, not in truecrypt of course. The same happens when I try outputting an input file that I know is perfectly healthy. What could I be doing wrong?

- 4144414D


Hunt will find a backup header without a normal header just fine, that is what example two is.


Also, I looked into what was happening with hunt.py, to make sure it doesn't see the backup header if it hasn't previously run through the actual header. And it doesn't, at least in my experience. It gets the same error any random chunk of files without a backup header gets, a string index out of range issue which I can't quite parse. Even a chunk that starts with a header, but doesn't have the backup header, finishes with this warning.

 
 
  

jaclaz
Senior Member
 

Re: Anyone got a bot to find deleted truecrypt container hea

Post Posted: Mar 20, 18 15:33

I believe there has been a communication problem of some kind.

The UNTRUE can be run in three main modes:
1) Check a password against a TrueCrypt volume or drive
2) Decrypt a TrueCrypt volume or drive, using a given key
3) Check a password against a TrueCrypt volume or drive, and then use the resultant key to decrypt the volume or drive contents

In order to be able to use it in mode 2) above you need a source, i.e. a Truecrypt volume (which you DO NOT have).
Right now you have a "chunk" of data that you don't know if it corresponds or not to the Truecrypt volume (and probably has a number of corrupted/overwritten sector) so you cannot run it in mode 2).

The modes 1) and 3) can have as argument/source also a Truecrypt header.

You seem to have been able to identify the backup header.

The idea was to try the UNTRUE on this backup header using the --volume_header_file parameter in mode 1).

Check the testcases:
github.com/nccgroup/Un.../TestCases

In any case, if you try mode 2) on a "good" input file (for tests) the output will be (hopefully) a decrypted volume or whole disk image, which you will be able to "open" only in a hex editor (or - it depends - with 7-zip or other tool capable of mounting/accessing volumes/disks image).

Mind you I have no idea if the UNTRUE will actually work because it is limited to a give kind of encryption, and it is aimed to the "main" header, not the backup one, from what I can understand.

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

loonaluna
Member
 

Re: Anyone got a bot to find deleted truecrypt container hea

Post Posted: Mar 20, 18 16:07

I'm running UNTRUE by decrypting a clean test 5mb truecrypt container that I know isn't corrupted, and still daemon tools can't open it, saying it might be corrupt. Plus, after decryption, the password doesn't work so I can't even access the data anymore. Also, under algorithm options in the UNTRUE wiki, it says that when decrypting based a successful password check, the algorithm specified in the decrypted volume header will be used.

I'm interested in the issues hunt.py might be having when trying to see lone backup headers to increase my chances of finding the other container. But I've copied the 52gb extracted chunk and written the header in with the help of the backup header, as advised to do so by the truecrypt program, in volume tools. And it's with this corrected file, that opens raw and unreadable in truecrypt by punching in the password just once (whereas in the uncorrected 52gb chunk you have to type it in 3 times and though it then opens, truecrypt advises to write the header in again), that I'm running UNTRUE.  
 

Page 5 of 6
Page Previous  1, 2, 3, 4, 5, 6  Next