Фиктивный трек, совпадающий с подлинным треком
Создание фиктивного трека, совмещенного с подлинным треком, приводит к тому, что длина первого трека обращается в ноль. Почему в ноль, а не в отрицательное число, ведь длина подлинного трека в данном случае равна: &Track2– &Track1 – sizeof(post-gap) – sizeof(pre-gap), что в конкретных цифрах выглядит так: 00:02:00 – 00:02:00 – 00:02:00 – 00:02:00 == –00:04:00 или в переводе в LBA-адреса: – 300.
Все дело в том, что адрес 00:02:00 —– особенный. Трек, начинающийся с этого адреса, не имеет Pre-gap (вернее, не позволяет обрабатывать свою областьй Pre-gap нормальным образом) и потому вычисление фактической длины такого трека происходит в отдельной ветке программы, которая оказывается достаточно интеллектуальной для того, чтобы догадаться не вычитать sizeof(post-?gap) из нулевого значения. Особенности реализаций конкретных копировщиков сейчас нам неинтересны, достаточно лишь знать, что подавляющее большинство из них вычисляют длину первого и всех последующих за ним треков вполне корректно (правда, от проблем копирования защищенного диска это их все равно не избавляет).
Внедренение X-сектора в подлинный трек (см. защиту типа "Шакал" в разд. "Фиктивный трек в Pre-gap подлинного трека" этой главы) приводит к следующему побочному эффекту: попытка чтения X-сектора командой READ CD возвращает ошибку, позицирование головки на X-сектор командой SEEK проходит без ошибок, но и без перемещения самой головки. Чтение заголовка X-сектора командой READ HEADER вновь возвращает ошибку. Забегая вперед отметим, что копия диска, полученная с помощью Clone CDCloneCD читает заголовк и выполняет позиционирование головки без ошибок (головка при этом действительно перемещается), благодаря чему дубликат диска элементарно отличается от оригинала.
При открытии оригинального образа защищенного диска, Clone CDCloneCD обнаруживат лишь второй —– фиктивный —– трек в первой сессии, "в упор не видя" настоящего (см.
листинг 6.27 ниже). К счастью, несмотря на это, "прожиг" диска проходит успешно.
Листинг 6.27. Реакция CloneCD на фиктивный трек, совпадающий с настоящим треком
ИНФОРМАЦИЯ О СЕССИИ 1:
Размер сессии: 4726 Кбайт
Число треков: 2
Track 2: Данные Mode 1, размер: 4726 Кбайт
ИНФОРМАЦИЯ О СЕССИИ 2:
Размер сессии: 3939 Кбайт
Число треков: 1
Track 3: Данные Mode 1, размер: 3939 Кбайт
Листинг 19 реакция Clone CD на фиктивный трек, совпадающий с настоящим треком
Просмотр геометрии диска подтвержает существование двух треков с одинаковыми стартовыми адресами, причем длина первого трека действительно равна нулю, а не отрицательному числу (см. рис. 6.150x102). Еще интереснее то, что тип первого трека определен как "ISO 9660/Joliet", что мягко говоря не совсем соответствует истине. Идентификатор типа файловой системы ISO 9660 содержиться в шестнадцатом, а Joliet —– в семнадцатом секторе трека. При условии, что длина трека равна нулю (а это так и есть!) возникает вполне законный вопрос: какое отношение эти сектора имеют к первому треку? Сдается мне, что процедура идентификации типа файловой системы вообще не проверяет диапазон доступных адресов на переполнение!
Рис. 6.15. унок 10 0x102 Первый и второй трек имют идентичные стартовые адреса в результате чего длина первого трека обращается в ноль
Приводы NEC и TEAC оказались достаточно интеллектуальными, чтобы суметь прочитать такой диск, а вот ASUS к своему стыду увидел лишь первую сессию. Следовательно, на вторую и все последующие сессии закладываться нельзя.
Попытка копирования защищенного диска программой Alcohol 120% Алкоголиком традиционно проходит неуспешно (если режим "попуска ошибок чтения" не включен, Alcohol 120% Алкоголик вообще не хочет копировать такой диск, а в режиме "пропуска ошибок чтения" "врезается" в область Lead-outLead-Out и входит в дурной цикл, не позволяя себя прервать иначе, чем принудительным завершением процесса).Копировщик Clone CDCloneCD, как уже говорилось, обрабатывает фиктивный трек вполне нормально, но удаляет защиту типа "Шакала" из области Post-gap, "благодаря" чему дубликат диска легко отличается от оригинала.