Here is the bootsector/BIOS Parameter Block (BPB). This would normally be at the start of the drive, but in your dump I found it beginning at file position 201216 (0x1ed760). Call this the beginning of the "drive", or Head 0 Track 0 Sector 1. 2-byte numeric entries are stored ..er..something-endian (low byte first). In the table below I list these with the high byte first, showing the "actual" value. Those with more bytes than that, I've left as they would appear in a hexeditor. Usage Size (bytes) Value ============================================= Jump 3 e9 00 00 (Don't know which 'endian' this is stored as. Arbitrary anyway since there is no bootloader that needs to "jump over" this data anyway.) OEM_ID 8 SUNPLUS Bytes per sector 2 0x0200 Sectors per cluster 1 0x20 Reserved Sectors 2 0x0001 Total FATs 1 0x02 Max Root Entries 2 0x0100 Total Sectors 2 0x7cd7 Media Descriptor 1 0xF8 (Non-removable media) Sectors Per FAT 2 0x0003 Sectors Per Track 2 0x0010 Number of Heads 2 0x0004 Hidden Sectors 4 29 00 00 00 TotalSectorsLarge 4 00 00 00 00 int13 Drive Number 1 0x00 (OS-specific, ignore) Flags (Reserved) 1 0x00 ExtendedBootSignature 1 0x29 (indicates the following 3 fields are present...) Volume ID 4 00 00 00 00 Volume Label 11 00 00 00...00 System ID 8 FAT12 (according to MS whitepaper, this field should not be relied upon to determine the FAT type actually in use. However, the math works out, this is a FAT12 system) Special Bonus Bytes: the two-byte word beginning at file position 201726 (BPB+510) is 0xAA55. According to (http://scottie.20m.com/fat.htm) this is what the BIOS looks for to indicate that the disk is a boot disk. Why this would be set in a digital camera's FLASH is anyone's guess. (I don't think you can boot from the cameras :-) Or, I may be relying too much on bad documentation. The actual 1st FAT then would start at the sector after the BPB (BPB+512). The FAT in this case is 3 sectors (from Sectors Per FAT above), so file positions 201728 up to (not including) (201728+(512*3))=203264. There are 2 copies of the FAT, so the 2nd copy starts at 203265 and runs up to (not including) (203264+(512*3))=204800. The *root directory* begins at this point, and will be explained later. Under normal circumstances the FAT copies should be identical; the extra copy is for redundancy. FAT (Sector Table) (starts at 201728) ================ The FAT itself acts as a linked list. When a file is stored to the disk, it is split up into pieces (clusters), and the FAT is used to keep track of those clusters. From the above, a cluster for us is 0x20 (32) sectors. Each FAT entry represents a cluster of data, and the value of this entry points to the FAT entry representing the next cluster of the file. Each points to the entry representing the next piece of file until an 0xfff (indicating "last entry in chain") is reached. Actually, the possible values and their meanings are as follows: 0x00 Unused 0xFF0-0xFF6 Reserved cluster 0xFF7 Bad Cluster 0xFF8-0xFFF Last cluster in a file (anything else) Number of the next cluster in the file So, a file (slightly fragmented) might be represented as: 0 1 2 3 4 5 6 7 8 0x001 0x002 0x003 0x006 0x000 0x000 0x007 0xFFF 0x000 This would indicate that our file occupies clusters 0,1,2,3,6,7. Clusters 4, 5 and 8 are free. Things get slightly hairy for us here because, besides the screwed-up endians, each FAT entry is *12 bits* long. Additionally, the first 2 *entries* (not bytes!) are reserved. (The first should be equal to the media descriptor from the BPB, or 0xf8. The second is kind of arbitrary.) Finally, remember that the first entry is called entry 0, the next entry 1, and so on. There are a number of documents on the WWW explaining how to map a 12-bit cluster entry to a byte position in the FAT, and, as far as I can tell, they are *all wrong*. Here is a method that DOES seem to work... Converting cluster number to FAT physical byte position: For any logical cluster number n, ### If n is even ### the physical location of the entry is the low four bits in location 1+(3*n)/2 and the 8 bits in location (3*n)/2 ### If n is odd ### then the physical location of the entry is the high four bits in location (3*n)/2 and the 8 bits in location 1+(3*n)/2 (round down). Remember endian switch. If you remember to count from 0, this works and takes into account the reserved entries so you don't have to remember to skip over them. Root Directory (begins at 204800) ============== Each entry in the root directory is 32 bytes. Since MaxRootEntries=0x0100 (256), this entire section is 32*256=8192 bytes long. So the Data Area (to be discussed later) starts at position 212992. Here is where all that Sector/Head/Track stuff we've been largely ignoring (since this is a chip [actually, file!], not a disk) would come back to bite us if we were reading a disk. Directory and file entries store locations in "Logical sector addressing", which ignores the physical sector/head/track and stores only a logical Sector number instead. (Head 0 Track 0 Sector 1 = "Sector 0", and so forth.) We will not have to convert logical sectors to head/track/sector. Entries in the Root directory (or any other) are 32 bytes arranged as follows: Usage Size (bytes) Value (single example taken from memory) ============================================= Filename 11 (File or directory name. ".", "..", "DCIM" or "100MEDIA" for us) Attributes* 1 Attribute flags. (Reserved) 8 (00 00 00 00 00 00 21 00) index in EA data 2 (0x0000) Timestamp 4 (00 00 21 00) Starting cluster 2 (0x0002) File size 4 (00 00 00 00) (Backward-endian) *The highest 2 bits are unused. The lower 6 bits indicate attributes as follows: xxxxx1 Readonly xxxx1x Hidden xxx1xx System xx1xxx Volume ID x1xxxx Directory 1xxxxx Archive For us, the Root Directory contains only a reference to a subdirectory, "DCIM". Directories are just a type of file, with the Directory bit set. This file (in the data area) contains a list of 32-byte file entries just like the Root directory. Directories other than root *should* start with "." and ".." entries that point to themselves and the parent directory, respectively. The "DCIM" directory has a subdirectory of its own, "100MEDIA". It is this directory that contains the picture files, DSC*.JPG. The important parts to get out of the directory entry are the starting cluster number and the file length. The starting cluster number tells you where to start in the FAT sector table; just follow the chain there until it ends, and assemble the clusters referenced by that chain into a file. The file size will seldom be an exact multiple of the cluster size, so there will be some slack at the end of the last cluster. Truncate it at the filesize obtained from the directory entry. The Data Area (should begin at position 212992, but may be different due to wear-leveling system used by the camera) ============= As its name implies, the data area stores the actual clusters of data that comprise the files. Some of these "files" may be directories, and contain entries of the same form as those in the Root directory. Non-directories simply contain the raw file contents.