Техника защиты компакт-дисков от копирования

Диск, начинающийся не с первого трека


"Ну и запросы у вас..." —–

"сказала" база данных и "повисла".

Требование стандарта начинать нумерацию треков с единицы в купе с наличием point'a указателя A0h, хранящего номер первого трека выглядит несколько странным, если не сказать —– избыточным. Мне могут возразить, что point указатель A0h имеет смысл для второй и всех последующих сессиий, но я резонно отвечу: во-первых, номер первого трека каждой сесссии равен point'у указателю A1h предыдущей сессии плюс единица, во-вторых, номер первого трека всякой сессии —– это наименьший номер трека из всех треков, принадлежащихей данной сессии. Так что point'ы указатели A0h и A1h все равно избыточны и предназначены исключительно для быстрого определения номера первого и последнего треков, без анализа всего TOC'а целиком, что для "хлипбких" микропроцессоров первых аудиоплееров было действительно актуальным.

Но вот интересно —– анализирут ли современные приводы эти point'ы указатели или молчаливо закладываются на номер первого трека по умолчанию (чего стандарт кстати деать не запрещает)? Попробуем это выяснить, создав диск, начинающийхся не с первого трека, а, например, сразу с трека номер два. Используя свой предыдующий опыт мы это сделаем без труда. Достаточно лишь изменить point указатель 0x01 на point указатель 0x02, соответствующим образом перенумеровав все point'ы указатели последующих треков (если они есть), изменить [TRACK  1] на [TRACK  2] и перенумеровать все последующие треки (если они есть), наконец, увеличить point указатель A1h первой сессии, а так же point'ы указатели A0h или /A1h всех последующих сессий на единицу. Если этого не сделать, оставив point'ы указатели "прозябать" по умолчанию, то такой диск не будет читаться приводом NEC вообще, приводу TEAC'у он будет доступен лишь на секторном уровне и даже ASUS "увидит" только первую сессию, да и то лишь после долгих раздумий и сексапильных подергиваний головкой (так что ASUS —– это "круто"рулез, правда в других отношения он ведет себя весьма нервно).
При попытке копирования такого диска посредством Clone CDCloneCD, последний "скажет", что диск пуст (хотя это и нет так), зато при очистке диска пишет "диск пуст: нет". Alcohol 120% Алкоголик на таком диске так же ничего "в упор не видит" и, равно как и Clone CDCloneCD, ничего и не копирует. Если вы уверены, что приводы ваших пользователей способны читать такие диски хотя бы на секторном уровне, вы легко можете создать практически непрошибаемую защиту, которую не скопирует практически ни один копировщик (мой —– скопирует, поскольку он вообще не заглядывает в TOC), однако, ввиду потенциальной конфликтности защиты такого типа на вашем месте я бы этого делать не стал, ну разве что в качестве курсовой работы, которая все равно никому не нужна, так почему бы тогда и не поизвращаться? (Помините историю о том парне, который написал в курсовой "тому, кто дочитает до этого места —– ставлю ящик пива/водки/шампанского"?).

Диск, начинающийся не с первого трека, но с корректно установленными point'ами указателями A0h и A1h практическими всеми, доступными мне приводами, читается нормально. И все бы хорошо, да вот досада —– привод NEC, под тихие щелкающие звуки, "завешивается" таким диском вплоть до нажатия на кнопку Eject. Так что это не очень хорошая защита, тем более, что тот же Clone CDCloneCD "обламывает" ее по полной программе, создавая вполне корректную и работоспособную копию. Иначе ведет себя Alcohol 120%Алкогль, выбрасывающий сообщение об ошибке "access violation" (нарушение доступа) и аварийно завершающий свое выполнение.

Таким образом, приводы ASUS и TEAC активно используют point'ы указатели A0h и A1h, а NEC судя по всему рассчитывает на то, что нумерация треков всякого диска обязательно должна начинаться с единицы, что с одной стороны не противоречит Стандарту, а с другой стороны – и не соответствует ему, т. к. point указатель A0h присутствует в нем не даром и его игонирование ни к чему хорошему не приводит.

Ситуация с Alcohol 120% Алкоголем до конца не ясна. Ошибка доступа —– очевидное следствие грубых алгоритмических ошибок и просчетов проектирования. Скорей всего, Alcohol 120% Алкоголь читает TOC в буфер и последовательно сканирует его на предмет поиска трека номер один, забывая при этом контролировать "вылет" за доступные буферу границы.

А вот Clone CDCloneCD понимает стандарт правильно, благодаря чему копирует защищенные диски на ура (впрочем, не в обиду будет сказано, такое поведение Clone CDCloneCD скорее исключение, чем правило и, как мы видели выше и, как мы увидим далее, редкий диск с искаженным TOC'ом удается скопировать без ошибок).


Содержание раздела