[Windows Phone 7 Development and Hacking] Da_G:
TexFAT is indeed one of the filesystems used by WP7. It does in fact function as you guess (WP7 looks for the partition marked as User, and formats it to TexFAT to store user data)

However, the User partition is only one of the partitions contained inside the flash.store.bin. Knowing what goes there after the image is flashed to the device doesn't help us determine the format of flash.store.bin, unfortunately.

Referring to one of my earlier posted screenshots:

There are 2 copies of the FAT (this is the part we need to be able to read), followed by these partitions, in order: LOGO, BLDR, BSP, USP, SLDR1, SLDR2, ULDR1, ULDR2, NK, IMGFS, User.

You'll note that the User partition comes last. This is because, as you guessed, once WP7 is booted, it formats the area of flash from the beginning of the User partition to the end-of-flash. It does this so the available user storage can vary depending on the size of the ROM, and the size of the flash.

If anyone cares to take a stab at it, here's some detailed info:

Take a look at this hex dump posted by itsme (thanks for the great breakdown, itsme!)

See how there are 2 sets of rows, containing FLPART10 - that is the FAT1 and FAT2. These 2 copies are identical. You'll notice there are quite a few identical copies of things in the ROM, this is to facilitate fail-safe updating. If the power fails, you pull the plug, or a meteor strikes during a flash, and ruins one of the copies, the system will automatically fall-back to the fail-safe copy, allowing you to fix the problem by re-flashing without rendering your device into an unusable brick that needs to be sent back for JTAG flashing.

Cross-referencing the screenshot above with the hex offsets and sizes, we need to find a correlation between the numbers describing each FLPART10 partition, and the offsets/sizes in the actual file.

Taking the first one as an example:

"FLPART10" 41ff000a 00000000 L"LOGO" 00000005 00000000 00000006 00000000 00000005 00000000 00000000 00000028 {0} 00000000 00000000 00000000 00000000 {0} 00000040 00000800 {0} ff ff ff ff ff ff

FLPART10 means "this is a flash partition" - another possible value here is FLBADB10, "this is a section of bad flash blocks"

The only values i'm sure of are the 0x40 and 0x800 at the end. 0x800 is the sector size (2048 bytes per sector) and 0x40 is the number of sectors per block (64 sectors per block), knowing that we can extrapolate the block size of 0x20000 (131072 bytes per block) - each partition is aligned to this blocksize. If you take a look at the screenshot above, each one is located at a multiple of 0x20000. So it's logical that one of the values describes which block the partition is at.

The value immediately preceeding the partition name (a DWORD, 1 or 0) seems to indicate if this partition is writable or visible by the OS. (only NK, IMGFS, User are marked as 1)

Now, somewhere else in that same line of text, are numbers that describe the size of the partition, and where it is in the file. That's the bit I don't know yet :) As soon as we get that figured out, we can fully dump and rebuild flash.store.bin.

Sorry if that's too much technical info, but there's no easier way to explain that :)