I need some help with Data Recovery

Hello. I have an .ods file that seems to have been corrupted, possibly when encrypting the file in which the usb device may have been prematurely removed. The file was encrypted using ccrypt. The file appears to be a .ods but it has .ods.cpt in the name. Usually the .ods file is green with horizontal lines to describe a spreadsheet. the .cpt file appears to be a binary file. I have the .ods appearance just with the .cpt extension. Possibly means the encrypting did not complete?

Is it impossible to fix or recover any data on this file in such a state?

I was using linux when encrypting the file, the file is within an encrypted container (usb luks2 encryption type), and the file is password protected.

In linux, I decrypted the device, and I seen the spreadsheet .ods.cpt and I opened it, it prompted me with a warning that there is an error and it wants to know if I want libre office to try and repair the file.

In windows, it prompted me for password to the file but then said there is an error and it wants libre office to repair it.

Both ways leave me stranded without access to the data I desperately need from that particular file.

Good thing is, I had libre office doc files that had the same information, in which I then moved into a spreadsheet. Reason why is I had many doc files and thought, why not just put them all into a single .ods file, so I did and then deleted the doc files on the same usb drive, just in a different directory than the .ods.cpt file I mentioned above. How can I now recover, if possible, said deleted doc files?

I could recover this data I need from the .doc files as well as by fixing the .ods.cpt file. But I need help.

Can anyone help or direct me here? I greatly appreciate it.

*EDIT:
I forgot to mention specifically that the usb drive is formatted in ext4, and for me to use ccrypt on windows ,I simply copied the corrupt file to another usb which windows and linux can both use.

I thought this was interesting to read, if I may paste here with the source as a log?

"RECOVERING DATA FROM CORRUPTED FILES

   Encrypted data might be corrupted for a number of reasons. For instance, a file might have been partially encrypted or decrypted if  ccrypt
   was  interrupted  while processing the file. Or data might be corrupted by a software or hardware error, or during transmission over a net-
   work. The encryption algorithm used by ccrypt is designed to allow recovery from errors. In general, only a few bytes of data will be  lost
   near where the error occurred.

   Data  encrypted	by  ccrypt can be thought of as a sequence of 32-byte blocks. To decrypt a particular block, ccrypt only needs to know                 
   the decryption key, the data of the block itself, and the data of the block immediately preceding it. ccrypt cannot tell  whether  a  block	is
   corrupted or not, except the very first block, which is special. Thus, if the encrypted data has been altered in the middle or near the end
   of a file, ccrypt can be run to decrypt it as usual, and most of the data will be decrypted correctly, except  near  where  the	corruption
   occurred.

   The very first block of encrypted data is special, because it does not actually correspond to any plaintext data; this block holds the ran-
   dom seed generated at encryption time. ccrypt also uses the very first block to decide whether the given keyword matches the data  or  
   not. 

   If  the first block has been corrupted, ccrypt will likely decide that the keyword does not match; in such cases, the -m option can be used
   to force ccrypt to decrypt the data anyway.

   If a file contains some encrypted and some unencrypted data, or data encrypted with two different keys, one should decrypt the entire  file
   with each applicable key, and then piece together the meaningful parts manually.

   Finally,  decryption  will  only  produce meaningful results if the data is aligned correctly along block boundaries. If the block boundary
   information has been lost, one has to try all 32 possibilities."

unix /man-page/linux/1/ccrypt/

This made me feel better but I have to wonder, because my file in particular does not appear to be encrypted, though it has the .cpt extension.
Screenshot from 2022-09-23 22-05-34

This is what the encrypted file should look like, though it would have a different name but with the same extension and appearance.
Screenshot from 2022-09-23 22-10-48

Make an image of a drive, before touching the filesystem further. Use dd.

Then backup that image.


Have you tried extundelete?

2 Likes

Right. So without reading your post, I had been researching further, and got testdisk installed and managed to actually recover two different directories which both have an .ods.cpt file however, they both appear like .ods files. Not sure if that matters, nonetheless, the file themselves will not open and I get the same error message as when I attempt to open the original corrupted file. This is perhaps because the file was deleted, so there may be more steps to recover the data from the files . . . That is at least where I am right now.

Further, I did manage an image.dd and that is sitting on a freshly updated linux distro. I did not back up the image, because I have nothing atm to back that file size up to, but I did backup the files that were recovered, and the log from testdisk, and the image.dd file is an iso of the usb partition, container, etc. I did select the luks encrypted from the list, and in there is where I found the two files that were deleted, I believe this is correct.

I would like to back up the image.dd in case the usb is damaged, as well as the linux machine I have the image file on, but I just don’t have anything with the capacity to store extra 120 GB. That said I think I have made some progress today, this is day three. Thanks for the tip!

Tomorrow I need to find out if I can’t get any data from the two files I copied from testdisk to an output dir. If I can recover said data and actually have the contents, given I do have the passwords for the encryption as well as the password protection on the file, that would be great. It would confirm or deny that my memory and the recovery of written password is correct, it could possibly have other information that I had in which I could otherwise access what I need.

How can I access the information within the .ods.cpt files I have? They appear as the green .ods image posted above. Which isnt encrypted as the file would typically be after encrypting it. Strange. The good thing is the drive itself is intact. The other files were intact just fine, the ones I recovered, that I deleted, they never had the issue I am having with the original file I have. So I am unsure as to why they appear identical to the original corrupted file.

Screenshot from 2022-09-24 00-50-08

No I will check that out right now. Thank you.Got extundelete installed and am reading up on it before using. Looks promising. So I ran it but am getting an error, bad magic number in super block when trying to open filesystem /dev/sd1

I am working on it, reading up on what this means now, about to crash though. Sleep . . .

this was the result after checking into extundelete,

I figure its a permissions thing, but I don’t know how to correct it right now. Any tips?

Anyone ?

/dev/sda is the whole disk, which may have several partitions on it. The partition you want will be something like /dev/sda1, sda2, etc…

1 Like

I’ve not used extundelete, but the manpage suggests it should be conducted on a partition / filesystem?
like @rcxb suggested
eg sudo extundelete /dev/sda1 -- restore-all maybe ?

I think someone mentioned making a DD image might be a good idea, working off that to avoid breaking things further, but it’s your data

The fdisk app also needs sudo / root access, in case the login was not in sudo mode at the time? but you probably already tried that

1 Like

project has been on hold cause irl stuffs, now settled again, can get back on track with continuing progress. There are several partitions, being new to this, it sometimes can be confusing to know which partition I want to work with. I did manage to copy, image the drive, and recover deleted files that had that same information as the corrupted file, did send the usb off to a data recovery specialist but, they want 2 - 3 times what their website states, and only managed to use the passwords I provided to access the drive and screenshot the file structure. They eventually said they cannot recover corrupted files. Their website states that is exactly what they do however, then I pressed that I also had deleted files they could recover, If I can they should be able to. Asking if they cant get the data from those files. havent heard back its been several weeks.

this will be a good project for me now that I am settled again and can spend time on it (weekends)
I did do a dd image, and backed that up. I did run the command in sudo, :slight_smile:

looking forward to getting into the files,