Почему файлы, которые не были удалены, указывают на недействительные записи NTFS MFT? - PullRequest
Новая
       94

Почему файлы, которые не были удалены, указывают на недействительные записи NTFS MFT?

0 голосов
/ 12 апреля 2020

В последнее время я работаю с NTFS, чтобы выполнить быстрый поиск (путем анализа MFT), который должен выявить файлы с указанными расширениями c (даже если они были удалены) и найти их путь. Первая странная вещь, с которой я столкнулся, это то, что во всех случаях, которые я видел (3), диск C содержит много недопустимых записей MFT (более 3/4). Большинство из них (если не все) не проходят проверку подписи.

Обычно я думаю, что эти записи не используются, но есть еще одна проблема, которая заставляет меня думать, что что-то не так: когда все записи файла с требуемым расширением некоторые записи указывают на родительские записи MFT, которые не проходят проверку по той же причине. Но файлы помечены как «используемые», и я вижу их в проводнике. Кроме того, еще одна странная вещь заключается в том, что каталог, в котором они находятся, является действительным, поскольку есть файлы, которые находятся в том же каталоге / подкаталогах, которые указывают на допустимые каталоги (например, у меня есть файл log.txt, который находится на рабочем столе, и он указывает на неверная запись в файле. Также есть папка data (на рабочем столе тоже), которая содержит файл info.txt и «data» указывает на допустимую запись файла).

Проверка подписи (упрощенная): 

struct FILE_RECORD_HEADER  
{
    uint32      Magic;          //Should match FILE_RECORD_SIGNATURE
    uint16      OffsetOfUS;     //Offset of Update Sequence
    uint16      SizeOfUS;       //Size in 2-byte ints of Update Sequence Number & Array
    uint64      LSN;            //$LogFile Sequence Number
    uint16      SeqNo;          //Sequence number
    uint16      Hardlinks;      //Hard link count
    uint16      OffsetOfAttr;   //Offset of the first Attribute
    uint16      Flags;          //Flags
    uint32      RealSize;       //Real size of the FILE record
    uint32      AllocSize;      //Allocated size of the FILE record
    uint64      RefToBase;      //File reference to the base FILE record. Low 6B - file reference, high 2B - MFT record sequence number
    uint16      NextAttrId;     //Next Attribute Id
    uint16      Align;          //Align to 4 uint8 boundary
    uint32      RecordNo;       //Number of this MFT Record
};

#define FILE_RECORD_SIGNATURE       'ELIF'

FILE_RECORD_HEADER * header = (FILE_RECORD_HEADER *)rawFileRecord; //where rawFileRecord is a pointer to a block of memory in which a file record is stored
if(header->Magic != FILE_RECORD_SIGNATURE) //The file record is invalid

Получение LCN родителя: 

struct ATTR_FILE_NAME
{
    uint64  ParentRef;      //File reference to the parent directory. Low 6B - file reference, high 2B - MFT record sequence number
    uint64  CreateTime;     //File creation time
    uint64  AlterTime;      //File altered time
    uint64  MFTTime;        //MFT changed time
    uint64  ReadTime;       //File read time
    uint64  AllocSize;      //Allocated size of the file
    uint64  RealSize;       //Real size of the file
    uint32  Flags;          //Flags
    uint32  ER;             //Used by EAs and Reparse
    uint8   NameLength;     //Filename length in characters
    uint8   NameSpace;      //Filename space
    uint16  Name[1];        //Filename
};

ATTR_FILE_NAME * attr = (ATTR_FILE_NAME*)filenameAttr; //where filenameAttr is a pointer to the beginning of filename attribute somewhere in the rawFileRecord
uint64 parentLCN = attr->ParentRef & 0x0000FFFFFFFFFFFF;

Возможно ли потерять (с точки зрения поиска) файлы из-за этого несоответствия подписи (я думаю, да, но я хочу быть уверенным)? Почему некоторые записи в файлах указывают на недопустимых родителей, а другие указывают на допустимых (они должны иметь одного и того же родителя)?

...