Рекурсивные папки FAT32

в 9:14, , рубрики: hack, hex, ненормальное программирование, метки: ,

Ниже приведены два интересных и в тоже время простых опыта с Fat'ом и WinHex'ом.
Сам материал, возможно, не имеет большого практического значения, интересен сам подход,
познания скрытых возможностей системы путём бесшабашного экспериментирования с ней. Собственно, я полагаю,
именно такие вот детские опыты и разжигают у людей интерес к более глубокому изучению работы системы.

Нестандартные имена

Итак, мы имеем флешку, размером 8Гб:
image

Форматируем её в FAT32:
image
image
image
image

Создаём на ней папку 001:
image
image

В папке 001 создаём папки 002 и 003:
image

В папке 002 создаём папки 004 и 005:
image

В папке 003 создаём папки 006 и 007:
image

Запускаем WinHex 17.0 от имени админа:
image
image

Открываем в WinHex'е нашу флешку:
image
image
image

Делаем текстовый поиск по секторам, чтобы найти запись о папке 002:
image
image
image

Вот и нашли:
image

Редактируем запись, заменяя двойку на тройку:
image

Сохраняем изменения:
image

Если WinHex не full, то безжалостно кря... срочно покупаем полную версию:
image

Со всем соглашаемся:
image
image

Изменения прошли удачно.:
image

Результаты налицо, две папки «003» и в обоих поддиректории «004» и «005»:
image

А теперь задумаемся...

Сколько интересного кроется за таким очень простым опытом.
К примеру, проделывая это на Win7 заметил нечто, чего и сам не мог предвидеть.
Раньше я делал этот опыт под WinXP и должен вам сказать результат был иным.
Так например проводник XP позволял иметь доступ к обоим папкам 003, то есть операционка
позволяла корректно обрабатывать такие файлы, но с одной особенностью. В проводнике вы могли
получить доступ к обоим директориям независимо! Система корректно отличала первую 003 директорию от
второй 003. Почему операционная система официально не позволяет создавать двух директорий с
одинаковыми именами, ведь всё обрабатывается корректно? Дело в том что система не способна была обрабатывать
прямые пути к файлам такой директории. Точнее могла, но только к первой из них. В общем, складывалась
следующая ситуация, пользователь мог запустить программу из второй 003'ей директории, а вот прикладной
софт не мог! Проще говоря, разместив во второй директории файл zlo.exe пользователь мог спокойно его запустить через проводник.
При этом большинство программ не могли обнаружить этот файл, так как сканировали первую 003'ю директорию.
Собственно про это я и хотел было написать, но всё уже изменилось. Тестировал я тогда этот феномен на
альтернативных вариантах софта: на штатном проводнике, на тотал командере и виндовс командере, на некотором антивирусном софте, на системных батниках и на собственном софте ( на вин апи). Результат был одинаков.
Теперь же всё несколько иначе. Виндовс7 отображает как бы две директории 003, но фактически они синхронизированы. Произведя изменения в одной, такой же результат получим и во второй. Причем фактически работаем с той директорией, которая первой «попалась под руку» драйверу файловой системы.
Так содержимое обоих директорий до переименования было разным, а после стало одинаковым:
image
Куда же делось содержимое второй директории 003? А оно так и осталось на своих секторах, просто, видимо, теперь «руки» драйвера файловой системы не доходят до неё. Если быть точнее, то скорее всего, драйвер честно предоставляет информацию об обоих директориях, а некая более высокоуровневая прослойка выполняя сканирование директории 001 при первом проходе «напарываясь» на первую 003ю директорию «ставит галочку», что обработала 003ю, а при втором проходе уже игнорирует её, тем самым пропуская считывание структуры второй 003ей директории.
Чтобы отобразить скрытое содержимое второй директории необходимо переименовать первую в имя отличное от «003».

Рекурсия рулит

В корне нашей флешки создаём директорию 999:
image

В директории 999 создаем поддиректорию 888:
image

В директории 888 создаем поддиректорию 777:
image

Раскуриваем спецификацию на FAT32, любезно предоставленную самим дядей Биллом microsoft.
Нас интересуют только поля DIR_name, DIR_FstClusHI и DIR_FstClusLo в структуре Derectory_Entry_Structure:
image

Узнаем DIR_FstClusHI и DIR_FstClusLo для папки 999.
Делаем это в два шага. Сперва, находим саму запись Derectory_Entry_Structure, баналь но поиском по названию «999»:
image

Нашли, — отлично! Отчитываем заветные 20 и 26 байт от начала названия (DIR_name. Его помечаю зелёным) и находим
заветные DIR_FstClusHI и DIR_FstClusLo (их помечаю красным).
image

У меня 00 00 и 0A 00, но у вас могут быть и другие числа.
Записываем полученные значения для директории 999.
Теперь аналогично находим DIR_FstClusHI и DIR_FstClusLo для директории 888 и тоже записываем.(У меня 00 00 и 0B 00):
image
image

Теперь самое интересное. Аналогичным образом находим DIR_FstClusHI и DIR_FstClusLo для директории 777:
image
image

Но их мы не запоминаем, а заменяем на ранее определённые значения. Можно заменить на значение
как от директории 888 так и от директории 999. Я заменил на значения директории 999 (т.е. на 00 00 и 0a 00):
image

Теперь записываем изменения на диск:
image
image

Что же мы получили? А вот что…
Директория 999 на месте:
image

В директории 999 поддиректория 888, как и прежде:
image

В директории 888 попрежнему поддиректория 777:
image

А вот содержимое директории 777 зациклено на директориюю 999
image

image

image

По моему, здорово.

Не знаю как в настоящее время, но ещё совсем недавно такими нехитрыми
приёмами можно было порядочно потрепать нервы многим антивирусным системам а некоторое ПО даже вывести в астрал.
Вероятно и сейчас может найтись реализация ПО, в котором не разрулены должным образом подобные варианты.

Конечно данная информация, надо прямо сказать, на любителя… Но, возможно, для кого-то она послужит толчком к более интересным экспериментам.

Автор: zx300

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js