Почему heck NTFS позволяет невидимые исполняемые файлы?

Можно скрыть любой файл в другом файле только путем ввода:

type sol.exe > container.txt:sol.exe

и выполнять скрытый файл файла просто используйте:

start c:\hide\container.txt:sol.exe

Но сумасшедшая часть об этом - это, не увеличивает размер файла (таким образом, это полностью скрыто).

И если Вы удаляете файл со скрытым материалом внутри, скрытый материал не становится удаленным. Просто используйте:

more <  container.txt:sol.exe > sol.exe

Почему NTFS позволяет это? Это походит на лучший способ скрыть вирус.

105
задан 10.10.2013, 01:37

5 ответов

Существует две стороны к этому вопросу. Первое - то, почему эта функция существует вообще, и второе - то, почему не делает GUI (или командная строка) помогают видеть и управлять функцией.

Это существует, потому что это полезно. Несколько других платформ поддерживают несколько потоков данных на файл. На Mac их назвали ветвлениями, например. Я довольно уверен, что подобные вещи существовали в мейнфреймовом мире, но не могут поместить мои пальцы ни на какие явные примеры сегодня.

В современном Windows это используется для содержания дополнительных атрибутов для файла. Вы могли бы заметить, что поле Properties, доступное от Windows Explorer, имеет вкладку Summary, что в представлении Simple (я нахожусь на Windows XP, Ваш пробег разойдется в других разновидностях), включает набор полезных полей как Заголовок, Предмет, Автор, и т.д. Те данные хранятся в альтернативном потоке, вместо того, чтобы создать некоторую базу данных расширения за счет внешних устройств для содержания всего этого, который разделился бы из файла слишком легко.

Альтернативный поток также используется для содержания маркера, который говорит, что файл прибыл из источника небезопасной сети, который применяется и Internet Explorer и Firefox на загрузках.

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

Править:

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

Получите копию тестового файла EICAR. Это - 68 байтов текста ASCII, который, оказывается, также допустимый исполняемый файл для процессоров типа х86. Хотя абсолютно безопасный, было согласовано антивирусной промышленностью быть обнаруженным, как будто это был реальный вирус. Инициаторы думали, что тестирование программного обеспечения AV с реальным вирусом будет немного совсем как тестирование пожарной сигнализации путем освещения корзины в огне...

Файл EICAR:

X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*

Сохраните его с расширением .COM и это выполнится (если Ваша AV не обратит внимание), и распечатайте приветствие.

Это было бы информативно, чтобы сохранить его в альтернативном потоке данных и выполнить сканирование...

98
ответ дан 07.12.2019, 07:53

Эта функция требуется для кросс-платформенной функции Windows Server: сервисы для Mac.

Это позволяет Windows Server, работающий на доле NTFS к макинтошам через AFP. Чтобы эта функция работала, файловая система NTFS должна поддерживать ветвления, и она имеет со дня один.

И перед выяснением эта функция все еще используется? Да, который это, у меня есть он выполнение и используемая ежедневная газета на сервере в клиенте, который я поддерживаю.

Основная проблема безопасности прибывает, когда люди и приложения забывают или не понимают, что это там.

Вероятно, должна быть опция, хотя включать ветвления в общий размер файла или показать им в Windows Explorer.

15
ответ дан 07.12.2019, 07:53

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

Я мог вообразить интересное использование в IDE, например, где иногда несколько файлов включены для формирования единого блока (файл кода / файл формы, и т.д.), который мог быть присоединен к исходному файлу таким образом так, чтобы они не могли случайно разделиться.

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

5
ответ дан 07.12.2019, 07:53
5
ответ дан 07.12.2019, 07:53

Хороший вопрос, я правильно не знал о ADS до прошлого года, и я много лет был разработчиком Windows. Я могу гарантировать, что не являюсь одним на этом.

Относительно способности проверить на альтернативные данные по файлам, я нашел полезный небольшой инструмент под названием Парни доступным из программного обеспечения Frank Heyne. Это может перечислить ADS на всех файлах в данном каталоге, даже на Зашифрованных файлах (и также в подкаталогах).

5
ответ дан 07.12.2019, 07:53

Теги

Похожие вопросы