PMin=0                  ; -+

PSec=0                  ; -+

PFrame=0                ; -+

PLBA=-150

[TRACK 1]

MODE=0

INDEX 1=45000

Сокращение сессий с двух до одной очень сильно смущает. Куда девалась вторая – неискаженная(!) сессия, вообще непонятно. И, хотя искаженные данные первого трека сохранились, оказались неожиданно измененными поля Application Code и ATIP (и это несмотря на то, что запись производилась на ту же самую CD-RW-болванку, что и раньше, хотя ее «прожиг» осуществлялся различными приводами).

Как следствие: скопированный диск оказывается работоспособен не на всех приводах (ASUS и NEC его прочитают, а вот PHILIPS – нет), к тому же защите ничего не стоит прочитать текущий TOC и сравнить его с эталонным.

Короче говоря, «факир был пьян, и фокус не удался». Что ж, попробуем обратиться за помощью к Alcohol– уж он-то должен наверняка с этим справиться. Действительно, Alcohol видит обе сессии: как искаженную, так и неискаженную, однако по малопонятным причинам сохраняет в образ лишь вторую из них (Clone CD сохранял первую). Ну что это за зоопарк, а? Содержимое TOC скопированного диска можно даже и не сравнивать – там будет далеко не то, что защита собирается ожидать. И напрасно! Содержимое TOC, снятое Alcohol, практически полностью соответствует оригиналу. Единственно, в чем ошибся Alcohol, – определил тип pre-gap обоих треков не как Mode 1, но как Mode 2. Впрочем, в силу отсутствия в образе первой сессии полученная с его помощью копия диска все равно оказывается неработоспособной.

Рисунок 2. Alcohol видит обе сессии защищенного диска, но…

Рисунок 3. Копирует лишь вторую из них, а первую нагло пропускает

А ведь заявлялось, что Clone CD/Alcohol 120% способны копировать любые существующие на сегодняшний момент защищенные диски, и вдруг на поверку оказывается, что даже такую простую защиту, которую может создать на кончике пенька любой программист, они преодолеть ни вместе, ни по раздельности не в состоянии! Причем аппаратура, на которой все эти эксперименты и осуществлялись, возможность корректного копирования искаженного диска гарантированно поддерживает (сам проверял), и потому отмахнуться физическими ограничениями приводов разработчикам обоих копировщиков уже не удастся!

Даже не верится, что такой простой прием «ослепляет» лучших копировщиков защищенных дисков! Неужели и вправду создание некопируемых дисков вполне осуществимо на обыкновенном бытовом оборудовании?! Да! Именно так! Конечно, не стоит путать некопируемость диска автоматическими копировщиками с принципиальной невозможностью получения его идентичной копии. В ручном режиме копирование таких дисков вполне осуществимо (правда, при условии, что ваш пишущий привод поддерживает режим RAW DAO, а читающий – читает сектора из обоих секций), и сейчас мы продемонстрируем как.

Так как же все-таки скопировать такой диск?

Конечно, с помощью «Добермана Пинчера» (или любого другого блочного копировщика файлов), HIEW, двух образов защищенного диска (один – с первой сессией – от Clone CD, другой – со второй сессией – от Alcohol) мы можем воссоздать идентичную копию оригинального диска путем их совокупного объединения, но… это будет как-то не по-хакерски, да и вообще некрасиво.

Чтобы не писать свою собственную программу «прожига» диска, ограничимся использованием Clone CD. При условии, что подсунутый ему образ диска запечатлен правильно, Clone CD обычно справляется с прожигом «на ура». Итак, у нас есть более и менее верный файл image.ccd, содержащий TOC, но недостает файла образа image.img. Попробуем его получить? Будем отталкиваться от того, что LBA-адреса всех секторов диска пронумерованы последовательно, включая области, занятые Lead-In/Lead-Out и прочим служебным барахлом. Разумеется, непосредственное чтение служебных областей диска на секторном уровне невозможно, но… именно на этом мы и собираемся сыграть! Последовательно читая диск с первого по последний сектор, мы обнаружим, что сектора с LBA-адресами с 0 по 2055 сектор включительно читаются без каких-либо проблем, после чего наступает сумеречная зона нечитающихся секторов, протянувшаяся вплоть до сектора 13307. Здесь сектора либо совсем не читаются либо возвращаются в сильно мутированном виде, легко опознаваемые по отсутствию правильной синхропоследовательности в их заголовке. Наконец, с адреса 13308 чтение вновь продолжается без каких-либо проблем.