Книга: Восстановление данных. Практическое руководство
Искажение размеров файлов
Искажение размеров файлов
Еще (или, скорее уже) во времена монохромных терминалов и первых магнитных дисков существовал некрасивый, но элементарно реализуемый защитный прием, препятствующий пофайловому копированию носителя. Внося определенные искажения в структуры файлов системы, разработчики "портили" дискету ровно настолько, чтобы работа с ней становилась возможной лишь при условии учета характера внесенных искажений. Защищенная программа, "знающая" об искажениях файловой структуры, работала с ней без проблем, но штатные утилиты операционной системы работать с такими дисками не могли. Общедоступных "хакерских" средств копирования в те времена еще не существовало.
Несколько файлов зачастую ссылались на общие для всех них кластеры, и тогда запись данных в один файл приводила к немедленному их появлению в другом, что защита могла так или иначе использовать. Естественно, после копирования файлов на новый диск пересекающиеся кластеры "разыменовывались", и хитрый способ неявной пересылки данных переставал работать. Вместе с ним переставала работать и сама защищенная программа, если, конечно, содержимое диска вообще удавалось скопировать. Ведь копирование файлов с пересекающимися кластерами приводило к тому, что эти кластеры многократно дублировались в каждом копируемом файле, в результате чего их суммарный объем подчас увеличивался настолько, что емкости тогдашних носителей попросту не хватало для хранения таких объемов данных! Если же последний кластер файла "приклеивался" к его началу (файл, таким образом, попросту зацикливался), то объем и время его копирования попросту обращались в бесконечность. Конечно, дисковые доктора в то время уже существовали, но их использование не давало желаемого результата, потому что лечение файловой системы приводило к полной неработоспособности защиты. В случае с зацикливанием, например, если защита основывалась на том, что за концом файла следует его начало, то после обработки диска доктором осуществление этого приема становилось невозможным со всеми от сюда вытекающими последствиями.
Файловые системы лазерных дисков, конечно, совсем не те, что на гибких дисках, но общие принципы их искажений достаточно схожи. Увеличивая фиктивные длины защищаемых файлов на порядок-другой, разработчик защиты может довести их суммарный объем до нескольких сотен гигабайт, так что для копирования защищенного диска понадобится, по меньшей мере, пачка DVD или винчестер солидного объема. Защитный механизм, "помнящий" оригинальные длины всех файлов, сможет работать с ними без проблем, но все средства копирования файлов не поймут этого юмора, и их поведение станет неадекватным.
В принципе, выход за границы файла ничем не чреват. Файловые системы лазерных дисков очень просты. Лазерные диски не поддерживают фрагментацию файлов, а потому и не нуждаются в FAT. Все файлы занимают непрерывный ряд секторов, и с каждым файлом связано только две важнейшие характеристики: номер первого сектора файла, заданный в формате LBA (Logical block address), и его длина, заданная в байтах. Остальные атрибуты, вроде имени файла и времени его создания — не в счет, мы сейчас говорим исключительно о секторах.
Увеличение длины файла приводит к "захвату" того или иного количества примыкающих к его хвосту секторов, и при условии, что номер последнего сектора, принадлежащего файлу, не превышает номера последнего сектора диска, копирование файла, в принципе, протекает нормально. Я не случайно заметил, что "в принципе нормально", а не просто "нормально", так как в копируемый файл будут включены все файлы, встретившиеся на его пути. Если же в процессе своего копирования файл "выскакивает" за конец диска, то привод CD-ROM сигнализирует об ошибке и прекращает чтение. Штатные средства копирования, входящие в состав операционной системы, равно как и большинство оболочек сторонних производителей, автоматически удаляют "огрызок" недокопированного файла с диска, и в результате пользователь остается ни с чем.
Утилита IS09660.DIR.EXE выгодно отличается тем, что позволяет копировать не только весь файл целиком, но и любую его часть! Но как мы узнаем, сколько именно байт следует скопировать? Как определим, где идут полезные данные, а где начинается "послехвостовой" мусор (over-end garbage)? Будем исходить из того, что по Стандарту файлы на диске располагаются последовательно, т. е. за последним сектором одного файла, непосредственно следует стартовый сектор следующего. Поскольку стартовые сектора всех файлов нам известны, определение истинных длин всех файлов за исключением последнего, не составит никакого труда! Так как длина одного сектора лазерного диска составляет 2048 байт, истинный размер всякого файла равен: (стартовый адрес следующего файла — стартовый адрес самого этого файла) * 2048
. Все просто, не правда ли?
С помощью утилиты IS09660.DIR.EXE мне и моим друзьям удалось скопировать большое количество дисков с MP3, обладающих защитой данного типа.
- Резервное копирование многофайловых баз данных
- Восстановление из резервных копий многофайловых баз данных
- Создание файлов с блокировкой
- Рекомендуемое расширение для файлов баз данных - *.ib
- Создание многофайловой базы данных
- Правила именования файлов
- Глава 6 Файловые системы
- 3.4 Сетевая файловая система
- 6.4 Другие файловые системы
- 6.5 Файловая система NTFS
- 6.6 Файловые системы для сетей хранения данных
- Файловые типы