Принцип сортировки NTFS_RECORD

← →
Riply © (2007-06-23 07:06) [0]

Здравствуйте !
Уже почти целый день бьюсь и никак не могу понять:
по какому принципу отсортированы записи в MFT :(
В общем случае, задача звучит так: по имени файла определить "номер записи в MFT".
Если постараться, то, вроде, ее можно свести к
"написанию" функции сравнения двух записей в MFT:
function Ntfs_RecordCompare(const pRec1, pRec2: PFILE_RECORD_HEADER): integer;
При помощи "метода научного тыка", можно сделать (ну очень шаткое) предположение,
что результат этой функции зависит от следующих параметров FILE_RECORD_HEADER:
Ntfs.Usn: Int64;
// The Update Sequence Number of the NTFS record.
Flags: USHORT;
// A bit array of flags specifying properties of the MFT entry.
// The values defined include: 0x0001 = InUse, 0x0002 = Directory
BytesInUse: ULONG;
// The number of bytes used by the MFT entry.
Сюда же надо добавить параметры из FILENAME_ATTRIBUTE
DirectoryFileReferenceNumber: ULONGLONG;
// The file reference number of the directory in which the filename is entered.
NameType: UCHAR;
//The type of the name.A type of zero indicates an ordinary name, a type of one indicates
//a long name corresponding to a short name, and a type of two indicates a short
//name corresponding to a long name.
А также, от того является ли данная запись, записью "системного файла" или нет.
То что зависит от NameType, у меня вообще в голове не укладывается.
Остальные, хоть как-то да можно объяснить( с натяжкой) :)
P.S. Что-то я совсем запуталась :(

← →
Riply © (2007-06-23 12:25) [1]

Интересно: если у DirectoryFileReferenceNumber рассматривать
только последние 48 бит: NewNum := (DirectoryFileReferenceNumber and $0000FFFFFFFFFFFF),
то начинает проявляться что-то напоминающее закономерность :)
При (NewNum >= 30), если рассматривать объекты типа "FILE", исключив директории,
то оставшиеся записи в MFT отсортированы по NewNum.
NewNum меньше 30 имеют файлы типа: $ObjectID, $LogFile и т.п.
Исключение составляют три файла: MOUNP~1, bootex.log и tracking.log
Что это за файлы - не знаю.
Explorer их не находит(к разряду "уничтоженных" они не относятся).
$ - файлы, бог с ними. Они не от мира сего :)
А вот если бы суметь "объяснить" неувязочку с этими тремя файлами,
то у нас появилось бы некое подобие сортировки :)
Никто не знает кто они такие ?
P.S. Подопытный диск не системный.

← →
Anatoly Podgoretsky © (2007-06-23 12:38) [2]

Ну ты дала, нашла где задавать такой вопром, а ну бегом в WinAPI

← →
Dimaxx © (2007-06-23 16:47) [3]

> MOUNP~1, tracking.log

Лежат в папках SystemVolumeInformation, по умолчанию к ней (и всему содержимому) имеет доступ тока сама винда. Хотя ничто не препятствует сделать до содержимого доступ себе... :)

← →
Dimaxx © (2007-06-23 16:49) [4]

> NewNum меньше 30 имеют файлы типа: $ObjectID, $LogFile и
> т.п.

Насколько я понимаю - это файлы невидимые для пользователя. Поэтому не учитывай их - они нужны для функционирования файловой системы NTFS.

← →
Riply © (2007-06-24 01:37) [5]

> [3] Dimaxx © (23.06.07 16:47)
>> MOUNP~1, tracking.log
>Лежат в папках SystemVolumeInformation
Спасибо.
Видимо, я пошла не тем путем :(
Можно, конечно, сказать про $-файлы и файлы из SystemVolumeInformation
что "это неправильные пчелы" (с) Винни и убрать их из рассмотрения :)
Но, мне не нравятся правила, в котроых есть исключения :).
Алгоритм существует. Просто обязан быть. Про него известно следующее:
Базовый принцип: минимальное количество обращений
к диску при поиске записи, соответствующей файлу.
Чем меньше "вложений" в имени файла,
тем меньше обращений к диску требуется системе для его нахождения.
Скорее всего я не там его ищу.
Видимо, есть еще какие-то характеристики, про которые я еще не знаю (пока не знаю :)
[2] Anatoly Podgoretsky © (23.06.07 12:38)
>Ну ты дала, нашла где задавать такой вопром, а ну бегом в WinAPI
Ну вот. Дожили. Ликвидированы последние остатки демократии. :)
Теперь прогоняют даже из "начинающих" :)

← →
Германн © (2007-06-24 02:34) [6]

> Ну вот. Дожили. Ликвидированы последние остатки демократии.
> :)
> Теперь прогоняют даже из "начинающих" :)
>

Почти все стадии сего процесса ты уже прошла. Следущая стадия вполне может оказаться стадией "Прогона Через Строй"! Готова?
:)

← →
Riply © (2007-06-24 03:01) [7]

Если кому интересно:
В MFT (NTFS) нет "прошитого" алгоритма сортировки :)
Она позволяет сортировать практически по любому параметру(набору параметров).
За тип сортировки отвечает параметр CollationRule из INDEX_ROOT структуры.
"A numeric identifier of the collation rule used to sort the index entries."
P.S.
Я конечно понимаю: гибкость системы и все такое...
Но надо же и меру знать ! :))

> [6] Германн © (24.06.07 02:34)
>Следущая стадия вполне может оказаться стадией "Прогона Через Строй"!
Это как в "царской" армии ?
Сижу себе смирно. Никого не трогаю. А тут "через строй" :)

← →
Германн © (2007-06-24 03:14) [8]

> > [6] Германн © (24.06.07 02:34)
> >Следущая стадия вполне может оказаться стадией "Прогона
> Через Строй"!
> Это как в "царской" армии ?
> Сижу себе смирно. Никого не трогаю.

Ты ещё скажи "починяю примус"! :)

← →
tesseract © (2007-06-24 12:28) [9]

> В общем случае, задача звучит так: по имени файла определить
> "номер записи в MFT".

> В MFT (NTFS) нет "прошитого" алгоритма сортировки :)

NTFS использует B-tree организацию, какой номер записи?. То что ты упоминаешь это файловые потоки, их может быть до 2^32 если правильно помю Руссиновича.

← →
Riply © (2007-06-24 14:10) [10]

>[9] tesseract © (24.06.07 12:28)
>NTFS использует B-tree организацию, какой номер записи?.

"The filename attribute is always resident." (с) Gary Nebbett
Отсюда делаем вывод, что для каждого файла, в MFT существует NTFS_RECORD,
сожержащая базовую информацию о файле "внутри себя" (в том числе и его имя).
Эту запись можно найти, например, используя FileReferenceNumber.
Следовательно, можно построить соответствие Файл ---> NTFS_RECORD.
Порядковый номер этой записи и имеется ввиду.
Использование же ATTRIBUTE_LIST для хранения атрибутов файла, ничего не меняет,
т.к. внутри MFT все равно есть NTFS_RECORD с filename attribute, содержащий еще и ссылку на этот лист.

>NTFS использует B-tree организацию
Да, использует. Например, в таких структурах как: NTFS_RECORD_HEADER с типом "INDX" (INDEX_ROOT)
или в атрибутах типа AttributeIndexRoot, один из вариантов - хранение (резидентно или нет) списка файлов в данном каталоге.
Но, даже, если он (список) не резидентный, то все равно, его "начало" резидентно.
Поэтому, я не понимаю исходя из ты противопоставляешь:
"NTFS использует B-tree организацию" и "какой номер записи"

>То что ты упоминаешь это файловые потоки, их может быть до 2^32 если правильно помю Руссиновича.
Эту фразу я совсем не поняла. Что имеется ввиду под "То что ты упоминаешь" ?
И какую роль играет то, сколько потоков у файла ?

← →
Riply © (2007-06-24 14:18) [11]

>[10] Riply © (24.06.07 14:10)
> для каждого файла, в MFT существует NTFS_RECORD
Порушенную или подвегшуюся атаке "самопрячущихся" троянов систему не рассматриваем. (пока :)

← →
Игорь Шевченко © (2007-06-25 10:16) [12]

> по какому принципу отсортированы записи в MFT :(

По FILEID

Я же говорил, читай Неббета. Марш в библиотеку!

← →
Riply © (2007-06-25 11:40) [13]

> [12] Игорь Шевченко © (25.06.07 10:16)
> По FILEID
А где такой ID живет ? В тех структурах, которые я "передирала" из С++ ничего похожего нет.

>Я же говорил, читай Неббета. Марш в библиотеку!
Маршаю !
P.S.
Хорошо еще, что послали в библиотеку к Неббету, а не к брату во Христе :)

← →
Игорь Шевченко © (2007-06-25 12:19) [14]

Собственно, FILEID - это индекс для файла в файле $MFT.

A file ID is the number of the file, like the inode number on unix systems, $Mft has filenumber 0 and is the first entry (in itself). The Openfilebyid allows you to go through all the files and folder on the volume, you could just write one for loop which will open and analyze/defragment all your files and folders. When you call the function with fileId 0 for instance it will return you handle to the $Mft,
when you try to open an file with a filenumber that doesn"t exist, it returns a handle to the file that has the largest possible filenumber under the number you specified and gives you the filenumber of that file.
In other words you start by trying to open the largest possible filenumber 0xFFFFFFFF and you will get a handle to lets say file 45000, next you try 44999 and if it exists good and you do your stuff and defragment the file or folder, otherwise you get the next file that exists (e.g. 44587 ) and so on.

← →
vpbar (2007-06-25 14:44) [15]

Звиняйте, что лезу. Но просьба - развивайте тему. Может найдете что нибудь позволяющее получить целочисленный идентификатор(ID) для файла (типа i-node в unix системах) чтоб затем по этому ID можно было найти файл (определить имя, размер и т.д). А то я искал искал, но не нашел.
Нашел только GetFileInformationByHandle которая вроде возвращает чтото похожее ID (http://vsokovikov.narod.ru/New_MSDN_API/Menage_files/str_by_handle_file_information.htm) но как затем по этим nFileIndex найти файл - непонятно.
Так что, успехов.

← →
Riply © (2007-06-25 15:05) [16]

> [15] vpbar (25.06.07 14:44)
>Нашел только GetFileInformationByHandle которая вроде возвращает чтото похожее ID
>этим nFileIndex найти файл - непонятно.
Например, через IoControlDevice

> [14] Игорь Шевченко © (25.06.07 12:19)
Игорь, в "моем Неббете" (Windows NT 2000 Native API Reference) ничего подобного я найти не сумела :(
Может у меня он "неправильный" ? :)
Или надо искать другую его книгу ?

← →
Игорь Шевченко © (2007-06-25 15:40) [17]

Riply © (25.06.07 15:05) [16]

Оно и есть. В приложении описание структур NTFS и примеры работы через FILEID

← →
Игорь Шевченко © (2007-06-26 09:49) [18]

Riply © (25.06.07 15:05) [16]

Есть такая полезная функция Nt(Zw)QueryInformationFile. Указывая в качестве FileInformationClass FILE_INTERNAL_INFORMATION как раз получается заветный FileID для известного файла. А у файлов метаданных NTFS эти самые FileID"s ваще фиксированные.

← →
vpbar (2007-06-26 11:10) [19]

>>[16]Riply ©
>> Например, через IoControlDevice
Ууу. Муторно. К тому же IoControlDevice , по-моему, работать будет только под админом.
Видимо в данном случае нет нормальных решений.

← →
Игорь Шевченко © (2007-06-26 11:21) [20]

vpbar (25.06.07 14:44) [15]

> Может найдете что нибудь позволяющее получить целочисленный
> идентификатор(ID) для файла (типа i-node в unix системах)
> чтоб затем по этому ID можно было найти файл (определить
> имя, размер и т.д).

Пост № 18 читай

← →
Riply © (2007-06-26 14:36) [21]

>[17] Игорь Шевченко © (25.06.07 15:40)
>Оно и есть. В приложении описание структур NTFS и примеры работы через FILEID
С этим приложением, с грехом попалам, вроде, разобралась.
Правда, не совсем уверена, что приложения у нас одинаковые: нет у меня рассуждений о том, что
"when you try to open an file with a filenumber that doesn"t exist,
it returns a handle to the file that has the largest possible filenumber
under the number you specified"

>[18] Игорь Шевченко © (26.06.07 09:49)
>Есть такая полезная функция Nt(Zw)QueryInformationFile.
>Указывая в качестве FileInformationClass FILE_INTERNAL_INFORMATION как раз получается заветный FileID для известного файла.
>А у файлов метаданных NTFS эти самые FileID"s ваще фиксированные.
Попробовала: действительно, полезная. :) Спасибо.

Что же. Для начала, не все так плохо, как кажется :)
Теперь у нас есть широкие возможности, для работы с файловой системой.
Но, есть и ложка дегтя:
Для работы, нам необходим FILE_ANY_ACCESS уровень доступа (для получения FileID).
Я понимаю, что с этим уровнем, нам доступны практически все файлы в системе,
но хочеться вообще убрать ограничение.
Это реально. Нужно научиться находить "файловую запись" только по имени файла, без его открытия.
И здесь, к сожалению, если я не ошибаюсь, FILEID - нам не помошник :(
Перебирая файлы на диске (через MFT) и просматривая их св-ва,
я убедилась, что "исходно" FILEID не нулевой у очень ограниченного кол-ва файлов.
При открытии какого-то файла ID у него появляется и, даже, остается после его закрытия.
Но нам от этого пользы мало :(
Пытаюсь делать так. (Допустим, мы ищем C:\Dir1\Dir2\Dir3\Test.txt)
Открываем в MFT корневую директорию и в ее IndexRoot атрибутах пытаемся найти Dir1.
Найдя Dir1 начинаем просматривать ее(Dir1) IndexRoot, в поисках Dir2 и т.д.
Вот "просматривать" INDEX_ROOT у меня (пока) и не получается.
А может, надо искать вовсе не в INDEX_ROOT ?
P.S.
Когда восстанавливают информацию, идут другим путем:
Начинают с удаленного файла.
В нем есть ссылка на директорию, в которой он находился, в которой есть ссылка... и т.д.
С оговоркой: если я правильно поняла :)

← →
vpbar (2007-06-26 15:21) [22]

>>Игорь Шевченко © (26.06.07 11:21) [20]
Прочитал после моего сообщения (видно страница не успела обновиться). Спасибо не знал. Хотя по видимомо этот FileID тотже что и для GetFileInformationByHandle (в ней идет обращение к NTQueryInformationFile).

А потом по этому FileID можно найти файл (определить имя, размер и т.д). А то если нет, то я не буду пока искать более подробную инфу по NTQueryInformationFile

← →
Riply © (2007-06-26 22:09) [23]

:))
Попутно решаются всякие смешные задачки.
Давным-давно, я интересовалась:
можно ли не пробегая FindFist/FindNext"ом узнать кол-во файлов в диретории,
для отображения в ProgessBar процесса их обработки(не помню какой).
Нужно было установить максимальную позицию.
Тогда мне сказали, что "низяяяя" :)
Через MFT на получение кол-ва директорий и файлов на всем диске уходит 380 ms :)

← →
Игорь Шевченко © (2007-06-27 09:54) [24]

Riply © (26.06.07 22:09) [23]

Заведи каталог с несколькими десятками тысяч файлов и посчитай через MFT, чтобы жизнь не казалась пресной

← →
Riply © (2007-06-27 11:59) [25]

> [24] Игорь Шевченко © (27.06.07 09:54)
>Заведи каталог с несколькими десятками тысяч файлов и
>посчитай через MFT, чтобы жизнь не казалась пресной

Попробовала посчитать весь "системный диск":
TimeOut: 1297
Objects Count: 84 974
FilesCount: 78 031
DirCount: 6 927
UnUseFiles: 15
UnUseDir: 1
(TimeOut - в милисекундах)
Причем, перебирается процедурой, написанной не для подсчета.
Т.е. если ее(процедуру) "заточить" именно для этого,
то результаты будут гораздо лучше :)

Так что я, пока еще, в розовых очках, жизнь кажется прекрасной и совсем "не пресной" :)

← →
Игорь Шевченко © (2007-06-27 12:20) [26]

Riply © (27.06.07 11:59) [25]

Ты не поняла. Я имею в виду, что если ты создашь каталог с большим количеством файлов, у тебя элемент в MFT может разползтись и жизнь пресной не покажется, если ты собираешься считать количество файлов. В реализации FindFirst/FindNext все эти нюансы учтены (в NtQueryDirectoryFile)

← →
Riply © (2007-07-02 00:44) [27]

Пытаюсь построить MFT дерево, но на некоторых файлах получаю AV.
Вот экстракт проблеммы:
Структура "базовых" атрибутов
type PATTRIBUTE = ^ATTRIBUTE; ATTRIBUTE = record AttributeType: ATTRIBUTE_TYPE; Length: ULONG; Nonresident: BOOLEAN; NameLength: UCHAR; NameOffset: USHORT; Flags: USHORT; AttributeNumber: USHORT; end;
И тестировочная функция, которая подсчитывает, сколько разных атрибутов в нашей записи:
function EnumAttribute(const pFileRec: PFILE_RECORD_HEADER): integer; var pBaseAttr: PATTRIBUTE; begin Result := 0; if pFileRec.Flags = 0 then Exit; pBaseAttr := PATTRIBUTE(DWord(pFileRec) + pFileRec.AttributesOffset); while (pBaseAttr <> nil) and (DWord(pBaseAttr.AttributeType) <> MAXDWORD) do begin inc(Result); if pBaseAttr.Length > 0 then pBaseAttr := PATTRIBUTE(Dword(@pBaseAttr) + pBaseAttr.Length) else Break; end; end;
Вылетаем очеь редко ( примерно один файл на 20000 ).
Механизм вылета простой: Неожиданно параметр Length принимает астрономически большое значение.
Ну и, разумеется, по такому смещению нас выбрасывает черти-куда :)
При сканировании всего дерева MFT, раз двадцать это может быть на одном и том же файле.
Потом, вдруг, мы его проходим нормально, но появляется другой :)
Сразу оговорюсь:
Все стальные параметры в норме (в "связанных" структурах тоже), никаких отклонений.
AV - шный файл не испорчен, никем не используется, к всяким "незявным" не относится :)
- обычный txt, pas или jpeg.
ChkDisk - ом проверяла.
Такое впечатление, что он (Length) "законно" может принимать такие значения
и, в этих случаях, их надо трактовать как-то по-другому.
Подскажите, пожалуйста, в чем может быть дело ?

← →
Игорь Шевченко © (2007-07-02 10:06) [28]

> Подскажите, пожалуйста, в чем может быть дело ?

Хотел бы я знать, в какой ситуации pBaseAttr может принять значение nil...

> [28] Игорь Шевченко © (02.07.07 10:06)
>Хотел бы я знать, в какой ситуации pBaseAttr может принять значение nil...
Sorry.
Я чуть-чуть слукавила (все-таки код варварски выдирается из проекта :)
Вот то, что более походит на правду :)
type
PFILE_RECORD_HEADER = ^FILE_RECORD_HEADER;
FILE_RECORD_HEADER = packed record
Ntfs: NTFS_RECORD_HEADER;
//.......
NextAttributeNumber: USHORT;
function pAttr_Base: PATTRIBUTE;
end;

function FILE_RECORD_HEADER.pAttr_Base: PATTRIBUTE;
begin
Result := Pointer(DWord(@Self) + AttributesOffset);
end;

type
PATTRIBUTE = ^ATTRIBUTE;
ATTRIBUTE = record
AttributeType: ATTRIBUTE_TYPE;
//.....
AttributeNumber: USHORT;
function IsValidType: Boolean;
function pNextAttr: PATTRIBUTE;
end;

function ATTRIBUTE.IsValidType: Boolean;
begin
Result := DWord(AttributeType) <> MAXDWORD;
end;

function ATTRIBUTE.pNextAttr: PATTRIBUTE;
begin
if ResidentLength > 0
then Result := PATTRIBUTE(Dword(@Self) + ResidentLength)
else Result := nil;
end;

И наша тестировочная функция приобретает другой вид:
function EnumAttribute(const pFileRec: PFILE_RECORD_HEADER): integer;
var
pBaseAttr: PATTRIBUTE;
begin
Result := 0;
if pFileRec.Flags = 0 then Exit;
pBaseAttr := pAttr_Base;
while (pBaseAttr <> nil) and pBaseAttr.IsValidType do
begin
inc(Result);
pBaseAttr := pBaseAttr.pNextAttr;
end;
end;

А что пишет Неббет про значения полей в записях ? :)

Мы так и будем в допрос партизана играть ?

> [30] Игорь Шевченко © (02.07.07 14:28)
>Мы так и будем в допрос партизана играть ?
Нет. не будем :) Просто очень сложно "варварски выдирать код" :)

>А что пишет Неббет про значения полей в записях ? :)
В той статье, что у меня - ничего,
но алгоритм поиска нужного атрибута в FILE_RECORD_HEADER такой же.
Кажется, разбирая DIRECTORY_INDEX, я учитываю не все обстоятельства.
Скорее всего, ошибка закрадывается раньше, при "прыжках" с одного "узла" на другой,
а проявляется при разборе полученных структур.
Попробую еще раз проверить алгоритм,
может смогу более конкретно описать условия ее(ошибки) возникновения.(а может и исправить ее :)

Вроде, нашла область, где, возможно, происходит искажение данных.
Имя из FILENAME_ATTRIBUTE, я вытаскиваю следующим образом:
FILENAME_ATTRIBUTE = packed record ..... NameLength: UCHAR; NameType: UCHAR; // 0x01 = Long, 0x02 = Short Name: array[0..0] of WideChar; function _ExstactName: string; end; function FILENAME_ATTRIBUTE._ExstactName: string; begin if NameLength > 0 then Result := WideCharLenToString(PWideChar(@Name), NameLength) else Result := ""; end;
Некоторые из них получаются вот в таком виде (с нечитаемыми символами):
D:\ATI\atidesk\FACCES.DLL
D:\Dissertation Kraft\Off_Docs\Выиска НТС.doc
D:\FdlNew\Dual files\Dul69a.int
D:\FdlNew\INP Files\defaul.inp
D:\Mathematics\Color\CiteSeDr\liu93multiresolution.pf
D:\Mathematics\Numerical Methods\LSDEMO.PAS
D:\Mathematics\Numerical Methods\SAMPLE6D.DT
D:\Mathematics\Numerical Methods\SAPLE3F.DAT
D:\Text\Electronical report 2005\Primary_Image.mp
С чем это может быть связано ?

Riply © (02.07.07 23:02) [32]

> С чем это может быть связано ?

С ошибкой выравнивания ?

Ты, если хочешь нормальной помощи, собери проект, чтобы его можно было откомпилировать и запустить, да и выложи куда, а то и на мыло брось. Мыло вроде знаешь

← →
SLoW.AlfaMoon.Com (2007-07-03 11:58) [34]

собери проект, чтобы его можно было откомпилировать и запустить, да и выложи куда
+1

> [33] Игорь Шевченко © (03.07.07 09:47)
>Ты, если хочешь нормальной помощи
"Тык, кто ж ее не хочет ?" :) (с) "Формула любви"
>собери проект, чтобы его можно было откомпилировать и запустить.
На это потребуется время.
Уж очень много "Common_Unit - ов" у меня задействовано. "И не сосчитаешь" :)
>да и выложи куда, а то и на мыло брось. Мыло вроде знаешь
Выкладывать стыдно: не доросла еще, а вот e-mail сохранился.
P.S.
Большое спасибо, за предложение.
Обязательно воспользуюсь, хотя и это и не очень удобно:
затаскивать Вас в те дебри, в которые Вы мне и соваться не советовали :)

> На это потребуется время.

Я не тороплюсь :)

> Обязательно воспользуюсь, хотя и это и не очень удобно:

Нормально.

> Уж очень много "Common_Unit - ов" у меня задействовано.
> "И не сосчитаешь" :)

Считай, что у того, кто будет компилировать проект, есть только стандартные из Delphi юниты - не скупись на файлы

> Riply ©

Когда человек реально хочет помощи, то выкладывает исходники, тут каждый по разу посмотрит что-то подправит. Десять голов лучше одной :)
З.Ы. Все когда начинали ;)

>[33] Игорь Шевченко © (03.07.07 09:47)
>С ошибкой выравнивания ?
Была предпринята последняя отчаянная попытка разобраться где и какую стуктуру
я "не так" выравниваю, которая закончилась тем, что прокляла
"тот день, когда я, впервые, села за баранку этого пылесоса" :)
(с)(Кавказкая пленница)
Пришлось приступить к соберке проекта, "чтобы его можно было откомпилировать и запустить"

>[37] Игорь Шевченко © (03.07.07 15:28)
>Считай, что у того, кто будет компилировать проект,
>есть только стандартные из Delphi юниты - не скупись на файлы
А "у того, кто будет компилировать проект", есть такие файлы как:
HsNtDef, NtPEB, NtStatus и NtDLL ? :)

Принцип сортировки NTFS_RECORD - ов в MFT. Найти похожие ветки