I have a uSD card here which has a dreaded "USBC" identifier-based CORRUPTION at the (former
) boot sector of its exFAT partition(gory details see "Hibernate may destroy fat32 partitions on USB-devices" https://bugs.gentoo.org/409565 ), thereby killing any normal access to the exFAT partition.
I tried to use testdisk 7.1-5 on Ubuntu, but failed (the partition type 7 - NTFS/exFAT - would be analyzed by testdisk, but seemingly as NTFS rather than exFAT partition layout).
Since I seem to have been successful, I am now quickly documenting a rough outline of the most important / crucial tricks needed here.
Page 7 of https://events.static.linuxfound.org/im ... owda_s.pdf
shows a nicely referenced hex edit overview of the exFAT boot sector data format.
We can see there that at offset 0x03 there's "EXFAT" identifier (the tell-tale sign of an exFAT boot sector).
Now it's time to install hexedit package.
By doing a simple
hexedit /dev/sdXXX (or wherever your formerly working exFAT partition resides - for me it's /dev/sdd1 currently; DO NOT HIT THE WRONG DEVICE FILE ELSE IT WILL BE TOAST, POSSIBLY) you can scroll over the entire content of your exFAT partition's data
(but avoid doing any modifications!!).
I then noticed that at offset 0x1800, there is *another* sector with "EXFAT" marker. I.e., most likely that's exFAT boot sector copy number 2.
You can then use a calculator such as kcalc (in Logic mode, to get Hexadecimal representation support).
[0x]1800 in hex when switching to dec is 6144. Dividing by the per-sector size (512), we'll get a result (sector number) of 12.
Now it's time to fire up the trusty old "dd" tool.
With commands such as
dd if=/dev/sdXXX of=~/MY_RECOVERY/boot_sector_corrupted.dat bs=512 count=1
we'll get a backup file of the corrupted sector (use a pager such as "less" to verify that you got the correct sector's content in that file).
Even better, for reliable forensics purposes (to definitely avoid unrecoverable corruption damage while experimenting!), it's possibly a good idea to write an entire device image (or at least definitely sufficiently large initial parts, say some 500MB) to some backup file somewhere:
dd if=/dev/sdXXX of=~/MY_RECOVERY/corrupted_disk_image_orig.dat
By doing a
dd if=/dev/sdXXX skip=12 of=~/MY_RECOVERY/boot_sector_number_2_ok.dat count=1
we'll get a backup file of the hopefully good, second exFAT boot sector.
Then we'll write that second boot sector copy to the normal boot sector at partition offset 0:
dd if=~/MY_RECOVERY/boot_sector_number_2_ok.dat of=/dev/sdXXX count=1
Successful result can be verified by doing another hexedit analysis of the exFAT partition device.
When starting testdisk again, I am now able to do a successful filesystem scan, and list directory contents.
A (previously unsuccessful, but now doable) run of fsck.exfat in my case does complain about cluster issues of some specific files, though. This may or may not be due to mismatching attributes/content of the second exFAT boot sector copy.
Since I do have a full backup of the original device image state (forensics rule #1!), I can now try to do properly filesystem-based repair attempts with sufficiently fully exFAT-oriented tools (even on Windows, perhaps?).
DISCLAIMER: this obviously is a very risky (DATA LOSS!), daunting area of work - I am not responsible for any issues caused by my quick descriptions, yaddayadda. And if you are not sufficiently experienced, then ask an expert for help.
I am wishing you the best of luck!
Oh, and finally: many thanks for an otherwise extremely useful recovery tool!!