Разрыв в нумерации треков второй сессии
Хорошо, "хачить ломать" нумерацию треков первой сессии– саксь и маст дай, но вот реакция приводов на разрыв второй сесии уже не такая "психованная" и, если предпринять все необходимые предосторожности, вероятность конфликта с оборудованием будет сведена к разумному минимуму, которым можно смело пренебречь (читай —– ущерб от несанционированного копирования "голых" дисков намного превышают убытки от возврата "нечитающихся" дисков, правда, среди пользователей встречаются и такие, что за каждый конфликтующийх диск грозяться подать на вас в суд или просто оторвать вам головуяйца, правда, никому из моих знакомых их еще не отрывали, так что риск оказается недееспособным не так уж и велик).
Опираясь на опыт, приобретенный в процессе предыдующих экспериментов, мы без труда разорвем вторую сессию, изменив номер третьего трека на девятый (естественно, вы можете выбрать и другой номер, но только помните, что четные номера приносят несчастье).
При записи искаженного образа на диск Clone CDCloneCD неправильно определяет номер последнего трека разорванной сессии, ошибочно принимая выводную область за самостоятельный трек (листинг 6.37). Действительно, CloneCD некорректно определил количество треков второй сессии, ошибочно посчитав, что их восемь (в то время как правильный ответ: два), так же трек с номером 170 представляющий собой трек Lead-Out, ошибочно интерпретируется как трек с данными (совмещенные треки). Однако, на качество "проотжига" диска это никак не влиянет.
Листинг 6.37. CloneCD некорректно определяет количество треков второй сессии
ИНФОРМАЦИЯ О СЕССИИ 1:
Размер сессии: 4726 Кбайт
Число треков: 1
Track 1: Данные Mode 1, размер: 4726 Кбайт
ИНФОРМАЦИЯ О СЕССИИ 2:
Размер сессии: 3939 Кбайт
Число треков: 8
Track 2: Данные Mode 1, размер: 1722 Кбайт
Track 9: Данные Mode 1, размер: 2216 Кбайт
Track 170: Data, размер: 4294932446
Кбайт
"Листинг 29 Clone CD некорректно определил количество треков второй сессии, ошибочно посчитав, что их восемь (в то время как правильный ответ: два), так же трек с номером 170 представляет собой Lead-Out трек, ошибочно интерпретированный как трек с данными (совмещенные треки)
Полевые" испытания защищенного диска показывают следующие результаты. Приводы NEC и TEAC "видят" лишь первую сессию диска, а вторая оказывается недоступной даже на секторном уровне, однако, команды SEEK, READ SUBCHANNAL и READ HEADER исполняются успешно. Если бы аналогичным образом вели себя все приводы, —– разработчику защиты ничего бы не стоило разместить в Q-канале подкода второй сессии ключевую метку или просто проверить Q-канал "разорванной" сессии на читабемльность. Такие копировщики как Alcohol 120% Алкоголь и Clone CDCloneCD просто не увидят разованной сессии, а если даже и увидят, то не смогут скопировать ее содержимое, возвращаемое как уже говорилось, не в отдельном канале, а вместе с основным потоком данных. При условии, что разорванная сессия не доступна на секторном уровне (а это действительно так), на несанкционированных копиях диска ее просто не окажется и команды SEEK, READ SUBCHANNAL и READ HEADER возратят ошибку, позволяя тем самым отличить копию от оригинала.
Увы, некоторые приводы (ASUS в частности) не дают к разорванной сессии никакого доступа вообще, "благодаря" чему оригинальный диск ошибочно опознается защитой как копия. Так что закладываться на вторую сессию ни в коем случае нельзя! Впрочем, эти меры предосторожности практически не ослабляет защиту, поскольку даже целая сессия такого диска все равно не копируется.
Просмотр геометрии диска с помощьюпод копировщикаом Ahead Nero показывает, что последний не только не может определить длины треков разорванной сессии (которые по его мнению не имеют никакой длины вообще), он катострофически неправильно отображает их номера. Истинные номера треков, записанные в TOC'е на экран вообще не выводятся, замещаясь на последовательные порядковые номера (см. рис. 6.200x0103). Таким образом, трек номер девять представляется как трек с номером три. В некотором смысле это может быть и верно, но вот для корректного копирования защищенного диска одних лишь порядковых номеров оказывается недостаточно.
Рис. 6.20. унок 15 0x103 Ahed Nero неправильно отображает номера треков
Копировщик Clone CDCloneCD видит лишь первую сессию защищенного диска и, судя по всему, даже и не подозревает о существовании второй (см. листинг 6.38, приведенный ниже). Как следствие —– разорванная сессия вообще не копируется и в TOC'е диска-копии отсутствует всякое упоминание о ней. Таким образом, для проверки лицензионной чистоты диска защитому механизму достаточно лишь считать TOC и сравнить его с эталотнным TOC'ом оригинала.
Листинг 6.38. CloneCD неправильно отображает номера треков
ИНФОРМАЦИЯ О CD В ДИСКОВОДЕ:
Число сессий: 1
Занято на диске: 30911 Кбайт
Секторов: 13458
Время: 02:59:33 (мин:сек:кадр)
ИНФОРМАЦИЯ О СЕССИИ 1:
Размер сессии: 30911 Кбайт
Число треков: 3
Track 1: Данные Mode 1, размер: 30911 Кбайт
Листинг 30 Clone CD неправильно отображает номера треков
Ладно, с разорванной сессией все более или меннее понятно. Ну не рассчитывали создатели Clone CDCloneCD на такие "извращения", ну не додумалисьперли до того, что нумерация треков может быть коварно измена. Ведь не кастрировать же их за это, верно? Но ведь и первая сессия защищенного диска так же оказалась скопированной неверно (листинг 6.39).! Отсюда мораль: несвоевременная санкции предъявленные к разработчикам придают "неприятный привкус" программному продукту. (Отсюда мораль: несвоевременная кастрация разработчиков придает неприятный привкус программному продукту).
Листинг 6.39. Содержимое TOC оригинального диска (слева) и диска, скопированного CloneCD (справа)
|
[Entry 2] |
[Entry 2] |
; адрес выводной области первой сессии оказался |
|
Session=1 |
Session=1 |
; определен неправильно! Clone CD установил его |
|
Point=0xa2 |
Point=0xa2 |
; на адрес начала трека номер два (первого трека |
|
ADR=0x01 |
ADR=0x01 |
; второй сессии), что повлекло за собой искажение |
|
Control=0x04 |
Control=0x04 |
; длины первого трека и породило множество |
|
TrackNo=0 |
TrackNo=0 |
; нечитающихся секторов, расположенных в Lead-Out/ |
|
AMin=0 |
AMin=0 |
; Lead-In областях. Таким образом, для определения |
|
ASec=0 |
ASec=0 |
; подлинности диска вовсе необязательно читать |
|
AFrame=0 |
AFrame=0 |
; содержимое TOC'a и достаточно всего лишь |
|
ALBA=-150 |
ALBA=-150 |
; определить полную емкость носителя, что можно |
|
Zero=0 |
Zero=0 |
; сделать и штатными средствами операционной системы |
|
PMin=3 à |
PMin=0 |
; без обращения к интерфейсам ASPI32/SPTI |
|
PSec=1 à |
PSec=29 |
; альтернативный путь – прочитать содержимое |
|
PFrame=33 |
PFrame=33 |
; TOC командой IOCTL_CDROM_READ_TOC, что так же не |
|
PLBA=13458 à |
PLBA=2058 |
; требует обращения к ASPI32/SPTI |
|
[Entry 10] |
[Entry 4] |
; трек номер два, принадлежащий второй сесии, ; CloneCD |
|
Session=2 |
Session=1 |
; запихнул в конец первой, даже не потрудившись |
|
Point=0x02 |
Point=0x02 |
; сопоставить стартовый адрес последнего со ; стартовым |
|
ADR=0x01 |
ADR=0x01 |
; адресом выводной области первой сессии. Очевидно, |
|
Control=0x04 |
Control=0x04 |
; что они "волшебным" образом совпадают, вероятно |
|
TrackNo=0 |
TrackNo=0 |
; потому-то выводная область и принимается за ; самостоятельный трек |
|
AMin=0 |
AMin=0 |
; попытка чтения содержимого второго трека ни к чему |
|
ASec=0 |
ASec=0 |
; хорошему не приводит, а третий ; (ну то есть девятый) |
|
AFrame=0 |
AFrame=0 |
; трек вообще оказался потерян, поэтому копия диска, |
|
ALBA=-150 |
ALBA=-150 |
; полученная с помщью CloneCD отличается от ; оригинала, |
|
Zero=3 |
Zero=3 |
; как небо от земли и защите не будет стоит большого |
|
PMin=3 |
PMin=3 |
; труда обнаружить факт несанкционированного ; копирования |
|
PSec=1 |
PSec=1 |
; даже без обращений ко второй сессии! Вот такой он, |
|
PFrame=33 |
PFrame=33 |
; CloneCD! А еще претендует на звание дома высокой |
|
PLBA=13458 |
PLBA=13458 |
; культуры и быта, тьфу, на звание защищенного ; копира! |
AMin=0 AMin=0 ; Lead- In областях. Таким образом, для определения
ASec=0 ASec=0 ; подлинности диска вовсе необязательно читать
AFrame=0 AFrame=0 ; содержимое TOC'a и достаточно всего лишь
ALBA=-150 ALBA=-150 ; определить полную емкость носителя, что можно
Zero=0 Zero=0 ; сделать и штатными средствами операционной системы
PMin=3 à PMin=0 ; без обращения к интерфейсам ASPI32/SPTI
PSec=1 à PSec=29 ; альтернативный путь – прочитать содержимое
PFrame=33 PFrame=33 ; TOC командой IOCTL_CDROM_READ_TOC, что так же не
PLBA=13458 à PLBA=2058 ; требует обращения к ASPI32/SPTI
[Entry 10] [Entry 4] ; трек номер два, принадлежащий второй сесии, Clone CD
Session=2 Session=1 ; запихнул в конец первой, даже не потрудившись
Point=0x02 Point=0x02 ; сопоставить стартовый адрес последнего со стартовым
ADR=0x01 ADR=0x01 ; адресом выводной области первой сессии. Очевидно, что
Control=0x04 Control=0x04 ; они "волшебным" образом совпадают, вероятно потому-то
TrackNo=0 TrackNo=0 ; выводная область и принимается за самостоятельный трек
AMin=0 AMin=0 ; попытка чтения содержимого второго трека ни к чему
ASec=0 ASec=0 ; хорошему не приводит, а третий (ну то есть девятый)
AFrame=0 AFrame=0 ; трек вообще оказался потерян, поэтому копия диска,
ALBA=-150 ALBA=-150 ; полученная с помщью Clone CD отличается от оригинала,
Zero=3 Zero=3 ; как небо от земли и защите не будет стоит большого
PMin=3 PMin=3 ; труда обнаружить факт несанкционированного копирования
PSec=1 PSec=1 ; даже без обращений ко второй сессии! Вот такой он,
PFrame=33 PFrame=33 ; Clone CD! А еще претендует на звание дома высокой
PLBA=13458 PLBA=13458 ; культуры и быта, тьф,у на звание защищенного копира!
Листинг 31 содержимое TOC'а оригинального диска (слева) и диска, скопированного Clone CD (справа)
Alcohol 120% Алкоголик с копированием такого диска справляется не в пример лучше, однако, полученная с его помощью копия имеет по меньшей мере одно существенное отличие от оригинала. Номер разорванного трека непроизвольным образом меняется с девяти на три, то есть Alcohol 120% Алкоголик автоматически восстанавливает поврежденную нумерацию треков на правильную. Но ведь искаженная нумерация треков нам как раз и нужна! Защитный механизм, привязывающийся к TOC'у просто забракует такой диск, обозвав его несанкционированной копий! (Забвно, но содержимое указателяpoint'a A1h, указывающего на номер последнего трека диска остается неизменным и по прежнему равно девяти, то есть восстанавливая TOC, Alcohol 120% Алкоголик все равно восстановил его не корректно).
Таким образом, для привязки к оригинальному TOC'у, защитному механизму незачем считывать его содержимое в "сыром" виде и можно вполне обойтись штатными средствами операционной системы, поскольку искажения, вносимые копировщиками в TOC настолько велики, что в прямом смысле слова видны невооруженным глазом.
Тем не менее, стойкость защит данного типа достаточно невелика. Хакеру ничего не стоит вручную отредактировать образ диска, снятый Alcohol 120%Алкоголем, вернув разорванному треку его законный номер равный девяти или иному другому числу (конкретное значение легко узнать с помощью утилиты CD_READ_TOC или аналогичной ей).
