Два метода сокрытия данных

Статья написана для журнала "Хакер" в 2004 году. Она вышла в номере 09/04 (69) под названием "Деструктивные потоки".

Захватывая очередную NT-систему и устанавливая в нее свой самодельный шпионский софт, необходимо решать проблему хранения собираемой информации на компьютере жертвы. Обычно лог пишется в простой файл в каталоге с большим количеством файлов, например, в system32.

Возможности NTFS

Это распространенный, но далеко не лучший способ спрятать информацию на локальном компьютере. Есть шанс, что пользователь заметит лишний, постоянно обновляющийся файл, который вдруг неожиданно появился у него в системном каталоге. Дописывать лог к уже существующему файлу? Для начала надо найти такой файл, добавление к которому информации не испортит его содержимого. А как насчет того, чтобы сохранять инфу в такое место, которое не будет видно ни из проводника, ни из командной строки, ни из любого файлового менеджера? Такую возможность нам предоставляет файловая система NTFS. На обычной домашней персоналке ее редко встретишь, так как большинство пользователей по-прежнему предпочитают FAT32, даже те, кто сидит под XP. Но зато в локальной сети какой-либо фирмы, работающей под Win2k/XP, почти наверняка используется NTFS, потому что эта файловая система предоставляет такие возможности, как назначение прав доступа пользователям, шифрование и компрессию файлов. Кроме того, NTFS гораздо более надежна, чем FAT32. Так что метод сокрытия данных, который я опишу, идеально подходит для промышленного шпионажа. С появлением Longhorn, NTFS имеет шанс обосноваться и на дисках домашних компов, так как грядущая файловая система WinFS, основанная на NTFS, обещает дополнительные возможности по упорядочиванию и поиску информации, которые должны привлечь обычных пользователей.

Прикрепи к файлу любые данные

Способ заключается в том, чтобы сохранять данные не в файл, как обычно, а в файловый поток NTFS. Поток можно прикрепить к другому файлу (при этом его размер не меняется, и данные остаются нетронутыми, а значит, утилиты, проверяющие чексуммы файлов, не заметят изменений), к каталогу или к диску. Альтернативные файловые потоки NTFS – это одна из возможностей NTFS, присутствующая в ней еще с самых ранних версий Windows NT. Она заключается в том, что у одного файла может быть несколько потоков, содержащих данные, причем пользователю доступен лишь главный поток, в котором хранится содержимое файла. Нечто похожее есть в файловой системе HFS на Макинтошах. Там потоки (streams) называются разветвлениями (forks). До недавнего времени они использовались как хранилище ресурсов файла или содержали информацию о типе файла. С появлением MacOS X, Apple рекомендовала помещать ресурсы в отдельные файлы, а типы файлов определять по расширениям. Но поддержка разветвлений все равно остается. В Windows потоки обычно используются для хранения какой-либо дополнительной информации о файле. Например, в потоке может содержаться сводка документа. Если система стоит на диске с NTFS, то файл explorer.exe наверняка содержит сводку. В зависимости от содержимого сводки, к файлу могут прикрепляться потоки с именами SummaryInformation, DocumentSummaryInformation и некоторые другие. У себя на компьютере я обнаружил поток с именем $MountMgrRemoteDatabase, прикрепленный к диску C.

О прикрепленных к файлу потоках юзер может узнать лишь в некоторых случаях, например, при копировании файла с прикрепленным потоком на диск с FAT/FAT32. Эти файловые системы их не поддерживают, поэтому система выдаст запрос на подтверждение потери информации в потоках, указав их названия. Разумеется, такая ситуация никогда не возникнет, если поток прикреплен к диску или к системной папке. Необязательно использовать потоки в шпионских целях. Если ты разработчик shareware программ, то ты вполне можешь использовать потоки для хранения информации о регистрации, количестве дней до истечения срока использования, словом, все то, что должно быть скрыто от пользователя твоей проги.

Работа с потоками

В работе с файлами и потоками есть и сходства, и различия. Похожего не так уж много. И файлы, и их потоки создаются и удаляются одними и теми же WinAPI функциями CreateFile и DeleteFile. Чтение и запись реализуются, соответственно, функциями ReadFile и WriteFile. На этом сходства кончаются, дальше идут одни различия. В именах потоков могут содержаться спецсимволы, которые не могут быть частью имени нормального файла: такие как “*”, “?”, “<”, “>” ,“|” и символ кавычки. Вообще, любое имя потока сохраняется в формате Unicode. Еще могут использоваться служебные символы из диапазона 0x01 – 0x20. Нет стандартной функции копирования и переноса потока: MoveFile и CopyFile с потоками не работают. Но никто не мешает написать свои функции. У потоков отсутствуют собственные атрибуты, даты создания и доступа. Они наследуются от файла, к которому прикреплены. Если в самом файле есть какие-либо данные, то их тоже можно представить в виде потока. Имена потоков отображаются как «имя_файла:имя_потока:атрибут». Стандартный атрибут потока, в котором находятся данные, называется $Data. Есть много других атрибутов, имена которых также начинаются со знака “$”. Содержимое файла находится в безымянном потоке (имя_файла::$DATA). С этим свойством файловой системы представлять содержимое файла в виде потока был связан баг в старых версиях Microsoft IIS, когда хакер, который хотел узнать текст какого либо скрипта на уязвимом сервере, просто добавлял к его имени “::$DATA”, и сервер, вместо того чтобы выполнить скрипт, выдавал его исходный код. Работа с потоками похожа на работу с файлами. Взгляни на листинг 1. Это простой пример программы, создающей файл с потоком и записывающей в него информацию. После запуска программы в ее каталоге появится пустой файл «testfile». Увидеть содержимое прикрепленного потока можно, набрав в командной строке «more < testfile:stream». Как видишь, имя потока указывается после имени файла, отделенное от него знаком двоеточия. Самое трудное при работе с потоками – это получить их список для конкретного файла. Стандартной функции нет, и поэтому придется писать ее самому. Напишем небольшую консольную программу, которая бы возвращала список потоков по имени файла. Такая прога есть у ребят из Sysinternals, с открытым кодом, и она работает, но мне не понравился их способ. Они используют вызовы Native API, и поэтому их код большой и трудный для понимания. Мы же напишем свою прогу, которая будет работать из командной строки, с алгоритмом попроще и со стандартными API функциями.

Получаем список потоков

Алгоритм основан на применении функции BackupRead. Она предназначена для резервного копирования файлов. Когда делаешь резервную копию файла, важно сохранить как можно больше данных, включая и файловые потоки. Информация берется из структуры WIN32_STREAM_ID. Оттуда можно достать имя потока, его тип и размер. Нам понадобятся только потоки типа BACKUP_ALTERNATE_DATA. Все функции и структуры описаны в заголовочном файле winnt.h. Для начала надо открыть файл для чтения с помощью CreateFile. В параметре dwFlagsAndAttributes надо указать флаг FILE_FLAG_BACKUP_SEMANTICS, что позволит открывать не только файлы, но и каталоги. Затем запускаем цикл while, который считывает информацию о файле в структуру sid, из которой мы будем доставать информацию о каждом потоке. Перед следующим проходом цикла очищаем структуру и сдвигаем указатель файла к следующему потоку с помощью функции BackupSeek. После того как все потоки найдены, очищаем lpContext, содержащий служебную информацию, и закрываем файл. Исходный код программы приведен в листинге 2. Уже скомпилированную прогу ты можешь взять с нашего диска. Для работы с потоками необязательно писать специальные программы. Можно кое-что сделать прямо из командной строки. Несколько примеров приведено на врезке.

Обнаружение

Прикрепив поток с информацией к чему-нибудь, до его содержимого трудно добраться, не зная его имени. Если поток прикрепить к логическому тому, то в Windows вообще нет стандартных средств, чтобы его обнаружить. Так как в имени потока могут содержаться символы, недопустимые в именах обычных файлов, это создает дополнительные трудности при попытке узнать содержимое потока, пользуясь командной строкой. Содержимое сводки документа обычно хранится в потоке с названием, которое содержит символ с кодом 0x05. Этот символ можно набрать в консоли (Ctrl+E), но если бы это был символ 0x10 или 0x13 (возврат каретки и перевод строки), то набрать их было бы невозможно. Теоретически ты можешь узнать о прикрепленных потоках случайно, используя некоторый софт, который с большой вероятностью есть на твоем компьютере. В WinRAR есть опция, и если она включена, то ты можешь заметить, что размер небольшого файла, помещенного в архив, не только не уменьшается, а даже увеличивается (за счет того, что данные в потоках тоже помещаются в архив). Это может вызвать подозрения. Программа для отслеживания обращений к файловой системе - FileMonitor от тех же Sysinternals - не делает различий между обращениями к файлам или потокам. Соответственно, внимательное изучение лога обращений к диску подозрительной программы (твоего кейлоггера) выдаст и название потока, куда пишется лог, и имя файла, к которому он прикреплен.

Вирусы

В сентябре 2000 года появился первый вирус, использующий для своего распространения альтернативные файловые потоки. W2k.Stream был первым представителем нового типа вирусов - stream companion. Он ищет в своем каталоге файлы.exe, и если находит, то начинает процесс заражения. К файлу прикрепляется дополнительный поток, в который вирус переносит содержимое оригинального файла, а потом копируется тело вируса в основной поток файла. После запуска зараженного файла вирус снова пытается заразить файлы в своем каталоге, а затем запускает программу из дополнительного потока. Действительно, с помощью функции CreateProcess можно запускать процесс из потока. Причем файл с потоком можно спокойно удалить, а процесс останется. Просто сказка для троянов! Несмотря на то, что с момента появления W2K.Stream прошло уже почти четыре года, еще не все антивирусы способны обнаруживать вредоносный код в файловых потоках. Поэтому появление новых червей и вирусов, использующих их, может представлять серьезную опасность.

Другие вирусы, использующие потоки

Кроме W2K.Stream, потоки нашли применение и в других вирусах и червях. Первым червем, использовавшим файловые потоки, являлся I-Worm.Potok. Эта зверушка прикрепляет несколько потоков к файлу odbc.ini в каталоге Windows и хранит там скрипты для рассылки себя по почте. Еще одним вирусом является W2k.Team. Описание этих и других подобных вирусов ты можешь найти на сайте http://www.viruslist.com/

Работа с потоками из консоли

Создание файла с потоком:
type nul > somefile.txt:Stream

Запись в поток:
echo "Something" >> somefile.txt:Stream

Чтение из потока:
more < somefile:Stream

Копирование содержимого существующего файла в поток:
type file1.txt >> somefile.txt:Stream

Копирование содержимого потока в файл:
more < somefile.txt:Stream >> file2.txt

Удаление потоков

Существует мнение о том, что поток можно удалить только вместе с файлом, к которому он прикреплен. Это не так. Если ты знаешь название потока, то ты всегда сможешь удалить его стандартной функцией DeleteFile.

Листинг 1. Пример создания потока.

#include int main() { DWORD dwRet; HANDLE hStream = CreateFile("testfile:stream", GENERIC_WRITE, FILE_SHARE_WRITE, NULL, OPEN_ALWAYS, NULL, NULL); WriteFile(hFile, "This is a stream", 17, &dwRet, NULL); CloseHandle(hStream); return 0; }

Листинг 2. X-Stream: Программа, показывающая список потоков

#include #include #include #include int _tmain(int argc, _TCHAR *argv) { WIN32_STREAM_ID sid; ZeroMemory(&sid, sizeof(WIN32_STREAM_ID)); DWORD dw1,dw2,dwRead; INT numofstreams = 0; //Буфер для имени потока в формате Unicode WCHAR wszStreamName; LPVOID lpContext = NULL; /* * Открываем файл для чтения с параметром * FILE_FLAG_BACKUP_SEMANTICS, что позволяет нам * открывать не только файлы, но и каталоги с дисками. */ HANDLE hFile = CreateFile(argv,GENERIC_READ,FILE_SHARE_READ, NULL,OPEN_EXISTING,FILE_FLAG_BACKUP_SEMANTICS,NULL); if (hFile == INVALID_HANDLE_VALUE) {printf("\nError: Could"t open file, directory or disk %s\n",argv); exit(0); } DWORD dwStreamHeaderSize = (LPBYTE)&sid.cStreamName - (LPBYTE)&sid + sid.dwStreamNameSize; printf("\nStreams information for %s:\n",argv); while (BackupRead(hFile, (LPBYTE) &sid, dwStreamHeaderSize, &dwRead, FALSE, TRUE, &lpContext)) { //Если тип потока неверный, значит прерываем цикл if (sid.dwStreamId == BACKUP_INVALID) break; ZeroMemory(&wszStreamName,sizeof(wszStreamName)); //Получаем имя потока if (!BackupRead(hFile, (LPBYTE) wszStreamName, sid.dwStreamNameSize, &dwRead, FALSE, TRUE, &lpContext)) break; if (sid.dwStreamId == BACKUP_DATA || sid.dwStreamId == BACKUP_ALTERNATE_DATA) { numofstreams++; printf("\n\nStream\t\t#%u",numofstreams); switch (sid.dwStreamId) { case BACKUP_DATA: printf("\nName:\t\t::$DATA"); break; case BACKUP_ALTERNATE_DATA: printf("\nName:\t\t%S",wszStreamName); break; } printf("\nSize:\t\t%u\n",sid.Size); } //Перемещаемся к следующему потоку BackupSeek(hFile, sid.Size.LowPart, sid.Size.HighPart, &dw1, &dw2, &lpContext); //Очищаем структуру перед следующим проходом цикла ZeroMemory(&sid,sizeof(sid)); } //Очищаем lpContext, содержащий служебную информацию //для работы функции BackupRead BackupRead(hFile, NULL, NULL, &dwRead, TRUE, FALSE, &lpContext); //Закрываем файл CloseHandle(hFile); return 0; }

По теме файловых потоков также есть следующее:

• NTFS Stream Explorer 2.00 Программа для работы с потоками NTFS и

Были представлены в Windows NT 4.0 и были вокруг всех потомков (исключая win-95 потомки: 98, Me). В XP, Vista и Win 7 они все еще существуют. Пока версии Windows поддерживают NTFS, они будут поддерживать файловые потоки. Они будут поддерживать NTFS в течение длительного времени.

Ошибка, которую вы указали, описана на странице, которую вы видите в своем вопросе. Команда type не понимает потоки. Использование:

More < 1013.pdf:Zone.Identifier

Работа с потоками

Microsoft имеет только несколько команд, которые работают с потоками, фактически только < , > работают с потоками, и поэтому могут использоваться только команды, которые могут работать с этими операторами перенаправления. Я написал о том, как вы все еще можете управлять потоками только с этими командами.

Потоки будут работать только с программами, которые предназначены для работы с ними, просто потому, что их нужно обрабатывать специально (сравнить точки соединения, а также функцию NTFS, но драйвер скрывает детали, и программам не нужно ничего делать специальные: они просто считают точку соединения реальным файлом).

Когда вы пытаетесь открыть поток файлов с помощью start filename:streamname , и программа говорит что-то вроде "незаконного имени файла" или "файл не найден", и вы уверены, что имя потока верное, то, скорее всего, программа не поддерживают потоки. Я заметил, что Notepad, Wordpad и Word/Excel работают правильно с потоками, хотя Word и Excel считают файлы опасными. Ниже приведены некоторые эксперименты .

ПРИМЕЧАНИЕ: вам кажется, что альтернативные потоки данных нечетны. Они странные, потому что они настолько скрыты, но многие основные файловые системы (HFS, NSS) имеют это, и концепция восходит к началу 80-х годов. Фактически, изначально потоки были добавлены в NTFS для взаимодействия с другими файловыми системами.

В последнее время, в связи с удешевлением аппаратных средств (в долларовом эквиваленте) все большее число пользователей компьютера получает в распоряжении ресурсы вполне достаточные для работы операционной системы Microsoft Windows NT (i200MMX + 32-64 Mb). Ненадежность и непредсказуемость Windows 95/98, а также неспособность ее к управлению на должном уровне ресурсами современных компьютеров приводит многих пользователей к мысли о переходе на NT.

При этом многие неискушенные пользователи не находят для себя ничего кардинально нового. И действительно, установив Internet Explorer 4 и не пользуясь многочисленными возможностями NT по применению политики безопасности и защиты, самыми большими отличиями от Windows 98 может показаться наличие двух папок “Автозагрузка” в пусковом меню (текущего пользователя и общей для всех пользователей) и отсутствие апплета Add/Remove Hardware в Панели управления. А если еще и не форматировать диск файловой системой NTFS, то разницы можно больше и не найти.

Но эта статья как раз и описывает некоторые отличия NTFS от FAT, VFAT, FAT16 и FAT32. Общеизвестные отличия: способность к самовосстановлению, отложенная запись, максимальный размер тома и файла на нем до 16 Экзабайт (1 Экзабайт = 1000000 Гбайт), возможность сжатия отдельных файлов и папок, установки разрешений и аудита достаточно широко освещены в литературе и документации к Windows NT. Но существуют еще малоизвестные и малоиспользуемые возможности NTFS: жесткие ссылки (hardlinks) и множественные потоки данных (multiply data flows или forks). Далее пойдет речь именно о них.

Множественные потоки данных . Этот термин знаком пользователям Macintosh. В этой системе файл может иметь два потока (forks): поток данных и поток ресурсов. В потоке данных хранятся данные файла - этот поток и копируется как единственный при переносе файла с Macintosh на PC. Второй поток файла - поток ресурсов, содержащий данные операционной системы – меню, значки, шрифты, в общем, все то, что принято называть ресурсами. Когда Windows NT Server обслуживает клиентов Macintosh и предоставляет им дисковое пространство для хранения файлов, необходимо чтобы файловая система сервера поддерживала формат файлов клиента. Это является одной из причин появления множественных потоков данных в NTFS.

Каким образом это реализовано? Любая информация о файле, начиная с его имени, разрешений и заканчивая собственно данными, хранящимися в файле, с точки зрения NTFS представляет собой атрибут, хранящийся в собственном потоке (stream). Разработчики NTFS посчитали, что можно не ограничиваться одним потоком для данных – безымянным, и добавили возможность создания нескольких, помимо основного, именованных потоков. Для создания множественных потоков можно применить функцию Win32 API, но можно поступить и проще.

Со времен Кернигана и Ричи – разработчиков языка C и операционной системы UNIX у многих операционных систем существует возможность обобщения операций ввода – вывода. С этой точки зрения, любая операция ввода – вывода может рассматриваться как операция ввода из потока или вывода в поток независимо оттого, что является источником данных (консоль, т.е. клавиатура, файл или порт) и приемником (опять же консоль, в данном случае уже экран монитора, принтер или файл). Существует и возможность перенаправить ввод – вывод программы с экрана на принтер и вводить команды не с клавиатуры, а из файла. В наше время повсеместного использования графического пользовательского интерфейса эти возможности применяются очень редко, поэтому поясним сказанное примером.

Команда операционных систем Microsoft echo используется для вывода информации на экран в текстовом режиме:

C:>echo Hello, World!

Команда echo в качестве устройства вывода информации использует экран монитора. Вывод этой команды можно перенаправить с консоли в файл (для этого используется символ “ > ”):

C:>echo Hello, World! > file

Как видите, команда echo в данном случае на экран ничего не вывела. Но в файле file можно обнаружить строку “Hello, World!”. Аналогично вывод команды echo можно перенаправить и на принтер:

C:>echo Hello, World! > lpt1

На экране опять ничего, но на листе бумаги в принтере можно обнаружить все ту же строку “Hello, world!”, если конечно принтер подсоединен к порту lpt1. Таким образом, вывод любой программы текстового режима можно перенаправить на любое устройство, поддерживающее потоковый ввод информации или в файл, за исключением тех программ, которые в текстовом режиме используют для вывода информации непосредственную модификацию видеопамяти и другие нестандартные, с точки зрения классического C, возможности.

Аналогично можно перенаправить и ввод программы. Команда more операционных систем Microsoft используется для буферизации вывода команд, выводящих информации больше, чем умещается на экран. Но эту команду можно использовать и для иллюстрации перенаправления ввода:

C:>more Hello, World!

В файле file находилась строка “Hello, World!”, которая была направлена на экран.

Точно также, с помощью перенаправления ввода - вывода можно создавать и читать множественные потоки данных:

C:>echo string1 > file:fork1

Записью file:fork1 определяется в файле file поток с именем fork1 (поскольку он еще не существует, то создается новый с этим именем) и перенаправляем в него вывод команды echo. При этом размер файла при просмотре его свойств не изменяется, и стандартными средствами Windows NT, не зная имени потока его существования нельзя определить. Но, зная его имя, можно с помощью команды more определить и его содержимое:

Таким образом, можно создавать и читать содержимое потоков данных файла. Количество потоков, создаваемых в одном файле ограничено только наличием свободного пространства на диске. Аналогично можно создавать потоки данных в каталогах, но для просмотра содержимого потока придется применить другое средство вывода потока на экран, так как команда more при этом выдает следующую ошибку:

Если ничего подходящего найти не удалось, то можно написать в любом компиляторе C++ такую программу:

while (cin.get(ch)) cout.put(ch);

Скомпоновать эту программу лучше как консольное Win32 приложение, и использовать как средство для изучения потоков каталогов.

Windows NT не предоставляет стандартных средств для получения информации о множественных потоках данных. Но что делать, если все же необходима такая информация? В этом случае можно воспользоваться программой streams Марка Руссиновича (Mark Russinovich), которую вместе с исходным кодом можно взять на www.sysinternals.com . В этой программе для получения информации о множественных потоках данных используются недокументированные функции Windows NT. Вот информация, полученная с помощью программы streams о файле file:

NTFS Streams Enumerator v1.0

Systems Internals - http://www.sysinternals.com

Здесь можно видеть как название потока данных, так и его размер в байтах (дополнительные 3 символа это пробел после символа “ > ”, возврат каретки и перевод строки, добавляемые командой echo). К сожалению, streams не позволяет определить множественные потоки данных в каталогах.

Для чего можно применять множественные потоки данных? Помимо применения, найденного для них фирмой Apple, можно сказать о самом простом средстве для скрытия информации, например, для запоминания даты установки программы shareware. На заре технологии OLE Microsoft предполагала использовать потоки данных для хранения информации о внедренных объектах, но видимо обеспечить потоки данных на FAT оказалось сложнее, чем создать длинные имена файлов и от этой идеи пришлось отказаться. Создание “файла ресурсов” для скрипта с хранением в нем всех надписей, выводимых на разных языках, также может быть интересной возможность применения потоков. Помимо приведенных, существует еще множество интересных применений для множественных потоков данных, чтобы не обходить их своим вниманием.

Жесткие ссылки . Пользователям различных клонов UNIX хорошо знакомо это понятие. В отличии от файловой системы FAT, в которой принято, что у каждого файла может быть только одно имя, в UNIX такого ограничения нет – каждый файл может иметь несколько имен и его данные не могут быть удалены, пока счетчик имен файла не равен 0. В UNIX существуют также символьные ссылки – аналог ярлыков (shortcut) в Windows, но следящих за перемещением объекта, на который они ссылаются.

Windows NT ограниченно соответствует стандарту POSIX (Portable Operating System Interface for Computing Environments). Один из примеров ограниченности – поддержка жестких ссылок и отсутствие поддержки символьных. Видимо, было решено, что ярлыки являются достойным аналогом символьных ссылок.

В NTFS жесткие ссылки организованы аналогично множественным потокам данных: если у файла есть несколько потоков с данными, почему не может быть нескольких потоков с именами? Несколько имен файла могут находиться в разных каталогах, но только в пределах одного раздела.

Для изготовления жесткой ссылки необходима программа для подсистемы POSIX Windows NT. Такая программа вместе с исходными текстами находится на компакт-диске “Ресурсы Windows NT”. По аналогии с UNIX эта программа называется ln. Синтаксис этой команды:

C:>Ln file hardlink1

С помощью этой команды мы создаем для файла file второе имя или жесткую ссылку hardlink1 и, изменяя содержимое файла file можно изменить содержимое hardlink1, точнее это один и тот же файл, но с двумя именами. Аналогично можно менять и другие атрибуты файла. Количество имен у файла не ограничено, но при копировании имени файла ссылка разрывается и создается еще один файл. Существует возможность создания ссылки в другом каталоге:

C:>Ln file ../temp/hardlink2

В этом случае необходимо указывать не абсолютное, а относительное имя каталога.

Применений для жестких ссылок можно найти не меньше, чем для множественных потоков данных. Например, создавать жесткие ссылки для библиотек dll, чтобы обезопасить свою программу от случайного удаления необходимого файла. Другие возможные применения жестких ссылок лучше всего искать в литературе, относящейся к UNIX. И, конечно же, применение жестких ссылок можно комбинировать с описанными выше множественными потоками данных.

В данной теме я рассмотрю четыре вида метаданных, которые могут быть прикреплены к файлу или каталогу средствами файловой системы NTFS . Я опишу, в каких целях можно использовать тот или иной тип метаданных, приведу пример его применения в какой-либо технологии Microsoft или стороннем программном обеспечении.

Речь пойдёт о точках повторной обработки (reparse points), идентификаторах объектов (object id) и о других типах данных, которые может содержать файл помимо своего основного содержимого.

Идентификатор объекта это 64 байта, которые можно прикрепить к файлу или каталогу. Из них первые 16 байт позволяют однозначно идентифицировать файл в пределах тома и обращаться к нему не по имени, а по идентификатору. Остальные 48 байт могут содержать произвольные данные.

Идентификаторы объектов существуют в NTFS со времён Windows 2000. В самой системе они используются для отслеживания расположения файла, на который ссылается ярлык (.lnk). Допустим, файл, на который ссылается ярлык, был перемещён в пределах тома. При запуске ярлыка он всё равно откроется. Специальная служба Windows в случае, если файл не найден, произведёт попытку открыть файл не по его имени, а по заранее созданному и сохранённому идентификатору. Если файл не был удалён и не покидал пределы тома, он откроется, а ярлык снова будет указывать на файл.

Идентификаторы объектов использовались в технологии iSwift Антивируса Касперского 7-ой версии. Вот как описана эта технология: Технология разработана для файловой системы NTFS. В этой системе каждому объекту присваевается NTFS-индентификатор. Этот индентификатор сравнивается с значениями специальной базы данных iSwift. Если значения базы данных с NTFS-индентификатором не совпадают, то объект проверяется или перепроверяется, если он был изменен.

Впрочем, переизбыток созданных идентификаторов вызывал проблемы со сканированием диска стандартной утилитой проверки chkdsk, она происходила слишком долго. В следующих версиях Антивируса Касперского отказались от использования NTFS Object Id.

Reparse Point

В файловой системе NTFS файл или каталог может содержать в себе reparse point, что переводится на русский язык как «точка повторной обработки» . В файл или каталог добавляются специальные данные, файл перестаёт быть обычным файлом и обработать его может только специальный драйвер фильтра файловой системы.

В Windows присутствуют типы reparse point, которые могут быть обработаны самой системой. Например, через точки повторной обработки в Windows реализуются символьные ссылки (symlink) и соединения (junction point), а также точки монтирования томов в каталог (mount points).
Reparse-буфер, присоединяемый к файлу это буфер, имеющий максимальный размер 16 килобайт. Он характеризуется наличием тега, который говорит системе о том, к какому типу принадлежит точка повторной обработки. При использовании reparse-буфера собственного типа ещё необходимо задавать в нём GUID в специальном поле, а в reparse-буферах Microsoft он может отсутствовать.

Какие типы точек повторной обработки существуют? Перечислю технологии, в которых используются reparse point"ы. Это Single Instance Storage (SIS) и Cluster Shared Volumes в Windows Storage Server 2008 R2, Hierarchical Storage Management, Distributed File System (DFS), Windows Home Server Drive Extender. Это технологии Microsoft, здесь не упомянуты технологии сторонних компаний, использующие точки повторной обработки, хотя такие тоже есть.

Extended Attributes

Расширенные атрибуты файла . Про них был . Здесь стоит упомянуть только то, что под Windows эта технология практически не применяется. Из известного мне программного обеспечения только Cygwin использует расширенные атрибуты для хранения POSIX прав доступа. У одного файла на NTFS могут быть или расширенные атрибуты, или буфер точки повторной обработки. Одновременная установка и того и другого невозможна. Максимальный размер всех расширенных атрибутов у одного файла составляет 64 Кб.

Alternate Data Streams

Дополнительные файловые потоки. Про них знает уже, наверное, каждый. Перечислю основные признаки этого вида метаданных: именованность (то есть у файла может быть несколько потоков, и у каждого своё имя), прямой доступ из файловой системы (их можно открывать, используя формат «имя файла, двоеточие, имя потока»), неограниченный размер, возможность запуска процесса прямо из потока (и возможность реализовать через это ).

Использовались в технологии iStream Антивируса Касперского. Используются в самой Windows, например при скачивании файла из интернета к нему прицепляется поток Zone.Identifier, содержащий информацию о том, из какого места получен данный файл. После запуска исполняемого файла пользователь может увидеть сообщение «Не удаётся проверить издателя. Вы действительно хотите запустить эту программу?» .

Так пользователю даётся дополнительная защита от необдуманного запуска программ, полученных из интернета. Это лишь одно применение потоков, а так в них можно хранить самые разные данные. Упомянутый Антивирус Касперского хранил там контрольные суммы каждого файла, но позже от этой технологии тоже по какой-то причине отказались.

Что-нибудь ещё?

Есть ещё идентификатор безопасности , плюс стандартные атрибуты файла, к которым нет прямого доступа, несмотря на то, что они тоже реализованы как потоки файлов. И они, и расширенные атрибуты, и reparse и object id - всё это потоки файла с точки зрения системы. Напрямую изменять идентификатор безопасности, показанный на следующей картинке как::$SECURITY_DESCRIPTOR смысла нет, пусть его изменением занимается система. К другим типам потоков сама система не даёт прямого доступа. Так что на этом всё.

Просмотр содержимого object id, точек повторной обработки, а также работа с расширенными атрибутами и альтернативными файловыми потоками возможна с помощью программы