[mkgmap-dev] OT: Garmin Edge 705 FAT recovery needed

Wed Mar 23 08:36:51 GMT 2011

On Mon, Mar 21, 2011 at 09:27:09PM +0200, Marko Mäkelä wrote:
>Any hints? How could I use dff or some other tool to reconstruct the 
>file allocation tables? Is there a good presentation of the FAT16 file 
>allocation table format somewhere, so that I could try to interpret the 
>tables in a hex editor? Or is there a Linux tool for visualizing or 
>pretty-printing the file allocation tables?

I found http://en.wikipedia.org/wiki/File_Allocation_Table to be a 
useful resource. It contains a table of the FAT entry values.

I tried writing the FAT entries for gmapbmap.img last night, but the 
file appears to be heavily fragmented in the file system. I restored the 
first two 16-kilobyte clusters so far.

So, today I tried to automate the FAT reconstruction. From a good file 
system dump, I extracted gmapbmap.img and got 16-byte strings that I 
could search for in my file system hexdump:

unzip -p Garmin.zip gmapbmap.img|od -Ax -t x1|
sed -ne 's/.*[048c]000 /[26ae]200: /p' > gmapbmap.img-data
grep -f gmapbmap.img-data garmin-sdb.txt > gmapbmap.img-addr 

(my hexdump has a : after the address, but od does not write it)

This almost worked. One 16-byte string was all zero, and it produced 
lots of matches.

[26ae]200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

So, I replaced that line with another:

[26ae]210: 20 5c df 22 01 01 4b e7 00 24 00 d3 16 00 00 62

After this, I verified that I have exactly one match for each pattern, 
that is, the md5sum of the sorted lines of the 16-byte hexdumps is the 
same, and that the patterns are unique:

sed -e 's/.*: //'<gmapbmap.img-data|sort|uniq -d
sed -e 's/.*: //'<gmapbmap.img-data|sort|md5sum
sed -e 's/[0-9a-f]*: //;s/ : .*//'<gmapbmap.img-addr|sort|md5sum

The next step is to create a map from image file offsets in 
gmapbmap.img-addr to file offsets in the real gmapbmap.img, to convert 
that to FAT cluster numbers, and to write the values to FAT1 and FAT2.  
Then, dosfsck should be happy with this file, and mtype from mtools 
should produce an identical copy of gmapbmap.img from the image.

This is quite a bit of work, but as I do not know if the device would 
boot if the entire file system were rewritten in a different layout, I 
prefer to go through the trouble. Once I am finished, I will archive a 
compressed file system image. It should be less than 6 megabytes, after 
all.

	Marko