YAFFS2 Implementation Notes

From SleuthKitWiki
Revision as of 13:01, 4 February 2013 by Apriestman (Talk | contribs)

Jump to: navigation, search

General File System Reconstruction

Determining the format of the spare area

The YAFFS2 specification does not specify exactly where the data in the header should be stored or exactly how the extra fields should fit in. In practice we've seen this format:

  • 4 byte sequence number
  • 4 byte object ID (with the object type in the high four bits if the header flag is set in the next entry)
  • 4 byte chunk ID OR high bit set (header flag) and the parent ID in the rest
  • 4 byte number of bytes

At present we've seen these 16 bytes start at offset 0, offset 2, or offset 30. TSK attempts to determine where the fields are by reading in a reasonable number of intialized spare areas and then doing some tests on each possible offset:

  • Sequence numbers should be the same for all chunks in a block
  • Sequence number shouldn't be null or 0xffffffff
  • Object ID can't be zero
  • If we have other options, we'd prefer the sequence number not to start with 0xff

These tests could certainly be improved upon.

Constructing the current version of each object

  1. Read in the sequence number, object ID, and chunk ID from the spare area of each chunk and record the offset of the chunk
  2. Make a list of chunks for each object ID and sort it by sequence number and then offset, resulting in a chronological list of chunks for each object
  3. The current header and data chunks can then be found by reading backwards through the list

The inode for the current version of an object is its object ID.

Constructing the file hierarchy

  1. The root directory always has object ID 1
  2. To find the children of a directory, search over all objects to find those with the appropriate parent ID