I acidentally formatted a drive which contained some Veracrypt volumes.
Used recovery program Wondershare Recoverit and retrieved the volumes.
But the password didnt work on teh retreived volumes
Two of the volumes I had copies of on another drive and the size of the files etc is IDENTICAL between copies and recovered. The copies I can access with no problem but i get the standard password not recognized when attempting to access reterived Volumes ( the most important one of which I didnt have a copy of !! )
I can think of no obvious reason for failure to access to the retreived and identical copy files - any suggestions?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have carried out a series of tests on different drives and configurations.
Using the simplest possible setup to create a veracrypt volume in a folder on a drive containing "normal folders and files " and creating a new file during volume creation.
Then I did a "Quick format" of the drive.
Recovered the drive contents using Recoverit which recovered apparently perfectly all files encrypted or not on the drive. All the recovered files including the Veracrypt volumes matched the original properties
BUT
the VeraCrypt drives could not be opened with the confirmed correct password. This failure occurred with Veracrypt volumes from small to large 5Mb to 150Gb
** This is totally reproducible**
I tried restoring the internal header copy with no change.
Its really bugging me that the VeraCrypt files seem to have been properly recovered with matching properties to the original and I cannot think of what would be changed to prevent acccess using the correct password. As I say all recovered other files of any type -Excel word jpg mov. etc ect all were fine and totally correctly restored
If I hadnt managed to recover what appears to be a totally correct volume it would be less frustrating.
Has anyone any suggestions as to what could have gone amiss - and how to fix it?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No. You can't be sure that files are identical because of their size. You can only be sure that files are identical if you compare checksums of original files and checksums of the recovered files. Files being exactly the same size doesn't mean they are identical.
Succesfully recovering excel or jpg file is much easier, becuase these files have recognisable structure, known headers ,footers, which recovery software can easily pick on. But veracrypt volume ( to my knowledge) has no distringuishable header or footer or structure to "outside observer"(recovering software_. And what most likely happened - file properties hepled identify the file as existing, but the nature of veracrypt file made recovery program find some other random data on disk as part of original volume.
And since that random data probably overwritten volume header in the recovered volume, opening that file may be next to impossible. At this point your best bet is probably to find the most recent backups. Unless, you immediatly cloned your drive , before attempting to recover the data - this may have given some small hope, although probably wouldn't help much,
👍
1
Last edit: AlexGardener 2021-02-24
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I hear your suggestions gentlemen - but you are missing my underlying point.
I can take a totally clean USB - create a new VeraCrypt volume - add files and manipulate fine as one would expect.
Quick format the USB.
NO action on the USB thereafter until I recover using Recoverit - all the files appear to be recovered. Files all seem correct. Only problem is the password doesnt work with the Vear Cryot volume.
This sequence is totally reproducible . I have done it in various combinations some 4 times
I am going to repeat the whole sequence again taking screen shots and i will look for additional thinsg like checksums while i do it to confirm is teh recovered file are indeed as identical as they seem to be.
I had initailly asssumed that since the lost VeraCrypt volumes were very large 100 -300GB that may have been the issue and that the size had defeated in some way the recoverybut the failure occurs even with 5MB volumes .
Since it is a very important loss i am also going to try alternative recovery programs
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
what do you mean with "volume"?
are you talking abot a CONTAINER or did you encrypt th WHOLE DRIVE?
if you quickformatted the encrypted drive how did you manage to recover files?
or did you create a container, put data in it, quickformat the drive, recover the container, mount the container and the password for the recovered container doesnt work?
Last edit: vonDatuh 2021-02-25
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Before you look into another recovery solution, rememebr that the chances of you recovering files now are very low. The only way your files still have some hope is that before attempting to recover you made a clone of hdd and left it alone.
If you were attempting to recover on the same drive and has been working with it for so long, the data was likely overwritten to the point it is permanently lost. So keep that in mind before you look into expensive recovery solutions. It may be a complete waste of resources.
If you are currently working on that same drive, you are trying to recover from, you literally overwriting any chances of ever recovering anything .
Your recovery software had indeed recovered you the files of the same size, but these are not identical files. Recovery software simply picked something from hdd, it recovered something, but not the intact veracrypt file. It's goal was to salvage something and it did. Again, unfortunately , recovering veracrypt volume file is a hard taks because your recovery software has very little to work with . It just sees a bunch of randomness on your drive.
You can attempt to do the follwoing (but I am not responsible for the results and can't gurantee it will work)
If you have recovered broken volume A and you have older working copy of the same volume A, you can attempt to
-backup header from working volume A
-attempt to restore that header to broken recovered volume A
Obviously, these would have to be same volumes, simply saved at different point of time. Don't attempt to do the same with volume A and volume B - this will not work. If you don't have older working copy of the volume, then it wouldn't be possible to perform.
Last edit: AlexGardener 2021-02-24
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you gentlemen, I am fully aware that my chances of restoring the encoded volumes is low - though I am pleased to have recovered what seems like all the unencrypted files.
I have just run yet another simple test which seems to verify that recovering Veracrypt volumes throws out the passwords procedure even with tiny VC volumes.
It would be nice if one could understand what the mechanism of failure is.
Just possibly a unlocking procedure could be devised - I have already tried restoring header from the internal copy
The recovery programs work on recognising logically contiguous areas not on base data -random or not. And it would be very strange indeed if data randomness failed the process but concidentally matched file size and checksum.
I have had a IT career spanning 50 years - the last time that i lost a storage device without backup was when I dropped a punched card tray in the late 1960s so this one peeves me !
About to try another test run I will post screen grabs this time.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In lieu of fancier file comparison software, a quick and easy DOS command can be the final judge of how perfectly the container file was recovered: FC /b Container1.hc Container2.hc > filediff.txt
If the recovered file passes the test and still cannot be opened, I'm as surprised and befuddled as you are. I've backed up many containers and never been unable to mount the backup copy on a different drive. Other than file contents, my only other guess would be if Recoverit were failing to restore some critical property of the file, but I'm unaware of what that might be. It's been over a decade since I used file recovery software, and partition recovery might add another wrinkle.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks Gary - thats one of those things that are blatently obvious - once someone else has thought of it - I shall try it. Because as you say if the recovered file is truly identical - as it seems at present to be - then i cannot see how the password would fail.
But the failure is reproducible starting from scratch - i was just getting another test run ready - I will add your suggestion into those checks. I will screen grab and report in a day or so but at the moment i am urgently checking all my backups and backing up the correctly retrieved files
I was concerned because of the size of my encrypted volumes - 50 - 150 Gb which might have sensibly been expected to be a probable cause of errors.
But i can reproduce the problem with trivial 5Mb volumes
But if originals and retrieved files are indeed identical and the password works on the original and not on the recovered - befuddled is the right word !
Vondatuh
Just for clarity i am using"volume" to describe ane encrypted area simply because its the term used on the front end of Veracrypt
I damaged a whole 500Gb backup hard drive which contained a large number of standard files and three encrypted '.hc' containers . And i have recovered the whole volume with Recoverit - good program if a tad expensive- and the only issue is the password access to the .hc files (which i had relabelled as '.tib'
I have apparently recovered totally correctly all the standard files but all three of the encrypted areas do not allow entry with the password. Fortunately I have other identical copies of the two smaller 50Gb "volumes" and i will do further checks to see if those copies really do match the recovered file.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
i formatted a 8 gb stick and copied a 200mb container on it.
mounting the container on the usb stick- no problem
adding files, deleting files- no problem
quickformat, recoverysoftware found the container, restored it, mounting aaaaaand...
nope, no access. same problem here...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Wait. This is really interesting.
So your original volume file and volume file you recovered both produce SAME exact checksum, yet one can be opened with the password, while the other can't be opened with the same password? What are the odds of that happening?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
AlexGardener
Quite !!!! I cannot see how two files which are truly identical checksums etc can react differently to the same password!
I am going to recheck the checksums on a simple example because since i caused the whole problem by my carelessness, I dont trust myself any more. ( Take care with creating ISO drives with Rufus - it doesnt have an " are you sure" question after you select the drive to be worked on - just thank heavens i didnt accidentally select my main drive !)
But just at the moment i am not touching my main PC s until the backups onto a replaced external HDD has completed -500Gb takes a loooooong time.
But later to day i will run and document a trial on a small simple set of data.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
update ..
made a 250mb container, made a copy of it, saved header, saved both on an usb stick.
both can be mounted and edited on the usb stick.
now: quickformat, recovering both files with DMDE, mounting.....
fail!
now i restored the header ... WORKED.
mounting ....
ups.. i can mount the volume now and it says that the volume needs to be formatted.
but no access...
i did fc /b and stopped at 2.7GB of filediff.txt
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just clarification
you used DMDE to restore
could not mount initally
restored saved heading and could then mount
but still no access
The files seem to have major differences ?
Would this be accounted for by a simple offset?
What are the nominal file sizes ?
I was running my test but stopped because a teeny container I created was not recovered AT ALL.
Need to check that i had indeed made container before I format the stick - because I have never failed to recover something !! and this was a "clean" simple trial.
I am speaking to the guys at Wondershare to see if they can throw some light on what might happen during recovery.
I am getting reconciled to the probable loss of my files but want to take it a bit further to see if anything pops up.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well after vonDatu's note about using DMDEI tried recovery using that instead of Recoverit.
Blow me down - worked first try and got my main 250GB container back apparently completely correctly and NO problems with the password.
Main noticeable difference was that while Recoverit reported lots of connection queries DMDE did not.
However I think that demonstrates that recoveryfrom a quick formatted partition containing large VC volumes is not easy .
Though my and the other tests upon small volume recoveries is a bit worrying because they simply didnt work .
The message however is clear - backups !!!
Thanks for your input chaps
But just to complete the story I will complete and post my info and screen shots on my tests to confirm that indeed there does seem a problem at times of identical size and checksum original and recovered where the recovered failed password access.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I acidentally formatted a drive which contained some Veracrypt volumes.
Used recovery program Wondershare Recoverit and retrieved the volumes.
But the password didnt work on teh retreived volumes
Two of the volumes I had copies of on another drive and the size of the files etc is IDENTICAL between copies and recovered. The copies I can access with no problem but i get the standard password not recognized when attempting to access reterived Volumes ( the most important one of which I didnt have a copy of !! )
I can think of no obvious reason for failure to access to the retreived and identical copy files - any suggestions?
are these containers or partitions ?
i would try to copy the containers to another harddrive and try again .
have you tried to restore the volume header of the hard drive? maybe wondershare eradicated the header ?
I have carried out a series of tests on different drives and configurations.
Using the simplest possible setup to create a veracrypt volume in a folder on a drive containing "normal folders and files " and creating a new file during volume creation.
Then I did a "Quick format" of the drive.
Recovered the drive contents using Recoverit which recovered apparently perfectly all files encrypted or not on the drive. All the recovered files including the Veracrypt volumes matched the original properties
BUT
the VeraCrypt drives could not be opened with the confirmed correct password. This failure occurred with Veracrypt volumes from small to large 5Mb to 150Gb
** This is totally reproducible**
I tried restoring the internal header copy with no change.
Its really bugging me that the VeraCrypt files seem to have been properly recovered with matching properties to the original and I cannot think of what would be changed to prevent acccess using the correct password. As I say all recovered other files of any type -Excel word jpg mov. etc ect all were fine and totally correctly restored
If I hadnt managed to recover what appears to be a totally correct volume it would be less frustrating.
Has anyone any suggestions as to what could have gone amiss - and how to fix it?
No. You can't be sure that files are identical because of their size. You can only be sure that files are identical if you compare checksums of original files and checksums of the recovered files. Files being exactly the same size doesn't mean they are identical.
Succesfully recovering excel or jpg file is much easier, becuase these files have recognisable structure, known headers ,footers, which recovery software can easily pick on. But veracrypt volume ( to my knowledge) has no distringuishable header or footer or structure to "outside observer"(recovering software_. And what most likely happened - file properties hepled identify the file as existing, but the nature of veracrypt file made recovery program find some other random data on disk as part of original volume.
And since that random data probably overwritten volume header in the recovered volume, opening that file may be next to impossible. At this point your best bet is probably to find the most recent backups. Unless, you immediatly cloned your drive , before attempting to recover the data - this may have given some small hope, although probably wouldn't help much,
Last edit: AlexGardener 2021-02-24
hmmm.... lets try not to recover the files.
try to recover the whole partition table. worked for me one time.
.... but i must agree with mr. gardener.
I hear your suggestions gentlemen - but you are missing my underlying point.
I can take a totally clean USB - create a new VeraCrypt volume - add files and manipulate fine as one would expect.
Quick format the USB.
NO action on the USB thereafter until I recover using Recoverit - all the files appear to be recovered. Files all seem correct. Only problem is the password doesnt work with the Vear Cryot volume.
This sequence is totally reproducible . I have done it in various combinations some 4 times
I am going to repeat the whole sequence again taking screen shots and i will look for additional thinsg like checksums while i do it to confirm is teh recovered file are indeed as identical as they seem to be.
I had initailly asssumed that since the lost VeraCrypt volumes were very large 100 -300GB that may have been the issue and that the size had defeated in some way the recoverybut the failure occurs even with 5MB volumes .
Since it is a very important loss i am also going to try alternative recovery programs
what do you mean with "volume"?
are you talking abot a CONTAINER or did you encrypt th WHOLE DRIVE?
if you quickformatted the encrypted drive how did you manage to recover files?
or did you create a container, put data in it, quickformat the drive, recover the container, mount the container and the password for the recovered container doesnt work?
Last edit: vonDatuh 2021-02-25
Before you look into another recovery solution, rememebr that the chances of you recovering files now are very low. The only way your files still have some hope is that before attempting to recover you made a clone of hdd and left it alone.
If you were attempting to recover on the same drive and has been working with it for so long, the data was likely overwritten to the point it is permanently lost. So keep that in mind before you look into expensive recovery solutions. It may be a complete waste of resources.
If you are currently working on that same drive, you are trying to recover from, you literally overwriting any chances of ever recovering anything .
Your recovery software had indeed recovered you the files of the same size, but these are not identical files. Recovery software simply picked something from hdd, it recovered something, but not the intact veracrypt file. It's goal was to salvage something and it did. Again, unfortunately , recovering veracrypt volume file is a hard taks because your recovery software has very little to work with . It just sees a bunch of randomness on your drive.
You can attempt to do the follwoing (but I am not responsible for the results and can't gurantee it will work)
If you have recovered broken volume A and you have older working copy of the same volume A, you can attempt to
-backup header from working volume A
-attempt to restore that header to broken recovered volume A
Obviously, these would have to be same volumes, simply saved at different point of time. Don't attempt to do the same with volume A and volume B - this will not work. If you don't have older working copy of the volume, then it wouldn't be possible to perform.
Last edit: AlexGardener 2021-02-24
Thank you gentlemen, I am fully aware that my chances of restoring the encoded volumes is low - though I am pleased to have recovered what seems like all the unencrypted files.
I have just run yet another simple test which seems to verify that recovering Veracrypt volumes throws out the passwords procedure even with tiny VC volumes.
It would be nice if one could understand what the mechanism of failure is.
Just possibly a unlocking procedure could be devised - I have already tried restoring header from the internal copy
The recovery programs work on recognising logically contiguous areas not on base data -random or not. And it would be very strange indeed if data randomness failed the process but concidentally matched file size and checksum.
I have had a IT career spanning 50 years - the last time that i lost a storage device without backup was when I dropped a punched card tray in the late 1960s so this one peeves me !
About to try another test run I will post screen grabs this time.
In lieu of fancier file comparison software, a quick and easy DOS command can be the final judge of how perfectly the container file was recovered:
FC /b Container1.hc Container2.hc > filediff.txtIf the recovered file passes the test and still cannot be opened, I'm as surprised and befuddled as you are. I've backed up many containers and never been unable to mount the backup copy on a different drive. Other than file contents, my only other guess would be if Recoverit were failing to restore some critical property of the file, but I'm unaware of what that might be. It's been over a decade since I used file recovery software, and partition recovery might add another wrinkle.
Thanks Gary - thats one of those things that are blatently obvious - once someone else has thought of it - I shall try it. Because as you say if the recovered file is truly identical - as it seems at present to be - then i cannot see how the password would fail.
But the failure is reproducible starting from scratch - i was just getting another test run ready - I will add your suggestion into those checks. I will screen grab and report in a day or so but at the moment i am urgently checking all my backups and backing up the correctly retrieved files
I was concerned because of the size of my encrypted volumes - 50 - 150 Gb which might have sensibly been expected to be a probable cause of errors.
But i can reproduce the problem with trivial 5Mb volumes
But if originals and retrieved files are indeed identical and the password works on the original and not on the recovered - befuddled is the right word !
Vondatuh
Just for clarity i am using"volume" to describe ane encrypted area simply because its the term used on the front end of Veracrypt
I damaged a whole 500Gb backup hard drive which contained a large number of standard files and three encrypted '.hc' containers . And i have recovered the whole volume with Recoverit - good program if a tad expensive- and the only issue is the password access to the .hc files (which i had relabelled as '.tib'
I have apparently recovered totally correctly all the standard files but all three of the encrypted areas do not allow entry with the password. Fortunately I have other identical copies of the two smaller 50Gb "volumes" and i will do further checks to see if those copies really do match the recovered file.
i formatted a 8 gb stick and copied a 200mb container on it.
mounting the container on the usb stick- no problem
adding files, deleting files- no problem
quickformat, recoverysoftware found the container, restored it, mounting aaaaaand...
nope, no access. same problem here...
Wait. This is really interesting.
So your original volume file and volume file you recovered both produce SAME exact checksum, yet one can be opened with the password, while the other can't be opened with the same password? What are the odds of that happening?
AlexGardener
Quite !!!! I cannot see how two files which are truly identical checksums etc can react differently to the same password!
I am going to recheck the checksums on a simple example because since i caused the whole problem by my carelessness, I dont trust myself any more. ( Take care with creating ISO drives with Rufus - it doesnt have an " are you sure" question after you select the drive to be worked on - just thank heavens i didnt accidentally select my main drive !)
But just at the moment i am not touching my main PC s until the backups onto a replaced external HDD has completed -500Gb takes a loooooong time.
But later to day i will run and document a trial on a small simple set of data.
Well Vondatuh nice to know i am not alone !
So it seems to be an real issue.
Have you compared the size and checksum do they seem identical ?
update ..
made a 250mb container, made a copy of it, saved header, saved both on an usb stick.
both can be mounted and edited on the usb stick.
now: quickformat, recovering both files with DMDE, mounting.....
fail!
now i restored the header ... WORKED.
mounting ....
ups.. i can mount the volume now and it says that the volume needs to be formatted.
but no access...
i did fc /b and stopped at 2.7GB of filediff.txt
Just clarification
you used DMDE to restore
could not mount initally
restored saved heading and could then mount
but still no access
The files seem to have major differences ?
Would this be accounted for by a simple offset?
What are the nominal file sizes ?
I was running my test but stopped because a teeny container I created was not recovered AT ALL.
Need to check that i had indeed made container before I format the stick - because I have never failed to recover something !! and this was a "clean" simple trial.
I am speaking to the guys at Wondershare to see if they can throw some light on what might happen during recovery.
I am getting reconciled to the probable loss of my files but want to take it a bit further to see if anything pops up.
Well after vonDatu's note about using DMDEI tried recovery using that instead of Recoverit.
Blow me down - worked first try and got my main 250GB container back apparently completely correctly and NO problems with the password.
Main noticeable difference was that while Recoverit reported lots of connection queries DMDE did not.
However I think that demonstrates that recoveryfrom a quick formatted partition containing large VC volumes is not easy .
Though my and the other tests upon small volume recoveries is a bit worrying because they simply didnt work .
The message however is clear - backups !!!
Thanks for your input chaps
But just to complete the story I will complete and post my info and screen shots on my tests to confirm that indeed there does seem a problem at times of identical size and checksum original and recovered where the recovered failed password access.