Некорректный номер последнего трека
Искажение номера последнего трека (указатель A1h в TOC) подавляющее большинство приводов воспринимает крайне "болезненно", поэтому данный способ защиты носит скорее академический, чем практических характер (по типу: так защищать свои диски не надо). Тем не менее, при условии соблюдения определенных предосторожностей и пользоваться этой методикой все-таки можно.
Итак, берем уже известный нам образ диска IMAGE.CCD, находим в нем строку "Point=0xA1", расположенную в сессии1 и изменяем значение принадлежащего ей поля PMin с единицы на двойку. Тем самым мы заставляем привод считать, что номер последнего трека первой сессии равен двум, а не одному, как это имеет место быть в действительности.
[Entry 1] [Entry 1]
Session=1 Session=1
Point=0xa1 Point=0xa1
… …
PMin=1 PMin=2
PSec=0 PSec=0
PFrame=0 PFrame=0
При записи измененного образа на диск Clone CDCloneCD выдает вполне корректную информацию о количестве треков, косвенно свидетельствуя о том, что он вообще не анализирует значения указателя A1h, а номер последнего трека определяет путем анализа указателей 01h— – 99h. Последний встретившийся указательpointer – и будет последним номером трека данной сессии.
(Внимание!:
point Указатель с наибольшим номером не обязательно является последним треком, т. к. нумерация треков может быть умышлено искажена с целью затруднения копирования диска).
Защищенный таким образом диск (точнее и, правильнее было бы сказать "изуродованный таким образом диск") под приводом ASUS показывает лишь свою первую сессию. NEC "видит" оба трека, но ввиду "разбушевавшейся фантазии своих электронных цепей" ошибочно распознает их тип как AUDIO, однако, проигрывать их наотрез отказывается (жаль, а то бы мы услышали неповторимую симфонию Шума и Скрежета).
Привод TEAC не опознает такой диск вообще. Короче, все указывает на то, что микропроцессорная начинка приводов ведет себя совсем не так, как Clone CDCloneCD и вместо подсчета количества треков, напрямую считывает содержимое указателя A1h. И, если он оказывается искажен, поведение привода становится в высшей степени неадекватно. В общем, это плохая защита и мы ее рассматривать не будем.
Гораздо "лояльнее" приводы относятся к искажению номера последнего трека второй сессии (в том смысле, что "изуродованная" вторая сессия никак не мешает чтению первой). Давайте в порядке свободного эксперимента возьмем оригинальную копию IMAGE.CCD и совершим над ней следующую "хирургическую" операцию (изменим содержимое поля PMin, принадлежащего point'у указателю A1h второй сессии с двойки на единицу, пытаясь убедить привод в том, что номер последнего трека второй сессии оканчивается на единицу, хотя можно выбрать и любое другое значение, например три или восемь)::
[Entry 8] [Entry 8]
Session=2 Session=2
Point=0xa1 Point=0xa1
… …
PMin=2 PMin=1
PSec=0 PSec=0
PFrame=0 PFrame=0
Приводы ASUS и TEAC показывает лишь первую сессию искаженного диска, вторя же недоступна даже не секторном уровне. Привод NEC так же видит только одну сессию —– первую, но "великодушно" позволяет считывать вторую на секторном уровне, тем не менее на щедрость подобного рода нам закладываться нельзя, поскольку подавляющее большинство остальных приводов не столь "благородны", как NEC.
Попробуем скопировать защищенный диск, предварительно изучив его геометрию с помощью любой подходящей программы (например, Ahead Nero).
Смотрите (см. рис. 6.190x070) Ahead Nero Нерон видит оба трека диска, но второй —– искаженный —– трек представляется ему абсолютно пустым, что в общем-то недалеко от истины, т. к. на секторном уровне этот трек все равно не доступен. Попытка копирования диска тем же Ahead Nero Нероном приводит к копированию лишь первой его сессии и хотя скопированный диск формально вполне работоспособен, защита может разгадать подмену элементарным анализом TOC, проверяя количество сессий, имеющихся на диске и атрибуты второго трека. На диске, скопированным Ahead Nero Нероном они, разумеется, не совпадут.
Рис. 6.19. унок 14 0x070 Реакция Ahead Nero Нерона на некорректный номер последнего трека
Копировщик Clone CDCloneCD так же "обламывается" с копированием. Во-первых, он теряет способность корректно распознавать границы сессии и при достижении конца первой сессии упорно пытается прочесть содержимое области Lead-outLead-Out на секторном уровне. Правда, процесс "обмолачивания" дефективных секторов протекает достаточно быстро и пользователь даже не успевает заскучать. Вторая сессия по понятным причинам остается не скопированной и Clone CDCloneCD корректирует TOC, выбрасывая из него всякие упоминая о последней (это во-вторых). Как следствие: TOC скопированного диска будет кардинально отличается от TOC'a оригинала и защите не составит большого труда обнаружить факт несанкционированного копирования. Alcohol 120% Алкоголь
так же копирует только первую сессию.
Может ли такой диск быть скопирован вручную? Разумеется! Достаточно только один к одному переписать оригинальный TOC не внося в него никаких изменений и "залить" на диск содержимое первой сессии.
