Фиктивный трек в Pre-gap подлинного трека
Размещение фиктивного трека в области Pre-gap области первого подлинного трека приводит к довольно интересным результатам, обсуждению которых не грех посвятить отдельныйую разделглаву. На первый взгляд такая защита полностью аналогична предыдущей, с той лишь разницей, что теперь исказиться адрес первого, а не второго треков. Да, это так, но лишь отчасти! Область Pre-gap первого трека —– особеннаяый. Мало того, что по стандарту она вообще не доступнаен для чтения (хотя некоторые приводы вроде бы ухитряются ееего читать), так еще и LBA-адрес еего начала измеряется отрицательным числом! Вспомним, что адреса LBA адреса связаны с абсолютными адресами следующим соотношением:
LBA = ((Min * 60) + Sec) * 75 + Frame – 150,
где 150 и есть sizeof(pre--gap).
Абсолютный стартовый адрес первого нормального трека по стандарту должен быть равен 00:02:00 (что соответствует LBA-адресу 0h), абсолютный стартовый адрес первой областиго Pre-gap —– 00:00:00 (что соответствует LBA-адресу –96h и –150 в десятичной нотации). Даже если разработчик копировщика использовал для хранения адресов знаковые переменные это все равно ничего не меняет, поскольку аргументы команд READ и READ CD всегда представляют собой беззнаковые числа! К тому же, размещение второго трека в области Post-gap'e первого приводит к тому, что стартовый адрес второго трека становится меньше стартового адреса первого трека, к чему подавляющее большинство копировщиков просто не готово.
Скопировать содержимое первой областиго Pre-gap (в которойм расположен фиктивный трек) —– нельзя, да, собственно, и не нужно. Но всякий ли копировщик об этом знает? Если только его разработчики заранее не предусмотрели обработку такой ситуации, копировщик в зависимости от типа используемой им адресации либо выдаст ошибку чтения (абсолютная адресация), либо совершит очень далекое перемещение головкой по "сумасшедшему" LBA-адресу (LBA-адресация без проверки корректности адресов), либо же просто не будет знать, что ему с этим отрицательным адресом делать (LBA-адресация с проверкой корректности адресов).
Забегая вперед, отметим, что с защитой данного типа (кодовое наименование "Шакал") способен справиться один лишь Clone CDCloneCD.
Используя файл IMAGE.CCD, оставшийся от предыдущих эксприменов с "лисой", давайте переместим начало фиктивного трека по абсолютному адресу 00:01:00, как это показано в листинге 6.16.ниже:
Листинг 6.16. Фиктивный трек в Post-gap подлинного трека, расположенный по адресу 00:01:00
[Entry 4]
Session=1
Point=0x02
ADR=0x01
Control=0x04
TrackNo=0
AMin=0
ASec=0
AFrame=0
ALBA=-150
Zero=0
PMin=00
PSec=01
PFrame=0
PLBA=-1
Листинг 8 фиктивный трек в post-gap подлинного трека, расположенный по адресу 00:01:00
При открытии отредактированного файла IMAGE.CCD, копировщик Clone CDCloneCD неправильно вычисляет длину первого трека (см. листинг 6.17 ниже), однако на "прожиге" болванкеи это обстоятельство никак не сказывается.
Листинг 6.17. CloneCD выдает неправильную информацию о длине первого трека
ИНФОРМАЦИЯ О СЕССИИ 1:
Размер сессии: 4726 Кбайт
Число треков: 2
Track 1: Данные Mode 1, размер: 4.294.967.124 Кбайт
Track 2: Данные Mode 1, размер: 4899 Кбайт
ИНФОРМАЦИЯ О СЕССИИ 2:
Размер сессии: 3939 Кбайт
Число треков: 1
Track 3: Data, размер: 3939 Кбайт
Листинг 9 Clone CD выдает неправильную информацию о длине первого трека
Проверка показывает, что защищенный таким способом диск, нормально читается на приводах NEC и TEAC, а ASUS "видит" лишь первый трек первой сессии диска, поэтому закладываться на вторую и все последующие сессии —– неразумно да и не безопасно для своего здоровья (разъяренные пользователи при случаи и побить могут).
При попытке скопировать защищенный диск шатными копировщиками, последние ведут себя довольно странно. Stopm Record Now! и Ahead Nero вообще отказываются читать такой диск, "ругаясь" на Invalid Disk и Imvalid Track Mode соотвественно.
Столкнувшись с фиктивным треком в области Pre-gap, Ahead Nero совершенно дезореентируется и при попытке определения геометрии диска впадает в грубые ошибки (см. рис. 6.9рис. 0x101). Ну, то что длина первого трека определяется неправльно —– это нас и не удивляет, но вот насколько же нужно быть "тупым", чтобы не суметь определить атрибуты всех остальных треков —– это уже интересно! Стартовый адрес второго трека, равный 3728:17:16 со всей своей очевидностью указывает на то, что в качестве базового типа адресации Ahead Nero использует беззнаковоые LBA-адреса, оперативно переводя их в MSF при необходимости. Поскольку, беззнаковый LBA-адрес начала второго трека представляет собой очень большое положительное число, разница между стартовым адресом Lead-outLead-Out и стартовым адресом фиктивного трека вновь оказывается отрицательна, что окончально запутывает Ahead Nero, приводя его к катострофически неверному результату. О причинах же неудачного определения типа третьего трека остается только гадать. Наверное, это как-то связано с неправильным определением количества сессий: Ahead Nero "увидел" всего лишь одну сессию из двух. Только не спрашивайте меня почему, я этого все равно не знаю, а обращаться за разьяснениями в службу технической поддержки мне лень, да и не подписывался я сообщать разработчикам о "ляпах" в их программе. Пускай лучше думают головой, чем гонятся за деньгами.
Рис. 6.9. унок 4 0x101 Ahead Nero, встретив фиктивный трек в Pre-gap подлинного трека запутался настолько, что не смог определить длину ни одного из треков и некорректно определил адрес второго — – фиктивного трека.
Попытка сканирования поверхности диска утилитой Ahead Nero CD Speed на предмет поиска повержденных секторов (~Extra à ScanDisk) приводит к тому, что окно программы просто "слетает". Тесты такие как "CPU Usage", "Spin Up/Dows" так же останавливается с сообщением об ошибке.
Таким образом, размещение фиктивного трека в области Post-gape'e подлинного трека может служить эффективным средстом борьбы с утилитами, определяющими качество диска, позволяя тем самым продавать дефективные диски под видом хороших. Нет, это отнюдь не призыв (за такое морды бить надо!). Напротив, это грустная констатация факта, что мир в котором мы живем, не иделен и доверять нельзя никому и ничему. Ладно, не будемт вдаваться в лирику, а лучше попробуем скопировать защищенный диск Alcohol 120%Алкоголиком.
Если только галочка флажок Попуск ошибок чтения [Y174] [n2k175] "попуск ошибок чтения" не была заблаговременно взведенаустановлен, то программа Alcohol 120%Алкоголик, прервав чтение диска на 13%, "невнятно ругнется" на "Illegal Mode For This Trak" и предложить удалить незавершенные файлы. Как бы сказал чЧучкча из анедота про оленей "Тенденция, однако!"
Чтение диска с пропуском ошибок так же не дает никакого результата. Достигнув сектора 2056 (предпоследний сектор в Post-gap подлинного трека), Alcohol 120% Алкоголик со всего маху "врзезается" в область Lead-outLead-Out широко "раскинув мозгами" (в смысле —– разбросав ихей по всей терриотрии).
