Marc Lehnen

SUCCESS! so the offset 135266304 which i assumed at the beginning really was right ;D DMDE could find many files incl. 3 vc/tc containers and i could recover them and open them and all files in them seem to be readable \o/ autopsy maybe can recover the containers too but i like the DMDE interface more. autopsy is a bit complicated. thank this post which led me to DMDE. https://sourceforge.net/p/veracrypt/discussion/general/thread/02be73c5ce/?limit=25#d149 so - again - this is what i did in short:...

SUCCESS! so the offset 135266304 which i assumed at the beginning really was right ;D DMDE could find many files incl. 3 vc/tc containers and i could recover them and open them and all files in them seem to be readable \o/ autopsy maybe can recover the containers too but i like the DMDE interface more. autopsy is a bit complicated. thank this post which led me to DMDE. https://sourceforge.net/p/veracrypt/discussion/general/thread/02be73c5ce/?limit=25#d149 so - again - this is what i did in short:...

EDIT i think i made a mistake in the calculation of the size of the vc volume in bytes. gotta correct this. maybe ignore my text for now ^^ EDIT ok, so i did a bit more research and updated the currently partition layout (see pic). and i got a few questions that maybe can be answered by someone. 1) at byte 1048576 the current (wrong?) partition is starting. at its beginning there are 65536 bytes of encrypted data and i think this might be the restored header from my own external header backup because...

ok, so i did a bit more research and updated the currently partition layout (see pic). and i got a few questions that maybe can be answered by someone. 1) at byte 1048576 the current (wrong?) partition is starting. at its beginning there are 65536 bytes of encrypted data and i think this might be the restored header from my own external header backup because im pretty sure i restored it to this current partition. BUT: why only 65536 bytes? the header backup is 65536+65536=131072 bytes long. will...

so here i am again ;D after a long pause i continued the recovery and i learned a bit about hdd layouts and examined the hdds with a hex editor. So thats the result (see picture). my problem is to find the start and the end of the lost vc-partition. Im pretty sure the size is 2000263315968 bytes because i created a vc-testfile with wxhexeditor and this gives me the size of the „volume“ in testdisk and wxhexeditor. I only could „mount“ the testfile like this: veracrypt -t --filesystem=none -m=nokernelcrypto...

I'm not sure if there is still a possibility to get usable data off a partition with wrong offset. My assumption would be "no", so I think, the offset should be correct. But I could be mistaken. ok. i will ask maybe some testdisk-pro or so to verify the offset is correct. and i will let photorec finish the recovery and check the recovered files. then i will try to recover the partition to recover the tc/vc-containers. perhaps this needs some deeper research. or luck ;D i will post the result here...

hello again, Are the recovered files actually usable? Or does it just recover junk? both. for example photorec (i stopped recovery after about 1 hour or so) could recover few video files which can be played (avi, mpg), pictures, txt, docs which can be viewed and some other files from which i dont know why these were recoverd (ifo, h, db...) i cant remember i had those file types on the hdd but so what. but of 102 recovered files 31 are unplayable swf-files. But mostly this happens when the filesystem...

hello again, Are the recovered files actually usable? Or does it just recover junk? both. for example photorec (i stopped recovery after about 1 hour or so) could recover few video files which can be played (avi, mpg), pictures, txt, docs which can be viewed and some other files from which i dont know why these were recoverd (ifo, h, db...) i cant remember i had those file types on the hdd but so what. but of 102 recovered files 31 are unplayable swf-files. But mostly this happens when the filesystem...