Blog: NTFS Write Support GSoC - Week 5+

Here you can discuss ReactOS related topics.

Moderator: Moderator Team

Post Reply
coderTrevor
Posts: 14
Joined: Mon Mar 14, 2016 12:23 pm

Blog: NTFS Write Support GSoC - Week 5+

Post by coderTrevor »

I'll use this topic to cover the discussion of every week from here on. As always, comments are welcome and encouraged :)

Week 5
Week 6

Pathoswithin
Posts: 4
Joined: Mon May 30, 2016 3:04 pm

Re: Blog: NTFS Write Support GSoC - Week 5+

Post by Pathoswithin »

In Windows XP, the $END attribute is just 0xFFFFFFFF00000000. It certainly compatible with newer Windows, not sure about opposite.

coderTrevor
Posts: 14
Joined: Mon Mar 14, 2016 12:23 pm

Re: Blog: NTFS Write Support GSoC - Week 5+

Post by coderTrevor »

Hmmm I would not have expected there to be a difference between XP and server 2003. That's interesting, thanks!

jimtabor
Developer
Posts: 226
Joined: Thu Sep 29, 2005 3:00 pm

Re: Blog: NTFS Write Support GSoC - Week 5+

Post by jimtabor »

I wonder if it is a throw back to the FAT end of record 0xFF~FF depending on the bit size.

hbelusca
Developer
Posts: 1164
Joined: Sat Dec 26, 2009 10:36 pm
Location: Zagreb, Croatia

Re: Blog: NTFS Write Support GSoC - Week 5+

Post by hbelusca »

Concerning the 32-bit number after the file attribute 0xFFFFFFFF : I searched on Google for 0x11477982 and I've found this:
https://www.google.fr/search?q=0x11477982
http://winfaq.com.ru/ubb/Forum15/HTML/009680.html
http://forum.windowsfaq.ru/archivefr/in ... 44250.html
https://social.technet.microsoft.com/Fo ... Clustering
Looks like it is to be understood as the "record length"... At least this is what chkdsk says. Maybe the end of that structure is something like:

struct
{
...
ULONG Attributes;
ULONG RecordLength;
};

??

coderTrevor
Posts: 14
Joined: Mon Mar 14, 2016 12:23 pm

Re: Blog: NTFS Write Support GSoC - Week 5+

Post by coderTrevor »

Hi hbelusca! Thanks again for taking the time to do that search. As we discussed on IRC, I think these results actually indicate that the people posting those logs had file system corruption.

Let's take a look at the relevant lines from each of the three logs:
The record length 0x11477982 of attribute of type 0xffffff00 and
instance tag 0x0 in file 0x24c6 is not aligned.
La longueur d'enregistrement de 0x11477982 attribut de type 0xffffff00 et
balise d'instance 0x0 dans le fichier 0x24c6 n'est pas aligné.
27160: The record length 0x11477982 of attribute of type 0xfbffffff and
instance tag 0x1cc in file 0x100000000001d is not aligned.
(Let's ignore the fact that this last example has a pretty fishy file number and instance tag)


Here's some lines from our NTFS_ATTR_RECORD struct:

Code: Select all

typedef struct
{
    ULONG        Type;
    ULONG        Length;
    UCHAR        IsNonResident;
    UCHAR        NameLength;
    USHORT        NameOffset;
    USHORT        Flags;
    USHORT        Instance;
    ...
} NTFS_ATTR_RECORD, *PNTFS_ATTR_RECORD;
NTFS typically stores attribute records in their file record, one after another. There may be some padding to ensure each is aligned on an 8-byte boundary but they'll be stored sequentially. After the last attribute, is the end marker, 0xffffffff, aligned to the next 8-byte boundary. This is also where the type of the next attribute would be if there was one. We can see the "mystery magic" number after that, stored where the next attribute would store it's length.

Knowing this, it's pretty clear to see what happened: In each instance, the end marker of 0xffffffff has been corrupted by one byte, so the data at this offset is interpreted as another attribute. This causes the mstery number to be interpreted as record length. Of course, it makes no sense as record length; as chkdsk helpfully points out: it isn't even aligned!

One point this makes is it may be possible to get chkdsk to document the name of an unknown field by providing it with invalid information, and seeing a field's name certainly hints at its function. I don't know if that's helpful or not given what's already known about NTFS; in this instance we already knew which fields chkdsk [thought it] was referring to.

Post Reply

Who is online

Users browsing this forum: Ahrefs [Bot], Google [Bot] and 12 guests