Creating FAT File System from Flash Memory Image

I suggest you read the article "How a Corrupted USB Drive Was Saved by GNU/Linux" published in the Linux Journal and which can be found on the Internet.

Thanks ba2llb,

The article is a good one. However, from what I could tell with a quick glance through it was that the author was attempting to repair a corrupted logical image that was found on the USB drive.

What I have is a byte by byte copy (from 0 to 0x10800000) of the physical memory of a flash device. I need to take the blocks from this physical image and place them in the proper order so that a logical image of the FAT16 filesystem is created. My understanding so far of how flash memory saves data is that the data blocks (2048 bytes in this case) are not necessarily in any particular order, and the metadata associated with each block (64 bytes for each block in this case) contains references to where the block "fits" in the logical image. The File Translation Layer (FTL) of the OS interface with Flash memory takes care of a lot of the logical ordereing of the blocks. So, what I need to do is emulate the FTL in order to create the logical image from the physical one.

Thanks!

You would expect for as FAT disk to have a BPB (Bios parameter block) near the start of the disk. It may be in place of a boot sector, or pointed to by the boot sector, typically at location 0x3f or 0x20

Following the BPB will be the FAT. This normally starts with a 0xF8 0xFF and then typically incrementing 16 bit numbers (with gaps)

If you can see this type of pattern, any data recovery program should work.

If you don't see these patterns, it may not be a FAT disk.

Other indicators can be subdirectories for a FAT you should find sectors that start '. ' and then at byte 0x20 '.. '

You do not state if you think the memory is valid or corrupted. A common FAT failure is that the start of the memory gets overwritten, killing all file system parameters. In these cases, analysis with the subdirectory pointers can be very useful

Hi mscotgrove,

I have a logical image from the same make/model device that I am using as a reference to help with the translation from the physical image. The logical image does have the 0xF8 0xFF starting at 0x200, and there are references to FAT16 within the logical image.

However, I am having difficulty finding the corresponding bytes in the hex dump of the physical memory.

As far as I know, the physical hex dump is not corrupted. It is the result of the physical extraction of the flash module from the device circuit board, and then reading the data directly from the module.

My ultimate goal is to develop some sort of algorithm/translator to take a physical dump of a flash module and create a logical image on which I can perform data analysis.

I am partially wondering if the boot sector is made on the fly by the Flash Translation Layer, and doesn't actually exist in the physical memory at all. However, this doesn't make complete sense to me…

Thanks!

FAT16 as a single partition does not always have a boot sector

If you performed a forensically sound imaging of the flash memory device given that the FAT file system is almost guaranteed to have been used, there should be no problem examining the contents. Did you only grab a particular partition or the entire contents of the storage media? Have you tried reading the contents of the image using AccessData FTK? Something tells me you do not know enough yet about FAT layout / structure to develop the utility programme you initially spoke about in this thread. Could you post a URL to grab the image so others can help you?

Ok, I am pretty new at this, and I expect that my terminology is not yet consistent with the industry. Based upon the responses I have seen so far, I expect there is some confusion as to what "image" we are talking about.

My understanding is that flash memory does not work the same way a hard disk drive does. Flash memory needs to be concerned with "wear-levelling" so the same sectors are not written all the time, thus wearing out the sector prematurely. Because of this wear leveling, the order that the data appears in the sectors is generally fragmented, and the flash module (or the flash translation layer, just above the flash in the OS) keeps track of how the fragmented blocks are put together. It keeps this ordering in a different manner than FAT or inodes would. In fact, quite often the wear-levelling algorithms and other sector management details are proprietary.

So, if I had a hard disk drive, and performed a dd command to create an image of the disk, I would get a file that I could mount and then perhaps use the many forensic tools available to look at it.

However, if I were to perform a similar dump of a flash memory module (from address 0x0 to the end of memory), I would get a file that contains N blocks of size X, each of which has M bytes of metadata associated it. However, these blocks are not in any particular order due to wear levelling and other "features" of the flash. (The Flash Translation Layer or whatever the manufacturer uses will fetch these blocks in the proper order as needed). At my worksite, we are calling this type of hex dump a "physical" image.

In order to make an image that would match an image made from a dd command on a hard drive, I need to reorder the blocks in the physical image (removing the meta-data along the way) to create such an image (we are calling it a "logical" image because the logical address of the data is likely not the same as its physical location in the flash memory). According to the paper I referenced in my original post, the metadata for each flash block has information that can be used to do this (perhaps not *all* the information, but some necessary information at least).

So, what I have, is a "physical" dump of a flash module, which was obtained by physically removing a memory module from a device, remounting it on a custom board, and the using VHDL or some other manner to get the memory values from byte 0x0 to the end. I also have a "logical" image of the same model device (which I can mount and look for deleted files, etc) that I am using as a reference. As I stated before, my goal is to come up with an algorithm that I can use to translate the "physical" image to create a "logical" one.

As I said, I am pretty new at this (I started looking into this about four weeks ago). If anything I have said is out of whack, please correct/educate me, especially as to what the proper terminology might be and how flash stores data.

To ba2llb Yes, it is likely that I do not know enough about FAT yet. The last time I had to deal with FAT directly was an Operating Systems class 18 years ago, and even then it was a sideline, since we were doing hands on with UNIX and inodes… The logical image I have is FAT16, and I can trace the boot sector and directory table (albeit slowly, since I am not used to it) using a hex editor. I can also mount it and peruse it as a regular filesystem on my workstation. Unfortunately, I am unable to post either image.

To Michael Thanks for the information that a FAT partition may not always have a boot sector. The logical image I have does have a boot sector, but the image was obtained and put together via commands to the flash driver. Do you think the flash driver could have created it as it returned the data? That would be very useful information if that sometimes happens…

Thanks for your help and any other information you may have!

If you do have wear leveling then that is an extra layer you will have to handle. I have never dealt with wear leveling, but for a device fixed/soldered to the controller, there would be no necessity to make the leveling portable. Somewhere there will be mapping table to map the logical sectors to physical sectors, probably in clusters rather than 512 byte sectors.

You need to find some points in your image that are self referencing. Subdirectory entries are often the best for FAT. You may then see a pattern of how data has been stored, or translated.