Так как же все-таки скопировать такой диск?
Конечно, с помощью "Добермана Пинчера" (или любого другого блочного копировщика файлов), HIEW'а, двух образов защищенного диска (один– с первой сессией – от Clone CD, другой – со второй сессией – от Алкоголя) и еще чьей-то матери мы можем воссоздать идентичную копию оригинального диска, путем их совокупного (не путать с совокупленным) объединения, но… это будет как-то не по-хакерски, да и вообще не красиво.
Чтобы не писать свою собственную программу "прожига" диска ограничимся использованием Clone CD. При условии, что подсунутый ему образ диска запечатлен правильно, Clone CD обычно справляется с прожигом на ура. Итак, у нас есть более и менее верный файл image.ccd, содержащий TOC, но недостает файла образа image.img. Попробуем его получить? Будем отталкиваться от того, что LBA-адреса всех секторов диска пронумерованы последовательно, включая области, занятые Lead-In/Lead-Out и прочим служебным барахлом. Разумеется, непосредственное чтение служебных областей диска на сектором уровне невозможно, но… именно на этом мы и собираемся сыграть! Последовательно читая диск с первого по последний сектор, мы обнаружим, что сектора с LBA-адресами с 0- по 2055 сектор включительно читаются без каких-либо проблем, после чего наступает сумеречная зона не читающихся секторов, протянувшаяся вплоть до сектора 13307. Здесь сектора либо совсем не читаются, либо возвращаются в сильно мутированном виде, легко опознаваемым по отсутствию правильной синхро-последовательности в их заголовке. Наконец, с адреса 13308 чтение вновь продолжается без каких-либо проблем.
Судя по всему мы имеет дело в двух-сессионным диском и сумеречная зона между сессиями есть ни что иное как Lead-Out/Lead-In. Накинув два сектора на post-gap (при условии, что он записан с соблюдением Стандарта), получаем, что LBA-адрес последнего значимого сектора первой сессии составляет: 2057 или, в пересчете на абсолютные единицы – 00 минут, 29 секунд и еще 32 фрейма. Соответственно, LBA-адрес первого сектора второй сессии равен: 13308 + 150 (pre-gap) == 13458 или 3 минуты, 1 секунда, 33 фрейма. Конечно, если исследуемый диск содержит большое количество ошибок, то его анализ значительно усложняется, т. к. физические дефекты на сектором уровне могут выглядеть точно так же, как Lead-In/Lead-Out области, конечно, при том условии, что дефективные области имеют соответствующую протяженность – а это вряд ли.
Отбросив сектора, расположенные в зонах pre- и post-gap (т.е. 150 секторов от конца первой читаемой области и ровно столько же от начала следующей), мы должны объединить их в один файл, используя для этой цели любой файловый копировщик (например, штатную команду MS-DOS copy file_1 /b + file_2 image.img). Остается прочитать сырой TOC SCSI/ATAPI командой READ TOC (opcode: 43h, format: 2h) и записать его в image.ccd файл в соответствии с синтаксисом Clone CD. Как альтернативный вариант – можно воспользоваться ccd-файлом, сформированным программой Alcohol, предварительно скорректировав pre-gap Mode (как уже сказано выше, Алкоголик определил его неправильно, перепутав Mode 1 с Mode 2). Согласно стандарту, режим сектора задается пятнадцатым, считая от нуля, байтом его заголовка. Если этот байт равен одному (что, собственно, и наблюдается в нашем случае), то и Mode сектора будет 1, но не 2.
При условии, что все сделано правильно, после записи собственноручно сформированного образа диска, мы получаем практически идентичный оригинал. Просто? Да проще простого! И написать автоматический копировщик, автоматизирующий наш труд, можно буквально за несколько часов! Если чтение "сырых" секторов с диска представляет для вас проблему, воспользуйтесь исходными текстами утилит ASPI32.raw/SPTI.raw как раз такое чтение и осуществляющих.
Так что искажение TOC'a – не очень-то надежный прием защиты от копирования, как ни крути. Правда, от обычных пользователей, вооруженных Clone CD/Alcohol'ем он все-таки спасает, а больше от защиты зачастую и не требуется.
