Трек с данными, маскирующийся под аудио
Чем отличаются аудиотреки от треков с данными? И что произойдет если трек с данными пометить как аудиотрек? На первый взгляд здесь не случиться ничего интересного и подопытный трек будет спокойно читаться командой READCD с той лишь разницей, что автоматическая коррекция ошибок Q- и P-уровней уже не выполняется приводом, но сбойные сектора вполне поддаются восстановлению вручную. Защитный механизм, знающий истинный формат считываемых секторов такую коррекцию сможет осуществить без труда, а вот программы-копировщики — нет. А потому при многократном перекопировании диска, количество ошибок чтения будет неуклонно накапливаться и на каком-то этапе корректирующих способностей кодов Рида-Соломона окажется недостаточно и очередная по счету копия откажет в работе. Однако, при нынешнем качестве оптических носителей при бережном обращении с ними количество ошибок Q- и P-уровней крайне невелико и копии первых трех поколений гарантированно будут читаться даже раздолбанными "узкоглазыми" приводами. Так что хорошей защиты мы из этого не "сварим".
Подобные рассуждения типичны для специалиста средней руки, считающего что треки с данными отличаются от аудиотреков одним лишь битом поля ADR/Control (и это третий, считая от нуля бит), и в тоже время удивляющегося почему его привод "грабит" аудио-треки не вполне корректно. Хорошенько порывшись в спецификациях и отдизассемблировав пару тройку микропрограмных прошивок, мастера своего дела приходят к выводу, что в обработке аудиотреков и треков с данными присутсвует по меньшей мере пять концептуальных различный. Вот они.
q
q Точное позиционирование на заданный аудиосектор невозможно в принципе, поскольку адреса секторов, "проплывающих" в данный момент над оптической головкой, хранятся не в самом секторе, а в Q-канале подкода, "размазанном" вдоль спиральной дорожки. Упрощенно говоря, субканальные данные из 748 фреймов или 8 секторов (хотя, их правильное название — блоки) объединяются в пакеты, причем каждый такой пакет содержит в себе по четыре точки отсчета, что в идеальном случае соответствует погрешности в ±1 сектор, а на практике погрешность может достигать и большиших величин.
Стандарт устанавливает предельно допустимый уровень погрешности в ±1 сек (± 75 секторов), однако некоторые приводы показывают значительно худший результат, так, например, мой TEAC "уплывает" вперед аж на ~500 секторов! И у нас нет никакой возможности прочитать сектор с заранее заданным адресом! Такое положение дел, вполне удовлетворяющее запросы аудиотреков, для треков с данными категорически неприемлимо и потому они вынуждены оснащать свой заголовок специальным полем, содержащим их собственный адрес. Грубая наводка на сектор осуществляется по субканальным данным, а точная — по их заголовку, в результате чего привод всегда считывает именно тот сектор данных, который и был запрошен.
q Понятие "сектора" к аудиотрекам вообще не применимо. В них нет секторов, но есть так называемые блоки (blocks), которые состоят из последовательности непронумерованных фреймов, причем границы блоков категорически не фиксированы и блок имеет право начинаться с любого понравившегося приводу фрейма, расположенного в окрестностях позиционирования. Поэтому, при чтении трека с данными в режиме аудио мы не можем быть уверенными, что прочитанные сектора будет начинаться с "головы", а не "хвоста".
q Сектора с данными скремблируются, а аудиосектора — нет, причем необходимость в скремблировании определяется не типом текущего трека, а наличием синхропоследовательности и правильным Mode в его заголовке. Трек с данными, записанный как аудиотрек принудительно скремблируется при записи (что "гробит" Mode), но не дескремблируется при его чтении. Другими словами, с диска читается совсем не то, что на него писалось.
q Некоторые приводы (например, Plextor) осуществляют принудительную аудиокоррекцию записываемых данных, мотивируя это своим стремлением обеспечить более приятное звучание. Неудивительно, что попытка записи трека с данными в режиме аудио приводит к его полному уничтожению.
q Как уже говорилось ранее, аудиотреки не содержат Q- и P-кодов коррекции и потому привод и не корректирует их, что ведет к накоплению ошибок, однако, копии первых трех-пяти поколений замечательно читаются и без корректирующих кодов.
Так, теперь понятно, почему задача точного извлечения аудиотреков такая сложная, если не сказать — невозможная. Но как это обстоятельство можно использовать на практике? Давайте запишем трек с данными как аудиотрек и немного поэкспериментируем с ним. Это поможет нам ответить на поставленный выше вопрос.
Разумеется, непосредственно этого не сделать и шатаные программы "прожига" нашего хитрого замысла просто не поймут, в лучшем случае выдав что-то наподобие "Illegal mode for this track", а в худшем просто обозвав нас дураками. Что ж, придется идти обходным путем. Используя Ahead Nero, Stomp Record Now! или любую другую программу аналогичного назначения, создадим обыкновенный лазерный диск, содержащий один или несколько треков данных. Затем, используя копировщик Clone CDCloneCD (Alcohol 120%Алкоголь) снимем с диска образ и слегка отредактируем его CCD-файл. Все, что нам надо — найти Entry, чей указательPoint равен номеру нашего трека и изменить содержимое поля Control на ноль или два (аудитрек без защиты авторских прав и аудиотрек с защитой оных соотвественно). Так же следует поменять MODE трека c одного на ноль (см. секцию [TRACK] листинга 6.58).
Листинг 6.58. Создание образа защищенного диска
|
[Entry 11] |
[Entry 11] |
[TRACK 1] |
[TRACK 1] |
|
Session=2 |
Session=2 |
MODE=1 |
MODE=1 |
|
Point=0x02 |
Point=0x02 |
||
|
ADR=0x01 |
ADR=0x01 |
[TRACK 2] |
[TRACK 2] |
|
Control=0x04 |
Control=0x02 |
MODE=1 |
MODE=0 |
|
TrackNo=0 |
TrackNo=0 |
INDEX 1=0 |
INDEX 1=0 |
|
AMin=0 |
AMin=0 |
||
|
ASec=0 |
ASec=0 |
||
|
AFrame=0 |
AFrame=0 |
||
|
ALBA=-150 |
ALBA=-150 |
||
|
Zero=0 |
Zero=0 |
||
|
PMin=3 |
PMin=3 |
||
|
PSec=1 |
PSec=1 |
||
|
PFrame=33 |
PFrame=33 |
||
|
PLBA=13458 |
PLBA=13458 |
[Entry 11] [Entry 11] [TRACK 1] [TRACK 1]
Session=2 Session=2 MODE=1 MODE=1
Point=0x02 Point=0x02
ADR=0x01 ADR=0x01 [TRACK 2] [TRACK 2]
Control=0x04 Control=0x02 MODE=1 MODE=0
TrackNo=0 TrackNo=0 INDEX 1=0 INDEX 1=0
AMin=0 AMin=0
ASec=0 ASec=0
AFrame=0 AFrame=0
ALBA=-150 ALBA=-150
Zero=0 Zero=0
PMin=3 PMin=3
PSec=1 PSec=1
PFrame=33 PFrame=33
PLBA=13458 PLBA=13458
Листинг 50 создание образа защищенного диска
Субканальные данные корректировать не обязательно. Напротив, лучше оставить их в своем неизменном виде. Это запретит проигрывание данного трека в аудирежиме и избавит вас и ваших пользователей от тяжелого психического шока, вызыванного прослушиванием "симфонии данных", замаскированных под аудио. Что произойдет, если, скорректировав субканальные данные, проиграть "аудиотрек" на бытовом или компьютерном приводе? Да в общем-то ничего ужасно, но… Вы когда-нибудь загружали программы с магнитофонной ленты в персональный компьютер типа "Правец-8Д", "Электроника-БК" или "ZX-Spectrum"? А динамик модема во время передачи данных включали? Если да, тогда вы имеете представление о характере звука, который обрушится на ничего не подозревающих пользователей, вставивших такой диск в привод.
Так и заикой недолго стать, особенно если регулятор громкости выведен на максимум. Некоторые специалисты утверждают, что существует риск вывода усилителя и колонок из строя, однако, на мой взгляд, подобные слухи беспочвены и бессмысленны. Ни предельно доступимый уровень выходного сигнала, ни предельно достустимый спектр частот при этом не может быть превышен, и правильно спроектированный усилитель перенесет это испытание без особого вреда для себя. Тоже самое относится и колонкам.
Тем не менее, если вы используете режим "цифрового воспроизведения" треков, штатно поддерживаемый Windows 2000, то независимо от содежимого каналов подкода, треки с данными, помечанные как аудиотреки, воспроизводиться все-таки будут! А некоторые приводы (такие, например, как NEC) воспроизведут эти треки и в аудиорежиме. Что ж, пусть воспроизводят! А на все недовольные вопли ошарашенных пользователей мы ответим, что программа загружает себя через аудиотракт, — как и в былые времена. Ну чем не лекарство от ностальгии?
Рис. 6.23. унок 18 0x106 Данные, представленные как аудио[Y179]
А теперь прочитаем образ диска с аудиотреком и сличим его содержимое с исходным (см. рис. 6.23). Уверяю вас, результат превзойдет все ваши ожидания! Начнем с побайтового сравнения IMG-файлов, несущих на своих плечах данные основного канала. Используя любой компаратор (хоть fc.exe из штатной поставки Windows, хоть мой любимый c2u от Профессора Нимнула (Professor Nimnul)), запустим его приблизительно следующим образом: FC.EXE IMAGE.IMG IMAGE_T.IMG /B > IMAGE.DIF, где IMAGE.IMG — образ, снятый с "нормального" диска, а IMAGE_T.IMG, — образ, снятый с диска с "аудиотреком".
Через несколько минут (утилита fc.exe работает до "ужжжаса" медленно, не то, что c2u) на вашем жеском диске образуется файл IMAGE.DIF с размером в добрые 50 Мбайт. Стало быть какие-то отличия между "копией" и "оригиналом" все-таки есть и этих отличий не просто много, а очень-очень много!
Листинг 6.59. Фрагмент оригинального диска
0049D2B0: 00 FF FF FF FF FF FF FF ¦ FF FF FF 00 00 29 32 01 )2O
0049D2C0: 00 00 00 00 00 00 00 00 ¦ 00 00 00 00 00 00 00 00
…
0049DBE0: 00 FF FF FF FF FF FF FF ¦ FF FF FF 00 03 01 33 01 ¦O3O
0049DBF0: 00 00 00 00 00 00 00 00 ¦ 00 00 00 00 00 00 00 00
0049DC00: 00 00 00 00 00 00 00 00 ¦ 00 00 00 00 00 00 00 00
0049DC10: 00 00 00 00 00 00 00 00 ¦ 00 00 00 00 00 00 00 00
0049DC20: 00 00 00 00 00 00 00 00 ¦ 00 00 00 00 00 00 00 00
0049DC30: 00 00 00 00 00 00 00 00 ¦ 00 00 00 00 00 00 00 00
0049DC40: 00 00 00 00 00 00 00 00 ¦ 00 00 00 00 00 00 00 00
0049DC50: 00 00 00 00 00 00 00 00 ¦ 00 00 00 00 00 00 00 00
