* Искажение TOC'а и его последствияФиктивный трек в настоящем треке
Не зная броду больше шансов утопиться
народная мудрость
Тот факт, что диски с данными адресуются исключительно на секторном уровне, дает большой простор для "извращений" с раскладкой треков, —– ни сам привод, ни операционная система не обращают на это обстоятельство ни малейшего внимания, но сбивает с толку подавляющее большинство копировщиков, включая копировщиков защищенных дисков, пытающихся скопировать диск именно по трекам, а не по секторам. Еще больший эффект дает размещение фиктивных треков в служебных областях, которые либо вовсе не могут быть скопированы приводом, либо завязаны на малоизвестных и редко используемых структурах, присутствие которых копировщики предпочитают не замечать. Но для начала разберемся как организованы стандартные треки и как все это хозяйство ухитряется работать.
По соображениям экономии места служебные структуры лазерных дисков содержат минимум необходимой информации и длина треков нигде явным образом не хранится. В грубом приближении она вычисляется путем вычитания стартового адреса текущего трека от стартового адреса следующего трека (стартового адреса выводной области диска —– если текущий трек в сессии последний). Сами же стартовые адреса хранятся в оглавлении диска (листинг 6.9), так называемом TOC'e (Table Of Contents).
Листинг 6.9. Пример содержимого оглавления диска в "сыром" виде с комментариями
session number
| ADR/control
| | TNO
| | | point
| | | | AM:AS:AF
| | | | | | | zero
| | | | | | | | PM:PS:PF
01 14 00 A0 00 00 00 00 01 00 00 ß номер первого трека первой сессии диска
01 14 00 A1 00 00 00 00 02 00 00 ß номер последнего трека первой сессии диска
01 14 00 A2 00 00 00 00 00 1D 21 ß адрес выводной области первой сессии диска
01 14 00 01
00 00 00 00 00 02 00 ß стартовый адрес трека N1
01 14 00 02
00 00 00 00 00 11 00 ß стартовый адрес трека N2
02 14 00 A0 00 00 00 00 03 00 00 ß номер первого трека второй сессии диска
02 14 00 A1 00 00 00 00 03 00 00 ß номер последнего трека второй сессии диска
02 14 00 A2 00 00 00 00 03 18 17 ß адрес выводной области второй сессии диска
02 14 00 03 00 00 00 00 03 01 21 ß стартовый адрес трека N3
Листинг 1 пример содержимого оглавления диска в сыром виде с комментариями
Между концом области Lead-inLead-In области и стартовым адресом первого трека каждой сессии расположена область пред-зазора иначе(так же называемая областью Pre-gap областью) протяженностью в 150 секторов, формально принадлежащая первому треку и по стандартам "Красной" и "Желтой" кКниг (базовые стандарты для аудиодисков и дисков с данными соответственно) не содержащая никаких полезных данных и на штампованных дисках CD-ROM дисках обычно заполненная нулями. Тип области пред-зазора совпадает с типом относящегося к ней трека и она сконструирована по его образу и подобию. А это значит, что для треков, записанных в MODE1, MODE2 FORM1 и MODE2 FORM2 область пред-зазора оказывается совсем не пустой. Как минимум она содержит корректные заголовки секторов, а как максимум —– заголовки секторов, контрольную сумму, корректирующие коды Рида-Соломона и прочую служебную информацию.
Листинг 6.10. Сектор из области Pre-gap аудио-трека (слева) и трека с данными (справа)
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ¦ 00 FF FF FF FF FF FF FF FF FF FF 00 00 00 02 01
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ¦ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ¦ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ¦ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ¦ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ¦ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ¦ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ¦ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ¦ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ¦ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ¦ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ¦ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ¦ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ¦ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ¦ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
… ¦ …
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ¦ 69 A0 A7 82 CA 8A 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ¦ 00 00 00 00 00 00 CA 65 65 BC AF D9 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ¦ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ¦ 00 00 A7 5B BD 72 88 0A 92 23 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ¦ 00 00 00 00 00 00 00 00 00 00 3D 90 90 48 AD D8
Листинг 2 сектор из pre-gap области аудио-трека (слева) и трека с данными (справа)
Между концом последнего трека и выводной областьюью каждой сессии расположена область постзазора иначе(так же называемая областью Post-gap областью) протяженностью от 150 и более секторов, формально принадлежащая последнему треку и аналогично области Pre-gap области не содержащая никаких данных. Тип области постзазора такой же, как и у предшествующего ей трека.
Если за треком одного типа следует трек другого типа (например, MODE1 сменяется на MODE2 или аудио-треки чередуются с треками данных), такие треки разделяются переходной областью (transition area) протяженностью по меньшей мере в 350 секторов.
Первые 150 секторов занимает область Post-gap область предшествующего трека, а остальные 200 секторов принадлежат расширенной (Extended) pre- gap области последующего трека. Расширенная область пред-зазора состоит из двух частей, занимающих по 50 и 150 секторов соответственно. Первые 50 секторов сохраняют тип предшествующего им трека, а оставшиеся 150 секторов представляют собой обычную область пред-зазора.
Треки данных идентичного типа могут располагаться как вплотную друг к другу, так и разделяться переходными областями. Однако, некоторые копировщики (в частности, Ahead Nero) ошибочно полагают, что переходные области между соседними треками присутствуют всегда и в порядке собственной инициативы пропускают последние ~350 секторов каждого трека. Поэтому, диски без переходных областей (или с укороченной переходной областью) такими копировщиками копируются некорректно, несмотря на свое полное соответствие стандарту.
Заметим, что выше здесь указаны лишь минимально допускаемые по стандарту размеры переходных областей, а их предельная длина практически ничем не ограничена. Размеры переходных областей нигде в явном виде не хранятся и для определения их границ необходимо проанализировать субканальные данные. Конкретно —– содержимое поля INDEX Q-канала подкода. Нулевое значение соответствует Pre-gap (или, применительно к аудиодискам —– паузе), любое другое —– действительному сектору трека или области Post-gap области. Таким образом, область постзазора ничем не отличается от предшествующего ей трека и копировщик не в состоянии определить ее длину и наличие Post-gap распознается лишь по косвенным признакам, – а именно по отсутствию информации в пользовательской части последних секторов трека. Грамотно спроектированный копировщик должен копировать содержимое всех сессий диска целиком —– от первого до последнего принадлежащего им сектора, не пытаясь анализировать раскладку треков, ибо она может быть произвольным образом искажена (адресация дисков с данными идет исключительно на секторном уровне и треки в ней не участвуют, а потому искажение их атрибутов вполне допустимо и не приводит ни к каким возмущениям со стороны операционной системы).
К сожалению, подавляющее большинство копировщиков (включая и копировщики защищенных дисков) негласно закалываются полагается на стандартные размеры переходных областей и крайне чувствительны к их искажениям. Обратите внимание (листинг 6.11), что второй трек начинается с адреса 465h, что соответствует абсолютному адресу 00:11h:00, приведенному в листинге 6.9 адрес начала Pre-gap, равный 3CFh, отстоит от стартового адреса трека ровно на 96h (150) секторов, следовательно, данная область Pre-gap полностью соответствует стандарту.
Листинг 6.11. Определение длины области Pre-gap по субканальным данным
++- номер трека
!! ++- index
03CC:00 15 00 0C 01 14 01 01 00 00 03 CC 00 00 03 CC
03CD:00 15 00 0C 01 14 01 01 00 00 03 CD 00 00 03 CD
03CE:00 15 00 0C 01 14 01 01 00 00 03 CE 00 00 03 CE ß конец post-gap первого трека
03CF:00 15 00 0C 01 14 02 00 00 00 03 CF 00 00 00 96 ß начало pre-gap второго трека
03D0:00 15 00 0C 01 14 02 00 00 00 03 D0 00 00 00 95
03D1:00 15 00 0C 01 14 02 00 00 00 03 D1 00 00 00 94
…
0462:00 15 00 0C 01 14 02 00 00 00 04 62 00 00 00 03
0463:00 15 00 0C 01 14 02 00 00 00 04 63 00 00 00 02
0464:00 15 00 0C 01 14 02 00 00 00 04 64 00 00 00 01 ß конец pre-gap второго трека
0465:00 15 00 0C 01 14 02 01 00 00 04 65 00 00 00 00 ß начало второго трека
0466:00 15 00 0C 01 14 02 01 00 00 04 66 00 00 00 01
0467:00 15 00 0C 01 14 02 01 00 00 04 67 00 00 00 02
Листинг 3 определение длины pre-gap области по субканальным данным, обратите внимание, что второй трек начинается с адреса 465h, что соответствует абсолютному адресу 00:11h:00, приведенному в листинге $-3. адрес начала pre-gap, равный 3CFh, отстоит от стартового адреса трека ровно на 96h (150) секторов, следовательно, данный pre-gap полностью соответствует Стандарту.
Однократно записываемые и перезаписываемые лазерные диски, используют Pre-gap для хранения такой экзотической и малоизвестной структуры данных как TDB (Track Descriptor Block —– блок описания трека), содержащей сведения о режиме записи, размере одного пакета и т. д.
Стандарт предписывает "прожигать" блок описания трека в режиме пакетной записи и режиме TAO (Track At Once —– по треку за раз), однако, большинство программ "прожига" (включая уже упомянутый Ahead Nero), "прожигают" TDB во всех доступных режимах записи, включая DAO. В листинге 6.12 представлен пример TDB с диска, прожженного Ahead Nero (диск записан в XA MODE2 FORM1, поэтому первый байт пользовательской области начинается со смещения 17h, а не 10h как это происходит в MODE1).
Листинг 6.12. Пример TDB с диска, "прожженного" Nero
000:00 FF FF FF FF FF FF FF FF FF FF 00 00 00 05 02 ¦O ; sector head
010:00 00 00 00 00 00 00 00 54 44 49 01 50 01 01 01 TDIOPOOO
; TDT-блок \
020:01 80 FF FF FF 00 00 00 00 00 00 00 00 00 00 00 OА ; TDU-блок / TDB
030:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
040:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
050:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
…
810:00 00 00 00 00 00 00 00 C3 0C 2E 82 00 00 00 00 ++.В ; к
820:00 00 00 00 00 00 00 00 93 78 85 F5 60 F5 F5 F5 УxЕї`їїї ; о
830:F5 0B AA AA AA 00 00 00 00 00 00 00 00 00 00 00 ї>ккк ; р Р
840:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; р И
850:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; к Д
860:00 00 00 00 00 00 00 00 00 00 00 00 00 00 58 14 X¶ ; т А
870:72 9B 00 00 00 00 00 00 00 00 00 00 00 00 C7 3C rЫ ¦< ; и
880:CC F4 30 F4 F4 F4 F4 8B 55 55 55 00 00 00 00 00 ¦Ї0ЇЇЇЇЛUUU ; р
890:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; у С
8A0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ю О
8B0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; щ Л
8C0:00 00 00 00 9B 18 5C 19 00 00 00 00 00 00 00 00 Ы^\v ; и О
8D0: 00 00 00 00 00 00 72 9B E5 94 71 47 E6 48 00 00 rЫхФqGцH ; е М
8E0:D1 00 F3 15 CC F5 2B 2C B1 AF F6 51 41 80 E0 F2 T є§¦ї+,-пЎQAАрЄ ; О
8F0:23 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 #@ ; к Н
900:00 00 00 00 00 00 00 00 00 00 5C 19 54 03 75 4A \vT¦uJ ; о А
910:7D 50 00 00 7B 00 0C BF 93 AB D5 AD 24 2E 42 51 }P { +¬Ул-н$.BQ ; д
920:4E 0D 6E CF 77 04 00 00 00 00 00 00 00 00 00 00 Ndn¦w¦ ; ы
Листинг 4 пример TDB с диска, прожженного Nero (диск записан в XA MODE2 FORM1, поэтому первый байт пользовательской области начинается со смещения 17h, а не 10h как это происходит в MODE1). дешифровка TDT: длина pre-gap 150 секторов, данный TDB относится только к первому треку, следом за TDT идет один-единственный TDU, описывающий текущий трек; дешифровка TDU: тип записи – непрерывная запись.
Блок описателя трека занимает один сектор, начинаясь с первого байта его пользовательской части, и дублируется во всех секторах второй половины Pre-gap данного трека. На структурном уровне он стоит из двух частей: таблицы описателя трека и одно или двух модулей описателей трека, сокращенно обозначаемых как TDT (Track Descriptor Table) и TDU (Track Descriptor Unit) соответственно. Дешифровка TDT в представленном листинге 6.12: длина Pre-gap 150 секторов, данный TDB относится только к первому треку, следом за блоком TDT идет один-единственный TDU, описывающий текущий трек; дешифровка TDU: тип записи — непрерывная запись.
Таблица описателя трека начинается со специальной сигнатуры: TDI (54h 44h 49h), что расшифровывается как Track Descriptor Identification (идентификатор описателя трека), следующие два байта хранят заявленную длину Pre-gap области, записанную в BCD-формате. Поле Type of Track Description Unit (табл. 6.1) указывает на количество модулей описания трека (сокращенно TDU от Track Description Unit), начинающихся непосредственно за концом блока TDB.
Единичное значение соответствует одному-единственному модулю, относящемуся к текущему треку. Нулевое значение указывает на наличие двух модулей, следующих друг за другом, первый из которых описывает атрибуты предшествующего трека, а текущий трек специфицируется вторым модулем.
Поля Lowest Track Number и Highest Track Number , записанные в BCD-формате, содержат наименьший и наибольший номера треков, описанных в данном TDB и используются главным образом в режиме пакетной записи для определения режимов предпочтительной записи. Во всех остальных случаях, следить за корректностью этих полей необязательно.
Первый байт модуля описателя трека содержит BCD-номер трека, который он, собственно, и описывает. Следующий за ним байт специфицирует метод записи и может принимать следующие значения:
q 00000000b — непрерывная запись (аудио-трек);
q 10010000b — непрерывная запись (всего лишь один пакет);
q 10010000b — инкрементная запись с пакетами переменной длины;
q 10010001b — инкрементная запись с пакетами фиксированной длины.
Поле Packet Size действительно только в режиме инкрементной записи пакетов постоянной длины – в этом случае оно содержит размер одного пакета, измеряемых в секторах. Иначе здесь должно находится FF FF FFh.
Таблица 6.1. Структура блока описателя трека с одним модулем описателя трека на конце
|
Байт |
Содержимое |
|
0 |
"T" |
|
1 |
"D" |
|
2 |
"I" |
|
3 |
Pre-gap length |
|
4 |
|
|
5 |
Type of Track Description Unit |
|
6 |
Lowest Track Number |
|
7 |
Highest Track Number |
|
8+00 |
Track Number |
|
8+01 |
Write Method of the Track |
|
8+02 |
Packet Size |
|
8+03 |
|
|
8+04 |
|
|
8+05 |
Reserved |
|
8+06 |
|
|
8+07 |
|
|
8+08 |
|
|
8+09 |
|
|
8+10 |
|
|
8+11 |
|
|
8+12 |
|
|
8+13 |
|
|
8+14 |
|
|
8+15 |
|
|
8+16 |
Большинство копировщиков защищенных дисков (и Alcohol 120%/Clone CD в том числе) в отношении переходных областей ведут себя чрезвычайно некорректно и никогда не копируют область Pre-gap первого трека, либо оставляя ее "непрожженной" (Alcohol 120%Алкоголь), либо забитой нулями (Clone CD). Последующие же переходные области копируются вполне нормально.
Все переходные области, за исключением Pre-gap первого трека первой сессии диска, свободно доступны на секторном уровне и не вызывают никаких проблем при чтении. Но область Pre-gap первого трека первой сессии — особенная. Поскольку, логический адрес первого значимого сектора диска принят за ноль (и это адрес первого сектора первого трека), то предшествующая ему область Pre-gap целиком лежит в отрицательных адресах. Это не вызывает никаких затруднений у команды READ CD MSF, принимающей в качестве аргументов абсолютные адреса, однако при использовании READ CD уже требуется совершенно иная система преобразования адресов (отрицательные LBA-адреса привод "в упор" не понимает). Она описана в стандарте, однако, разработчики копировщиков не всегда обращают на нее внимание, а может быть, им просто лень "топтать" кнопки? Кто знает… Но, как бы там ни было, первую область Pre-gap никто из них не читает, что позволяет нам использовать ее для хранения ключевой информации (на штампованных и дисках CD-R/RW) или же привязываться к конкретному TDB (на дисках CD-R/RW).
Сектор с адресом 00:00:00 (первый сектор Pre-gap) по стандарту читаться не обязан, т. к. у привода еще отсутствуют субканальные данные и он вынужден некоторое время заниматься их накоплением. На практике же, однако, штампованные и однократно записываемые диски CD-ROM/CD-R в зависимости от их качества и модели привода начинают читаться где-то со второго—десятого сектора, а до этого идут сплошные ошибки. С перезаписываемыми дисками ситуация обстоит намного хуже и они зачастую содержат нечитабельные сектора даже в середине области Pre-gap!
Таким образом, для защиты лазерного диска от несанкционированного копирования мы можем использовать следующие приемы:
q размещать соседние треки вплотную, без переходных областей (такой диск не копируется Ahead Nero, но копируется Алкоголем Alcohol 120% и Clone CDCloneCD);
q разместить в области Pre-gap первого трека диска ключевую информацию (такой диск копируется Ahead Nero, но не копируется ни Alcohol 120%Алкоголем, ни Clone CDCloneCD);
q создать фиктивный трек в подлинном треке или в переходной области подлинного трека (такой диск не копируется Ahead Nero, но копируется Clone CDCloneCD);
q разместить фиктивный трек в области Pre-gap первого трека (такой диск не копируется вообще ничем).
Добавление фиктивного трека приводит к искажению длины первого трека, т. к. теперь она вычисляется путем вычитания стартового адреса первого — подлинного — трека от стартового адреса второго — фиктивного — трека минус размер области Post-gap первого трека и Pre-gap второго (рис. 6.7). Допустим мы имеем диск с одним треком (рис. 6.7, а) и добавляем в TOC фиктивную запись о втором, реально несуществующем треке; как следствие этого длина первого трека уменьшается на sizeof(TRACK2) + sizeof(post-gap) + sizeof(pre-gap), причем между треком номер один и треком номер два образуется "дыра" в sizeof(post-gap) + sizeof(pre-gap) байт (рис. 6.7, б), которая штанными копировщиками не копируется! Поскольку, номера треков в адресации дисков с данными вообще не участвуют, операционной системе по-прежнему доступно все содержимое исходного трека, включая и области Pre-gap или Post-gap, образовавшиеся на границе настоящего и фиктивного треков. Другими словами, диск будет нормально читаться на любом оборудовании и под любой операционной системой, но скопировать его смогут лишь те копировщики, которые копируют содержимое Pre-gap и Post-gap, что по стандарту они делать не обязаны, т. к.
с официальной точки зрения эти области не содержат ничего интересного. Как следствие —– скопированный диск будет содержать "дыру" в 300 секторов, заполненных нулями. Такая "рана" способа угробить любой файл, а то и несколько файлов сразу!
Рис. 6.7. унок 2 0x074 Длина трека определяется как разность стартовый адресов следующего трека и стартового адресам самого этого трека минус размер области Post-gap области . допустим мы имеем диск с одним треком (рисунок сверху) и добавляем в TOC фиктивную запись о втором, реально несуществующем треке; как следствие этого – длина первого трека уменьшается на sizeof(TRACK2) + sizeof(post-gap) + sizeof(pre-gap), причем между треком номер один и треком номер два образуется "дыра" в sizeof(post-gap) + sizeof(pre-gap) байт (рисунок снизу), которая штанными копировщиками не копируется!
Еще большие перспективы открывает создание фиктивных треков в буферных областях Post-gap и Pre-gap областях. Длина образовавшегося трека, вычисленная по алгоритму PreGap_len = min(&Lead-Out, &NexTrack - 150) - &MyTrack – 150$, становится резко отрицательной, дезориентируя такие копировщики как Ahead Nero, CDRWin, Blind Write и даже самого Alcohol 120%Алкоголя. Причем, если первые три копировщика дипломатично отказываются копировать защищенный диск, завершая свою работу вежливым сообщением об ошибке, то дезориентация Alcohol 120% Алкоголя сопровождается конкретным обрушением последнего.
А вот Clone CDCloneCD копирует такие диски вполне корректно! На первый взгляд, это полностью обессмысливает данный защитный механизм (действительно, кому нужна защита, копирующаяся хотя бы одним-единственным широко распространенным копировщиком?). Однако, не торопитесь выносить окончательное решение! Среди защитных механизмов существует и такие, что легко копируются Alcohol 120%Алкоголем, но жестоко "обламывают" Clone CDCloneCD.
Совмещение нескольких защитных механизмов на одном диске, равносильно объединению разрозненных штатов (княжеств) в единую державу, стойически сопротивляющуюся натиску злобных полчищ врагов. В этом свете, операцииизвращения с размещением фиктивных треков в областях Pre-gap и Post-gap областях становятся весьма перспективной и к тому же чрезвычайно неконфликтной технологией защиты, претендующей на широкое распространение. Достаточно заманчивые перспективы, не так ли?
Итак, задача-минимум: добавить в файл IMAGE.CCD еще один трек, соответствующим образом скорректировав все, связанные с ним поля. Эта, элементарная на первый взгляд миссия, на самом деле требует внесения в файл большого количества изменений. По меньшей мере должны быть проделаны следующие операции:
q количество TocEntries должно быть увеличено на единицу;
q поле PMin, принадлежащее указателю point'у'у 0A1h, также должно быть увеличено на единицу;
q необходимо добавить новый Entry с подложным треком (для простоты можно скопировать Entry подлинного трека, слегка изменив его стартовый адрес);
q номера всех последующих треков должны быть увеличены на единицу (т. е. все последующие указатели (point)'ы такие, что 64h > point > 00h, должны быть перенумерованы, при этом предполагается, что диск содержит менее 63h треков, т. к. максимальное количество треков жестко ограничено сверху);
q номера всех последующих Entry должны быть увеличены на единицу;
если на диске имеется больше, чем одна сессия, то номера треков и указатели point'ов A0h/A1h последующих сессий должны быть увеличены на единицу (указательpoint A0h первой сессии увеличивать ненужно);
q в карту треков должен быть добавлен фиктивный трек, а номера всех последующих треков перенумерованы.;
q за сим все.
Для пущей важности ( в смысле для лучшего соответствия стандарту) было бы нелишне скорректировать субканальные данные фиктивного трека, увеличив содержимое полей TNO (Track Number) каждого из них, на единицу. Эта информация содержаться в Q-канале подкода, который вместе со всеми остальными каналами находится в файле IMAGE.SUB. Каждый 0Dh + 60h * N байт файла содержит поле TNO -поле сектора N (строго говоря: жесткого соответствия между субканальными данными и секторами нет, поэтому эта формула весьма приблизительна). После внесения всех необходимых изменений, контрольная сумма каждой 16-байтовой субканальной секции должна быть пересчитана заново, в противном случае защищаемый диск перестанет работать. Для этой цели можно воспользоваться функцией CalcSubChannelCRC из динамической библиотеки newtrf.dll, входящей в состав прожигателя Ahead Nero.
Листинг 6.13. Пример секции субнанальных данных, выделенное полужирным шрифтом поле содержит номер текущего трека
0003060C: 41 02
01 00 00 06 00 03 ¦ 01 39 63 8A 00 00 00 00 AOO ¦ ¦O9cК
Листинг 5 пример секции субнанальных данных, выделенное жирным шрифтом поле содержит номер текущего трека
Если вам лень возиться с субканальными данными —– ничего не трогайте и оставьте все как есть —– в процессе чтения диска с данными номера треков никак реально не используются. Вот аудиодиски —– другое дело. Там поле TNO используется для индикации текущего воспроизводимого трека и (иногда) для переключения между треками.
С другой стороны, наличие некорректных полей TNO существенно усиливает защищенность диска, поскольку лишь немногие из копировщиков способны копировать субканальные данные, да и у тех эта опция по умолчанию отключена (у Clone CDCloneCD отключена точно).
