Source
r/datarecovery•
40ft

I'm willing to write software to recover my file (with your help)

tldr: Would it be possible to iterate through non-allocated clusters of FAT16, so I can parse them myself and look for my missing data?

Hey, so I've just lost a single important file from a Garmin device. I hypothesize the culprit was my Android phone (I tried to OTG my Garmin to my Nexus 5). My Nexus showed me the file, and let me copy it, but the copy was 0 bytes on my phone. When I mounted the Garmin on my Mac, it showed as 0 bytes on the Garmin as well. But I'm 99% sure it was >200k before I plugged it in to my Nexus. So, looking at the Nexus logs, I see this:

02-21 13:36:34.768   148   166 V vold    : /system/bin/sgdisk
02-21 13:36:34.768   148   166 V vold    :     --android-dump
02-21 13:36:34.768   148   166 V vold    :     /dev/block/vold/disk:8,0
02-21 13:36:34.884   148   166 V vold    : DISK mbr
02-21 13:36:34.886   148   166 W vold    : disk:8,0 has unknown partition table; trying entire device
02-21 13:36:34.886   148   166 V vold    : /system/bin/blkid
02-21 13:36:34.886   148   166 V vold    :     -c
02-21 13:36:34.886   148   166 V vold    :     /dev/null
02-21 13:36:34.886   148   166 V vold    :     -s
02-21 13:36:34.886   148   166 V vold    :     TYPE
02-21 13:36:34.886   148   166 V vold    :     -s
02-21 13:36:34.886   148   166 V vold    :     UUID
02-21 13:36:34.886   148   166 V vold    :     -s
02-21 13:36:34.886   148   166 V vold    :     LABEL
02-21 13:36:34.886   148   166 V vold    :     /dev/block/vold/disk:8,0
02-21 13:36:35.538   148   166 V vold    : /dev/block/vold/disk:8,0: LABEL="EDGE520" UUID="0000-094B" TYPE="vfat"
02-21 13:36:35.540   148   171 V vold    : /system/bin/blkid
02-21 13:36:35.540   148   171 V vold    :     -c
02-21 13:36:35.540   148   171 V vold    :     /dev/null
02-21 13:36:35.541   148   171 V vold    :     -s
02-21 13:36:35.541   148   171 V vold    :     TYPE
02-21 13:36:35.541   148   171 V vold    :     -s
02-21 13:36:35.541   148   171 V vold    :     UUID
02-21 13:36:35.541   148   171 V vold    :     -s
02-21 13:36:35.541   148   171 V vold    :     LABEL
02-21 13:36:35.541   148   171 V vold    :     /dev/block/vold/public:8,0
02-21 13:36:36.185   148   171 V vold    : /dev/block/vold/public:8,0: LABEL="EDGE520" UUID="0000-094B" TYPE="vfat"
02-21 13:36:36.186   148   171 V vold    : /system/bin/fsck_msdos
02-21 13:36:36.186   148   171 V vold    :     -p
02-21 13:36:36.186   148   171 V vold    :     -f
02-21 13:36:36.186   148   171 V vold    :     /dev/block/vold/public:8,0
02-21 13:36:40.098   148   171 W Vold    : Filesystem modified - rechecking (pass 2)

Note the last call to fsck_msdos with the "preen" option. What? It checked and "repaired" the filesystem without even asking me! Is it possible this "check" just ate my data. The file was still correctly named, and still in the correct location, but it was zero bytes.

Anyway, back to the solution. I cloned the image, mounted it, repaired it, looked for lost files etc. and nothing comes up. But I'm guessing the data is still there somewhere. My last idea is to go looking through non-allocated clusters for my data. The data is quite regimented (i.e. a long list of similar records), and I can write some fault tolerant parsing code. I don't really want to have to write a FAT16 implementation to get to the clusters though. Any ideas?

Posted Feb 21, 2016, 10:33 AM UTC

34
DataMedics•

What type of file is it that you're trying to recover?

1
40ftOP•

It's a Garmin FIT file. I'm actually making good progress. I decided to skip trying to get a FAT library to give me me data, and started just parsing the entire disk image, from byte 0 in the Boot Record, all the way to the end. Due to the fact that the missing FIT data is mostly just a series of similar records smaller than sector boundaries, it's not too difficult to write fault tolerant code that just skips over stuff it doesn't understand, and spits out stuff it does. Each record also has a timestamp, so I've nearly got a dump that I'll be able to re-parse, re-order, then re-write the original file.

I will have to go back later though and find out exactly how it happened. This is the most egregious instance of data corruption I've ever experienced from tools which really shouldn't be corrupting filesystems, i.e. Android and the ancient code that's managing FAT.

1
DataMedics•

If you have any other sample files of the same type I can probably write a custom search algorithm to plug into R-Studio and just find the file in RAW that way.

1
40ftOP•

I very much appreciate the offer. Thanks. I just succeeded in recovering the file, with valid checksums and all, so I'm pretty happy. I was able to identify all the the clusters which had my data, extracted them, and sorted them using timestamps embedded in the data, and then fed them into the file parser. When the parser finally completed without errors, I knew I had the original file recovered.

1