фрагмент оригинального диска
Листинг 6.60. Фрагмент скопированного диска
0049D2B0: 00 FF FF FF-FF FF FF FF-FF FF FF 00-00 29 32 01 yyyyyyyyyy )2O
0049D2C0: 00 00 00 00-00 00 00 00-00 00 00 00-00 00 00 00
…
0049DBE0: 00 FF FF FF-FF FF FF FF-FF FF FF 00-02 81 33 61 yyyyyyyyyy O?3a
0049DBF0: 00 28 00 1E-80 08 60 06-A8 02 FE 81-80 60 60 28 ( ^И•`¦?O??И``(
0049DC00: 28 1E 9E 88-68 66 AE AA-FC 7F 01 E0-00 48 00 36 (^z?hfо?u¦Oa H 6
0049DC10: 80 16 E0 0E-C8 04 56 83-7E E1 E0 48-48 36 B6 96 И-adE¦V?~aaHH6¦Ц
0049DC20: F6 EE C6 CC-52 D5 FD 9F-01 A8 00 7E-80 20 60 18 oi?IROyYO? ~И `^
0049DC30: 28 0A 9E 87-28 62 9E A9-A8 7E FE A0-40 78 30 22 (0zЗ(bzй?~?а@x0"
0049DC40: 94 19 AF 4A-FC 37 01 D6-80 5E E0 38-48 12 B6 8D Фv?Ju7OOИ^a8H¦¦?
0049DC50: B6 E5 B6 CB-36 D7 56 DE-BE D8 70 5A-A4 3B 3B 53 ¦a¦E6?V??OpZд;;S
Листинг 52 фрагмент скопированного диска
Прежде всего, бросается в глаза, что в области Pre-gap второго трека, ранее заполненной нулями, теперь появились какие-то данные, по внешнему виду очень смахивающие на "мусор" и не соответствующие никаким данным исходного трека с данными. Выбрем любую, наугад взятую последовательность, например, 1E 9E 88 68 66 AE AA (в тексте листинга 6.60 она выделена полужирным шрифтом) и попытаемся отыскать ее в исходном файле IMAGE.IMG. Ее там не окажется!
Абсолютный адрес сектора, находящийся в его заголовке (в тексте он взят в рамку), так же выглядит весьма неадекватно, как студент после хорошей пьянки на следующее утро. Смотрите, поле A-SEC принимает неприлично высокое значение, дотягиваясь, аж до 81h, что представляет собой грубешую ошибку. Максииум — здесь может находиться 59h, но никак не больше! Поле Mode, равное в данном случае 61h, тоже очевидно искажено.
Может быть, это просто маленькая локальная ошибка? Но нет! Просмотр заголовков секторов, показывает, что они здесь все такие (листинг 6.61).
Листинг 6.61. Искаженные заголовки секторов
0049DBE0: 00 FF FF FF-FF FF FF FF-FF FF FF 00-02 81 33 61 yyyyyyyyyy O?3a
0049E510: 00 FF FF FF-FF FF FF FF-FF FF FF 00-02 81 34 61 yyyyyyyyyy O?4a
0049EE40: 00 FF FF FF-FF FF FF FF-FF FF FF 00-02 81 35 61 yyyyyyyyyy O?5a
0049F770: 00 FF FF FF-FF FF FF FF-FF FF FF 00-02 81 36 61 yyyyyyyyyy O?6a
004A00A0: 00 FF FF FF-FF FF FF FF-FF FF FF 00-02 81 37 61 yyyyyyyyyy O?7a
Листинг 53 искаженные заголовки секторов
Вот так дела творятся в Багдаде! Ладно, черт с ними — с заголовками секторов, сейчас нас больше волнует вопрос: в какие-же "тар-тарары" провались наши исходные данные и что это за "мусор" читается из аудиотрека? Кто же во всем этом виноват? Дисковые сбои? Аудио-коррекция или… все-таки скремблирование?
Скремблирование! Это точно! Обнаружив в заголовке сектора сигнатуру синхропоследовательности 00 FF FF FF FF FF FF FF FF FF FF 00 и MODE равный единице, привод, не взирая на тип трека, заданный в TOC, интерпретировал данный сектор, как сектор с данными и отскремблировал все его байты — с 12 по 2351 включительно. Не только пользовательская область данных, но и поле MODE отказалось отскреблированным и потому при последующем считывании данного сектора с диска его принадлежность к сектору данных оказалось не столь очевидной и привод, заглянув в TOC, понял, что имеет дело с сектором "аудио", ре-скремблировать который не нужно. В результате мы получили на выходе искаженные скремблером данные, которые оказалось некому восстанавливать!
Такая особенность поведения привода не санкционирована стандартом, который эти вопросы описывает слишком неоднозначно и туманно, поэтому часть приводов (и их большинство!) принудительно скремблируют записываемые "аудио" данные, а часть — пишут их так, как есть. Правда, возможность считывания неотскремблированных секторов никем не гарантирована, поскольку они могут содержать регулярные последовательности данных, дезореентирующих считывающий механизм и вводящий его в грубые ошибки (см. "слабые сектора[Y180] ").
Поэтому для начала лучше поработать с приводами, насильственно скремблирующими сектора. К таковым в частности относятся NEC и TEAC.
Пропустив считанные данные через ре-скремблер, который можно позаимствовать, например, из библиотечки ElbyECC.dll, входящей в состав Clone CDCloneCD, мы восстановим исковерконные скремблером сектора их исходный вид, с которым наша программа без труда сможет работать. А отдельные дисковые сбои могут быть устанены и в ручную, ведь корректирующие коды находятся в нашем распоряжении! Если писать свой собственный декодер Рида-Соломона вам лень, то воспользуйтесь услугами все той же библиотеки ElbyECC.dll (только не забывайте при этом, что распростаняя последнюю в составе своего продукта вы нарушаете авторские права ее создателей).
Кажется, что мы напали на настоящую золотую жилу! Раз содержимое трека с данными, помечанного как аудиотрека принудительно скремблируется при записи, попытка копирования такого диска приведет к его повторному скремблированию, в результате чего мы получим совершенно другие данные (строго говоря, это будет не совсем "другие" данные — повторное скремблирование равносильно ре-скремблированию и исходный "аудиотрек" будет полностью восстановлен, однако, поскольку защитный механизм так же прогоняет данные через ре-скремблер, то он сможет работать только со "своим" диском, а его копипей, правда копия с копии даст желанный результат, но всякий ли до этого догадается?).
Увы! Поскольку, поле MODE так же скремблируется, считанный с защищенного диска сектор уже не опознается приводом как сектор с данными и его принудительное скремблирование не выполняется, благодаря чему "защищенный" диск копируется вполне нормально. Однако… мы проделали слишком большой путь, чтобы вот так запросто сдаваться!
"Аудиотреки", записанные на проводе, который не выполняет их автоматического скремблирования, при попытке копирования на всех остальных приводах приведут к полному провалу, — ведь эти приводы, выполняя скремблирование, необратимо "гробят" содержимое секторов, которое невозможно восстановить даже двукратным перекопированием.
Единственный выход — найти нескремблирующий привод ( что будет весьма непросто, лично я таких приводов так и не нашел), либо изменить прошивку своего пишушего привода так, чтобы он позволял включать/выключать скремблирование секторов по нашему желанию. Для этого подойдет любой привод, который только можно "прошивать" (например, TEAC). Скачав свежую прошивку с сайта его производителя, "натравите" на него дизассемблер, понимающий "язык" данного процессора и проанализируйте алгоритм работы микропрограммы. Только помините, что некорректно измененная прошивка может полностью вывести привод из строя, поскольку процедура "прошивки[Y181] [n2k182] " привода в самой "прошивке" и содержиться и если последняя вдруг перестанет работать, перестанут работать и все "артерии" привода. И хотя осуществить задумание вполне реально, квалификация взломщика должна быть очень и очень высока.
К сожалению, разработчики защищаемого приложения находятся ничуть не в лучших условиях, поскольку для записии оригинальных дисков им требуется аналогичный привод, который чрезвычайно трудно застать в продаже и ничуть не легче изготовить самому. С другой стороны — было бы желание, а уж пути для его осуществления завсегда найдутся! Зато, данный защитный механизм как нельзя лучше подходит для штампованных CD, на логическую структуру которых вообще не наложено никаких ограничений. Диск, защищенный по данной технологии, скопировать практически нереально…
Теперь перейдем к "слабым" секторам, — то есть секторам, содержащим неблагоприятные для привода последовательности. И одна из таких последовательностей — …04 B9 04 B9 04 B9… Нескремблируемый сектор, содержащий такую запись в своем теле запишется без проблем, но в силу определенных конструктивных ограничений даже лучшими из приводов будет читаться крайне нестабильно, а то и вовсе не будет читаться вообще. Так происходит потому, что физическое представление данной последовательности приводит к образованию длиных цепочек лендов (питов), а приводу для работы жизненно необходим постоянно изменяющийся HF--сигнал (HF — High Frequency, высокая частота) и читать однородные области спиральной дорожки он не в состоянии.
Подробнее о "слабых" последовательностях можно прочитать в разд.главе "Синхрогруппы, объединяющие битыmerging bits и DSV" главы 1 и "Слабые (weak) сектора[Y183] ". Для нас же сейчас важно в первую очередь тот факт, чтово-первых, некоторые приводы все-таки ухитряются найти выход из положения, просто меняя стартовую позицию сектора во фрейме, что ведет к колоссальным изменениям на физическом уровне представления информации и "слабая" последовательность внезапно перестает быть таковой, нормально читаясь всеми приводами. Но! Скопировать такой диск можно только на том приводе, который умело распознает и корректно обрабатывает "слабые" последовательности (к таким приводам в частности относятся приводы Plextor, за полным списоком подходящих для этих целей моделей обращайтесь к справке Clone CDCloneCD).
С другой стороны, приводы пишушие "слабые" последовательности как есть оказываются невероятно полезными для качественной имитации сбойных секторов (подробнее см. разд. "Защиты, основанные на физических дефектах" главы 9), поскольку сектора, содержащие "слабые" последовательности, не читаемыбельны на физическом уровне. Это вам не тривиальное искажение полей EDC/ECC полей, легко обнаруживаемое защитным механизмом путем чтения сектора в "сыром" режиме. "Слабые" сектора к тому же заставляют привод сбросить скорость и немного поерзрхать головкой, вызывая тем самым определенную временную задержку —– точно такую, какую вызываются настоящие сбойные сектора (и многие защитные механизмы закладываются на это). Сектор с искореженным EDC/ECC, напротив, читается практически мгновенно, чем и выдает себя с головой. Короче говоря, "папуас папуасу друг, товарищ и корм", —– слабые сектора служает не только на благо защиты, но и неплохо чувствуют себя в руках "пролетариата" —– то бишь хакеров и кракеров, не желающих платить "буржуинам" свои кровные.
Надеююсь, вы будете не против немного поэкспериментировать с ними?
Итак, берем наш старый-добрый образ оригинального файла (нет, не искореженный скремблированием образ защищенного файла, а образ снятый с нормального диска), привычным дивжением руки меняем атрибуты трека с данными на аудио, как это мы уже делали ранее, но в дополнение к тому искажаением поле синхронизации Sync и/или поле MODE нескольких секторов с заранее известными адресами. Записываем образ на диск и убеждаемся, что теперь их содержимое уже не скремблируется и с диска читается именно то, что мы на него писали (правда, если сектор содержит в себе регулярные последовательности он может и не прочитаться —– все же не от простой жизни секторам с данными скремблирование придумали).
А теперь забьем эти сектора последовательностью …04 B9 04 B9 04 B9… и запишем их снова. Если ваш привод не достаточно интеллектуален для того, чтобы выбирать стартовую позицию сектора во фрейме, наши сектора запишутся самым неблагоприятным образом и попытка их чтения даст ошибку! Кстати, если вы густо усеете диск сбойными секторами, —– его копирование окажется чрезвычайно затруднено, особенно если расположить "слабые" сектора группами, размер которых варьируется от 9 до 99 секторов, а за концом каждой групы будет расположен один ключевой сектор (т. е. обыкновенный сектор, содержащий ключевую информацию). Дело тут вот в чем. Умные копировщики (Clone CDCloneCD или \Alcohol 120%Алкоголь), обнаружив, что диск содержит большое число дефектных секторов, на чтение которых уходит коллосальноеколоссальное количество времени, предлагают пользователю задействовать режим быстрого пропуска сбойных секторов, —– тогда, встретившись со сбойным сектором, копировщик пропускает 100 последующих секторов, экономя время на попытках их чтения. Защиты, привязывающиеся к настоящим физическим дефектам поверхности, на этом трюке "обламываются" по полной программе (т. к.дефекты имеют тенденцию со временем разрастаться и потому внедрять ключевую информацию в окрестности дефектной области крайне не рекомендуетсяопасно для своих яйиц). Однако, слабые сектора не являются дефективными в физическом смысле этого слова и потому чтению прилагающих к ним секторов ничуть не мешают. А раз так, то – мы можем смело закладываться на их существование! Копирование защищенного диска в режиме "быстрого пропуска" пропустит не только "слабые" сектора, но и ключевые метки, а копирование в обычном режиме растянется на несколько часов (если не больше) да и то по причинам о которых мы поговорим далеениже.