|
|||||||
АвтоАвтоматизацияАрхитектураАстрономияАудитБиологияБухгалтерияВоенное делоГенетикаГеографияГеологияГосударствоДомДругоеЖурналистика и СМИИзобретательствоИностранные языкиИнформатикаИскусствоИсторияКомпьютерыКулинарияКультураЛексикологияЛитератураЛогикаМаркетингМатематикаМашиностроениеМедицинаМенеджментМеталлы и СваркаМеханикаМузыкаНаселениеОбразованиеОхрана безопасности жизниОхрана ТрудаПедагогикаПолитикаПравоПриборостроениеПрограммированиеПроизводствоПромышленностьПсихологияРадиоРегилияСвязьСоциологияСпортСтандартизацияСтроительствоТехнологииТорговляТуризмФизикаФизиологияФилософияФинансыХимияХозяйствоЦеннообразованиеЧерчениеЭкологияЭконометрикаЭкономикаЭлектроникаЮриспунденкция |
Листинг 10.2. Оригинальный стартовый адрес Lead-Out (слева) и стартовый адрес первого трека диска (справа)[Entry 2] [Entry 3] Session=1 Session=1 Point=0xa2 Point=0x01 ADR=0x01 ADR=0x01 Control=0x04 Control=0x04 TrackNo=0 TrackNo=0 AMin=0 AMin=0 ASec=0 ASec=0 AFrame=0 AFrame=0 ALBA=-150 ALBA=-150 Zero=0 Zero=0 PMin=0 PMin=0 PSec=29 PSec=1 PFrame=33 PFrame=0 PLBA=2058 PLBA=0 Изменим поля PMin:PSec:PFrame, принадлежащие point 0xa2, так, чтобы они указывали на самый конец диска (0xa2 — это и есть Lead-Out). Измененный Lead-Out может выглядеть, например, так: 74:30:00. Адрес Lead-Out следует выбирать с тем расчетом, чтобы между ним и внешней кромкой диска остался, по меньшей мере, 30-секундный зазор. Еще лучше, если ширина Lead-Out составит примерно полторы минуты. Однако в этом случае будут неизбежно теряться последние треки восстанавливаемого диска (если, конечно, вам действительно требуется их восстановить). К содержимому полей PMin:PSec:PFrame, принадлежащих point 0x01 (стартовый адрес первого трека), необходимо добавить ту же самую величину, которую вы добавили к соответствующим полям Lead-Out. Отредактированный вариант может выглядеть, например, так: 74:01:42 (74:30:00 /* новый адрес Lead-out */ - 00:29:33 /* старый Lead-Out */ + 00:01:00 /* старый стартовый адрес первого трека */ == 74:01:42 /* новый стартовый адрес */). Короче говоря, новая версия файла ccd должна выглядеть так, как показано в листинге 10.3. Листинг 10.3. Ключевой фрагмент "реаниматора" 75-минутных CD-RW-дисков [Entry 2] [Entry 3] Session=1 Session=1 PMin=74 PMin=74 ...... PSec=30 PSec=01 PFrame=00 PFrame=42 Вообще-то для приличия следовало бы скорректировать и поля PLBA. Адрес LBA связан с абсолютным адресом следующим соотношением: LBA == ((Min*60) + sec)*75 + Frame, однако текущие версии работают исключительно с абсолютными адресами и игнорируют адреса LBA. Теперь все, что находится между концом области Lead-in и началом первого сектора, будет называться pre-gap. При "прожиге" диска область pre-gap останется нетронутой и позже может быть прочитана на секторном уровне, что нам как раз и требовалось. Сказать по чести, чрезмерное увеличение pre-gap первого трека — не самая лучшая идея, так как не все приводы способны читать такой "жирный" pre-gap. С точки зрения совместимости было бы лучше увеличивать pre-gap второго трека, однако при этом первый трек придется располагать в самом начале диска, и его тело неизбежно затрет восстанавливаемые сектора. И хотя это — не такая уж большая проблема, так как в первых секторах диска все равно ничего ценного нет, к такой мере без особой необходимости все же лучше не прибегать. На крайний случай действуйте так: запишите на диск две сессии, и вместо стартового адреса point 0x01 меняйте стартовый адрес point 0x02 (он будет находиться в разделе session=2). Теперь наскоро очистим наш подопытный диск, и до предела заполним его какими-нибудь файлами. Совет Предпочтительнее всего использовать текстовые файлы, так как в этом случае будет сразу видно, что извлекается с восстановленного диска — мусор или полезная информация. Записав файлы на диск, тут же выполним его быструю очистку. Убедившись, что диск действительно очищен, и его содержимое уже недоступно, запустим Clone CD и запишем на очищенный диск только что созданный нами "лечебный" образ. Запись должна проводиться в режиме DAO, иначе ничего хорошего у вас не получится. Совет Прежде чем восстанавливать сколько-нибудь ценный диск на еще неизвестном вам приводе, попробуйте провести эксперимент на диске, не содержащем ничего интересного. Вот, наконец, мы держим в руках свежевосстановленный диск. Но действительно ли он восстановлен? А вот сейчас и убедимся! Вставляем "воскресшего из пепла" в привод NEC и с замиранием сердца пробуем прочитать один из наугад взятых секторов из середины диска (начальные сектора обычно содержат нули, потом — файловую систему, и их очень легко принять за бессмысленный мусор). О чудо!!! Оригинальное содержимое очищенного диска читается, как ни в чем не бывало. Правда, при попытке прочесть оглавление диска средствами операционной системы привод может впасть в задумчивость, граничащую с полным зависанием (ведь стартовый адрес первого трека расположен не в начале диска, а совсем в другом месте), но это все ерунда! Главное, что на секторном уроне диск все-таки доступен, пусть и не на всех приводах. Так, в частности, ASUS вообще отказывается читать такой диск, возвращая ошибку, a PHILIPS читает сплошной мусор. К счастью, этот мусор можно восстановить, — достаточно на битовом уровне выполнить EFM-перекодировку с более "правильной" позиции. Поскольку возможных позиций всего 14, перебор обещает не затягиваться на длительное время. Тем не менее, лучше всего будет просто приобрести более качественный привод. Остается лишь привести диск в состояние, пригодное для работы с ним, средствами операционной системы. Последовательно читая все сектора диска один за другим, мы будем собирать их в один img-файл, для определенности именуемый recover.img. Сектора, которые не удалось прочитать даже с нескольких попыток, мы будем просто пропускать. Теперь скопируем "лечебный" ccd-файл в recover.ccd и вернем стартовый адрес первого трека на прежнее место. Запишем сформированный образ на новый диск. Теперь, если все было сделано правильно, любой привод должен корректно читать созданный диск. Сеанс демонстрационного восстановления окончен, и мы, освоившись с этой технологией, можем приниматься за вещи куда более серьезные. Например, откроем собственную компанию по восстановлению очищенных дисков. Шутка! Хотя… почему бы и нет? Хорошо, а как быть, если очищенный диск был многосессионным? Ведь описанные выше приемы рассчитаны на работу лишь с одной сессией! На самом деле можно восстановить и многосессионный диск. Это лишь чуть-чуть труднее. Но, чтобы это сделать, мы должны предварительно познакомиться с остальными полями TOC. Постойте, а что, если после очистки диска на него что-то писалось, — возможно ли тогда его восстановление или нет? Разумеется, непосредственно затертые позиции утеряны безвозвратно, но остальную часть информации по-прежнему можно спасти. Если диск до очистки был многосессионным, то нам даже не придется возиться над восстановлением файловой системы, так как файловая система каждой последующей сессии дублирует предыдущую, за исключением удаленных файлов. Последняя сессия диска оказывается достаточно далеко от его начала, а потому и риск ее затирания — минимален (если, конечно, спохватиться вовремя, а не тогда, когда весь диск перезаписан до отказа). Восстановление односессионных дисков с затертой файловой системой — намного более трудная, но все-таки разрешимая задача. Во-первых, этих файловых систем на типовом диске целых две: ISO-9660 и Joliet. Правда, в силу их близкого географического положения при затирании диска обе они обычно гибнут. Во-вторых, указанные файловые системы не поддерживают фрагментации, и всякий файл, записанный на лазерный диск, представляет собой единый информационный блок. Все, что нужно для его восстановления, — определить точку входа и длину. Точка входа в файл всегда совпадает с началом сектора, а подавляющее большинство типов файлов позволяют однозначно идентифицировать свой заголовок по уникальной сигнатуре (в частности, для zip-файлов характерна следующая последовательность: 50 4B 03 04). Конец файла, правда, определяется уже не так однозначно, и единственная зацепка — структура самого восстанавливаемого файла. Впрочем, большинство приложений довольно лояльно относится к "мусору" в хвосте файла, и потому точность определения его длины с погрешностью в один сектор на практике оказывается вполне достаточной. Поскольку файлы располагаются на диске вплотную, без "зазоров", конечный сектор всякого файла надежно вычисляется путем вычитания единицы из стартового сектора следующего за ним файла. Вообще же говоря, техника восстановления лазерных дисков намного проще и незатейливее искусства врачевания их прямых коллег — дискет и жестких дисков. Правда, поговорку "семь раз отмерь — один раз отрежь" еще никто не отменял, и одна из неприятнейших особенностей работы с CD-RW как раз и состоит в том, что вы не можете гарантированно управлять процессом происходящей записи. Дискеты и жесткие диски в этом смысле полностью прозрачны, — что вы пишете, то вы и получаете. Перезаписываемые же носители, напротив, представляют собой "черный ящик", и вы никогда не можете быть уверенными в том, что конкретный привод будет правильно интерпретировать отдаваемые ему команды (увы, восстановление дисков CD-RW никак не вписывается в рамки Стандарта, а все нестандартные махинации могут интерпретироваться приводом неоднозначно). Единственное, что остается посоветовать: не пускайте все на самотек. Бесконечно экспериментируйте, экспериментируйте и еще раз экспериментируйте, накапливая бесценный опыт, который вам когда-нибудь может очень пригодиться. Искажение размеров файлов Еще (или, скорее уже) во времена монохромных терминалов и первых магнитных дисков существовал некрасивый, но элементарно реализуемый защитный прием, препятствующий пофайловому копированию носителя. Внося определенные искажения в структуры файлов системы, разработчики "портили" дискету ровно настолько, чтобы работа с ней становилась возможной лишь при условии учета характера внесенных искажений. Защищенная программа, "знающая" об искажениях файловой структуры, работала с ней без проблем, но штатные утилиты операционной системы работать с такими дисками не могли. Общедоступных "хакерских" средств копирования в те времена еще не существовало. Несколько файлов зачастую ссылались на общие для всех них кластеры, и тогда запись данных в один файл приводила к немедленному их появлению в другом, что защита могла так или иначе использовать. Естественно, после копирования файлов на новый диск пересекающиеся кластеры "разыменовывались", и хитрый способ неявной пересылки данных переставал работать. Вместе с ним переставала работать и сама защищенная программа, если, конечно, содержимое диска вообще удавалось скопировать. Ведь копирование файлов с пересекающимися кластерами приводило к тому, что эти кластеры многократно дублировались в каждом копируемом файле, в результате чего их суммарный объем подчас увеличивался настолько, что емкости тогдашних носителей попросту не хватало для хранения таких объемов данных! Если же последний кластер файла "приклеивался" к его началу (файл, таким образом, попросту зацикливался), то объем и время его копирования попросту обращались в бесконечность. Конечно, дисковые доктора в то время уже существовали, но их использование не давало желаемого результата, потому что лечение файловой системы приводило к полной неработоспособности защиты. В случае с зацикливанием, например, если защита основывалась на том, что за концом файла следует его начало, то после обработки диска доктором осуществление этого приема становилось невозможным со всеми от сюда вытекающими последствиями. Файловые системы лазерных дисков, конечно, совсем не те, что на гибких дисках, но общие принципы их искажений достаточно схожи. Увеличивая фиктивные длины защищаемых файлов на порядок-другой, разработчик защиты может довести их суммарный объем до нескольких сотен гигабайт, так что для копирования защищенного диска понадобится, по меньшей мере, пачка DVD или винчестер солидного объема. Защитный механизм, "помнящий" оригинальные длины всех файлов, сможет работать с ними без проблем, но все средства копирования файлов не поймут этого юмора, и их поведение станет неадекватным. В принципе, выход за границы файла ничем не чреват. Файловые системы лазерных дисков очень просты. Лазерные диски не поддерживают фрагментацию файлов, а потому и не нуждаются в FAT. Все файлы занимают непрерывный ряд секторов, и с каждым файлом связано только две важнейшие характеристики: номер первого сектора файла, заданный в формате LBA (Logical block address), и его длина, заданная в байтах. Остальные атрибуты, вроде имени файла и времени его создания — не в счет, мы сейчас говорим исключительно о секторах. Увеличение длины файла приводит к "захвату" того или иного количества примыкающих к его хвосту секторов, и при условии, что номер последнего сектора, принадлежащего файлу, не превышает номера последнего сектора диска, копирование файла, в принципе, протекает нормально. Я не случайно заметил, что "в принципе нормально", а не просто "нормально", так как в копируемый файл будут включены все файлы, встретившиеся на его пути. Если же в процессе своего копирования файл "выскакивает" за конец диска, то привод CD-ROM сигнализирует об ошибке и прекращает чтение. Штатные средства копирования, входящие в состав операционной системы, равно как и большинство оболочек сторонних производителей, автоматически удаляют "огрызок" недокопированного файла с диска, и в результате пользователь остается ни с чем. Утилита IS09660.DIR.EXE выгодно отличается тем, что позволяет копировать не только весь файл целиком, но и любую его часть! Но как мы узнаем, сколько именно байт следует скопировать? Как определим, где идут полезные данные, а где начинается "послехвостовой" мусор (over-end garbage)? Будем исходить из того, что по Стандарту файлы на диске располагаются последовательно, т. е. за последним сектором одного файла, непосредственно следует стартовый сектор следующего. Поскольку стартовые сектора всех файлов нам известны, определение истинных длин всех файлов за исключением последнего, не составит никакого труда! Так как длина одного сектора лазерного диска составляет 2048 байт, истинный размер всякого файла равен: (стартовый адрес следующего файла — стартовый адрес самого этого файла) * 2048. Все просто, не правда ли? С помощью утилиты IS09660.DIR.EXE мне и моим друзьям удалось скопировать большое количество дисков с MP3, обладающих защитой данного типа. Звездная сила обращается в пыль На нас надвигается тьма! Защита Star-Force наступает по всем направлениям, и новые игры уже не копируются. Защита выглядит неприступной, как скала, и за ней уже закрепилась слава несокрушимой. На самом деле ситуация не так мрачна. Кроме столбовой дороги есть и обходные пути, никем не охраняемые. Воспользуемся одним из них. Что такое Star-Force Star-Force (рис. 10.3) — это семейство защит от копирования, привязывающихся к физической структуре спиральной дорожки. Оно оснащено термоядерным ракетным комплексом противохакерских средств типа "земля — пользователь". Вместо простейшей проверки по схеме "свой — чужой", которую можно запросто нейтрализовать заменой одной инструкции jmp, Star-Force преобразует топологические характеристики диска в число, используемое для расшифровки основного тела программы, причем специальные защитные компоненты следят за тем, чтобы после расшифровки никто не снял дамп. Рис. 10.3. Логотип Star-Force, по которому эту защиту легко отличить от любой другой Часть защитного кода сосредоточенна в многомегабайтной библиотеке protect.dll, часть — в драйверах, а часть — скомпилирована в p-код, выполняемый на собственном интерпретаторе. Помимо этого, защита реализует множество антиотладочных приемов, препятствующих как изучению защитного кода, так и эмуляции оригинального диска. Защита не стоит на месте, а напротив, активно совершенствуется. С каждой новой версией разработчики все туже и туже "затягивают гайки", да так, что резьба уже начинает сдавать. Последние версии "Звездной Силы" очень глубоко вклиниваются в Windows и даже модифицируют ее ядро, в результате чего система начинает работать нестабильно. У одних пропадают данные, у других система регулярно демонстрирует BSOD, у третьих после установки очередного обновления от Microsoft лицензионные игры внезапно отказывают в работе, требуя установки обновления от Star-Force (http://www.star-force.ru/support/sfdrvup.zip), а у кого-то защищенные диски вообще не опознаются. Разработчики, естественно, списывают все это на низкую квалификацию пользователей, которые не ведают, что творят. Хотя мое мнение и не обязательно однозначно правильно, но мне есть, что на это возразить. Никто не спорит, что Windows может упасть и сама. Тут посторонней помощи не надо. Но вот то, что вытворяет команда разработчиков Star-Force — это не просто "аморально" или "нехорошо". Ведь кроме закона о защите авторских прав, есть и закон о защите прав потребителя! Вмешиваться в работу операционной системы на компьютере пользователя, да так, чтобы защитная программа портила пользовательские данные — незаконно! Более того, требовать, чтобы при наличии привода IDE защищенный диск запускался именно с него (a Star-Force это требует) — незаконно с любой точки зрения. Если программа умышленно отказывается работать на определенных конфигурациях, и легальные пользователи никак не проинформированы об этом факте, то перед нами, как минимум, грубая конструктивная недоработка, а как максимум — злостная закладка. В западном мире защиты от копирования вообще мало популярны. Обычно используется серийный номер или прочие надежно работающие, хотя и легко ломаемые алгоритмы. А все потому, что лучше терпеть убытки от пиратства, чем держать специальную службу поддержки, отвечающую на звонки разгневанных пользователей, требующих или немедленно сделать что-нибудь, или вернуть деньги. И не важно, что это — аппаратная несовместимость, дефект защиты или ошибка покупателя. Клиент всегда прав! Поэтому серьезные продукты "Звездной Силой" защищать никогда не будут и никуда дальше игр она не уйдет. Как это работает Привязка к диску основана на измерении угла между секторами. Похожая техника использовалась еще во времена 8-битных компьютеров и дискет. Аналогичным образом работают CD-Cops, SecureROM и многие другие защитные механизмы, так что назвать идею Star-Force "революционной" очень трудно. Но это не помешало разработчикам запатентовать ее, или, по крайней мере, объявить, что она запатентована. Впрочем, не будем углубляться в юридические тонкости, а лучше перейдем к техническим деталям. Спиральная дорожка лазерных дисков очень похожа на грампластинку, только начинается не снаружи, а изнутри, и разворачивается от центра к краю. Лазерная головка, удерживаемая в магнитном поле (примерно так же, как удерживается звуковая катушка в акустических системах), движется на салазках поперек спиральной дорожки. Сама дорожка состоит из секторов с данными и каналов подкода. Номера секторов находятся как в заголовках самих секторов, так и в каналах подкода, "размазанных" вдоль спиральной дорожки. Для грубой наводки на требуемый сектор используются салазки и каналы подкода, а для точной — отклонение в магнитном поле и секторные заголовки. Просто взять и измерить структуру спиральной дорожки нельзя, но можно использовать следующий подход (рис. 10.4). Допустим, головка считывает сектор X, а следом за ним сектор Y. Если угол XOY, образованный центром (О) диска и секторами X и Y, составляет примерно 15 градусов, а сами сектора расположены в соседних витках спиральной дорожки, то приводу будет достаточно всего лишь немного отклонить головку и через мгновение сектор Y сразу же окажется у оптической головки. Если же угол составляет менее 15 градусов, то за время перемещения головки сектор Y уже "уплывет", и приводу придется ждать целый оборот лазерного диска. Рис. 10.4. Когда угол между секторами X и Y составляет -15 градусов, при переходе на соседний виток сектор Y сразу же "подлетает" к оптической головке (рисунок слева), при меньшем значении угла сектор Y успевает "уплыть" и головка вынуждена ждать целый виток (рисунок справа) Таким образом, замеряя время чтения различных пар секторов, мы можем приблизительно определить их взаимное расположение на спиральной дорожке. У каждой партии дисков оно будет своим (ведь плотность секторов на 1 мм и крутизна спирали неодинакова, и варьируется от партии к партии). Чтобы побороть упреждающее считывание, которым "страдают" многие приводы, защита должна читать сектора в порядке убывания их номеров. Кроме того, защита должна измерять скорость вращения привода, чтобы определить постоянство временных замеров и скорректировать формулу для вычисления угла, ведь, как легко показать, чем быстрее вращается диск, тем скорее "уплывает" сектор. Именно так Star-Force и поступает. Ниже приведен протокол работы защиты, перехваченный программой BusHound (рис. 10.5). При этом использовался накопитель SCSI, поскольку с IDE защита работает напрямую, и программный перехват уже не спасает. Рис. 10.5. BusHound за работой Сначала защита выполняет профилировку поверхности, определяя время одного оборота и оценивая величину разброса, на основании которого будет рассчитываться допуск на отклонение ключевых характеристик. Результаты профилировки спиральной дорожки представлены в листинге 10.4. Обратите внимание на то, что все номера секторов представлены в шестнадцатеричном формате. Поиск по сайту: |
Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Студалл.Орг (0.011 сек.) |