Recover from SSD

[DariusM]

Hello. I'm looking for some advice on how to recover some deleted files from a SSD using Photorec. I've used Photorec in the past on HDDs and SD cards and it worked ok.
So here's the situation: I have a small laptop which I use for astrophotography.
I just got home from a session and I had about 100 .fits files on the internal SSD of the laptop, on the only partition which is a NTFS with 512 bytes sector size (checked in System Information).

Some of these files I didn't need (bad calibration frames) so I wanted to delete them.
However... I mistakenly also deleted 39 .fits files which I do need, these were all the photos from tonight's session.
So I immediately went on another laptop, downloaded photorec to an external SSD, then connected it to the photography laptop and started to fiddle with it.

The laptop is an ASUS Slate Oled 13 inch, kind of a mix between a laptop and a tablet.

What I tried:
1. Photorec with default settings in GUI mode, ran the search on the partition.
Recovered 6 unrelated files, as follows:
- .mlv file. 2,158,074 KB
- .gpg file, 32 KB
- 4 .swf files, 2,458,789 KB / 2,479,596 KB / 3,133,597 KB / 2,501,190 KB

2. Photorec with default settings in terminal mode, ran the search on the partition. 0 files recovered

3. Photorec with default settings in terminal mode, ran the search on the drive. Multiple unrelated files recovered, mostly .exe, dll, txt, ttf and one .swf. All except for the swf have a size of at most 5,382 KB. The swf file is 2,458,789 KB

4. Photorec in terminal mode, made sure the sector size is set to 512B, and only the fit and fits files are enabled in the settings: 0 files recovered.

The paranoid setting is on but with brute-force disabled.
The recovery location is set to the external ssd where I also have the photorec executable.

What's strange to me is that there aren't any .fits file even though there should be hundreds of deleted .fits files on this drive.
I tried running photorec multiple times, I always select 512B as the sector size because I checked and the drive is formatted as NTFS with 512B sector size.
After it runs, I get a question: "Create an image_remaining.dd (254510 MB) file with the unknown data (Answer N if not sure) (Y/N) and I always select N

Some other information that I have:
- The path where all the files were: C:\Photography\N.I.N.A\SH2-200\OIII\2024-10-29\LIGHT\
- I also have the names of all the files from the logs of the photography software
- Each file was exactly 50,676 KB

Does anyone have any suggestions?

[recuperation]

1. Read the manual that came with your download.
2. Read the online documentation:
https://www.cgsecurity.org/wiki/PhotoRec

How many file formats exist in the world?
Have you verified that PhotoRec supports your very special file format before starting PhotoRec?

[DariusM]

yes, fits is supported. why the attitude though?

[recuperation]

I have to apologize, my answer is a total failure!

I tried! to look up the file format here

https://www.cgsecurity.org/wiki/File_Fo ... y_PhotoRec

found "fit" and ignored "fits".

But what is even worse the beginning of your description tells the reason for your failure:

Hello. I'm looking for some advice on how to recover some deleted files from a SSD using Photorec. I've used Photorec in the past on HDDs and SD cards and it
...

Your pictures have most likely not been deleted but erased by the firmware of the SSD. As an SSD has to erase a preused flash block before being able to write on it, a slowdown occurs during write operations as erasing before writing is necessary.

To speed up SSD write operations modern operating systems tell the SSD which sectors have been discarded. The SSD will then erase the corresponding blocks.
As far as I know the only chance you have is to immediately power down the SSD and contact a professional lab.

I had read somewhere that there is a chance left because somebody found out how to reach the blocks marked for erasure in the SSD that have not yet been erased. This may not apply for all SSD chipsets.

If there is sufficient write activity on your SSD after you deleted your files, the files may have been overwritten anyway by those write operations.

Thank you very much for informing me about my mistake - which annoys me - in the previous answer!
The yellowish smilies show me thinking about me.

30.10.2024 14:45 MESZ Recuperation: modified 2nd sentence

[DariusM]

No worries, thanks for getting involved and trying to help.
In the meantime I've looked a bit at the code. I'm not a C guy, mostly C# and just a bit of C++. However I found this:

Code: Select all

 if(memcmp(&buffer[i], "XTENSION", 8)!=0)
      break;
    {

at line 191 of

Code: Select all

 file_fits.c

However, on fits files there can be either "XTENSION" or "SIMPLE" there, so it will break the loop even for valid fits files that have "SIMPLE" instead of "XTENSION".
Do you think including "SIMPLE" here could help or am I not understanding the code correctly?

I'm attaching the start of a valid fits file produced by the software that I use.

beginning of the output of hexdump -C on a fits file

Screenshot 2024-10-30 150726.png (101.62 KiB) Viewed 12780 times

[recuperation]

I a not a C programmer but I sometimes look into the code and look up the syntax of C simultaneously.

Your documentation suggests that PhotoRec will not recognize this variation of the FITS format.

You can add a user-defined fingerprint that fits to the "SIMPLE"-variation.
Please look into the manual and the online documentation.

Your next step is to verify that your fingerprint works correctly.
Take a storage device that does NOT support TRIM, partition it, format the partition and copy your sample on it.
Your sample should be located pretty much at the beginning of the device.
Delete your sample file on your test storage device.
Have Photorec examine the partition with the deleted sample file. A result should come up pretty fast without the need to traverse the whole storage device.

I don't have an opinion if patching/recompiling is a good way to go.

But keep in mind: Your file content is most likely trimmed away. Use a hex editor such as HxD to find the beginning of one file if you don't believe. HxD should fail as well.
The recipe given above should work, but not on modern TRIMable storage devices in combination with current operating systems.

[DariusM]

I'll try with the fingerprint, thanks for the tip.
I understand that most likely the files are gone permanently due to TRIM, I'll report back my findings with the custom fingerprint.

[EDIT] Tried with the custom signature, nothing found.

In conclusion, recovery from SSDs is mostly not possible due to TRIM being enabled by default. It's probably the same on NVMe drives with DEALLOCATE and on SCSI devices with UNMAP.
Anyway, I guess I'm just very surprised that TRIM went to action in less than 10 minutes after I deleted the files. I thought it was gonna wait a while before moving data around on the drive.

The other intriguing fact to me is that random exe, dll and txt files were recovered - and those were probably deleted a very long while ago.
I haven't done a windows update on that laptop in ages. It's mostly not even connected to the internet because I want to avoid a windows update randomly happening when I'm out at night photographing.

[cgrenier]

TRIM may be prevent recovery, another possibility is BitLocker disk encryption.
Can you check if it's enable ?