Better micro SD 32GB recovery where PhotoRec gets a lot messy pieces/names?

[kxr99]

Samsung 32GB micro SD card, some 4 years old, mainly just added files. Only used in Android phone, no swapping.
Somehow it became invalid in the Android phone. no real idea why.? Problem with low voltage? phone mechanical shock? Do such brand cards simply fail electrically after so few years? Or likely Android bugs or voltage problems?
It asked to be formated in Android and also in Windows PC -> Aborted. Chkdsk /f wont start - no partition / RAW detected.

PhotoRec already recovered some thousands of files - but very messy quite without names. jpg's, gpx, mp3, txt, html, pdf, zip ... many types. Maybe 2/3 of stuff. Most mp3 data broken up in unusuable multiple pieces ....
Is there a chance for better recovery with TestDisk + chkdsk or so?

Starting key question: What is the typical preformatted partition table type of such 32GB Samsung microSD card? "Intel" or "None" ? What is "None"?

"Analyses" with both types fail to see anything reasonable with Quick & Deeper search.

"Intel" doesnt see a partition at all.

Code: Select all

Disk /dev/sdb - 32 GB / 29 GiB - CHS 3891 255 63
Current partition structure:
     Partition                  Start        End    Size in sectors

Partition sector doesn't have the endmark 0xAA552

Is it wise to try MBR Code / Write TestDisk MBR code to first sector - or better bet on "None" parti type at all?


"None" parti type shows:

Code: Select all

Disk /dev/sdb - 32 GB / 29 GiB - CHS 3891 255 63

     Partition                  Start        End    Size in sectors
>   P Unknown                  0   0  1  3891 197 18   62521344

Trying type "FAT32" there - "Rebuild BS" failes :

Code: Select all

Disk /dev/sdb - 32 GB / 29 GiB - CHS 3891 255 63
     Partition                  Start        End    Size in sectors
   P FAT32                    0   0  1  3891 197 18   62521344

Boot sector
Bad

Backup boot sector
Bad

Sectors are identical.

A valid FAT Boot sector must be present in order to access
any data; even if the partition is not bootable.

The dump of the "bad" boot sector shows all 0xFF bytes only (start area of flash erased?)

In expert mode and "None" type a manual FAT sector selection (0 ... 4BIGNUMER) + "Proceed" is offered after "Rebuild BS".

Code: Select all

Potential FAT location
FAT - sector - score
>[Proceed ]
                             Set FAT table location

Preset "1" -> Nothing. Again using "0" -> it starts searching:

Code: Select all

Disk /dev/sdb - 32 GB / 29 GiB - CHS 3891 255 63
     Partition                  Start        End    Size in sectors
   P FAT32                    0   0  1  3891 197 18   62521344

FAT : 32
Search subdirectory    4882432<upcounting slowly>/62521344 0

--- Then suddenly:

cluster size (0-128) :64  ---> ENTER for default

Disk /dev/sdb - 32 GB / 29 GiB - CHS 3891 255 63
     Partition                  Start        End    Size in sectors
   P FAT32                    0   0  1  3891 197 18   62521344

FAT : 32
Search root cluster      12288<upcounting slowly>/976514 1%

--- Then :

   P FAT32                    0   0  1  3891 197 18   62521344
Cluster 95052, Directory / found ?
Answer Y(es), N(o), Q(uit) or A(bort interactive mode). N or A if not sure.

>drwxr-xr-x   0   0         0  1-Feb-2021 22:20 files

---> Yes

FAT : 32
cluster_size 64 255
reserved     32 65535
sectors      0 65535
total_sect   62521344 4294967295
fat32_length 12272 4294967295
root_cluster 95052 4294967295
free_count   uninitialised uninitialised
next_free    uninitialised uninitialised
Extrapolated boot sector and current boot sector are different.


     Rebuild Boot sector           Boot sector
0000 eb3c904d 5357494e   .<.MSWIN  ffffffff ffffffff   ........
0008 342e3100 02402000   4.1..@ .  ffffffff ffffffff   ........
0010 02000000 00f80000   ........  ffffffff ffffffff   ........
0018 3f00ff00 00000000   ?.......  ffffffff ffffffff   ........
0020 0000ba03 f02f0000   ...../..  ffffffff ffffffff   ........
0028 00000000 4c730100   ....Ls..  ffffffff ffffffff   ........
0030 01000600 00000000   ........  ffffffff ffffffff   ........
0038 00000000 00000000   ........  ffffffff ffffffff   ........
0040 800029ac 22c07400   ..).".t.  ffffffff ffffffff   ........
0048 56b40ebb 0700cd10   V.......  ffffffff ffffffff   ........
0050 5eeb4641 54333220   ^.FAT32   ffffffff ffffffff   ........
0058 2020fe54 68697320     .This   ffffffff ffffffff   ........
0060 6973206e 6f742061   is not a  ffffffff ffffffff   ........
0068 20626f6f 7461626c    bootabl  ffffffff ffffffff   ........
0070 65206469 736b2e20   e disk.   ffffffff ffffffff   ........
0078 20506c65 61736520    Please   ffffffff ffffffff   ........
0080 696e7365 72742061   insert a  ffffffff ffffffff   ........
0088 20626f6f 7461626c    bootabl  ffffffff ffffffff   ........
0090 6520666c 6f707079   e floppy  ffffffff ffffffff   ........
0098 20616e64 0d0a7072    and..pr  ffffffff ffffffff   ........
00A0 65737320 616e7920   ess any   ffffffff ffffffff   ........
00A8 6b657920 746f2074   key to t  ffffffff ffffffff   ........
00B0 72792061 6761696e   ry again  ffffffff ffffffff   ........
00B8 202e2e2e 200d0a00    ... ...  ffffffff ffffffff   ........
00C0 00000000 00000000   ........  ffffffff ffffffff   ........
00C8 00000000 00000000   ........  ffffffff ffffffff   ........
00D0 00000000 00000000   ........  ffffffff ffffffff   ........
00D8 00000000 00000000   ........  ffffffff ffffffff   ........
00E0 00000000 00000000   ........  ffffffff ffffffff   ........
00E8 00000000 00000000   ........  ffffffff ffffffff   ........
00F0 00000000 00000000   ........  ffffffff ffffffff   ........
00F8 00000000 00000000   ........  ffffffff ffffffff   ........
0100 00000000 00000000   ........  ffffffff ffffffff   ........
0108 00000000 00000000   ........  ffffffff ffffffff   ........
0110 00000000 00000000   ........  ffffffff ffffffff   ........
0118 00000000 00000000   ........  ffffffff ffffffff   ........
0120 00000000 00000000   ........  ffffffff ffffffff   ........
0128 00000000 00000000   ........  ffffffff ffffffff   ........


   P FAT32                    0   0  1  3891 197 18   62521344
Directory /

>drwxr-xr-x     0     0         0  1-Feb-2021 22:20 files

Directory /files

 drwxr-xr-x     0     0         0 31-Jan-2021 13:00 .
 drwxr-xr-x     0     0         0 31-Jan-2021 13:00 ..
>-rwxr-xr-x     0     0         0  6-Feb-2021 00:52 sdcard

There is a emty file "sdcard", which however should be a folder perhaps?
The dates may have indeed been the last usage/modification times?
Dead end? Or a chance to somehow reconstrunct the filesystem?
Wise to use "Write boot sector"?
Or better bet on "Intel" parti type?

After more recovery or not: Is it wise to format the card and use it further? Or is it likely electrically impaired?

[recuperation]

Samsung 32GB micro SD card, some 4 years old, mainly just added files. Only used in Android phone, no swapping.
Somehow it became invalid in the Android phone. no real idea why.? Problem with low voltage? phone mechanical shock? Do such brand cards simply fail electrically after so few years? Or likely Android bugs or voltage problems?

Flash is convenience storage that can fail easily - apart from some medical approved Compact Flash cards. For answers ask a professional recovery company.

It asked to be formated in Android and also in Windows PC -> Aborted. Chkdsk /f wont start - no partition / RAW detected.

PhotoRec already recovered some thousands of files - but very messy quite without names. jpg's, gpx, mp3, txt, html, pdf, zip ... many types. Maybe 2/3 of stuff. Most mp3 data broken up in unusuable multiple pieces ....

As for the mp3s that observation of broken up pieces contradicts your statement of "mainly just added files". If you had just added files you would have good recovery chances.

Is there a chance for better recovery with TestDisk + chkdsk or so?

Maybe.

Starting key question: What is the typical preformatted partition table type of such 32GB Samsung microSD card? "Intel" or "None" ?

I don't know. Ask the manufacturer how he sold the cards.

What is "None"?

None means without a partition table, also called "superfloppy".

"Analyses" with both types fail to see anything reasonable with Quick & Deeper search.

Your card or partition might be encrypted.

"Intel" doesnt see a partition at all.

Code: Select all

Disk /dev/sdb - 32 GB / 29 GiB - CHS 3891 255 63
Current partition structure:
     Partition                  Start        End    Size in sectors

Partition sector doesn't have the endmark 0xAA552

Is it wise to try MBR Code / Write TestDisk MBR code to first sector - or better bet on "None" parti type at all?

Duplicating such a card with ddrescue would be wise. If you don't find a readable partition with Testdisk you can try out third party software.

After more recovery or not: Is it wise to format the card and use it further? Or is it likely electrically impaired?

It's not wise for you because you don't use backups and you are putting now lots of efforts into recovery. The question is if you can afford the loss of your content. When reusing the card you could use h2testw as a simple test. Otherwise the ddrescue reports will tell you a lot about errors and their location.

[kxr99]

Thanks

I already made a image within testdisk itself, w/o read errors, and I'm trying on that image. Is there an advantage of using ddrescue in addition?

Your card or partition might be encrypted.

Unlikely, I think: PhotoRec files were already found.
And with "None" parti table type, Type change of "Unkown" to "FAT32" , and in Expert mode after failing boot sector recover, and "Potential FAT location","Proceed", Cluster size 64, he finds 13 first-level directories accoring the log - with good file names - when searching with FAT sector 1 (or 0). But no reasonable root dir is found. The root dir may have been damaged. At the end he asks:

Code: Select all

Create a new root cluster with 13 first-level directories (Expert only) (Y/N)

That gives hope, that he could re-create a replacement FAT32 Superfloppy directory structure with at least many of the files orderly accessible.

But after Y on that question he says:

Code: Select all

Write error: Can't create FAT32 root cluster.

Why that? It operates on the image and there should be no hardware write failure?

Then I'm asked to enter the root cluster:

Code: Select all

root cluster (2-976513) :0

I enter 2, but then:

Code: Select all

Disk C:\backup\_sd32img\image.dd - 32 GB / 29 GiB - CHS 3892 255 63
     Partition                  Start        End    Size in sectors
   P FAT32                    0   0  1  3891 197 18   62521344

FAT : 32
cluster_size 64 124
reserved     1 191
sectors      0 62209
total_sect   62521344 129187456
fat32_length 24575 2281993727
root_cluster 2 74711100
free_count   uninitialised uninitialised
next_free    uninitialised uninitialised
Extrapolated boot sector and current boot sector are different.

--- LIST command:

   P FAT32                    0   0  1  3891 197 18   62521344
Directory /

No file found, filesystem may be damaged.

(CHS 3891 255 63, sector size=512 , 64 sectors per cluster -> 32768 byte per cluster)


Here I am stuck so far.

Any ideas?
Or which kind of software could bind these directories which testdisk already sees somehow partially - to form a reasonably working filesystem?

[recuperation]

Thanks

I already made a image within testdisk itself, w/o read errors, and I'm trying on that image. Is there an advantage of using ddrescue in addition?

The read error handling is better in ddrescue. Telling that you successfully created an image is an information worth to be posted in an initial posting.

Your card or partition might be encrypted.

Unlikely, I think: PhotoRec files were already found.
And with "None" parti table type, Type change of "Unkown" to "FAT32" , and in Expert mode after failing boot sector recover, and "Potential FAT location","Proceed", Cluster size 64, he finds 13 first-level directories accoring the log - with good file names -

I never used this option and instead of describing parts of what you had seen on the screen you would be better of posting screenshots.
I can't see your log file.

when searching from 1x FAX cluster 1 (or 0).

???

But not a reasonable root dir. The root dir may have been damaged. At the end he asks:

Code: Select all

Create a new root cluster with 13 first-level directories (Expert only) (Y/N)

That gives hope, that he could re-create a replacement FAT32 Superfloppy directory structure with at least many of the files orderly accessible.

But after Y on that question he says:

Code: Select all

Write error: Can't create FAT32 root cluster.

Why that? It operates on the image and there should be no hardware write failure?

Please check your rights in the file system. Did you lock the file with something else?

Then I'm asked to enter the root cluster:

Code: Select all

root cluster (2-976513) :0

I enter 2, but then:

Code: Select all

Disk C:\backup\_sd32img\image.dd - 32 GB / 29 GiB - CHS 3892 255 63
     Partition                  Start        End    Size in sectors
   P FAT32                    0   0  1  3891 197 18   62521344

FAT : 32
cluster_size 64 124
reserved     1 191
sectors      0 62209
total_sect   62521344 129187456
fat32_length 24575 2281993727
root_cluster 2 74711100
free_count   uninitialised uninitialised
next_free    uninitialised uninitialised
Extrapolated boot sector and current boot sector are different.

--- LIST command:

   P FAT32                    0   0  1  3891 197 18   62521344
Directory /

No file found, filesystem may be damaged.

(CHS 3891 255 63, sector size=512 , 64 sectors per cluster -> 32768 byte per cluster)


Here I am stuck so far.

Any ideas?
Or which kind of software could bind these directories which testdisk already sees somehow partially - to form a reasonably working filesystem?

As the root directory has not been created you won't see your folders. You only have a pointer pointing two cluster number 2 containing nothing.
You could search your file for free space where the root directory could possibly be installed instead. You are not bound to number 2.


I am not aware of any recovery software repairing file systems except for Testdisk. All the others do only recover. If you find the repair software you are asking for please let me know. As I said before try out other recovery software. Photorec does fingerprinting and won't incorporate this kind of information. Until now your metadata is broken. Other software might recover your folder without needing to write to your defective partition.

[kxr99]

EDIT: ".. FAX cluster" -> typo, meaning "when searching with FAT1-start 1 (or 0)" - this seems to be a sector number.
One has to enter a potential sector number for the FAT table(s to start this directory scan. I also tried FAT1 location 32 and 64 after reading https://en.wikipedia.org/wiki/Design_of ... tem#Layout (The total count of reserved sectors is indicated by a field inside the Boot Sector, and is usually 32 on FAT32 file systems.) . But after all that doesn't matter much here - see blow..

As the root directory has not been created you won't see your folders. You only have a pointer pointing two cluster number 2 containing nothing.
You could search your file for free space where the root directory could possibly be installed instead. You are not bound to number 2.

I am not aware of any recovery software repairing file systems except for Testdisk. All the others do only recover. If you find the repair software you are asking for please let me know. As I said before try out other recovery software. Photorec does fingerprinting and won't incorporate this kind of information. Until now your metadata is broken. Other software might recover your folder without needing to write to your defective partition.

Yes one needs a to write a root dir cluster - or enter the clusternumber of one of the dirs found.

I tried various combinations in expert mode directory scan. Instead of cluster size 64, I also tried cluster size 32 (=521*32 = 16kB) which was auto-suggested, when I put FAT1 & FAT2 start as 32. Then it was possible to write the artificial recovery root dir cluster composed from 13 first-level dirs found (13 plastic names DIR000NN in the root). But trying to enter these dirs with the "List" command resulted in invalid unreadable folders. Thus no subdirs with good names (as found according the log). Obviously inconsistent cluster pointers in the directory with clustersize 32.

While with 64 cluster when I accepted a folder containing a "files" sub-folder as root (see 1. post), it was possible to also navigate this sub-folder successfully. So I assume 64 is the correct cluster size, but somehow its not possible to write the auto-generated root dir cluster with clustersize 64. While several runs with 32 allow the auto root dir write - but the folders somehow point to invalid clusters.
Maybe testdisk has a bug with cluster size 64 ?

Its possible now that I manually set the cluster number of each first-level dir iteratively as root (tedious) - as found by clustersize 64 search. Those dirs & clusternumbers are written all in one into the log file with:
testdist /debug /log image.dd ; table type "None"; go back, set Expert mode. Force type to FAT32. Boot. Rebuild BS. Proceed. FAT1 location 32 (or 0 or ...). Let guess clustersize. Force it to 64. "A(bort)" for doing the complete search .
(I think dirs & clusternumbers were also written when using the original SD Card without /debug ).
This way its possible to at least avoid the complete search process for each first-level dir:
... Rebuild BS. Proceed. Stop early. let the dir search go (few seconds). force clustersize to 64. Stop early and give the clusternumber of the wanted first-level dir as seen in the previous log file.
So that is semi-successful now.
(The FAT1 start sector to be given doesn't seem to matter a lot. The correct clustersize is crucial.)

There are some deleted files (red marked) in the recovered listings - and those files usually are corrupt. Unfortunately it seems not possible to copy only everthing which is not marked red. But either single select or everything include the red ones...

I wonder if this is already the max quality which can be recovered. I think not everything what is indexed and findable (as done in a flat nameless and often fragmented manner via Photorec) ist accessible this way. Could be more. Maybe a suitable software should bind everything together which looks like a directory index cluster (whatever first or deeper level) and guess parameters from the validity of the cluster pointer and form a artifical recovery dir tree ...