Fat32 Data Recovery in 5 minutes

Geordie Millar | gm@stackunderow.com

Was ist in deutscher geschrieben, klingt eher technischen
Thursday, 16 September 2010

The Problem
Camera is constantly writing to the card File doesnt get a lesystem entry until its nished File is MIA, I want to see the crash video! Camera lost power before recording was nished (front part of plane separated, battery was ejected.

Thursday, 16 September 2010

PARKZONE RADIAN
Thursday, 16 September 2010

What to do?
Dont write to the card. Dont lesystem check the card. Dont even mount it. Image it. Stop diskarbitrationd on OS X dd if=/dev/disk2s1 of=~/sdcard.img bs=128m chmod -w ~/sdcard.img

Thursday, 16 September 2010

Volume Header (512 bytes)

Reserved Sectors FAT 1 FAT 2

Clusters

FAT32 STRUCTURE (NOT TO SCALE)

Thursday, 16 September 2010

jmp short 3c nop

totalSectors
media Descriptor

mkdosfs\0
sectorsPer sectorsPer FAT Track media Heads

bytesPer Sector nHiddenSectors

sectors Per Cluster

reserved Sectors
nSectors

num numdirent FATs

sectors PerFAT reserved

sectors PerFAT

ags reserved volumeLabel

fatVers Num

clusterNumRootDir
drive Letter NT Flags sig

cluster FSInfo

clusterBa ckupBoot

volumeSerialNumber

volumeLabel bootCode

sysIdent bootCode (415 more bytes)

partSig

VOLUME HEADER
Thursday, 16 September 2010

jmp short 3c nop

totalSectors
media Descriptor

mkdosfs\0
sectorsPer sectorsPer FAT Track media Heads

bytesPer Sector nHiddenSectors

sectors Per Cluster

reserved Sectors
nSectors

num numdirent FATs

sectors PerFAT reserved

sectors PerFAT

ags reserved volumeLabel

fatVers Num

clusterNumRootDir
drive Letter NT Flags sig

cluster FSInfo

clusterBa ckupBoot

volumeSerialNumber

volumeLabel bootCode

sysIdent bootCode (415 more bytes)

partSig

VOLUME HEADER (TL;DR)

Thursday, 16 September 2010

Volume Header (512 bytes)

0 bytes fat2addr = fat1addr + sectorsPerFat * bytesPerSector

Reserved Sectors FAT 1 FAT 2

512 bytes fat1addr = bytesPerSector * nHiddenSectors

rstDataSector = (nHiddenSectors * bytesPerSector) + (numFATs * (sectorsPerFat * bytesPerSector))

Clusters

FAT32 STRUCTURE (NOT TO SCALE)

Thursday, 16 September 2010

Cluster 2 Cluster 3 Cluster 4 Cluster 5 Cluster 6 Cluster 7 Cluster 8 Cluster 9

CLUSTER FORMAT
Thursday, 16 September 2010

0x0FFFFFFF 0x00000004 0x00000005 0x00000006 0x00000007 0x00000008 0x0FFFFFFF

0x00000000 - free cluster 0x00000001 - reserved 0x00000002 to 0x0FFFFFEF - next cluster is this one 0x0FFFFFF0 to 0x0FFFFFF6 - reserved 0x0FFFFFF7 - this cluster has a bad sector, dont use it 0x0FFFFFF8 to 0x0FFFFFFF - this is the last cluster Why do we need 8 values for EOF? Why are there only 28 bits used? What is 0x00000001 reserved for? (remember that this was a Microsoft invention here)

THE FAT
Thursday, 16 September 2010

0x0FFFFFFF 0x00000004 0x00000005 0x00000006 0x00000007 0x00000008 0x0FFFFFFF

directory: le1 starts at 3 consult FAT: 3->4->5->6->7->8 read clusters 3,4,5,6,7,8

READ CLUSTERS
Thursday, 16 September 2010

What next?

Go through the FAT, for each cluster, assemble a set of linked list chains from all the pointers. Go through each chain and dump all the clusters to a le.

Thursday, 16 September 2010

THE RESULT
Thursday, 16 September 2010

There are two unaccounted for videos here. Lets play them... Except they dont play. What a shame.

Thursday, 16 September 2010

gm$ file * 11.avi: RIFF (little-endian) data, AVI, 0 x 0, >30 fps, video: Motion JPEG, audio: uncompressed PCM (mono, 24000 Hz) 27.avi: RIFF (little-endian) data, AVI, 720 x 480, 30.00 fps, video: Motion JPEG, audio: uncompressed PCM (mono, 24000 Hz) 29.avi: RIFF (little-endian) data, AVI, 720 x 480, 30.00 fps, video: Motion JPEG, audio: uncompressed PCM (mono, 24000 Hz) 30.avi: RIFF (little-endian) data, AVI, 720 x 480, 30.00 fps, video: Motion JPEG, audio: uncompressed PCM (mono, 24000 Hz) 31.avi: RIFF (little-endian) data, AVI, 720 x 480, 30.00 fps, video: Motion JPEG, audio: uncompressed PCM (mono, 24000 Hz) 32.avi: RIFF (little-endian) data, AVI, 720 x 480, 30.00 fps, video: Motion JPEG, audio: uncompressed PCM (mono, 24000 Hz) 33.avi: RIFF (little-endian) data, AVI, 0 x 0, >30 fps, video: Motion JPEG, audio: uncompressed PCM (mono, 24000 Hz)

FILE *
Thursday, 16 September 2010

HEXEDIT TIME!
Thursday, 16 September 2010

RIFF type AVI LIST type hdrl avih - main headers strl - stream headers LIST type movi (optionally also rec ) 00dc compressed video 01wb audio 00dc compressed video 01wb audio

AVI FILE FORMAT

Thursday, 16 September 2010

AVI hdrl headers movi 00dc compressed video 01wb audio 00dc compressed video 01wb audio 00dc compressed video 00dc compressed video 00dc compressed video 01wb audio 01wb audio 01wb audio

00DC

01WB

DO THIS:
Thursday, 16 September 2010

AUDIO FORMAT
Thursday, 16 September 2010

Split the le by every instance of FFD8 and write to a le Motion JPEG frames have no DHT segment Simple. Apple must be using the QuickTime decoder for it which knows what motion JPEG is, and therefore is using the right DHT.
Thursday, 16 September 2010

Wrong! The le works in imagemagick and Chromium. FFC4 is the marker for the start of the Huffman table. Theres one in the le. This camera is doing it the dodgy way - probably just writes out JPEGs from an embedded JPEG camera chip.

Thursday, 16 September 2010

IMPORT
Thursday, 16 September 2010

What went wrong? Thats not the last frame!

Thursday, 16 September 2010

0x0FFFFFFF 0x00000004 0x00000005 0x00000006 0x00000000

directory: le1 starts at 3 consult FAT: 3->4->5->6->? Whered the le go? Delayed write = incomplete sector chain. The missing part of the FAT is on a sector boundary. Block allocation, however, is pretty much linear for a card that started off empty. Read from sector 3 to where the data becomes zeros. Use the FAT only for the starting position.

READ CLUSTERS - WHAT WENT WRONG?

Thursday, 16 September 2010

WHAT YOU WERE HERE FOR, RIGHT?

Thursday, 16 September 2010

A MORE PLAUSIBLE LAST FRAME

Thursday, 16 September 2010

Where to now?
http://gm.stackunderow.com/blog/pivot/entry.php?id=158 http://vimeo.com/14581494 http://en.wikipedia.org/wiki/File_Allocation_Table http://wiki.osdev.org/FAT http://gm.stackunderow.com/stuff/fat32_5mins.pdf

Thursday, 16 September 2010